…unless there is no aspect of AD testing for the Dev/Test stuff. I.E. No testing of AD authentication, no testing of AD IDs, no testing of management of AD, either on purpose or as a side effect of the testing you really are doing, etc. For example, if you are testing a new version of an application, how do you know it won’t flood AD with auth requests for an AD ID? How do you know you won’t need to troubleshoot at the AD level like with network sniffing or something? You don’t.
However, if you are testing an application on a member server and that application has nothing to do with AD (local IDs and groups, etc), go for it, but add that dev or test server to the production forest in a DEV/TEST OU. You don’t need a domain. If you think you need a domain, then you are possibly thinking that there exists some sort of boundaries between domains in a forest that do not really exist.
To put it another way. If I were a domain admin for an environment, I would be the domain admin for every domain in the forest in that environment. I would not allow anyone not on my team to have access to any DC in the forest, regardless of whether someone thought it was a Dev or Test Domain because it would still be a production forest domain and hence, production.
If you do not have a formal Dev/Test environment, meaning an entirely separate forest or forests, then in actuality, you have no production environment regardless of what you want to call it – you only have a lab environment and well, don’t expect production availability and stability out of a test/lab environment.
For those in the know, they realize I am paraphrasing something said by one of the father’s of Active Directory – Mr. AD – Don Hacherl on the ActiveDir Org list (Friday, February 20, 2009 4:08 PM) that I previously quoted on this blog (http://blog.joeware.net/2009/03/11/1623/).
I have to make a comment here, as I’ve heard this too many times. You do, in fact, have a lab environment. What you do not have is a production environment.
DonH
joe
