Step-By-Step: Migrating The Active Directory Certificate Service From Windows Server 2008 R2 to 2019
Published Jun 18 2019 12:01 AM 330K Views
Microsoft

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. This post contains steps on migrating the Active Directory Certificate Service to Windows Server 2019 that contains the same name. Check out this new post detailing steps on migrating the service to a newly named server should that be required.

 

Step 1: Backup Windows Server 2008 R2 certificate authority database and its configuration
 

  1. Log in to Windows 2008 R2 Server as member of local administrator group
  2. Go to Start > Administrative Tools > Certificate Authority
  3. Right Click on Server Node > All Tasks > Backup CA
     
    Certification Authority Backup CACertification Authority Backup CA
     
  4. Click Next on the Certification Authority Backup Wizard screen
  5. 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 SelectionCertification Authority Backup Wizard Item Selection
     
  6. Click Next
  7. Provide a password to protect private key and CA certificate file and click on next to continue
  8. Click Finish to complete the process

Step 2: Backup CA Registry Settings

 

  1. Click Start > Run > type regedit and click OK
  2. Expand the key in following path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc
  3. Right click on the Configuration key and click Export
  4. Provide a name, save the backup file and then click on save to complete the backup
     
    Backup CA Registry SettingsBackup 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 completeCA Backup complete

 

Step 3: Uninstall CA Service from Windows Server 2008 R2

 

  1. Navigate to Server Manager
  2. Click Remove Roles under Roles Summary to start the Remove Roles Wizard, and then click Next
     
    Uninstalling a CAUninstalling a CA

  3. Click to clear the Active Directory Certificate Services check box and click Next
     
    Removing Active Directory Certificate ServicesRemoving Active Directory Certificate Services
     
  4. Click Remove on the Confirm Removal Options page
  5. If Internet Information Services (IIS) is running and you are prompted to stop the service before you continue with the uninstall process, click OK
  6. Click Close
  7. 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
 

  1. Log in to Windows Server 2019 as Domain Administrator or member of local administrator group
  2. Navigate to Server Manager > Add roles and features
  3. Click on next to continue in the Add Roles and features Wizard
  4. Select Role-based or Feature-based installation and click next
  5. Keep the default selection from the server selections window and click next
     
    Windows Server 2019 Server SelectionsWindows Server 2019 Server Selections
     
  6. 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 ServicesAdding Active Directory Certificate Services
     
  7. Click Next in the Features section to continue
  8. Review the brief description about AD CS and click next to continue
  9. 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 ServicesWindows Server 2019 Add Role Services
     
  10. Review the brief description about IIS and click next to continue
  11. Leave the default and click next to continue
  12. Click Install to begin the installation process
  13. 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

 

  1. Navigate to Server Manager > AD CS
  2. In right hand panel it will show message as following screenshot and click on More
     
    AD CSAD CS
     
  3. Click on Configure Active Directory Certificate Service …… in the pop up window
     
    Configure Active Directory Certificate ServiceConfigure Active Directory Certificate Service
     
  4. In the Role Configuration wizard, ensure the proper credential for Enterprise Administrator is shown and click next to continue
  5. Select Certification Authority and Certification Authority Web Enrollment and click next to continue
  6. Ensure Enterprise CA is selected the setup type and click next to continue
  7. Select Root CA as the CA type and click next to continue
  8. 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 ConfigurationAD CS Configuration
     
  9. Click Import in the AD CS Configuration window
  10. 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 CertificateImport Existing Certificate
     
  11. With the key successfully imported and select the imported certificate and click next to continue
  12. Leave the default certificate database path and click next to continue
  13. Click on configure to proceed with the configuration process
  14. Close the configuration Wizard once complete

 

Step 6: Restore CA Backup

 

  1. Navigate to Server Manager > Tools > Certification Authority
  2. Right click on server node > All Tasks > Restore CA
  3. A window will appear confirming the stop of Active Directory Certificate Services. Click OK to continue.
     
    Confirm stop of Active Directory Certificate ServicesConfirm stop of Active Directory Certificate Services
  4. Click Next to start the Certification Authority Restore Wizard
  5. 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 WizardCertification Authority Restore Wizard
  6. Enter the password used to protect private key during the backup process and click next
  7. Click Finish to complete the restore process
  8. Click Yes to restart Active Directory Certificate Services

 

