Migrating a domain from Windows Server 2008 R2 to Windows Server 2012 R2

General Domain Migration Process

The common and recommended method for upgrading a domain controller is Side-by-side migration, which involves installing a new server, creating a domain controller from it, and moving roles and functions to it. Using an In-place upgrade is also possible under certain conditions, but it can cause a number of issues.

Documentation

Some information from the internet, starting with the official Microsoft description.

• Upgrade Domain Controllers to Windows Server 2012 R2 and Windows Server 2012
• Step-By-Step: Adding a Windows Server 2012 Domain Controller to an Existing Windows Server 2003 network
• Upgrading or Migrating Active Directory to Windows Server 2012 - Build Your Roadmap Now
• Introducing the first Windows Server 2012 Domain Controller (Part 1 of 2)
• Upgrading an Active Directory Domain from Windows Server 2008 or Windows Server 2008 R2 to Windows Server 2012 or Windows Server 2012 R2

Active Directory Migration Steps

• prepare documentation of the current state (domain, used services, who accesses AD, etc.)
• check prerequisites
• test the domain state and replication functionality (which we should do continuously or constantly)
• prepare the AD database (ADPREP)
• add a new server as a domain controller
  • install (virtual) server with Windows Server 2012 R2 OS, set a static IP address and DNS servers, leave IPv6 (its deactivation is not recommended)
  • (optionally) join the domain
  • promote the server to a domain controller
• move roles and functions
• remove the old DC
• repeat for the remaining controllers
• remove the last original DC
• raise the domain and forest functional level

Process From the Perspective of Individual DCs

Typically, we have two or more domain controllers. First, we need to know where the FSMO (Flexible Single Master Operations) roles are located, which are now correctly called Operations Master roles. These are the PDC Emulator, RID Master, Infrastructure Master, Schema Master and Domain Naming Master. A brief description is in the article Active Directory komponenty - domain, tree, forest, site.

If we don't have this information in any documentation, or want to verify the real state, we can use graphical AD management tools or get a simple overview using command-line tools:

• dsquery server - list of DC servers
• netdom query fsmo - lists all roles and their holders
• dsquery server -hasfsmo schema - lists who has the Schema Master role
• dsquery server -hasfsmo name - lists who has the Domain Naming Master role
• dsquery server -hasfsmo infr - lists who has the Infrastructure Master role
• dsquery server -hasfsmo pdc - lists who has the PDC Emulator role
• dsquery server -hasfsmo rid - lists who has the RID Master role
• dsquery server -isgc - lists DC that have GC

Roles can be distributed in different ways, for simplicity I will assume that all roles are on one DC and I will call it (historically) the PDC (Primary DC). I will refer to the other controllers as BDC (Backup DC). When migrating controllers, it's easiest to start with the one with the fewest roles, i.e., some BDC.

The second thing is the IP addresses of the domain controllers. If we have a new DC with a new IP address, we will likely have to change a large number of different configurations on workstations and servers (at least DNS, if used, RADIUS, etc.). Therefore, it seems simpler to swap the IP addresses so that the new DC has the same address as the one being replaced. Changing the IP address of a domain controller is officially supported. It is only recommended to check that the DNS records have been properly changed.

For some situations, the DNS name of the controller is also an issue, if we have, for example, various systems connected to LDAP (and use the DNS name in the configuration) or a certification authority running on the DC (this situation is discussed at the end of the article) or a print server. If we have multiple DCs, we can always remove one and then create a new one with the same name. Alternatively, we can rename the DC at some stage.

So a general process would be:

• install a new (backup) BDC
• set up all functions on it like on the replaced DC
• change the IP addresses
• test functionality and gradually remove functions from the original DC
• remove the original DC and the entire server

Then we will continue with the other BDCs until we reach the (primary) PDC, which holds the Operations Masters roles. When removing functions there, we will also transfer all roles.

Checking Prerequisites

The main prerequisite for us to be able to add a Windows Server 2012 R2 domain controller to our AD domain is that the functional level of the domain must be at least Windows Server 2003. I'm assuming we have Windows Server 2008 R2.

