Considerations when upgrading your Active Directory to Windows Server 2008 and 2008 R2
While upgrading your Active Directory Domain Controllers, Domain Functional Level(s) and Forest Functional Level to Windows Server 2008 and Windows Server 2008 R2 offer additional functionality compared to previous versions, also a couple of caveats exist, that I think you should be aware of.
In this blogpost:
NT 4.0 Compatible Encryption
Windows Server 2008 and Windows Server 2008 R2 Domain Controllers have a new more secure default for the security settings named “Allow cryptographic algorithms compatible with Windows NT 4.0”.
When you promote a server to a Domain Controller, a screen containing this message is displayed, right after the Welcome screen:
This policy is configured to prevent Windows operating systems and third-party clients from using weak cryptography algorithms to establish NETLOGON security channels to Windows Server 2008-based domain controllers.
While this does not seem like a big deal, it might be in the light of the Active Directory Migration Tool (ADMT). Without the ability to build a trust between the source and target domain, one cannot migrate objects from a Windows NT4 domain. You never hope to encounter a Windows NT 4.0 environment in a merger, acquisition, or divestiture situation, but one can never be sure…
Also, you may experience problems in environments merely containing Windows Server 2008 and Windows Server 2008 R2 Domain Controllers when you configure pre-Windows Vista SP1 clients to join the domain though Windows Deployment Services or the Microsoft Deployment Toolkit (MDT). For Windows XP and Windows Server 2003 an update is available to correct this problem.
Now, of course, not migrating to Windows Server 2008 (R2) is a bit excessive. When you’re running into problems and don’t mind the loosened security settings, you can always (temporarily) turn on the “Allow cryptographic algorithms compatible with Windows NT 4.0” setting on every Windows Server 2008 and Windows Server 2008 R2 you need it. Perform the following steps:
- Log on to a Windows Server 2008-based or Windows Server 2008 R2-based Domain Controller.
- Click Start, click Run, type gpmc.msc, and then click OK.
- In the Group Policy Management console, expand Forest: DomainName, expand DomainName, expand Domain Controllers, right-click Default Domain Controllers Policy, and then click Edit.
- In the Group Policy Management Editor console, expand Computer Configuration, expand Policies, expand Administrative Templates, expand System, click Net Logon, and then double-click Allow cryptography algorithms compatible with Windows NT 4.0.
- In the Properties dialog box, click the Enabled option, and then click OK.
After this step restart the netlogon service.
When you want to put the new default security settings into effect, perform the same steps, but click the Disabled option in step 5.
Going 64 (bit)
Windows Server 2008 R2 is only available in 64bit flavors. So, when transitioning from 32bit Domain Controllers to 64bit Domain Controllers, you’re bound to encounter some interesting challenges.
The first challenge is to prepare your Active Directory environment for Windows Server 2008 or Windows Server 2008 R2. To prepare an Active Directory environment for newer Domain Controllers, you’d run adprep.exe on the Domain Controller running the Primary Domain Controller emulator (PDCe) Flexible Single Master Operations (FSMO) role.
However, when preparing your 32bit Windows Server 2003 (R2) Active Directory environment for Windows Server 2008 x64-based Domain Controllers, you’d need to run the adprep.exe from the Windows Server 2008 x86 DVD. Luckily, the adprep.exe on the trial DVD will suffice for this purpose.
Preparing a 32bit Windows Server 2003 (R2) or Windows Server 2008 Active Directory environment for Windows Server 2008 R2 is a different story. You’ll need to run adprep32.exe in this case. It is located on the Windows Server 2008 R2 DVD in the same folder as adprep.exe. (This version of adprep.exe is x64 only.)
Also, when deploying Windows Server 2008 R2 Domain Controller, you should first check whether all the tools and programs you’re using in the current environment are 64bit- and Windows Server 2008 R2 ready. This includes anti-malware protection software, backup software, software for managing and responding to Uninterruptible Power Supply events, 3rd party management tools, and monitoring tools.
Getting acquainted with the Command-line
When migrating to Windows Server 2008 and Windows Server 2008 R2-based Domain Controllers and their respective Domain and Forest Functional Levels, prepare for some command-line stuff.
First off, to check for proper replication of the Active Directory preparation you can’t use the graphical replmon.exe tool. This tool is no longer available. Instead, you’ll need to use the command-line repadmin.exe tool.
Furthermore, most of the more advanced features, available when using Windows Server 2008 and Windows Server 2008 R2-based Domain Controllers and the Windows Server 2008 and Windows Server 2008 R2 Functional Levels, is only available on the command-line.
For instance, compacting your Active Directory database(s), managing fine-grained password policies, working with Active Directory snapshots, offline domain join, creating IFM media with SYSVOLs, enabling and using the Active Directory recycle bin and managing Managed Service Accounts (MSAs) is only available on the command-line (when using only built-in tools).
Read the series:
Limited ways to migrate to 2008 R2
While this blogpost was written, no suitable version of the Active Directory Migration Tool (ADMT) existed to restructure Active Directory environments to Windows Server 2008 R2.
Restructuring is one of three ways to migrate to a next version of Windows Servers as Domain Controllers. In-place upgrading and transitioning are the other two ways. With in-place upgrading a next version of Windows Server is used to upgrade a Domain Controller directly without reinstalling. Transitioning means adding additional Domain Controllers with a new version of Windows Server, side by side to existing Domain Controllers with the purpose of phasing out the old Domain Controllers.
When you want to restructure your Active Directory to Windows Server 2008 R2 you will either need to wait for the Active Directory Migration Tool (ADMT) version 3.2, or restructure to an Active Directory infrastructure, based upon Windows Server 2008 Domain Controllers and in-place upgrade or transition to Windows Server 2008 R2 Domain Controllers from there.
Deploying Server Core Domain Controllers
Server Core installations are optimized installations of Windows Server. This installation option was introduced with Windows Server 2008.
While Server Core Domain Controller are highly optimized, they also pose a problem when you’re mixing Windows Server 2008-based Server Core Domain Controllers, Windows Server 2008 R2-based Server Core Domain Controllers and the new Active Directory Administrative Center. (ADAC)
The Active Directory Administrative Center (ADAC) uses the Active Directory Web Service to communicate with Active Directory Domain Controllers. This service runs on top of the .Net framework.
The problem is Windows Server 2008-based Server Core Domain Controllers, don’t support the .Net framework. Therefore, you can’t use the Active Directory Administrative Center to manage these Domain Controllers. Of course, Windows Server 2008 R2-based Domain Controllers will still replicate changes, but your Domain Controllers will not be equal, which leads to a suboptimal management experience (over time).
Another difference between Server Core installations of Windows Server 2008 and Windows Server 2008 R2, is the different management tools available. Where Windows Server 2008 offers the ocsetup.exe and oclist.exe tools, Windows Server 2008 R2 offers dism.exe, which is more powerful.
Read more in: Some Server Core Domain Controllers heading for a dead end street
Virtualizing Domain Controllers
Hyper-V is a new server role, introduced in Windows Server 2008. Along with Hyper-V, the Server Virtualization Validation Program (SVVP) came to life. Virtualization was already a hot topic in many enterprises by that time, but the popularity of virtualizing the datacenter rose further.
While virtualized Domain Controllers (whether they’re Server Core or Full installations) offer significant benefits in terms of flexibility, scalability and disaster recovery, they’re also the heart of the infrastructure and should be deployed wisely.
Therefore, follow these best practices when virtualizing Domain Controllers using Hyper-V clusters:
- Deploy at least two Domain Controllers per domain and keep one physically deployed Domain Controller per domain;
- Apply minimum patchlevels;
(specific hotfixes exist for Windows 2000 Server and Windows Server 2003)
- Install the Integration components;
- Provide adequate Time Synchronization;
- Never save state or pause a Domain Controller;
- Don't use undo disks, differencing disks or snapshots;
- Backup and restore Domain Controllers the right way;
- Use Fixed-Sized VHDs;
- Use different disks for Active Directory files;
- Use Sysprep.exe instead of NewSID.exe;
- Don’t make your Domain Controllers highly available within Hyper-V;
(use Hyper-V R2 when you want to make your Domain Controllers highly available)
- Secure your virtual Domain Controllers like you would physical Domain Controllers, but at a minimum use syskey.exe in virtualized Domain Controllers;
- Perform Offline P2V Migrations when virtualizing an existing Domain Controllers;
- Don’t perform storage migrations on live Domain Controllers.
Read the series: