Hi! As part of Windows 2003 domain DC's replacement, I have to move MS Certificate Services (Enterprise root CA) from a root AD domain (domain.net) DC to another server (Windows 2008). The customer is using 3rd party smartcards to logon to their windows workstation, (see MS article Guidelines for enabling smart card logon with third-party certification authorities), so the MS CA only publishes Domain Controller certificates to the DC servers in the child.domain.net domain. The CRL lifetime settings and CDP paths have been updated from their default values, for example the CDP's now include a UNC fileshare in every DC in the child domain. The new server name will be different to the old one (unless you point out that it is not possible). Can I just remove the CA role and then install CA role to new server, as LE2Strat wrote in article http://social.technet.microsoft.com/forums/en-us/winserverDS/thread/7E8B15EC-C1AA-4368-9B38-BB89E9EB9418 If that is true, the following questions arise to me: 1. Would it be wise to install the new Enterprise Root CA with a different CA name, just for clarity and maybe, to prevent conflicts in the DC's that use the DC certs? 2. Do I just need to walk thru every child domain DC and then issue a "Request new Certificate" command in the Certificates MMC? 3. What are the risks, as I have to do this in production and there are thousands of users logging to their 3rd party smartcards to their XP workstations every day? Kind regards, Kari

Take a look at migrating CA to another server. http://awinish.wordpress.com/2011/02/05/migrateupgrade-ca-from-one-2003-to-2008r2/ Design & Implement PKI. http://awinish.wordpress.com/2010/12/29/designing-and-implementing-a-pki/ Regards Awinish Vishwakarma| MY Blog Disclaimer : This posting is provided AS-IS with no warranties or guarantees and confers no rights.

You said that you have got a DC that is a root CA. This is not recommanded for security reasons: a root CA should be offline after installing the secondary CA. Just follow what is mentioned in this Microsoft article in order to backup and restore the certification authority on a new SERVER. Like that it will be your new root CA. I recommand to you to test that on a test environment before proceeding. This posting is provided "AS IS" with no warranties or guarantees , and confers no rights. Microsoft Student Partner Microsoft Certified Professional Microsoft Certified Systems Administrator: Security Microsoft Certified Systems Engineer: Security Microsoft Certified Technology Specialist: Windows Server 2008 Active Directory, Configuration Microsoft Certified Technology Specialist: Windows Server 2008 Network Infrastructure, Configuration

Hello, please see the following article for upgrade/migration: http://technet.microsoft.com/en-us/library/cc742515(WS.10).aspx For migration to another host machine see "Option A: Migrate the CA to a New Host" in: http://technet.microsoft.com/en-us/library/cc742388(WS.10).aspx Also keep in mind that it is not recommended to install CA role ona DC, better use a memeber server instead.Best regards Meinolf Weber Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights.

Thanks for advices. I'm now training the http://technet.microsoft.com/en-us/library/cc742388(WS.10).aspx with scenario "Move to a computer with different host name" in my virtual test environment. When done, I will do it in production this Wednesday. To talk just in case, what would happen if I created the new CA with different CA name, as in http://social.technet.microsoft.com/forums/en-us/winserverDS/thread/7E8B15EC-C1AA-4368-9B38-BB89E9EB9418 Then test that CDP's are in place and then requested a new certificate on every DC with Certificates MMC. What might happen in the worst case? Might the DC's stop authenticating users that use their 3rd party smartcards on their XP workstations?

If you are going from 32 to 64 bit this is now possible to migrate, it wasn't always possible. So you could go from 2003 (32 bit) to 2008 R2 (64 bit). http://blogs.dirteam.com/blogs/paulbergson/archive/2010/10/18/upgrade-certificate-server-from-32-to-64-bit.aspx The link above will walk you through. It actually points to a Microsoft link. -- Paul Bergson MVP - Directory Services MCITP: Enterprise Administrator MCTS, MCT, MCSE, MCSA, Security+, BS CSci 2008, Vista, 2003, 2000 (Early Achiever), NT4 http://www.pbbergs.com Twitter @pbbergs http://blogs.dirteam.com/blogs/paulbergson Please no e-mails, any questions should be posted in the NewsGroup. This posting is provided "AS IS" with no warranties, and confers no rights.

When I tested the migration as in article http://technet.microsoft.com/en-us/library/cc742515(WS.10).aspx I found that requesting a new Domain Controller certificate (or renewing a previous one) results in a certificate with no CDP field. When I reapplied the reg export file that I had taken as reg backup just after the new server (SRV2) CA installation, then the CDP entries appear in the new certs OK. Double-checking, again when applied the reg file taken from DC1 installation (only the reg entries as in chapter "Restoring the CA Registry Configuration"), the CDP entry does not appear in the new certs. So it seems that the reg file restore from the old server (DC1) somehow breaks the CA installation in new server (SRV2). Any ideas of how to deal with the reg file?

Today we managed to move the Certification Authority from W2003 DC server to another W2003 DC server (both x86's). When tested, Domain Controller certs were able to get from there, with valid DCP's and trustchains. However, the following problems arose during the day: 1. As the windir path in destination server was different to source server, the "Restoring CA Database" section resulted in error "Restore of an incremental image cannot be performed before you perform restore from a full image.", despite of the steps in http://support.microsoft.com/kb/283193. We decided that the CA Database restore is not important, because the root key and cert were got from the source server to the destination server CA installation OK. What difficulties might appear from this? Would the DC's stop authenticating users that logon with their 3rd party smartcards? 2. When we looked at the root cert in the destination server, its CRL LDAP path in the CDP pointed to the old server hostname. We had no idea of how this should be resolved, because the root cert is the one that was created 5 years ago, during the original CA installation, and all the DC certs trustchain end up to that cert. We decided that when the source server is removed from AD, we fake its name with DNS Alias record to point the the new CA servername. Is this OK, or how should this be done? Kind regards, Kari

We now face a situation that we are unsure of what should be done: >2. When we looked at the root cert in the destination server, its CRL LDAP path in the CDP pointed to the old server hostname. We had no idea of how this should be resolved, because the root cert is the one that was created 5 years ago, during the original CA installation, and all the DC certs trustchain end up to that cert. We decided that when the source server is removed from AD, we fake its name with DNS Alias record to point the the new CA servername. This week we tested the DNS Alias and found that it is not the right way to fake the old CA servername anymore. As we have soon to shutdown the old W2003 DC server (the original CA enterprise root server), we face the following problem: How to get the root certificate on the new CA server and the DC certificates on the DC servers so that their trustchain end up with the new CA servername, not the old one? The obvious way might be to start the certificates-MMC and then request new cert with new key, but can we do so? Do it on the root CA server? On the DC servers? We do not want to risk the production environment, where users only use their 3rd party smartcards to logon to Windows. How to do the job right? We are thankful of any information. Kind regards, Kari