At the beginning, we should also verify that nothing else is preventing us from adding a new Windows Server 2012 R2 domain controller. This includes various applications that are heavily integrated with Active Directory. An example is Exchange Server 2010, which supports such a controller only with the installed Update Rollup (RU) 5. Or SharePoint Server.

Checking the State of Active Directory

We should perform AD checks continuously. It's important to verify that everything is in perfect order before making changes to Active Directory. The same checks will be performed after adding a new domain controller, removing the original, and at the end after raising the functional level.

Testing Active Directory, Domain, Replication

There are a number of things and tools we can use for the checks (some information is described in the article Active Directory Health Checks for Domain Controllers). Some options are listed below.

• We should definitely go through the event logs (Event Viewer) to make sure there are no critical Error or Warning events.
• The Domain Controller Diagnostics Tool will analyze the state of the domain controllers, we can call it without parameters or use switches and save the output to a file.
  • dcdiag
  • dcdiag /v /c /d /e /s:name-DC > c:\name-DC.log
• To check replication, we can use the Replication Diagnostics Tool, again there are a number of switches (in the last command, the domain controller name is entered as *dc, which includes all names ending in DC)
  • Repadmin /showreps
  • Repadmin /replsum /errorsonly
  • Repadmin /showrepl *dc /verbose /all /intersite > c:\repl.log
• Another (graphical) tool for checking replication can be downloaded from MS Active Directory Replication Status Tool
• For DNS diagnostics, we can download the (old) Description of the DNSLint utility, it is called from the command line and creates the dnslint.htm file
  • Dnslint /ad /s IP.address.of.DNS.server

For interest, here's how we can get information about the schema version (not the domain functional level) from AD. The first step before installing a new version of the domain controller is to use ADPREP to prepare the AD, which will upgrade the schema.

C:\>Dsquery * cn=schema,cn=configuration,dc=company,dc=local -scope base -attr objectVersion
  objectVersion
  47

The output version value means:

• 13 = Windows 2000 Server
• 30 = Windows Server 2003
• 31 = Windows Server 2003 R2
• 44 = Windows Server 2008
• 47 = Windows Server 2008 R2
• 56 = Windows Server 2012
• 69 = Windows Server 2012 R2

Installing a New Domain Controller

We will install a clean (virtual) server with the Windows Server 2012 R2 OS. We will set a static IP address and DNS server. We will leave IPv6 (its deactivation is not recommended). I also do the step of joining the server to the domain.

Preparing the Forest, Domain, and Schema

Before adding the first DC with Windows Server 2012 R2 to the domain, we need to prepare the forest, domain, and schema. We can use the Adprep command, which is located on the Windows Server 2012 R2 installation media in the Support/adprep folder. Only the 64-bit version of Adprep.exe is now present, so it can only be run on a 64-bit OS. Today, it is no longer necessary to run it directly on the DC holding the Operations Masters roles, but it works remotely. We must run it under a user who is a member of the Enterprise Admins, Schema Admins and Domain Admins groups. The following switches are used:

• Adprep /forestPrep - prepare the forest
• Adprep /domainPrep /gpPrep - prepare the domain and also Group Policy
• Adprep /rodcPrep - if we want to use DC only for read

Currently, we no longer need to use Adprep manually, the AD preparations will take place during the installation of the first new DC. This is described in the next step. But according to the information in Group Policy preparation is not performed when you automatically prepare an existing domain for Windows Server 2012, the Adprep /domainPrep /gpPrep will not be performed and we need to run it manually!

Promoting the Server to a DC

The entire process can be performed using a graphical wizard. There are two phases:

• first, we add the Active Directory Domain Services role (we can also immediately add other properties like DNS, certain RSAT tools, SNMP Service, etc.) - this is described with images in the article Windows Server 2012 Active Directory
• after installing the AD DS role, we promote the server to a DC - this is covered below

After completing the role addition, in the Server Manager we will see an exclamation mark on the flag, clicking on the icon will tell us that we need to perform a Post-deployment configuration - Promote this server to a domain controller.

In the first step of the wizard, we choose that we are adding a controller to an existing domain, we also see the credentials of the logged-in user and can change them using the Change button.

Certain checks and detection of our environment will be performed, either an error will be displayed or the next step. Here we specify the properties (DNS and GC), we can create the DC as a RODC, we choose the Site and set the password for the Directory Services Restore Mode (DSRM).

