Migrating PKI from Windows 2003 to Windows 2008 R2

Many customers are running into the need for a Windows 2008 or newer PKI infrastructure in order to enroll and auto enroll newer client operating systems like Windows 7, Vista, and Windows 2008 Server.

Actually, many business customers found the lack of certificate support in Vista (without upgrading their CA's later) as one of the reasons it wasn't business ready. With Windows 7 being almost 10 years newer than Windows XP, many business customers are ready for a software refresh and Windows 7 has enough other appealing features to help that decision along.

There are basically two routes to go; in place upgrade or migration. The only time I would attempt an in place is on a VM so that a snapshot could easily be taken and rolled back in the case of a failure. A migration gives a fresh start, but requires some additional time to complete because between steps you need to wait for certs to issue to clients.

Because certificates are fairly sensitive information, I won't post screen caps, but rather overview the process.

Research and Design

Research what your existing CA is in use for. Anything it has issued needs to be either determined to be invalid (expired, not in use, not needed) or documented as something to replicate on the new CA. The other decision on design is around what CA architecture and hierarchy you want or need. Depends on the size and complexity of your organization this can differ greatly. For most organizations under 2000 users, I would say a single CA is sufficient, and if an additional are needed, use the PKI planning guides that Microsoft provides, or better yet, read Komar's 2k8 PKI book.

Implement and Re-Issue certs

Depending on your usage, this could take a long time. Audit existing certificates, revoke the ones that are not in use or expired, and start re-issuing them on the new CA architecture. For larger organizations, this may take months to complete. Luckily, you can choose to have both CA's active. I recommend changing the certificate templates on the old CA to read only, and no longer allow enroll and auto enroll as you migrate each template type successfully, this way, the old CA still validates certificates issued that you haven't updated while you can work on updating them, without any noticeable downtime.

Decommission Legacy CA

The "easy" part for sure. Removing a CA (Unlike uninstalling Exchange) there are no checks or audits to make sure you did everything correctly. If you didn't notice that your Cisco ASA or VPN Concentrator had a certificate issued and miss it, it may cause some issues for you. I recommend stopping and disabling your legacy CA for a few days or even weeks (this depends on your comfort level, and organization) before you make the decision to decommission. Even then, before you decommission, I would also really recommend taking a complete backup of the server.

If going to Exchange 2007 - Windows 2003 or Windows 2008?

I had a customer ask this very question, and I replied with this. Feel free to comment and add any pros/cons you can think of.

Pros of deploying Exchange 2007 on Windows 2008:

Quicker deployment time � Win 2003 requires IE7, IE8, SP2, and about 55 patches to get it current. This speeds initial deployment, but more importantly in a crisis when you need to redeploy, you won�t need to wait as long for patching procedures. Additionally to this point, 2008 keeps the OS CD installed to a hidden directory unlike 2003 that will prompt for a CD when you add/remove features like IIS. Windows 2008 also has command line deployment for most Exchange pre-req�s so that spin up time is pretty quick.
Longer solution shelf life � Windows 2003 support lifecycle policy is to end support 2 years after the last Service Pack. SP2 for 2003 released in March of 2007. So unless we see SP3, at this point, Windows 2003 is already out of support. We typically attempt to deploy solutions that last the 3-5 years most organizations amortize their hardware.
Less known bugs/exploits available � granted, with newer OS, there is an inherent risk of a newly found exploit being found, but there is a LOT more know about 2003 code now.
Options to change after are limited � if you go 2003 now, and later want to move to 2008, there is no in place upgrade of the OS on an Exchange 2007 server � it would be decomm a server, rebuild as 2008 and repurpose. Far easier to start off at the end point of OS.

Cons of deploying Exchange 2007 on Windows 2008:
Cost - Your first Windows 2008 server means you need to migrate all of your CAL's to Windows 2008. For smaller organizations, or anyone with their CAL's on a Software Assurance plan, this is VERY easy. If this is an unexpected expense, Windows 2003 may be your only path.
Newest stuff - If you are of the "Wait for SP1" mentality when it comes to Microsoft products, you likely will have a hard time with this decision.
Missing skillset - If you have never run Windows 2008, there is a slight learning curve. And I do mean slight - most things are VERY similar, but if admin skills are a concern, sticking to what you know may be appealing.


Again, PLEASE comment, I know this is controversial for some folks.