• I had a long conversation with our VMware SE (he's moved on to bigger and better things within VMware now) who I had a previous working relationship with long before he got to VMware. As a result, the discussion was quite candid. Lab Manager, speaking from a directory services administrator side (my primary job) is a nightmare to keep synchronized. The idea is great in concept: you have a nice little sandbox to play in that can't affect the outside world. It does this by effectively creating a snapshot in time. Meaning all changes in production have to be performed in the LabManager environment as well. That's duplicate work. And while I'm sure scripting could have been worked out using VMware's APIs and packages, um, no.

    In my current organization we treat VMs as physical servers, as another poster indicated. They are in with the "regular" servers. We do segment production and development into two forests, and there is some duplication of effort, but once a change is applied on the development side, it remains. Since Lab Manager is designed to be replicated and refreshed from a point in time over and over again, you have to look at applying changes every time you stand up the environment. So while there is duplication of effort with a separate forest, it is far less than going the Lab Manager route. In our case we use the development forest to test security models and then roll them forward to production, so we put up with the duplication of effort in order to facilitate the improvement in modeling we gain.

    K. Brian Kelley
    @kbriankelley