We're helping a company that really doesn't have a Production AD..
they call it that, but its technically a test AD, if you catch my
No seriously though.. these guys want to get in the right and get to
standing up a real Dev/Test AD environment that is sort of close to
their "production", however have many questions. Some of which I'm
trying to help answer..
First off.. what to most of you here do with this concept of a Dev AD?
- Is the smart thing to do to stand up a totally separate forest and
create no trusts between them? If so how do most keep the two in
sync or provide a means for devs/users to login without having to
remember multiple passwords? Or better yet, how do we not increase
the admin burden with having to manage two stores.
- How close to Production is good enough?? They have 1 primary
forest, that contains the empty root and 1 child.. these two domains
comprise of about 75 DCs.. Majority branch offices.. I would imagine
the Dev AD should be at least the same forest structure.. but how
many DCs is "suitable" to provide a decent Dev environment?
- What would be the best way to start construction of this.. build
from scratch then find a way to import users/etc.. (better question,
whats the best way to import if domain names, etc are not the same)..
OR do we take a backup of production and build from there chopping off
pieces we dont need..
I hope this helps gets it started as I have a ton of questions.. I
appreciate any feedback you can provide..
Development AD, Production AD.. potato potAto..
- 1.7K Views
- Last Post 16 February 2011
We're helping a company that really doesn't have a Production AD..
Thanks for the suggestion Alpesh. Looking at it now on the Technet site. It looks promising.
GPMC scrips are the best tools so far. Research more on "createxmlfromenvironment.wsf" and you will know more. Tons of articles on technet. Sorry for being a bit lazy. Typing on iPhone sucks.
Sent from my iPhone
On Feb 15, 2011, at 11:04 PM, Ted Osheroff <Ted.Osheroff@lucasfilm.com> wrote:
> Does anyone have any detailed instructions or a blog post for syncing a dev environment with the production one? I’m assuming the dev one would be in its own forest? I would like to set up a dev one on a VM.
> Thank you,
> -Ted Osheroff
Does anyone have any detailed instructions or a blog post for syncing a dev environment with the production one? I'm assuming the dev one would be in its own forest? I would like to set up a dev one on a VM.
That is the way I've done it in the past. Find it easier than keeping the two in sync
United Kingdom: +44 1285 658542
South Africa: +27 11 252 1100
Swaziland: +268 442 7000
Fax:+27 11 974 7130
Mobile: +2783 306 0019
This email message (including attachments) contains information which may be confidential and/or legally privileged. Unless you are the intended recipient, you may not use, copy or disclose to anyone the message or any information contained in the message or from any attachments that were sent with this email, and If you have received this email message in error, please advise the sender by email, and delete the message. Unauthorised disclosure and/or use of information contained in this email may result in civil and criminal liability. Everything in this e-mail and attachments relating to the official business of Peterstow Aquapower is proprietary to the company.
Caution should be observed in placing any reliance upon any information contained in this e-mail, which is not intended to be a representation or inducement to make any decision in relation to Peterstow Aquapower. Any decision taken based on the information provided in this e-mail, should only be made after consultation with appropriate legal, regulatory, tax, technical, business, investment, financial, and accounting advisors. Neither the sender of the e-mail, nor Peterstow Aquapower shall be liable to any party for any direct, indirect or consequential damages, including, without limitation, loss of profit, interruption of business or loss of information, data or software or otherwise.
The e-mail address of the sender may not be used, copied, sold, disclosed or incorporated into any database or mailing list for spamming and/or other marketing purposes without the prior consent of Peterstow Aquapower.
No warranties are created or implied that an employee of Peterstow Aquapower and/or a contractor of Peterstow Aquapower is authorized to create and send this e-mail.
I like the "through away" environments a lot.
Yes, we do maintain a "permanent" test environment (which we rebuild every
so often as tends to drift over time), but for any sizable testing I like
to bring up a new environment, sync it with prod, complete testing and get
rid of it.
Thank you, Tony.
Aon Hewitt | Enterprise Architecture
MCITP:EA, Windows 2003 & 2000 MCSE, Windows 2003 MCSA, PMP
tel 847.295.5000 x37892
tony dot gordon at aonhewitt dot tld | www.aonhewitt.com
P Please consider the environment before printing this e-mail.
Agreed. It really depends on the cost involved, the management buy in (to dedicate resources to a non prod environment) and so on. I've worked in a set of Forests that the others have described, but in more recent roles I have struggled to even sell the benefits of having these environments, let alone spend time on them.
If you want to be a proactive, well organised shop with a valid "production like" test environment, it is gonna cost time and money. And those are the two hardest things to find in my experience...!
Sent from my iPad
On 11 Feb 2011, at 06:36, "Gil Kirkpatrick" <Gil.Kirkpatrick@quest.com> wrote:
> The better-organized IT shops I've worked with have dev (sometimes more than one), test, and production forests.
> The dev forest is completely isolated from everything else except the dev PCs and servers. It's usually up to the devs to manage.
> The test forest mirrors the production forest as far as domain/OU/container structure, but only a representative number of sites and site links. The GPs are the kept in sync. There are no trusts between test and production, and the IT staff manages the test forest. I've seen various ways of keeping them sync'd, including scripts, LDIF, and ILM/FIM. There are typically half a dozen or so servers in the test environment (virtual) running the various critical apps, and a handful of virtualized desktops as well. The change control process for the test forest mirrors the production change control process.
The better-organized IT shops I've worked with have dev (sometimes more than one), test, and production forests.
The dev forest is completely isolated from everything else except the dev PCs and servers. It's usually up to the devs to manage.
The test forest mirrors the production forest as far as domain/OU/container structure, but only a representative number of sites and site links. The GPs are the kept in sync. There are no trusts between test and production, and the IT staff manages the test forest. I've seen various ways of keeping them sync'd, including scripts, LDIF, and ILM/FIM. There are typically half a dozen or so servers in the test environment (virtual) running the various critical apps, and a handful of virtualized desktops as well. The change control process for the test forest mirrors the production change control process.
What we've always had here is three forests - Production, User-acceptance, and Development. When appropriate there is also a "Beta" forest running whichever version of Windows Server is in Beta (Speaking of which, isn't it about time for another one?)
UAT is kept to the same domain structure as production, but is only in one site with only 2 DCs/domain (all virtual machines). Given that you have a lot more sites, you might want a bit more than that.
DEV is only 2 domains (root and child) with 2 DCs each (all virtual machines)
As for keeping things in sync, the production AD is fed by a production IdM system and the UAT is fed by a UAT IdM system.
DEV, when it is fed at all, is fed by doing an LDIF dump of production. The LDIF file is run through a process to change the domain names and scrub the personal data, then imported
There are no trusts between the forests.
Passwords are not allowed to be the same in the 3 forests.
Yes all this makes for more overhead, but as DEV environments are where people tend to get sloppy about security (especially non-IT folks) it'll help you get sleep at nights.