End of support for Windows Server 2008 R2 has been slated by Microsoft for January 14th 2020. Said announcement increased interest in a previous post detailing steps on Active Directory Certificate Service migration from server versions older than 2008 R2. Many subscribers of ITOpsTalk.com have reached out asking for an update of the steps to reflect Active Directory Certificate Service migration from 2008 R2 to 2016 / 2019 and of course our team is happy to oblige.

Log in to Windows 2008 R2 Server as member of local administrator group

Go to Start > Administrative Tools > Certificate Authority

Right Click on Server Node > All Tasks > Backup CA

Certification Authority Backup CA

Click Next on the Certification Authority Backup Wizard screen

Click both check boxes to select both items to backup and provide the backup path for the file to be stored

Certification Authority Backup Wizard Item Selection

Click Next

Provide a password to protect private key and CA certificate file and click on next to continue

Click Finish to complete the process

Step 2: Backup CA Registry Settings

Click Start > Run > type regedit and click OK

Expand the key in following path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc

Right click on the Configuration key and click Export

Provide a name, save the backup file and then click on save to complete the backup

Backup CA Registry Settings

Backup of the Certificates is now complete and the files can now be moved to the new Windows 2016 / 2019 server.

CA Backup complete

Step 3: Uninstall CA Service from Windows Server 2008 R2

Navigate to Server Manager

Click Remove Roles under Roles Summary to start the Remove Roles Wizard, and then click Next

Uninstalling a CA

Click to clear the Active Directory Certificate Services check box and click Next

Removing Active Directory Certificate Services

Click Remove on the Confirm Removal Options page

If Internet Information Services (IIS) is running and you are prompted to stop the service before you continue with the uninstall process, click OK

Click Close

Restart the server to complete the uninstall

Step 4: Install Windows Server 2016 / 2019 Certificate Services

*NOTE: The new 2016 / 2019 server needs to have the same "Name" as this point. The screenshots below show the server name as WS2019 to highlight which server we are working on. This step-by-step highlights screenshots from Windows Server 2019. Windows Server 2016 process is the same with similar screenshots

Log in to Windows Server 2019 as Domain Administrator or member of local administrator group

Navigate to Server Manager > Add roles and features

Click on next to continue in the Add Roles and features Wizard

Select Role-based or Feature-based installation and click next

Keep the default selection from the server selections window and click next

Windows Server 2019 Server Selections

Select Active Directory Certificate Services, click next in the pop up window to acknowledge the required features that need to be added, and click next to continue

Adding Active Directory Certificate Services

Click Next in the Features section to continue

Review the brief description about AD CS and click next to continue

Select Certificate Authority and Certification Authority Web Enrollment, click next in the pop up window to acknowledge the required features that need to be added, and click next to continue

Windows Server 2019 Add Role Services

Review the brief description about IIS and click next to continue

Leave the default and click next to continue

Click Install to begin the installation process

Close the wizard once it is complete

Step 5: Configure AD CS

In this step will look in to configuration and restoring the backup created previously

Navigate to Server Manager > AD CS

In right hand panel it will show message as following screenshot and click on More

AD CS

Click on Configure Active Directory Certificate Service …… in the pop up window

Configure Active Directory Certificate Service

In the Role Configuration wizard, ensure the proper credential for Enterprise Administrator is shown and click next to continue

Select Certification Authority and Certification Authority Web Enrollment and click next to continue

Ensure Enterprise CA is selected the setup type and click next to continue

Select Root CA as the CA type and click next to continue

With this being a migration, select Use existing private key and Select a certificate and use its associated private key and click next to continue

AD CS Configuration

Click Import in the AD CS Configuration window

Select the key backed up during the backup process from windows 2008 R2 server. Browse and select the key from the backup we made and provide the password we used for protection and click OK.

Import Existing Certificate

With the key successfully imported and select the imported certificate and click next to continue

Leave the default certificate database path and click next to continue

Click on configure to proceed with the configuration process

Close the configuration Wizard once complete

Step 6: Restore CA Backup

Navigate to Server Manager > Tools > Certification Authority

Right click on server node > All Tasks > Restore CA

A window will appear confirming the stop of Active Directory Certificate Services. Click OK to continue.

Confirm stop of Active Directory Certificate Services

Click Next to start the Certification Authority Restore Wizard

Click both check boxes to select both items to restore and provide the backup path for the file to be restored from

Certification Authority Restore Wizard

Enter the password used to protect private key during the backup process and click next

Click Finish to complete the restore process

Click Yes to restart Active Directory Certificate Services

Step 7: Restore Registry info

Navigate to the folder with the backed up registry key and double click > Run to initialize the restore

Click yes to proceed with registry key restore

Click OK once confirmation about the restore is shared

Step 8: Reissue Certificate Templates

It is now time to reissue the certificate with the migration process now complete.

Under Server Manager, navigate to Tools > Certification Authority

Right click on Certificate Templates Folder > New > Certificate Template to Reissue

From the certificate templates list click on the appropriate certificate template and click OK

This concludes the Active Directory Certificate Service migration steps

@bradfore44 - Yes in this scenario the old server and new server would need to have the same name. I am currently working on writing another post that will address the need to have servers with different names. Stay tuned.

@Anthony Bartolo please update the comments here when the post dealing with different server names is ready. Also, if we have an offline root, is the process basically the same, we'd just choose the appropriate CA type for the root and the intermediate server? Thanks!

@Anthony Bartolo I put in a ticket with premier support referencing this ticket because I had a few follow up questions, but they came and told me that a upgrade directly from 2008 R2 to 2016/2019 was not supported. I asked them if they had tested this in their lab according to your article and they confirmed that they did. here is their response: "Unfortunately we cannot migrate the CA database directly form Server 2008 R2 to Server 2016 because the JET database engine changed so much between the two versions that if we restore the backup we get a JET version error at startup and the CA won't start. But if we add one more step we can successfully fulfill the above tasks. This additional step is to first restore the DB backup to a Server 2012 R2 CA and then backup the DB again form there. This new backup now can be restored to the Server 2016 CA. " Is this something that you ran into when upgrading directly from 2008 R2 to 2016/2019? I would like to do the upgrade directly from 2008 R2 if possible and not step up to 2012 R2 first. Thanks in advance!

@rdp21915 and @dwright187 I am currently researching further requests in regards to this post. This post was meant as an update to a previous post of which the steps above were tested. The above does not work for all scenarios hence the reason more research is being conducted. Thank you in advance for your patience.

Glad you are talking to this point but frankly there are many more details to the migration that is missing. These are all covered in the older, but still applicable and more detailed ADCS Migration Whitepaper. A couple of items of note in your process:

1) A very important step is missing from this and almost every migration doc that MICROSOFT has on this subject. You backup the CA while it is in production which means it could issue certificates after the backup and before you remove the role. I always recommend you note the templates that are installed on the CA, and then remove them from the CA. This prevents any further issuance. Now your backup will be accurate and no issued certificate details will be lost. After moving to the new platform, add back the appropriate templates.

2) In your backup of files you aren’t including the capolicy.inf file that may be in place and defining very important properties for your CA

3) When the CA is restored onto a new computer it had a new AD SID. As. Result the CA will not be able to publish its CRL to AD (if so configured) because the old CA computer object was the only one ACL’d to do that. So this object needs to be updated to allow the new computer object to publish the CRL.

Thank you for the additional information. I have found other tech blogs where the discuss getting the capolicy.inf.

My CRL site is on a third server, that only does that. I do need to migrate that to a newer OS server as well. Will I need to worry about the SID on that server as well, or will that not be a thing since it's not a ADCS server per se, just an IIS server?

Also, does anyone have any thoughts on my questions above? Or some actual official MS documentation on this topic, even if it is missing several steps? I have not found anything official on migrating ADCS from older OS to new OS.

No need to specifically upgrade your CRL Webserver, unless it too is going end of life. However, there is nothing it does in regards to the CRL or PKI that will be affected in AD by upgrading the OS. The ACL issue is just on the CA itself.

Here is the Microsoft official migration doc. It's old, but still applicable. Usual caveots as I pointed out. There are some gotchas to the method they have you follow (remember you should remove templates before backups, etc.)

@Thepkiguy Your comment and observation is a giant spot on! All these oversimplified migration guides from MSFT employees, that are simple next-next-finish-YouAreDone are extremely misleading. An advanced PKI in production needs a very careful planning, otherwise you can search for new job the next week... These blog posts wont reveal such depths, and thats the dangerous part if you read this post.

How about multi-tier PKI? Oopsie, havent thought about that. How to handle offline rootca? Hmm, I forgot that. Sha1 to Sha2 key migrarion? Ooo... And the list goes on and on and on and on and on abd on... Hint: there is no recent MSPRESS book about Windows PKI since Brian Komars 2008 book (yep, 10yrs old, and doesnt handle many PKI and crypto fundamentals at all, that is required for the windows admin to even understand what they are doing with that sha1->sha2 change etc.)

