Jorge's Quest For Knowledge!

All About Identity And Security On-Premises And In The Cloud – It's Just Like An Addiction, The More You Have, The More You Want To Have!

(2005-11-20) Considerations When Creating An AD Test Environment – Part 2

Posted by Jorge on 2005-11-20

When you are part of an AD forest and being in one of the child domains, it may also be important you keep track of forest wide update made by the forest root domain owners/admins. For this to work those owners/admins should notify you when changes occur in the schema and/or configuration partition.

After you have taken care issues mentioned earlier, the question remains on how to mirror the productie environment…

Assuming you are creating a test environment that will not have any connection to the production environment, a model should be made of the production environment to create the test environment. Create the same domains, with the same DC names and IP addresses.

To create the AD environment when concerning the different types of objects the following is possible:
* Configuring Sites, subnets, site links and their properties
–> Export from the production env. into the test env. using LDIFDE. remember that not all attributes should be exported. Also remember that each forest/domain contains default objects!
* Configuring OUs, GPOs , groups, users, object-links (e.g. group memberships) and their properties
–> Export from the production env. into the test env. using the GPMC scripts "CreateXMLFromEnvironment.wsf" en "CreateEnvironmentFromXML.wsf" en "CreateMigrationTable.wsf"
–> As the GPMC scripts do not export all the objects and attributes, you might need to additionally export information from the production env. into the test env. using LDIFDE. remember that not all attributes should be exported. As object already exist some of the operations need to be modified from ADD to MODIFY in the output file of LDIFDE
* Configuring delegations on containers (OUs)
–> To read the configured delegations you cound use the script "ACLReport.vbs" from Sakari Kouti ( at the end of the page). After reading, filtering out the default permissions and tweaking the file it may be possible to add it into the test env. using DSACLS

After the test environment is setup you need to think about change management. With this I mean: How are you going to make sure the test environment is kept up to date with changes in the production env.?
Especially when using the DTAP model (development, testing, acceptation, production), IMHO changes should be implemented in a automated way and with this I mean using scripts, batches or whatever. If possible and when having a good balance between "spending time creating the scripts/batches" and "spending time implementing the changes" (in the different stages) this will save you tons of time when doing the test for the Xth time and the chances are much smaller of making errors. IMHO to make sure a test env. is always up to date and ready for use for someone to use it for testing purposes, make sure someone is responsible for it. This hopefully prevents that when someone wants to do some tests, that someone first needs to cleanup/setup the test env. environment. Also make sure some reservation schedule exists so that people can make reservation for the use of the test environment.

* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
############### Jorge’s Quest For Knowledge #############
######### ########


3 Responses to “(2005-11-20) Considerations When Creating An AD Test Environment – Part 2”

  1. Hello Jorge.

    As usual, good thread ! 🙂

    I found this link on , that seems to be an other method of building an AD lab test. What is your opinion ? Not to compare your opinion to Tony Murray’s, but i’d like to have your advice.
    Tony Murray’s strategy seems to be fast and easy without having to use LDIFDE, CreateEnvironmentFromXML.wsf" etc….
    So what are the PROs and CONs that you may think of ?




  2. Jorge said

    Hi Yann,

    Both methods are possible options.

    When comparing both options: "clone" vs "rebuild"
    * Fast
    * Best copy from production
    * Security (Tony does not mention his remark for nothing!)

    * Very very very limited security issues (because of structure and samaccounts, although SIDs are different)
    * Slow
    * Might need additional work in some situations (e.g. permissioning)

    This is a quick and dirty comparisson between both options. It depends (the IT answer!) what the requirements are short-term and long-term.



  3. […] (2005-11-20) Considerations When Creating An AD Test Environment – Part 2 […]


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: