Migrate SBS 2011 Standard to Windows Server 2016


Your trusty old SBS 2011 is finally being retired. It had a good run. It probably still works but you cant get the parts, and the cloud is so appealing and for whatever reason you have, you are putting in a new on premises DC.

Hey, you don’t have to justify it to me. Chances are you shipped Exchange off to the cloud long ago, your clients never really ‘got’ SharePoint and SQL was just used by the backup software and WSUS.

The only thing we want to migrate is Active Directory and File & Print services.

Moving to 2016 makes a lot of sense, even if it is not for the seven year slog many of us are used to with our client servers. It is an elegant OS for a less Civilised time. it also gives us plenty of options for cloud integrations that we just don’t have with 2008 R2.

Many of our SMB clients will have skipped over 2012, and 2012 R2, in fact I am just finishing up my last SBS 2008 migration this week. That client has 20 staff and 100mb leased line. They wanted an on premises solution. Now that they have Server 2016 running, we have a lot more scope to link in services like Azure AD even if they don’t know they want them yet.

That’s enough rambling. Lets migrate.

In my lab examples I have a Single SBS 2011 Standard DC, and a Server 2016 Hyper V Server, which will host a 2016 DC and a 2016 File & Print Server.

Prep SBS 2011

The secret to any migration is preparation. In that vein we need to spend a little time checking our 2011 server for anything that might cause us an issue later on.

First thing we are going to do is a System State backup.

I have attached a 120gb USB Hard Drive just for this backup.

Open an Elevated Command Prompt window on your 2011 and enter:

wbadmin start systemstatebackup –backuptarget:f:


When prompted select Y to continue the backup.


On my lab system it took about an hour to complete.


Now we have this, we can go ahead and make system changes and not worry too much about not being able to roll back. Of course this should be a supplement to your already robust backup regime.

Next we look at DNS.

Open up the DNS Manager and find your internal domain name.

We want to make sure we have no left overs from any previous SBS Servers or Domain Controllers.

Go to the properties of your zone, and click on the Name Servers tab.

Well this is embarrassing isn’t it, apparently I did have another server on this network at some point. Long since forgotten.

If you find anything here that does not belong, select the server in question then click the remove button.



Go through every folder in the zone to make sure there are no references to servers that do not belong.


Pay special attention here and don’t get click happy, because there will be multiple entries for the SBS 2011 server in the same folder which we want to keep!


Repeat the process for the zone named _msdcs,yourdomain.local, including checking the name servers tab.


Next we can run everyone’s favourite AD Test tool, DCDiag.

in our CMD window, enter:

dcdiag /e /v /f:dcdiag.log /c


Now we need to review the log.

notepad dcdiag.log


Of course I cannot review your log for you, so this next step is all on you. Chances are, in a single domain controller environment you won’t have any major problems. There is plenty of information out there to solve most things, including the dreaded Journal Wrap.

We can also run a quick netdom command to check the current FSMO role holders, this is unlikely to show up anything you didn’t already know, because SBS would have been complaining wildly about it if there was a problem.

netdom query fsmo


Do you know what functional level your domain and forest are on?

If you don’t have the ActiveDirectory PowerShell Module installed, you should install it right now.

In SBS 2011 the default is 2003 Forest, and 2003 Domain mode. For the next process we need to raise up to 2008.

If you have old 2003 era DCs, now is the time to destroy them.

In an elevated PowerShell, run the following:

import-module activedirectory


In my environment I had already raised the Domain functional level to make use of Fine Grained Password Policies.

Now I am going to upgrade both forest and domain to 2008R2.

$currentForest = get-adforest
$currentDomain = get-addomain
set-adforestmode $currentforest -forestmode 4
set-addomainmode $currentdomain -domainmode 4


Next we can migrate SYSVOL replication from FRS to DFSR which is nicely explained here.

The process consists of running a few commands, and waiting for them to finish, which is my kind of work!

dfsrmig /getglobalstate


This should return that the migration has yet to begin.

Proceed as follows:

dfsrmig /setglobalstate 1


Then wait a minute or two and run:

dfsrmig /getglobalstate


This should return that Step 1 has succeeded and the DFSR Globalstate is ‘prepared’.

Proceed to run step 2.

dfsrmig /setglobalstate 2


Again waiting for this to arrive in the succeeded state.  We can then run a new command to check the status of the migration.

dfsrmig /getmigrationstate


With any luck you will see that ‘migration has reached a consistent state on all Domain Controllers’ which in my environment is great because I only have the one DC.

The final command is:

dfsrmig /setglobalstate 3


This completes our prep on our SBS Server. In summary we have cleaned up DNS of any values pointing to old servers. We have updated our domain functional level, and migrated NTFRS to DFS-R. You can perform another System State Backup at this point if you wish.

Install Server 2016

Next, install your Windows Server 2016 Hyper-V Server. Create a new Guest machine to serve as your Server 2016 DC, if you are not familiar with 2016 yet, I would suggest sticking to the Desktop Experience version.

When you get to Server Manager of your Server16 DC Box. go to local server, enable Remote Desktop.


Next open an Elevated PowerShell window. Enter the following to set your new servers IP Statically:

$currentIP = get-netIPConfiguration
ipconfig /release
New-NetIPAddress -interfaceIndex $currentIP.InterfaceIndex -IPAddress $currentIP.IPv4Address.IPAddress -PrefixLength $currentIP.IPAddress.PrefixLength -DefaultGateway $currentIP.IPv4DefaultGateway.NextHop
Set-DNSClientServerAddress -interfaceIndex $currentIP.InterfaceIndex -ServerAddresses $currentIP.DNSServer.serverAddresses
# end

This will take whatever IP was issued to it via DHCP and convert it to a Static IP.



If you run this command over RDP you will lose your connection temporarily, so i reccomend you run this from a direct VM Connection on the Hyper-V Server.

If you would prefer to manually set the IP of your Server, then do that.

Next we can rename our Server:

Rename-Computer Server16-DC0

rename server

After we restart the server we can install some roles and features.

From an Elevated PowerShell Window:

Add-WindowsFeature AD-Domain-Services,DHCP,DNS,FS-DFS-NameSpace,FS-DFS-Replication -includeAllSubFeature -IncludeManagementTools


Next we can promote our Server16 to be a domain controller.

$currentDomain = Read-Host -Prompt "Enter your internal domain name:"
$cred = Get-Credential -Message "Enter Domain Administrator Credentials"
Install-ADDSDomainController -NoGlobalCatalog:$false -CreateDnsDelegation:$false -CriticalReplicationOnly:$false -DatabasePath "C:\Windows\NTDS" -DomainName $currentDomain -InstallDns:$true -LogPath "C:\Windows\NTDS" -NoRebootOnCompletion:$true -SysvolPath "C:\Windows\SYSVOL" -credential $cred -Force:$true -Confirm:$false -SafeModeAdministratorPassword (ConvertTo-SecureString 'ntADRSM0deP@ssword!!' -AsPlainText -Force)

This will prompt you to enter your internal domain name, and your domain admin credentials.


Of course, with our expert preparation, the install will succeed and you will be prompted to reboot your server.




Logon as the Domain Admin.

Open an Elevated PowerShell window.

Now we can configure DNS Scavenging and a Reverse Lookup Zone if needed, and copy DNS forwarders from the SBS 2011.

$ipv4 = (Get-NetIPAddress -AddressFamily IPv4 | select *)
$ipA = $ipv4[0].IPAddress
$sMask = $ipv4[0].PrefixLength
$ipNet = $ipv4.IPAddress[0].Split(".")
$ipNet = $ipNet[0] + "." + $ipNet[1] + "." + $ipNet[2] + ".0"
$sNet = $ipNet + "/" + $sMask
Set-DnsServerScavenging -ScavengingState $true -ApplyonAllZones -ScavengingInterval "7.00:00:00"
Add-DnsServerPrimaryZone -NetworkID $sNet -ReplicationScope "Forest" -errorAction Stop
Write-Output "Reverse Zone Already Exists"
$pdc = (get-addomain).pdcemulator
$forwarders = (get-dnsserverforwarder -computername $pdc).ipaddress.ipaddresstostring
set-dnsserverforwarder -computername $env:computername -ipaddress $forwarders

You may receive an error if you already have a Reverse Lookup Zone for your subnet, but many people don’t have them.


Now we can set our Destination server to use itself for DNS.

$currentIP = get-netIPConfiguration
Set-DNSClientServerAddress -interfaceIndex $currentIP.InterfaceIndex -ServerAddresses $currentIP.IPv4Address.IPAddress


Referring back to an earlier post I did, i was reminded of another bit of PowerShell to setup DHCP.

Whilst that is certainly useful, I decided to spruce it up a bit and I have now built a new script that will pull all of your existing DHCP Configuration from the Source server using NETSH and then import that into the Destination server.

Once processed it then proceeds to disable DHCP on the Source server. It leaves the scope and settings intact, so if you want to roll back simply enable the DHCP Server service on the Source server and you are back where you started.


It seems even though we have configured DHCP with PowerShell we need to complete the post install wizard in Server Manager.

Just click through the pages without changing anything.


Next we take a look at something I had to learn the hard way.