In the DNS Options step, we can ignore the warning about DNS delegation.

We choose from which DC the AD replication will take place, we can also use a file (Install from media - IFM)

The default paths for the database, logs, and SYSVOL are offered. In general, it is recommended to place the DB files elsewhere than the logs, but I think for AD the default system folder is often left.

If we don't have AD prepared, the next step will inform us that the forest, domain, and schema will be prepared. If we are not logged in with an account with sufficient rights, we will be informed and can change it.

The final step is just a summary, and by clicking the Install button, the installation will start. After clicking the Close button, the server will restart.

Checks After DC Installation

After we have the new DC ready, it is important to check that everything is running properly. In addition to checking the event logs, replication, etc., we can also use the Best Practices Analyzer (BPA) for Active Directory (but also for DNS and other roles). We can find it in the Server Manager, where we choose AD DS, and scroll down to the Best Practices Analyzer section.

Moving Services and Roles

The following describes the migration of more common roles that may run on a DC to a new server.

Migrating the DNS Server

The DNS role was installed along with AD DS. The standard zones are part of AD, so they will be transferred with the AD replication. The new DNS server will also be automatically added as a Name Server for all zones. Only if we have used some zones that are not Active Directory-Integrated, we need to address them.

Migrating NPS

The Network Policy Server (NPS), which offers RADIUS (Remote Authentication Dial In User Service) server services, can be migrated very easily. The official description is Migrate Network Policy Server to Windows Server 2012 R2.

The graphical interface of the Network Policy Server mmc console is the same in Windows Server 2008 R2 and Windows Server 2012 R2. If we right-click on NPS (local), there is an Export Configuration option that will save the entire configuration (including shared secrets) to an XML file. On the new server, we then use the Import Configuration option. If needed, we can also find the Register server in Active Directory option in the context menu.

The question is, clients connect to the RADIUS server at a specific IP address. So we either need to change the settings everywhere, or it's simpler, after activating all the roles, to change the IP address of the new server to the address of the one being replaced.

Migrating DFS

The Distributed File System service is part of the File and Storage Services role, so we install the necessary parts (DFS Namespaces and DFS Replication). Then using DFS Management, we add a new Namespace Server for each used Namespace.

First, we right-click on Namespaces and choose Add Namespaces to Display. Then we right-click on the displayed Namespace and choose Add Namespace Server.

Migrating DHCP

The official description Migrate DHCP Server to Windows Server 2012 R2 uses the Windows Server Migration Tools (Export-SmigServerSetting, Import-SmigServerSetting), other articles like Migrating existing DHCP Server deployment to Windows Server 2012 DHCP Failover and DHCP PowerShell Export Import cmdlets in Windows Server 2012 use the new cmdlets in Windows Server 2012 Export-DhcpServer and Import-DhcpServer.

Migrating the DHCP server to a new controller is quite simple using export and import of the settings (including leased addresses). We can use the netsh command-line (which has the advantage of being supported even when migrating from Windows Server 2003, as I described in an older article), but it is now recommended to use PowerShell.

On the target server, we install the DHCP server role and perform the initial setup, which is authorization (addition) to AD. We start PowerShell and perform the export and import from this server. Export the DHCP settings from the server pdc.company.local to a file using the cmdlet:

Export-DhcpServer -ComputerName pdc.company.local -Leases -File c:\dhcpexp.xml -verbose

Then it's a good idea to stop the DHCP server service on the original server. Import to the new server using the cmdlet:

Import-DhcpServer -ComputerName pdc-new.company.local -Leases -File C:\dhcpexp.xml -BackupPath C:\dhcp -Verbose

The BackupPath parameter specifies the folder where a backup of the current server settings will be made before the new values are imported.

In our case, we have the DHCP server along with the DNS server on the DC, then it is recommended to use a special DNSCredentials account for registering DNS records. The configuration of this account was not transferred along with the backup. It is set by right-clicking on IPv4 (or IPv6) in the DHCP console, choosing Properties, the Advanced tab, and there is a Credentials button at the bottom.

Migrating the Print Server

The official description is Migrate Print and Document Services to Windows Server 2012, or a pictorial guide Step-by-Step: Migrating Print Servers from Windows Server 2008 to Windows Server 2012.

