Recovering ConfigMgr 2007 onto a new Server OS? Read this!

I have been recently engaged on a ConfigMgr 2007 SP2 w/R3 migration from a 32bit server to a new 64bit VM guest and boy it was tough going!  Throw into this job the fact we are migrating from Server 2003 to Server 2008 R2, SQL 2005 to SQL 2008 R2 and we have a potential nightmare.  If you think you know how to pull this whole trick off successfully, but haven’t actually attempted it – then think again!  Read on…

In this scenario, the Microsoft Technet Library for ‘Planning for Backup/Recovery’ of a ConfigMgr 2007 environment is sadly lacking in guidance – and if you follow the standard ConfigMgr Backup/Restore guides which are out there then you WILL end up with what appears to be a sucessful migration – until you dig a little deeper.

Many customers will be taking advantage of the Operating System Deployment features that ConfigMgr provides – and this is where problems will likely be noticed first following a migration to a new Server OS.  Typically, you will see within the SMSTS.LOG on the client that it is failing to use or decrypt the Network Access Account required for systems within WinPE to access network resources.  Clearing and re-entering the Network Account credentials does not resolve the problem.

When ConfigMgr is first installed onto the OS, private and public encryption keys are created to protect the Network Access Account credentials (and other user accounts specified within ConfigMgr) – these keys are unique to the current combination of the OS installation and ConfigMgr installation.  If you proceed to restore your ConfigMgr data over the virgin ConfigMgr installation then your restored encryption keys are also restored – which are no longer valid for this installation.

Now, this isn’t a problem because after performing your fresh ConfigMgr 2007 SP2 installation but before running the Site Repair Wizard you knew to take a copy of the hidden “srvacct” folder in the root of the ConfigMgr installation folder, which we can use to resolve this problem.  You didn’t?  Well, this is not surprising as this snippet of critical information seems missing from any article in the Technet Library for ConfigMgr or various blogs about ConfigMgr Site recovery.

Your best efforts at resetting the Client Network Access Account credentials, performing Site Resets and Googling the problem will eventually lead you to this recent article:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;2509330

Like me, you probably reached the ‘Resolution’ section, read the first paragraph and ‘Step 1’ and then promptly proceeded through your entire vocabulary of curses, expletives and profanities.  Yep, you just wasted a day or so of getting your new Server up and running, with SQL, ConfigMgr, FEP etc. Bad Times indeed.

I eventually resigned myself to following the above article and spent another day configuring a freshly provisioned 2008 R2 Server with IIS, SQL Server 2008 R2, WSUS, ConfigMgr 2007 SP2, Restored Forefront Endpoint Protection 2010, R3 and all associated Hotfixes, copying the “srvacct” folder, performing a Site Repair, replacing the “srvacct” folder and finally performing a Site Reset – which by the way took several hours due to a site reset causes the Distribution Manager component to verify the package signatures on all Branch DP’s!  There is a Hotfix available for ConfigMgr 2007 SP1 which also requires setting a registry key to circumvent this behaviour – however at this time I’m not sure if the fix/reg key is applicable to SP2:

http://support.microsoft.com/kb/969163

After all of this work above, I retried building a machine and I still see the same issues prior to getting any task sequence displayed – however, after regenerating the task sequence boot media we were all systems go!

Phew!  What a marathon – if only Microsoft offered some clearer guidance on migrating to new hardware a lot of the initial effort would not have needed to be redone.  You learn something new every day!