You may be familiar with EFS, Encrypted File System. Ok, you may have heard of EFS but in practice I think people using it are few and far between. EFS provides an interface from within File Explorer to Encrypt your files and folders. EFS uses digital certificates as the keys to encrypt and decrypt the files.

As a precaution to potential data loss, EFS provides something called a Data Recovery Agent, which is a nominated account that also has a key to unlock the files. By default the built-in Administrator account is recognised as the EFS recovery Agent.

That is relatively straight forward, however…. Did you know that the EFS Recovery Agent Certificate is only available on the FIRST Domain Controller promoted into that domain.

It is fair to say a topic like this really deserves its own post, of which there are plenty from folks much smarter than me.

I can, however, show you how to backup this certificate and keep it safe, which you can read here.

Once we have dealt with the drama of our EFS Recovery Agent, we can look at migrating our Certificate Authority.

The migration article is quite straight forward to follow.

We start off by backing up some data from our Source Server, tweak some settings and then restore the data to our Destination server.

First on our SBS Server we will backup the CA Database and Private Key, from an elevated command prompt:

certutil -backupDB c:\caBackup
certutil -backupKey c:\cabackup


Next, stop the CA Services.

net stop certsvc

Next backup the CA registry settings.

reg export HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc c:\cabackup\CA.reg


The next step in the TechNet article relates to using a custom CA Policy.inf file, on my SBS I did not have one so I will assume you also do not have one, so move along.

We now come to uninstall our Source CA. From an elevated PowerShell Window:

Import-Module ServerManager
Remove-WindowsFeature AD-Certificate


As the output suggests we should now reboot our SBS 2011.

I have copied the CA Backup folder from my Source server to my Destination server and Now we can begin restoring things.

On our Destination server we can Add the Certificate Services role.

Add-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools


Next, we can use this command to complete the install of our new CA.

Install-AdcsCertificationAuthority -CAType EnterpriseRootCA -CertFile C:\cabackup\trsbs11-SERVER-CA.p12 -CertFilePassword (read-host "Set user password" -assecurestring)


Next we can restore our DB Backup.

net stop CertSvc
certutil -f -restoreDB c:\cabackup


Open your Source CA.reg file in notepad.

The TechnetArticle on this process is uncharacteristically vague about this next step.

Some registry parameters should be migrated without changes from the source CA computer, and some should not be migrated. If they are migrated, they should be updated in the target system after migration because some values are associated with the CA itself, whereas others are associated with the domain environment, the physical host, the Windows version, or other factors that may be different in the target system.

In my Source CA.reg I modified two lines only.

"DisplayName"="Active Directory Certificate Services"


Save your changes to the CA.reg file and import the file.

reg import c:\cabackup\CA.reg


Now start the service.

 Start-Service CertSvc


You can test the issuance of a certificates by requesting a new certificate from MMC Certificates for the Local Computer. I requested a new DC Certificate and it was issued without any problem!


At this point it might be a good idea to let the dust settle for a week before moving on to remove the SBS from the network.


A few days have now passed and I am ready to proceed with the decomission on the SBS Server.

As I said at the beginning of the post, I am assuming you have already taken care of removing Exchange and SharePoint, to the degree that either they are uninstalled, or there is no data left in them you need to keep.

Moving the FSMO Roles is one of the last tasks you should do, because as you may recall SBS must be the FSMO Holder for your domain.

Once we have transferred the roles to our Destination server, we can shut down the SBS Server for another few days to make sure everything still functions as expected.

From an elevated PowerShell window:

Move-ADDirectoryServerOperationMasterRole -Identity $env:ComputerName -OperationMasterRole 0,1,2,3,4 -confirm:$false
netdom query fsmo


Once you are happy your environment can sustain the loss of your SBS Server, it is time to run that final DCPromo, and commit the SBS to the great Data Center in the sky.

On the SBS itself we want to put the DNS Server address to the Destination Server, which we cannot do with PowerShell but we can use NETSH.

netsh int ip set dnsservers "Local Area Connection" static primary

set dns client 1

Then run DCPromo.

Make sure to leave the ‘Last DC in the Forest unchecked’ and complete the wizard.




Goodnight, sweet prince.


PS. You can go ahead and remove it out of the domain into a workgroup, or just turn it off and delete the account from AD.

delete account

About Robert Pearman
Robert Pearman is a UK based Small Business Server enthusiast. He has been working within the SMB IT Industry for what feels like forever. Robert likes Piña colada and taking walks in the rain, on occasion he also enjoys writing about Small Business Technology like Windows Server Essentials or more recently writing PowerShell Scripts. If you're in trouble, and you can find him, maybe you can ask him a question.

Leave a reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: