SBS 2011 - Essentials 2012 Migration

Back in the Server 2003 era when the 500 account (usually "Administrator") was still in use by many people, it was a good idea to sync your DSRM password with this domain Administrator password in case you needed to perform an AD Recovery at some point.

Now, as the 500 account is disabled when AD is installed in current Server operating systems, this recommendation is no longer possible.  What we do here is use a DSRM password that is specifically *not* one of the Domain Admin passwords and make sure it is recorded.  All of these passwords are over 16 characters and those characters come from all 4 groups - upper case, lower case, numbers and special characters.  We do this simply for added security to the core of the network - the Active Directory.  It also means we can change our regular domain admin accounts and not need to concern ourselves with the DSRM password needing updating, though this synchronizing can easily be handled via scheduled PowerShell scripting or via Group Policy.

So, when migrating from SBS 2011 to Essentials 2012, the migration will fail at 48% and report that your DSRM password is not long enough.  This error is *incorrect* as that is not the issue at all here.  The actual issue is that the administrative account you're using to perform the migration has a password that is different from the DSRM password - and that is not the error message that Microsoft is reporting here.

So, *BEFORE* you start an SBS 2011 (or even an SBS 2008 or SBS 2003(1) or any Server Standard) to Server 2012 Essentials migration, I'd strongly recommend you do the following:

1. If the source server is a 2003 Server product, ensure you have a domain administrator account who is *NOT* the 500 user (generally "Administrator") and use the credentials for that account for the migration.  We'll assume this user is named "Derp" for the purposes of this exercise.  Make sure the 500 account and the Derp user are using the same password.
2. If the source server is a 2008 or 2008 R2-based server, then you should already have this user, and we'll use "Derp" for this administrative user in this exercise.
3. In an elevated command prompt on the source server, type the following command, substituting your actual administrative account for Derp:
   

   ntdsutil "set dsrm password" "sync from domain account Derp" q q

4. If the FSM was looking down on you and smiling, you should see the following results:
   

   C:\Users\Derp>ntdsutil "set dsrm password" "sync from domain account Derp" q q
   ntdsutil: set dsrm password
   Reset DSRM Administrator Password: sync from domain account Derp
   Password has been synchronized successfully.
   
   Reset DSRM Administrator Password: q
   ntdsutil: q

5. Assuming all other prerequisites have been successfully completed, you should be able to proceed with the migration without it failing at 48% with an incorrect error message.

In the steps above, you could (if you wanted) replace the "Derp" with "domain\Derp" where "domain" is your internal domain, but as this step is being performed on the source server itself, this is not required.

(1) Please be aware that I personally wouldn't be migrating any 2003-based servers to Server 2012 Essentials - I'd likely just do a fresh install.  The main reason for this is that we have no clients running  SBS 2003 that we had originally installed - we've already migrated them to SBS 2008 or SBS 2011 or full server products.  We do have a small number of SBS 2003 clients that we gained after the SBS 2003 was established, and as I'm not a fan of migrating someone else's AD configuration (normally because there's things I'd like to change - like their internal domain name), Therefore I've not actually tested this procedure on an SBS 2003 network, so the above procedure may well not be all that's needed, nor may it actually work if your Source Server is SBS 2003 - there may well be other issues that need addressing and if I come across them, I'll update this post.


Regards,

The Outspoken Wookie