Migrating the print server, including drivers, is a simple task.

• on the new server, we start the Print Management mmc console
• we right-click on the root Print Management item and choose Migrate Printers
• first, we choose Export printer queues and printer drivers to a file
• in the settings, we connect to the original server and save the data to a file
• then we run the wizard again and choose Import printer queues and printer drivers from a file
• we choose the current (new) server and our saved file
• we perform the import and finally check the event log and test the printers

In the wizard, we had a step where we chose whether the printers should be published to AD (List in the directory). If we published them and had them published before, we will now see them twice. We can remove the publication from the original server (Remove from directory).

When we migrated the printers from the old print server to the new one, the server-side part was transferred, but clients have the printer set up through the print server name. So they will have to add it again. A possible solution is to rename the new server to the name of the original one (in which case we don't perform the publication of the printers to AD during the import, but do this manually after the renaming).

Migrating the WINS Server

We still haven't got rid of the use of historical NetBIOS names (although Microsoft has been promising this for a long time), so we often use the WINS service. As on Windows Server 2008, it is also a feature of the server that we need to add.

The data transfer works simply on the principle of replication. We open the WINS console where we connect both servers. For each server, we expand Replication Partners, right-click and choose New Replication Partner, where we enter the other WINS server. Then we choose Replicate Now from the context menu.

The first time, replication didn't work for me, although no error was logged, it was solved by restarting the server (restarting the service didn't help).

SSL/TLS Security

We can increase the security of SSL/TLS protocols by setting the allowed ciphers, for example using the IISCrypto application, see the article SSL/TLS protocol - disabling weak ciphers and server security.

Monitoring

If we use any kind of monitoring, syslog server, etc., we need to include the new server in the monitoring and get SNMP and other used tools working.

Changing the IP Address

We will set the original DC to some free IP address. We will set the new DC to the original IP address and the correct DNS servers (it is recommended to set the Preferred DNS to the partner DNS server, Alternate DNS to your own IP address, and add a third address to 127.0.0.1). Then we can remove the functions on the original DC and check the functionality.

After changing the IP address, we can run the following commands on the DC (just to make sure the DNS records are set up properly), or restart it.

• ipconfig /flushdns
• ipconfig /registerdns
• dcdiag /fix

Removing Services from the Original DC

DFS (Distributed File System)

Using DFS Management, we open the given Namespace and switch to the Namespace Servers tab, select the original server and Delete. We cannot uninstall the role yet, only when removing AD DS.

NPS (Network Policy Server)

We remove the NPS role.

WINS (Windows Internet Name Service)

The official description is Decommission a WINS server. First, we check that all data has replicated. We right-click on Active Registrations, choose Delete Owner, select the IP address of the server being removed, and choose Replicate deletion to other WINS servers (tombstone). We force replication. We can remove the replication partners (with the removal of the bindings) and uninstall the WINS feature.

DNS (Domain Name System)

We remove the DNS role. By uninstalling the DNS role on the server, the records on the zones where this server was authoritative (in most cases these are the AD-Integrated ones) are not deleted. So we need to perform some manual interventions. The official description is Removing a DNS Server.

On each zone (Forward and Reverse Lookup Zones), we edit (right-click on the zone and choose Properties) the Name Servers tab and delete (remove) the server being removed. If we have a lot of zones, we can try a script, for example How to update the list of Name Servers on a DNS Zone with a Script.

Windows Server 2012 added DNS management capabilities to PowerShell, so we can create a small script that will perform the removal. The script below is an example and I don't guarantee its behavior ;-). We will use the cmdlets Get-DnsServerZone, Get-DnsServerResourceRecord, Remove-DnsServerResourceRecord.

First, for testing, we can list all zones and their name servers.

Get-DnsServerZone | Where-Object { $_.ZoneType -eq "Primary" -and $_.IsAutoCreated -eq $false } |
  ForEach-Object {
    echo $_.ZoneName
    Get-DnsServerResourceRecord $_.ZoneName -RRType NS -Node
  }

Then we can similarly remove the removed DNS server from all zones. In the example, you need to change the DNS name of the removed server instead of the placeholder old-dns.company.local.