Step 7: Restore Registry info

 

  1. Navigate to the folder with the backed up registry key and double click > Run to initialize the restore
  2. Click yes to proceed with registry key restore
  3. 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.

 

  1. Under Server Manager, navigate to Tools > Certification Authority
  2. Right click on Certificate Templates Folder > New > Certificate Template to Reissue
  3. From the certificate templates list click on the appropriate certificate template and click OK

 

This concludes the Active Directory Certificate Service migration steps

 

The following video also shares steps surrounding this process as well as migrating DNS.

 

109 Comments
Copper Contributor

Hi Anthony,

 

Great!

Thanks for the information and article.

 

Best Regards

Copper Contributor

Does it matter if new server and old server have different names?

Microsoft

@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.

Copper Contributor

@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!

Copper Contributor
You say that the servers have the same name but in the screenshots, don’t the servers have different names?
Microsoft

@Crchad Thank you for the heads up.  I updated the note found in the beginning of Step 4 to address this.

Copper Contributor

@Anthony BartoloWill be nice on blog post with the different server name also to describe upgrade CA from SHA1 to SHA2 of the root certificate. Thanks!

Copper Contributor

great article, thank you. I take it the process is the same for any subordinate CA's? And should the subordinates be done after the root CA?

Copper Contributor

Yes, is it the same for Offline root CA @Anthony Bartolo ?

I have a customer that i will migrate next week and they have a Offline root CA and a publishing CA.

Copper Contributor

what are thoughts about doing an in place upgrade from 2012 R2 to 2016?

Copper Contributor

@Anthony Bartolo  Any update regarding our questions for Offline Root CA?

Microsoft
Microsoft

@christianjonsson Still working on the research.  Stay tuned.

Copper Contributor
@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!
Copper Contributor

@rdp21915I have seen this same topic regarding the JET DB only one other time when researching this topic.   located here

https://social.technet.microsoft.com/wiki/contents/articles/37373.migrating-ad-certificate-services-...

 

I have not performed this upgrade yet but would like to here Anthony's response.

 

Microsoft

@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. 

Copper Contributor
@Anthony Bartolo Thanks Anthony! I appreciate the quick response.
Copper Contributor

Thank you, Anthony.

I have also read an article about upgrading the CA from 2008 to 2012, then 2016/2019 before reading your article, which I thought was a welcome relief.

 

I patiently await the result of your research on this topic.

 

Regards,

 

Okei

Copper Contributor

Any updates on the questions regarding;

1) what about if the root is offline?

2) is it the same process to migrate the intermediate CA server?

3) can I use a different server name for either of the above? (my friendly names on both are not linked to the server name in any way)

 

My environment is a 2008R2 offline root, and 2008R2 intermediate and ocsp responder servers. All of which I would like to get onto Server 2019.

Copper Contributor

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. 

 

Copper Contributor
Thanks to all who have provided information so far, a comprehensive guide that includes answers for the queries raised by @Thepkiguy above would be very handy.
Copper Contributor

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. 

Copper Contributor

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.)

 

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ee...

Copper Contributor

Oh nice, thank you!!  I'm doing all these upgrades to the OS as they are Server 2008R2, and so I'm getting off of that prior to January 2020 when it's EOS. 

 

 

Copper Contributor

Has anyway found a good tool for certificate expiration notification. SCOM is worthless

Copper Contributor
@bradfore44, PRTG Network Monitor is a useful tool as they have a SSL certificate monitor for websites, I have used this several times. Otherwise you could create a scheduled task that periodically runs a powershell script based on some of the information in https://blogs.technet.microsoft.com/scotts-it-blog/2014/12/30/working-with-certificates-in-powershel....
Copper Contributor

@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.)

Copper Contributor

We have just 1 enterprise CA on 2008R2 for years now.
It's working fine.

I want to go to Windows 2019.

While backupping everything I found that I don't have a capolicy.inf file.

@Thepkiguy Is that a problem?

Copper Contributor

Not a problem Rob. Not every deployment/CA has a capolicy.inf. 

Copper Contributor

this guide is not going through all the needed steps for this to work out.

 

1. Yes you need to do a complete install on a server 2012 r2 before going to a server 2016 or 2019.

 and the steps on a server 2012r2 is the same going forward.

 

!!Important make a copy of the reg file!!! we need 2 of them, that is the best solution.

2. Before you install the CA roles on the new server (2012,16,19...) you need to import the reg entries into the regedit db - BUT you need to remove some of the entries first. 

