In-Place Active Directory Upgrade to Windows Server 2012 R2 Standard: Detailed Steps

In June 2024, I undertook the task of upgrading one of our core Active Directory (AD) servers from Windows Server 2008 R2 to Windows Server 2012 R2 Standard. This was the second attempt after the initial upgrade failed. While our original plan was to migrate to Windows Server 2016, time constraints led us to stick with Server 2012 R2 for this upgrade cycle.
The existing environment consisted of:

ServerA: Running Windows 2008 R2 (primary AD server to be upgraded)
ServerB: Windows 2012 R2 (upgraded in a previous session)
ServerC: Windows 2012 R2 (upgraded in a previous session)

The servers were hosted on different Hyper-V hosts, with ServerA on Host1, ServerB on Host2 (part of a clustered Hyper-V setup), and ServerC on Host3 (a standalone Hyper-V server).

Here are the detailed steps I followed for the in-place upgrade:

Rebooted ServerA, ServerB, and ServerC in sequence and took full system snapshots of each.
On a ServerA, ran ‘netdom query fsmo’ to identify the FSMO role holders. Transferred all FSMO roles from ServerA to ServerB using ‘ntdsutil’ commands.
Backed up certificates and removed the Certification Authority (CA) from ServerA, as this is a prerequisite for the OS upgrade path.
Uninstalled the antivirus software (SEP) on ServerA and rebooted.
Took another round of snapshots for all three servers.
Initiated the in-place upgrade process on ServerA to install Windows Server 2012 R2 Standard. This failed after multiple attempts.
Investigated the issue and found that migrating ServerA to a different Hyper-V host resolved the problem. The upgrade then completed successfully.
Activated the KMS license and rebooted ServerA.
Using ‘ntdsutil’ again, transferred the FSMO roles back to ServerA and thoroughly tested all three server roles.
Installed the Active Directory Certificate Services (AD CS) role and loaded the required certificates.
Rebooted ServerA, verified all services were running correctly, and took a final snapshot.
Installed the latest patch updates on ServerA, ServerB, and ServerC.

With this process, all three AD servers are now running Windows Server 2012 R2 Standard, having overcome the initial failed upgrade hurdles on the primary domain controller.
While this was a lengthy process, following the recommended steps and being persistent in troubleshooting the issues eventually led to a successful outcome. For anyone undertaking a similar in-place AD upgrade, be sure to have proper backups, transfer FSMO roles during the process, and be prepared to try different steps (like migrating to a new host) if the initial upgrade fails.

How to Transfer FSMO Roles in Active Directory

The Flexible Single Master Operation (FSMO) roles in Active Directory are a set of five critical operations that must be handled by a single domain controller at any given time. These roles ensure the consistency and integrity of the Active Directory database.

Sometimes, you may need to transfer one or more of these FSMO roles to another domain controller. For example, if you’re decommissioning an old domain controller that currently holds FSMO roles, or if you want to redistribute the roles for load balancing purposes.

To check which domain controller currently holds the FSMO roles, you can use the netdom query fsmo command. This will list the current role holders.

To transfer the roles, you’ll use the ntdsutil command-line utility along with the roles and connections options. Here are the steps:

Open a command prompt on the domain controller you want to transfer the roles to.
Run ntdsutil to start the utility.
Run roles to enter the roles context.
Run connections to switch to the connections context.
Run connect to server servername.domain.com to specify the remote domain controller you want to transfer roles from.
Run quit to go back up a level.
For each role you want to transfer, run one of the following commands:
- transfer infrastructure master
- transfer naming master
- transfer PDC
- transfer RID master
- transfer schema master
Run quit again to exit ntdsutil.

Finally, run netdom query fsmo again to verify that the roles have been transferred successfully.

It’s important to carefully plan any FSMO role transfers, as they can impact Active Directory operations if not done correctly. Always make sure to follow best practices and have a rollback plan.

Resolving ‘Naming Information Cannot Be Located’ Error: Troubleshooting Guide

If you’ve ever tried to join a computer to an Active Directory (AD) domain or perform certain domain-related operations, you may have encountered the frustrating “Naming Information cannot be located because: The specified domain either does not exist or could not be contacted” error. This error typically occurs when a client machine is unable to communicate with the domain controller (DC) for the domain it’s trying to join or access.

There can be various reasons behind this error, such as network connectivity issues, misconfigured DNS settings, or problems with the domain controller itself. Fortunately, there are several troubleshooting steps you can take to resolve this issue.

Step 1: Specify the WINS Server’s IP Address on the Client WINS (Windows Internet Naming Service) was an older technology used for name resolution in Windows networks before the widespread adoption of DNS (Domain Name System). While it’s not commonly used anymore, specifying the WINS server’s IP address on the client machine can sometimes help resolve the “Naming Information cannot be located” error.

To do this, follow these steps:

Open the Network Connections control panel and access the properties of the local area network connection.
Navigate to the TCP/IPv4 settings and go to the Advanced > WINS settings.
Add the IP address of the WINS server, which is often the same as the domain controller’s IP address, to the WINS server list.

By providing the WINS server’s IP address, the client machine may be able to resolve the domain name and join the domain successfully.

Step 2: Check FSMO Role Status The Flexible Single Master Operation (FSMO) roles are special operations in Active Directory that must be carried out by a single domain controller at any given time. You can check the status of these roles using the netdom query FSMO command. If there are any issues with the FSMO roles, it could potentially cause problems with domain name resolution and communication with the domain controller.

Step 3: Modify the SysvolReady Flag The HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters registry key contains various settings related to the Netlogon service, which is responsible for authenticating and joining computers to a domain.

The SysvolReady flag is a registry value that indicates whether the Sysvol (System Volume) folder, which contains Group Policy Objects (GPOs) and other AD-related data, has been fully replicated to the domain controller. Setting the SysvolReady flag to 1 forces the domain controller to assume that the Sysvol replication is complete, even if it’s not.

To modify the SysvolReady flag, follow these steps:

Navigate to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters registry key.
In the details pane, right-click the SysvolReady flag and click Modify.
In the Value data box, type 1, and then click OK.
Reboot the server.

This step is often recommended as a troubleshooting measure when there are issues with Sysvol replication or when the domain controller is unable to locate the necessary domain information due to replication problems.

By following these steps, you may be able to resolve the “Naming Information cannot be located” error and establish successful communication between the client machine and the domain controller.

It’s important to note that these troubleshooting steps should be performed with caution, as modifying registry settings or network configurations can have unintended consequences if not done correctly. If you’re unsure about any of the steps, it’s recommended to consult with a qualified system administrator or IT professional.