As I understand there are 2 methods to upgrade AD to a newer version (let's say from 2003/2008 to 2008R2): either by adding new DCs/performing in-place upgrade of existing DCs and migration to the new forest/domain with ADMT. Latest option guarantees that your schema will be clean and you starting afresh, but it is more difficult & potentailly disruptive for environment.

My question is how can I test (apart from standatd DCDIAG) or what should I check to be sure that in place upgrade w/o domain/forest migration is OK for me & that I won't bring any problems/issues from legacy environment in upgraded one? Something that can justify AD upgrade through migration to new domain/forest apart from need consolidate names & teorethical concerns about legacy AD schema?


There's no "stock" reason to have to upgrade your domain via migration to a new one. You might do it if you need to change domain names and are running Exchange (thus domain rename is not available), or if you've actually broken AD in some way that's not repairable. The latter is very unlikely. Changing the schema back to the stock one is a potentially valid reason, I suppose, but it wouldn't affect most domains.

Unless you know that you need to change your domain name or schema, just add new DCs of the proper version, retire the old ones, and upgrade your functional levels if desired.


If this is really worth your time do it (as a test) first and see if the results and amount of work meet your expectations. Migrating to a new forest is not a trivial task.

One driver for going for a clean installation is the existing directory has undergone a period of "unstructured evolution", where there has been changes that were not documented properly.

This. It's like re factoring code.

If your current forest is healthy (no errors in the Replication/Directory Service logs, dcdiag /e /i looks clean and you don't know there is a problem you are probably best off sticking with your existing directory.


How can you check? Make a backup copy of a couple of production domain controllers, restore it to a test environment that is not accessible to/from your production Active Directory network (important), perform the update (adprep and dcpromo), and perform your validations. This could be as simple as setting up vms on your notebook. Suffice it to say that you would eventually need to do have an offline test environment anyway before proceeding with a production upgrade.

If there was something installed that updated the schema that you want to remove, you usually are aware of it, as there may be attributes on the various objects (User/Group/Computer/OU) that are no longer required.

One driver for going for a clean installation is the existing directory has undergone a period of "unstructured evolution", where there has been changes that were not documented properly. Another driver is if you cannot risk anything going sideways with the update and cannot backout.

One area of concern when adding the first uplevel domain controller may be if you have a large directory and/or a lot of domains, whenever you perform a schema update (using adprep /forestprep), all of the global catalog partitions are rebuilt. This may take a very long time. This also applies to other large schema updates such as for Exchange.

If you have an existing domain that started as Windows 2003 and have not yet enabled strict replication, you should enable that now, to surface any bogus objects in the directory, so it is not associated with the upgrade. You can read more about that here:

Enable strict replication consistency

If there are lingering objects in the directory, enabling strict may cause replication to stop, so those objects need to be dealt with before any upgrade. If there are a lot of these objects surfaced, it may be time to consider the clean installation approach.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.