Yes the reason for that is beacsuse the JET DB changes from 2008R2 to 2012R2 and so on. So you cant take that big of a jump beyond 2012R2 and upwards.

You need to first go to 2012R2 and then do then jump from there to either 2016 or skip 2016 and go to 2019.

Yes have original started with the jump from 2008R2 to 2016, that did no work out in any way. So goining for 2019 will have the same issues.

I have heard that some 2 customers have successfull made an inplace upgrade from 2008R2 to 2016, but have never self been able to have a succesfull go on that secnario. And from what I learn was a LOT of coding and hardning took place and pure luck was the reason for their success.

Some of the CU windows updates sometimes fixes/breaks stuff we all know that. and in some lucky way these customers have been able to jump inbetween and have a success inplace upgrade.

So then to clarify...I should/can do an in place upgrade from my 2008R2 to 2012R2...then follow up by building a new 2019 server and migrating my data over to that? Or does the migration to 2012R2 have to be done on a new server as well?

In addition, can you jump straight from 2008R2 to 2012R2, or do you have to do an intermediate to 2012?

Inplace upgrade: No, not from 2008R2 to 2012R2, you have to do a fresh install, best solution in any case. The 2 cases I talked about was impossibly lucky cases i have heard off, out of ~60 cases.

The best scenario is to build 2 new servers.

1. 2012 R2

1. 2016 or 2019

Inbetween of the 2008R2 and 2012R2, is the 2012, you dont need to do the jump to that, because the JET DB was not upgrades that much, but it was highly changes in the 2016 platform, hence the "jump" step from 2012R2 to 2016 or 2019, depending on what OS version you are aiming at.

Again:

Comming form below 2012 R2, then you have to do a clean install on a 2012R2 and then from there either inplace or fresh install to the next version you like, so far it is possible to go directly to 2019 from 2012R2 but not from below this version.

My environment is an offline root CA, a server running as the issueing CA, and then a third server hosting the CRL. I assume I will need a new 2012R2 server each of those, following the documented migration steps of moving the data and configurations over.

@RasmusJohnsen I am the Feature PM at Microsoft for ADCS and I need to point out some issues in your replies:

When migrating from 2008R2 to 2016 or 2019 the interim step of going to 2012R2 first is not required. That interim step is only required if you're starting with 2008 or earlier.

Your comment about removing all but the 4 entries from the registry backup is also not required.

Your reply regarding using certutil to add custom templates after a migration is a workaround and not a real solution. Occasionally, during a migration a couple of things may happen that prevent you from being able to publish custom templates with the GUI. One solution is to use ADSIEdit and navigate to CN=Configuration | CN=Services | CN=Public Key Services | CN=Enrollment Services. Right click the CA in the right pane that you want to enroll from and click properties. Find the flags attribute; and verify that it is set to 10. If it isn’t set to 10, then set it to 10 using ADSIedit.msc and allow for Active Directory replication to complete. The second thing to try is to run certutil -setreg ca\setupstatus +512 on the CA.

@RasmusJohnsen I'm not going to argue about this with. As I said, I own Active Directory Certificate Services at Microsoft and this has been tested, and yes, when migrating from 2008 R2 to 2016 or 2019, you do not need the interim step of 2012 R2. The Jet database change that requires this step was implemented after 2008 was released and before 2008 R2 was released.

@Paul_Adare, Hi Paul, since you own ADCA at MS and know better than anyone else, I have two questions.

We currently have 1 root offline CA and two online CA in AD. They are Windows 2008 R2. I understand there isn't any new certificate templates from Windows 2008 R2 to Windows 2012 R2 CA. After I introduce a new Windows 2016 or Windows 2019 online CA server in AD, are there going to have any new enterprise certificate templates that we should be aware of?

Secondly, which is the best practice recommended by MS? 1) do an in-place OS upgrade from Windows 2008 R2 to Windows 2012 R2 to Windows 2016/2019? or 2) build a new Windows 2016/2019 CA then migrate the CA role from Windows 2008 R2 CA? or either one should be fine?

@Dean Chen No, there are no new templates, though that really doesn't matter since you can take any default template and modify it for pretty much any use you need. Some will require less editing/changing than others but that's about it.

My personal preference is to avoid in-place upgrades, especially those that start with more than an N-1 version. Migrating a CA is a fairly painless procedure, and is very well tested and documented. In my team, we have a specific policy of not doing in-place upgrades on our CAs. Note that this should not be considered official Microsoft guidance, just my preference, established over 20 some odd years of experience.