- in the reg file under the first : [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration]

there is 14 items, you need to cut them down to only 4, these in specific:

"LDAPFlags"
"DBFlags"
"WebClientCAName"
"WebClientCAType"

 

Still with their values in the end of them. the sub folder in the regedit file are still there!!

Save the reg file and execute/merge it into your regedit on the server.

 

3. now go on an install the CA roles.

service will not start  = ok (see event viewer, error/warning = ok for now)

 

4. restore the CA DB.

 

5.  now execute/merge the backup reg file with all the items in, not the edited file from before.

 

6. start the CA service 

 

wolla :)

 

 

quick tip:

If you are going to have the server name changed, you have to change all the entries in the full, and edited reg file by search and replace, before you have them merged/imported into the regedit db.

 

 

 

 

Copper Contributor

update if you are missing CA templates after the deployment then either go into the ADSI for the confuguration of your AD DC server under : 

adsi -> configuration -> services -> public key services -> certificate templates  ->in there is all your templates self made and auto generated

 

The self made ones you need to import by powershell(admin mode) on your CA server:

 

certutil -SetCAtemplates +your-template-name

 

if your have a template name with () you need to do this:

 

certutil -SetCAtemplates +'your-template-name'

 

 

Copper Contributor

@RasmusJohnsen yes, that worked! Now SCCM clients are working again;)

Copper Contributor

Hi there,

 

I also have to migrate my Root-CA from Win-Server 2008R2 to 2019.

Is it really necessary to first (inplace) migrate to 2012R2 and then I would be able to migrate to 2019? 

 

Did anyone of you experience the JET-database issues trying to migrate the ADCS directly from 2008R2 to 2019?

 

What about you @Anthony Bartolo ? Are there any updates to the known issues?

Would be great if you can update your Blog :)

Thanks and regards,

Florian 

Copper Contributor

#flo_nuernberg

 

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.

Copper Contributor

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? 

 

Thanks

Copper Contributor

Hi GGearon,

 

I have not been able to get that to work out, I have only seen 2 cases out if “100” that have been able todo so. So the short answer us - No.

 

the time it takes for an inplace upgade is as close to a complete new installation, if you already have the deployment settings (SCCM , gpo settings, etc) setup. 

No you Van skip the 2012 version and jump to 2012R2. 

Current server: 2008R2 -> 2012R2 fresh install.

from this point inplace upgrade, or fresh install again to either 2016 or 2019.

 

the point here is that 2012R2 have a lot of changes to the JET DB. Hence we cant skip that point.

 

Copper Contributor

Hi GGearon,

 

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.

 

 

 

 

 

 

 

Copper Contributor

Awesome Rasmus thank you. 

 

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. 

Copper Contributor

Great topic/clear instructions, thanks Anthony!

Did you have a chance to write related article about scenario where the [destination] server name is different?

Copper Contributor
Alexander-A

 

If you are going to have the server name changed, you have to change all the entries in the full, and edited reg file by search and replace, before you have them merged/imported into the regedit db.

 

 

You can read the full explaniations in 9 comments up from here.

Copper Contributor

Does this process work for migrating from a Windows Server 2008 32bit RootCA to a Server 2019 RootCA? 

Copper Contributor

Yes it does.

Microsoft

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

 

  1. 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.
  2. Your comment about removing all but the 4 entries from the registry backup is also not required.
  3. 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.

Hope these clarifications help you folks.

Copper Contributor

@Paul_Adare 

I am getting ready to migrate a 2008 32bit CA to Server 2019.  Do I need to go to 2012 R2 first complete they migration and then upgrade to Server 2019.

Thanks

 

Nate

Microsoft

@Nathan Lamonski Yes, you can only skip the 2012 R2 step if you're starting with 2008 R2. Anything prior to that requires the 2012 R2 interim step.

Copper Contributor

Paul_Adare

No you can't, if you have 2008R2 CA server you can not skip the 2012(R2) step.

 

maybe on paper but not in real secanario.

Microsoft

@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.

Copper Contributor

@Paul_Adare 

 

Thanks for the clarification and probably saved me a major head ache had I skipped 2012 R2.

 

Nate

Copper Contributor

@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?

 

Thank you!

Dean

Microsoft

@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.

Co-Authors
Version history
Last update:
‎Jul 09 2021 12:30 PM
Updated by: