Then there is the question of how to migrate those users and computers to the clean environment. Are there any best practices that you could share? Typically, when you migrate, there are a lot of setting changes. You also have to deal with moving objects from the old environment to the new. This should be done with minimal user intervention or disruption. You can use built-in utilities. Microsoft provides its Active Directory Migration...
Tool, which lets you migrate user accounts, computer accounts, and there are also other features like password migration and having a desktop reboot on its own with the new version in Windows Server 2003. This tool greatly minimizes user intervention. The administrator can do it remotely so he doesn't have to touch every machine. There are also scripts available to help with these tasks.
I can't stress enough, though, that before you migrate, there should be lab testing. You should mimic your own environment in a lab. Also, make sure your production environment is backed up. This doesn't mean just backing up your servers. Get successful backups and test them. Go through the restore process on a lab server. Organizations can't afford to find out at the last minute that their "successful" backup strategy is actually taking them a week to restore critical data.
FOR MORE INFORMATION:
Learning guide: Planning and designing your Active Directory
Learning guide: Managing your Active Directory
Expert advice: Top 5 Active Directory migration tipsIf you are starting with a fresh Active Directory environment, do you have to consider all new hardware?
New hardware should always be a consideration for a migration or upgrade. Do you have new or fairly new hardware within the last year? How are the servers performing now? If you do and you meet the recommended requirements that Microsoft requests and performance hasn't been an issue, then you are probably OK to do an in-place upgrade. But if you want to start fresh, you may want new hardware to have a very clean environment. It may be a matter of replacing some hardware but not all of it. Does a placeholder root domain design assist with other administrative roles in the environment?
You'll typically have different sets of administrators managing an environment. Whether they are senior, or network engineers, they are at different levels. Some just manage user accounts. Others manage back-end server infrastructure and require additional rights. They need access to specific servers or services. There are developers that need to access to the schema for developing applications, and sometimes to servers at an administration level. You try to segment those groups from a security rights perspective.
The roles can be segmented through administrative delegation, groups and separate domains with Windows 2000 or Windows Server 2003. It's no longer an all -- with keys to the kingdom – or nothing approach.
When you've determining who should have access to the enterprise admins and schema admins groups, just select two or three experts. If you have two IT-related groups that are autonomous, select someone from each group. The real point is you must limit that access. You can then give domain admin rights to select individuals on a per-domain level rather than giving them rights to everything in the forest. How does the placeholder domain scenario assist with security?
One reason is that the placeholder root domain contains and segments two special groups by default -- enterprise admins and schema admins. The enterprise admins have full control over all domain controllers while the schema admins is a group that has control over the AD schema. This is important because many applications, like Exchange Server, modify the schema. The schema defines what directory objects look and act like. Breaking these groups apart helps protect the schema from careless changes and also prevents anyone from installing an application that requires schema modifications. Where do most IT professionals make their first mistakes when they are building an Active Directory?
Most organizations get tripped up with the design. At the high level, they need to review the design and make sure the team role is defined. Build a lab mimicking the production environment. I've seen organizations use a third-party tool and then they might practice on a few machines, but they don't do any [testing] with real data from their own environment. What aspect of Active Directory design is most critical to review before moving forward?
Microsoft has up until somewhat recently promoted a single domain, single forest directory structure. From a technical standpoint, about 60% can probably get away with a single domain/forest. However, there are a lot of political things that can happen as well: a merger, for example, that can cause a company to change its name. If an organization uses a placeholder root domain, there is greater flexibility and greater security. You can bring up a peer-root domain and it can be named anything the company wants. Name changes, security, etc. will be a lot simpler and more effective than creating a new directory structure. The placeholder root should only contain domain controllers while other domains can be built to house user accounts, computer accounts, etc. How do you determine if you should build from what you already have in place, or if you should construct a new Active Directory environment from scratch?
You need to assess the state of your current environment. It's a difficult question for most organizations to answer. Some think that if things are running OK, they do an in-place upgrade without any problems. That gets a lot of organizations in trouble.
So it might be good to do a brief, internal audit or have a third party do one. You may discover that it's worth it to build a fresh, new environment.