We
have a couple of test labs like Rick. Officially one for Exchange, one for other
stuff.
I
would like to see one global dev forest (or maybe better termed Production QA)
and have been pushing in that way so that the cost is spread out across several
divisions and also so the number of DC's can be significant as well as the sites
and subnets involved. I.E. Make it more like production. I would visualize
primary support by a couple of team members that rotate in and out of the main
production support team. I.E. The two teams have rotation. Keeps people from
burning out and keeps dev looking like prod. Would also be a good training
ground for new admins since we have a 2-3 month spin up time for new admins
before we give them Domain Admin Keys. This is still not truly enough time. The
SLA of that would be business hours of the location in the world that the team
exists at which in our case would be the US.
The
Exchange Test Lab Domain Controllers are controlled by the folks in Production
(my team) though we give out more rights in the lab for the lab folks -
basically Account Operator.
When
we do Schema Tests we spin up a growth from production. I.E. We promo some DC's
for each domain from production, then chop them off from the real network and
then cut the references out of production. And cut the references to production
out of the "lifeboat" lab. This way we can do testing on real data and the real
environment. The future of this lies somewhere in Virtual Server so we don't
have to cut the machines out of production, we will simply have a single DC for
every domain sitting in a virtual server session and copy the session files
occasionally to a dark network lab.
The
Exchange lab has all of the user objects and most of the domains. It is missing
the data center application domain as it has no bearing on
exchange.
The
other testing lab has some random number of users.
The
lifeboat lab is a mirror of production in terms of objects, just doesn't have
the real subnet coverage and site coverage and number of
DC's.
The
Exchange lab since it is controlled by me has a business hours SLA unless
someone is really under a time crunch and then they will sweet talk me into
hanging around. The other test lab is business hours and probably best effort.
There
are things that are not caught in Dev, you will never catch everything there,
but it is better than catching everything in production. It is especially useful
for doing things like turning up logging or doing network tracing since you can
control the traffic more easily.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of StickmanRunner87
Sent: Saturday, October 25, 2003 2:18 PM
To: [EMAIL PROTECTED]
Hello!
BACKGROUND
Recently, our Active Directory Team was asked
by executive management to implement
a development forest that very much mimics our production forest in many
ways. However, many of us struggle with this request because we're afraid
a development forest will incur more work and cost than
benefit.
QUESTIONS
Do you have a
development (DEV) forest?
If yes,
- How does DEV's size compare to PROD in terms of users, computers, domain controllers, domains, sites, gpo's?
- Do DEV admins support PROD too?
- How does DEV's SLA compare to PROD?
- How has DEV added-value to your company? Any stories to share?
- How current is DEV compared to PROD? Identical, one schema version behind, etc.?
- How does DEV's change control practices compare to PROD?
If no,
- Is there a specific reason why you don't have a DEV forest?
- Did you have a DEV forest previously and tear it down?
- Are you considering a DEV forest at the present time?
I appreciate any feedback you can share with me. If you would prefer to discuss in a telephone call, I'm willing to "phone a friend."
Sincerely,
Stick
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
