(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 (http://www.kouti.com/scripts.htm 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!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########