AD CS Migration: Preparing to Migrate

Updated: June 22, 2012

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012

To reduce the duration of the migration process, you can complete the procedures detailed in this topic before beginning the migration process and taking the certification authority (CA) offline.

The hardware requirements to install any of the Active Directory Certificate Services (AD CS) role services are the same as the minimum and recommended configurations for installation of Windows Server 2008 R2. This section includes the general hardware recommendations for Windows Server 2008 R2. For detailed requirements, see Windows Server 2008 R2 System Requirements (

In addition to the hardware requirements for the operating system, consider these storage and performance requirements for optimal CA performance and availability:

  • The disk space requirements for a CA database depend on the number of certificates that the CA issues. Because a CA stores certificate requests, the issued certificates, and optionally, archived key material, 64 KB of database space per certificate is recommended.

  • The operating system, the CA database, and the CA log files should be stored on separate physical disk drives in a multidisk configuration. For optimal CA performance and reliability, consider a redundant array of independent disks (RAID) system, such as RAID 5 for the CA database and log files and RAID 1 or RAID 0+1 for the operating system. A recommended minimum hard disk speed is 10,000 RPM.

  • Processor power is generally more important to CA performance than system memory capacity.

  • Failover clusters have additional hardware, software, and networking requirements. For more information, see Failover Cluster Requirements (

  • If a hardware security module (HSM) is used by the CA, consult with your HSM vendor to verify compatibility with Windows Server 2008 R2.

Enterprise CAs can be installed on computers running Windows Server 2008 R2 Foundation, Windows Server 2008 R2 Standard, Windows Server 2008 R2 Enterprise, Windows Server 2008 R2 Datacenter or any version of Windows Server 2012. Enterprise CAs cannot be installed on computers running Windows Web Server 2008 R2.

When AD CS in Windows Server 2008 R2 or Windows Server 2012 is installed in an Active Directory Domain Services (AD DS) domain, the AD DS schema version must be at least 30 and all domain controllers in the domain must be running one of the following operating systems:

  • Windows Server 2012

  • Windows Server 2008 with Service Pack 1 (SP1)

  • Windows Server 2008

  • Windows Server 2003 R2

  • Windows Server 2003 with Service Pack 2 (SP2)

  • Windows Server 2003 with SP1

  • Windows Server 2003

Domain controllers running Windows 2000 Server with Service Pack 4 (SP4) or Windows 2000 Server with Service Pack 3 (SP3) are technically compatible with AD CS deployments. However, the use of Windows 2000 Server is not recommended because Mainstream Support is no longer available for this operating system. For more information, see Microsoft Support Lifecycle (

If an HSM is used by the CA, consult your HSM vendor to verify cryptographic service provider (CSP) and key service provider (KSP) compatibility with Windows Server 2008 R2 or Windows Server 2012 depending on the operating system to be used.

To reduce the duration of the migration process, you can prepare the destination server by completing the following procedures before beginning the migration process and taking the source CA offline.

If you are migrating to a Server Core installation you should configure the server for remote management, which is disabled by default.

  1. Log on as an administrator.

  2. Type sconfig.cmd and press ENTER.

  3. Perform the following tasks by completing the procedures described in Configuring a Server Core installation of Windows Server 2008 R2 with Sconfig.cmd:

    1. Configure network settings as required for your environment.

    2. Join the server to your domain. This step is required if you are setting up an enterprise CA and optional if you are setting up a standalone CA.

    3. Configure Remote Management to enable MMC Remote Management or Server Manager Remote Management.

    4. Enable Remote Desktop (optional).

  4. Type 13 and press ENTER to close sconfig.cmd.

For information on configuring remote management in see Configure Remote Management in Server Manager (

Back up your source server to prepare for recovery of the source CA in the event of migration failure.

For information about backing up Windows Server 2012, see Windows Server Backup.

For more information about creating backups in Windows Server 2008, see the Windows Server Backup Step-by-Step Guide for Windows Server 2008 (

For more information about creating system state backups in Windows Server 2003, see article 326216 in the Microsoft Knowledge Base (

Detailed procedures for backing up the source CA database, private key, and registry settings are provided in the topic AD CS Migration: Migrating the Certification Authority.

To reduce the duration and impact of CA migration, the following procedures should be completed before you begin migration:

  • Back up the CA templates list (required only for enterprise CAs).

  • Record the CA's CSP and signature algorithm.

  • Publish a CRL with an extended validity period.

An enterprise CA can have certificate templates assigned to it. You should record the assigned certificate templates before beginning the CA migration. The information is not backed up with the CA database or registry settings backup. This is because certificate templates and their association with enterprise CAs are stored in AD DS. You will need to add the same list of templates to the destination server to complete CA migration.

It is important that the certificate templates assigned to the source CA are not changed after this procedure is completed.

You can determine the certificate templates assigned to a CA by using the Certification Authority snap-in or the Certutil.exe –catemplates command.

  1. Log on with local administrative credentials to the CA computer.

  2. Open the Certification Authority snap-in.

  3. In the console tree, expand Certification Authority, and click Certificate Templates.

  4. Record the list of certificate templates by taking a screen shot or by typing the list into a text file.

  1. Log on with local administrative credentials to the CA computer.

  2. Open a Command Prompt window.

  3. Type certutil.exe –catemplates > catemplates.txt and press ENTER.

  4. Verify that the catemplates.txt file contains the templates list.

    If no certificate templates are assigned to the CA, the file contains an error message: 0x80070490 (Element not found).

During CA installation on the destination server, you can specify the signature algorithm and CSP used by the CA, or accept the default configuration. If your source CA is not using the default configuration, then you should complete the following procedure to record the CSP and signature algorithm.

If an HSM is used by the source CA, follow procedures provided by the HSM vendor to determine the HSM CSP.

  1. Log on with local administrative credentials to the CA computer.

  2. Open a Command Prompt window.

  3. Type certutil.exe –getreg ca\csp\* > csp.txt and press ENTER.

  4. Verify that the csp.txt file contains the CSP details.

Before beginning CA migration, it is a good practice to publish a CRL with a validity period that extends beyond the planned migration period. The validity period of the CRL should be at least the length of time that is planned for the migration. This is necessary to enable certificate validation processes on client computers to continue during the migration period.

You should publish a CRL with an extended validity period for each CA being migrated. This procedure is particularly important in the case of a root CA because of the potentially large number of certificates that would be affected by the unavailability of a CRL.

By default, the CRL validity period is equal to the CRL publishing period plus 10 percent. After determining an appropriate CRL validity period, set the CRL publishing interval and manually publish the CRL by completing the following procedures:

Record the value of the CRL publishing period before changing it. After migration is complete, the CRL publishing period should be reset to its previous value.

Client computers download a new CRL only after the validity period of a locally cached CRL expires. Therefore, you should not use a CRL validity period that is excessively long.

After completing the procedures to prepare the source and destination servers, you should review the topic AD CS Migration: Migrating the Certification Authority and complete the procedures appropriate for your specific migration scenario.

Community Additions