Get-DnsServerZone | Where-Object { $_.ZoneType -eq "Primary" -and $_.IsAutoCreated -eq $false } |
  ForEach-Object {
    Try { 
      Remove-DnsServerResourceRecord -ZoneName $_.ZoneName -RRType NS -Name "@" -RecordData " old-dns.company.local." -Force 
    } Catch [system.exception] {
      "Some error during removal - probably the record doesn't exist or you don't have permissions."
    }
  }

DHCP (Dynamic Host Configuration Protocol)

When removing a DHCP server, we should remove its record from the authorized DHCP servers in Active Directory (AD). We can do this in the DHCP console, but at that moment the server must be running. We right-click on the given server and choose Unauthorize. Or using the netsh command or the Remove-DhcpServerInDC cmdlet, in which case the server may not exist at all.

Using the Network Shell, we first list the authorized servers from AD and then we can remove the old server.

netsh dhcp show server
netsh dhcp delete server pdc.company.local 10.0.0.10

Note: When we changed the IP address of the original server, the old one is still registered. But by combining the server name and IP address, we remove the correct record.

Using PowerShell, the procedure is the same (we need to use PowerShell on a Windows Server 2012 with the DHCP role).

Get-DhcpServerInDC
Remove-DhcpServerInDC -DnsName pdc.company.local -IPAddress 10.0.0.10

Finally, we can remove the DHCP role.

Changing the Bridgehead Server

I couldn't find anything about this in the official documentation, but in practice I ran into a problem, so I recommend performing this step (I expected AD DS to resolve this change automatically when removing the controller).

In case we have multiple Sites, before removing the domain services, check that the server is not a Preferred Bridgehead Server. And if it is, change this. We can list these servers using the following command-line command or use a graphical tool to make the change.

repadmin /bridgeheads

If our server being removed is a Bridgehead, we transfer this property to another domain controller. We use Active Directory Sites and Services - Sites - our site - Servers. In the table, we see which server is the Bridgehead for which transport (today probably only IP). We right-click on the new server and choose Properties. At the bottom, we choose Transport and Add. We remove the transport from the server being removed in a similar way.

AD DS (Active Directory Domain Services)

The official description is Removing a Domain Controller from a Domain. By removing the domain services, we will cancel the domain controller function.

First, we run dcpromo.exe and go through the wizard

After completion, the server will restart. Using Server Manager - Remove Roles, we remove the Active Directory Domain Services role and possibly also the File Services (DFS) role.

Problem During AD DS Removal

When removing a domain controller, I encountered the following error:

The operation failed because:
Active Directory Domain Services could not transfer the remaining data in directory partition DC=DomainDnsZones,DC=company,
DC=local to Active Directory Domain Controller \\pdc.company.local.
"The directory service is missing mandatory configuration information, and is unable to determine the ownership of floating
 single-master operation roles."

The problem is described in the article DCPROMO demotion fails if unable to contact the DNS infrastructure master. To verify the state described in the error, we can list the values using a command-line command:

dsquery * CN=Infrastructure,DC=DomainDnsZones,DC=company,DC=local -attr fSMORoleOwner
dsquery * CN=Infrastructure,DC=ForestDnsZones,DC=company,DC=local -attr fSMORoleOwner

In the case of this error, we will find the old domain controller OLD-PDC, which was a Windows Server 2003 that was removed years ago. The fix can be done using a script from KB 949257, more info at ForestDNSZones or DomainDNSZones FSMO says The role owner attribute could not be read. We run it for both zones:

cscript fixfsmo.vbs DC=ForestDnsZones,DC=company,DC=local
cscript fixfsmo.vbs DC=DomainDnsZones,DC=company,DC=local

Or we can do the same manually using ADSI Edit, where we can choose which DC to set instead of the faulty one. It's important that we connect to the role holder, otherwise when trying to change, we get an error:

Operation Failed. Error code: 0x20ae
The role owner attribute could not be read
  
000020AE: SvcErr: DSID-03152BF7, Problem 5003
(WILL_NOT_PERFORM) Data 0

So in ADSI Edit we connect to the Connection Point DC=ForestDnsZones,DC=company,DC=local and choose the appropriate DC. We navigate to the Infrastructure and change the fsMORoleOwner attribute to the value with the corrected server:

CN=NTDS Settings,CN=PDC,CN=Servers,CN=Praha,CN=Sites,CN=Configuration,DC=company,DC=local

Removing the Server

Even though we have removed the domain controller role from the server, we still have the record in the Site servers, which we can delete. Active Directory Sites and Services - Sites - our site - Servers, right-click on the server to be removed and choose Delete.

We remove the server from the domain (Control Panel - System - Change Settings - Computer Name - Change - Member of Workgroup) and delete its account in AD. We can check DNS to see if there are any records left with the original DC (especially the domain SRV).

If we have DCs in different Sites, we always need to wait for replication to occur when making changes. It's a good idea to check the replication topology in Active Directory Sites and Services to make sure it's not damaged during DC removal. Bridgehead server settings and connections between DCs (Connections). If there is a problem, we can manually reconfigure. Under certain conditions, we can delete the connection and on each DC we can run repadmin /KCC to regenerate the new topology. The Knowledge Consistency Checker (KCC) runs by default every 15 minutes and generates the AD replication topology.

Transferring Operations Master Roles

Transferring Operations Master Roles

Before removing the domain services from the PDC, which holds the roles, we must transfer these roles to another DC. The Schema Master and Domain Naming Master roles are unique for the entire forest, and the change must be made under an account with Enterprise Admin rights. The RID Master, PDC Emulator, and Infrastructure Master roles are unique to the domain, and the change must be made at minimum under an account with Domain Admin rights (changing all three is done with the same tool). We will describe the transfer of roles using graphical tools, but it is also possible to use the ntdsutil command.

The official description is Transfer the Domain-Level Operations Master Roles, Transfer the Domain Naming Master, Transfer the Schema Master.

Schema Master

Using Active Directory Schema, we right-click on the main item Active Directory Schema [DNS name of the connected DC], using Change Active Directory Domain Controller we connect to the DC to which we want to transfer the role, and using Operations Master and the Change button, we can change the role holder.

Note: For management, we use tools from Remote Server Administration Tools (RSAT), including the Active Directory Schema snap-in. Unlike the others, however, we must first register it in the system. We do this by running regsvr32 schmmgmt.dll. Then we can use the mmc console and add the Active Directory Schema Snap-in (preferably save it afterwards).

Domain Naming Master

Using Active Directory Domains and Trusts, we right-click on Active Directory Domains and Trusts [DNS name of the connected DC], using Change Active Directory Domain Controller we connect to the DC to which we want to transfer the role, and using Operations Master and the Change button, we can change the role holder.

Relative Identifier (RID) Master

Using Active Directory Users and Computers, we right-click on the domain name, using Change Domain Controller we connect to the DC to which we want to transfer the role, and using Operations Master and the Change button, we can change the role holder.

Note: We can continue with the other roles on the following tabs.

Primary Domain Controller (PDC) Emulator

Using Active Directory Users and Computers, we right-click on the domain name, using Change Domain Controller we connect to the DC to which we want to transfer the role, and using Operations Master, switching to the PDC tab, and the Change button, we can change the role holder.

Infrastructure Master

Using Active Directory Users and Computers, we right-click on the domain name, using Change Domain Controller we connect to the DC to which we want to transfer the role, and using Operations Master, switching to the Infrastructure tab, and the Change button, we can change the role holder.

Setting the Global Catalog (GC)

If we did not set the DC as a GC during installation, we can set it using Active Directory Sites and Services, where we navigate through the appropriate Site to the DC we're looking for, and under it we right-click on NTDS Settings and choose Properties. On the General tab, we check the Global Catalog item.

NTP (Network Time Protocol)

When we transfer the Operations Master roles, especially the PDC Emulator, we need to set the time source (usually) from the internet on this domain controller. The other DCs synchronize the time with the holder of this role, and client workstations use their domain controller.

On the original controller, we can list the settings using:

w32tm /query /configuration

We can set the configuration (in the example, the NTP server tik.cesnet.cz is used):

w32tm /config /manualpeerlist:tik.cesnet.cz /syncfromflags:manual /reliable:yes /update

If we need to test NTP on a server:

w32tm /stripchart /computer:tik.cesnet.cz

If we need to change the settings of the former PDC, i.e., set the server to synchronize with the DC:

w32tm /config /syncfromflags:domhier /update

Raising the Functional Level

Once we have migrated all the domain controllers, we can proceed to raise the functional level of the domain and forest. The functional level of the domain and forest determines the features that Active Directory Domain Services offers. A brief overview is in the article Understanding Active Directory Domain Services (AD DS) Functional Levels. If the new version of Windows Server is running on all domain controllers in the AD DS domain, we can raise the domain functional level to the same version as the OS. If the new version of Windows Server is running on all domain controllers in the AD DS forest, we can raise the forest functional level to the same version as the OS.

The official description for raising the domain and forest functional level is in the articles Raise the Domain Functional Level and Raise the Forest Functional Level.

Raising the Domain

We must perform this with Domain Admins or Enterprise Admins permissions.

• using Active Directory Domains and Trust
• we right-click on the domain
• we choose Raise domain functional level
• we select Windows Server 2012 R2 and click Raise

Raising the Forest

We must perform this with Enterprise Admins permissions.

• using Active Directory Domains and Trust
• we right-click on Active Directory Domains and Trust
• we choose Raise Forest Functional Level
• we select Windows Server 2012 R2 and click Raise

Active Directory Certificate Services (AD CS)

I'll add a brief description of the transfer of the certification authority (CA) as well. When I tried to migrate the CA from server 2003 to 2008, I failed. Now I know it's because I was changing the server name, and in that case, you need to manually modify a number of configurations. It's definitely better to keep the server name when migrating AD CS. Today's official documentation is also much better than before.

Migrating the certification authority can be problematic, and if you want to tackle it, it's recommended to keep the server name (i.e., first uninstall the CA, remove or rename the server, and name the new server the same as the original). I decided to keep this single function (the CA) on the original DC (to avoid having to migrate it) and remove everything else. However, when removing AD DS, I ran into the problem that it is not possible to cancel the domain controller function if the CA is running on it. The AD CS must be removed first, then we can remove the AD DS.

I decided to keep the original server and perform the following steps (all of which went without errors). Perform a backup of the CA, remove the AD CS role, then remove the AD DS, then reinstall the AD CS and restore the backup. So a slightly simplified migration process. The following steps describe a complete backup, including things that we won't restore in this specific case.

The official description is now quite well written Active Directory Certificate Services Migration Guide, further information can be found in Disaster Recovery Procedures for Active Directory Certificate Services (ADCS) and Step-By-Step: Migrating The Active Directory Certificate Service From Windows Server 2003 to 2012 R2.

I'll include a link to Mirek Knotek's article PKI - Migrating to SHA-2, which describes a simple method to switch certificate issuance from SHA1 to SHA256. Since in 2016 certificates with SHA1 will often be considered unsafe and in 2017 completely unsupported, this is a current topic.

Backing up AD CS

The complete backup of the Certificate Services consists of a series of steps.

Backing up a CA templates list

We note down the list of allowed certificate templates (e.g., a print screen from the console).

I think it's also a good idea to note down the installed properties of the AD CS role.

Just to be sure, we can also note down the locations of the CDP and AIA, by opening the Enterprise PKI in the AD CS console and navigating to our CA.

Recording a CA's signature algorithm and CSP

We save the information about the CA's signature algorithm and CSP.

certutil.exe -getreg ca\csp\* > csp.txt

Backing up a CA database and private key

We perform a CA backup using the console. We right-click on our CA and choose All Tasks - Back up CA, enter the path to the folder and the password to protect the CA certificate file (which also contains the private key).

Now we should stop and uninstall the CA!

Backing up CA registry settings

Using regedit, we back up (export) the registry in the following path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration.

Backing up CAPolicy.inf

If we use a modified C:\Windows\CAPolicy.inf file, we copy it to the backup.

Removing the CA role service from the source server

Before installing the CA on a new server (or in our case, on this one again after uninstalling AD DS), we need to remove the CA role. The Enterprise CA stores its configuration data in AD DS and is tied to the CA's common name. When we remove the CA role from the server, the CA database, private key and certificate are not deleted. In case of problems, we can then add the CA role to the server again and restore its functionality, which is actually our case.

Restoring AD CS

Adding the CA role service to the destination server

We add a new Active Directory Certificate Services role, type Enterprise, in the Set Up Private Key step, we choose Use existing private key and Select a certificate and use its associated private key. Our certificate should be offered (because it was not deleted upon uninstallation). We complete the installation.

Restoring the CA database and configuration on the destination server

We perform a CA restore using the console. We right-click on our CA and choose All Tasks - Restore CA, the services will first be stopped, as the restore item we only check the Certificate database and certificate database log, we choose the folder where the backup is stored. We perform the restore and start the services.

We make a backup of the current registry state in the path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration. And we restore the registry exported from the original server. We restart the CA service.

We can also verify that the locations of the CDP and AIA are correct and are being loaded properly.

The last step of the restoration is Restoring the certificate templates list, i.e. enabling the certificate templates. We right-click on Certificate Templates, choose New - Certificate Template to Issue and select our used templates.

Verifying the Migration

We can manually issue a CDP, right-click on Revoked Certificates and choose Publish, and check it.

We'll try to issue one or more certificates from our templates. The classic check is also to check the events using the Event Viewer for the AD CS role.

Some Errors During the Migration

From the very beginning, i.e. checking the domain and controllers, I encountered various minor errors. I'll briefly mention a few of them here.

DCdiag and RODCprep

When using DCdiag, the NCSecDesc part shows an error:

Error NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS doesn't have Replicating Directory Changes In Filtered Set access rights
 for the naming context

This is because adprep /rodcprep was not performed. We can ignore the error or perform adprep, description in Dcdiag fails for NCSecDesc test on Windows 2008 Domain Controllers.

Certificate from the Kerberos Authentication template

On the new controller, we find the following error in the event log Kerberos-Key-Distribution-Center, Event ID: 32:

The Key Distribution Center (KDC) uses a certificate without KDC Extended Key Usage (EKU) which can result in authentication
 failures for device certificate logon and smart card logon from non-domain-joined devices. Enrollment of a KDC certificate
 with KDC EKU (Kerberos Authentication template) is required to remove this warning.

There is a new CA template called Kerberos Authentication and it is recommended that the DC have a certificate issued from this template instead of the older Domain Controller. Some info is in the article Configure Windows Logon With An Electronic Identity Card (EID).

Authentication using NPS fails

Authentication of WiFi clients using RADIUS with PEAP fails. The error logged is Network Policy Server denied access to a user, which contains the reason:

Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user
 account or the password was incorrect.

The user credentials are fine, the problem was found in the certificate on the server. In the NPS policy in Constraints - Authentication Methods, the PEAP protocol is used and the certificate from the Kerberos Authentication template was automatically set instead of Domain Controller. After changing the certificate, everything started working. There is a mention in the article Windows NAP as RADIUS in a Windows 7 Server 2012 Wireless World.

Problem with public folders on the Exchange server

The problem, which should not have been related to the change of the domain controller, but I encountered it precisely at the time of adding the new DC. Email messages sent to the Public Folder are not delivered and return an NDR (Non-Delivery Report).

#554 5.2.0 STOREDRV.Deliver.Exception:ObjectNotFoundException; Failed to process message due to a permanent exception with
 message The Active Directory user wasn't found. ObjectNotFoundException: The Active Directory user wasn't found. ##

The problem arose in a situation where the Microsoft Exchange Server 2003 environment was migrated to Microsoft Exchange Server 2007 and newer. And in the AD configuration under the First Administrative Group, the Servers container remained empty. The solution is to delete this container (caution, the entire administrative group, even if it is empty, must not be deleted). We use adsiedit and the path:

Configuration Container - CN=Configuration,DC=DomainName,DC=local - CN=Services - CN=Microsoft Exchange -
 CN=OrganizationName - CN=Administrative Groups - CN=First Administrative Group - CN=Servers

The option to delete (for another reason) is also mentioned by Microsoft in their KB When trying to replicate the public folder content to Microsoft Exchange Server 2010 it will not replicate, additional information Public Folder Replication Fails Due To Empty Legacy Administrative Group or discussion When sending e-mail messages to a mail-enabled public folder that have been replicated from old Exchange Server 2000/2003/2007, Exchange Server 2010 environment mails are rejected with NDR.