Extending the AD schema to support either a new OS release or Active Directory (AD)-integrated applications that require it (e.g., Exchange Server) is a regular—if infrequent—administrative task. And these kinds of schema upgrades have always made AD administrators nervous. It's not because admins have personal experience with schema upgrades gone bad; if you ask 500 AD admins if they've personally had a bad schema-upgrade experience, 499 of them will admit they haven't. What makes AD admins wary is the fact that upgrading the AD schema can be confusing, and it's irreversible. Anything that affects the entire Windows authentication and authorization infrastructure, and has no "undo" button, is a process to be careful about. (See also, "Windows Server 2012 Active Directory Moves Forward " and " Virtualization-Safe Active Directory in Windows Server 2012").
Schema upgrades aren’t bothersome only to AD admins; they also irritate Microsoft's Customer Support Services (CSS), because confusion about the process is a high call generator. Further, adoption of many new AD-related and other features in a new OS was demonstrably slower if the feature depended on a schema upgrade because of the care (and resulting delay) associated with the process. As a result, one of the AD product group's goals for Windows Server 2012 was to make the process simpler, faster, and generally more pain-free than in previous versions. With Server 2012, Adprep has been integrated into the Active Directory Domain Services (AD DS) role installation process.
Adprep is the utility—included in the OS installation media—that performs several crucial functions to upgrade AD to support that OS. The utility has three major options: /forestprep, /domainprep, and /rodcprep. The /forestprep option runs first, extending the AD schema with new object and attribute classes that the new AD version needs. The /domainprep option creates new well-known objects in AD, applies security changes, and miscellaneous other bits. Finally, /rodcprep makes forest-wide security changes to allow read-only domain controller (RODC) functionality.
Adprep from Server Manager
The screenshot gallery in my article “ Upgrading Active Directory to Windows Server 2012” shows a Windows Server 2008 R2 forest being upgraded to Server 2012 with integrated Adprep and the subsequent promotion of the local DC from Server 2008 R2 to Server 2012. AD admins who didn't pay close attention to the documentation or who didn’t read this article will be in for a big surprise, as the Forestprep and domain preparation happens automatically as a result of initiating a Server 2012 DC installation—not beforehand, and with no warning at all. (See image #14 in the screenshot gallery.) This means that if one of your administrators gets the idea to put a Server 2012 DC into a domain, before you know it Adprep will have run its course. So much for careful planning! The other way to view it, of course, is that smaller shops won't have to worry about it.
Adprep from the Command Line
Fear not, you old-school AD admins; you can still run Adprep manually from the \support\adprep folder of the Server 2012 installation disk, if you need to. But a difference from older Adprep versions is that there's no 32-bit version (Adprep32) of the utility. So, you can run Adprep only from a 64-bit version of Server 2008 or later.
You don't have to run Adprep from the schema master, but the Server 2012 server you're running the upgrade from (it doesn't have to be a DC) must have connectivity to the forest's schema master and the domain's infrastructure master. You can now also specify separate credentials for Adprep /forestprep (Enterprise Admins membership) or /domainprep or /rodcprep (Domain Admins membership) using the /user and /userdomain parameters. This gives you a great degree of flexibility in how you upgrade your forest and domains.
The Death of Dcpromo
And even Dcpromo itself has disappeared. (If you try to run it, a dialog box appears, stating The Active Directory Domain Services Installation Wizard is relocated in Server Manager, and points you to a Technet article on how to install AD DS.) As the dialog box tells us, the process of installing the AD DS role on a server—thus making it a DC—has been moved to Server Manager. This is more than just a cosmetic move; the AD DS installation process has been completely re-engineered from the ground up. To make it less susceptible to errors, the process does a number of prerequisite checks before the promotion process ever begins, and either attempts to fix configuration errors or displays a message (in clear language, not developer-ese) describing the failure and suggesting steps to correct it. As with all other administrative tasks in Server 2012, everything you can do in the GUI can be done in PowerShell and vice versa. And you can export a PowerShell script that contains all the options you specified during the GUI installation, so you can reuse it on other DCs in your domain.
Every aspect of the Server 2012 DC installation and AD upgrade process has been examined and redesigned to be as seamless and low-effort as possible. In general, this is a very good thing; just be aware that it's so smooth and seamless that you'll need to guard against an unplanned forest and domain upgrade!
Sean writes about cloud identity, Microsoft hybrid identity, and whatever else he finds interesting at his blog on Enterprise Identity and on Twitter at @shorinsean.
