Active Directory Migration from SBS 2008 or 2011 to Windows Server 2016Alex Fields
There are three basic options for migrating Active Directory from Small Business Server–(1) you can move into Windows Server Essentials or (2) Windows Server Standard. Furthermore, (3) you can move to Windows Server Standard, and enable the Essentials Experience role afterward, which is what I typically recommend if you are interested in the Essentials features.
The steps for a migration are covered in this guide–for any of these configurations. Note: Whether or not you plan to use the Essentials Experience role on Windows Server Standard, you would begin by completing the steps under Part 1. Otherwise, if you are just installing Windows Server Essentials edition, and not Standard edition, you can start at Part 2. If you do not care to have the Essentials Experience, and just want to move to Standard, you would skip Part 2.
Before you begin
- Make sure your firewall is setup to allow DNS traffic outbound from the old (source) as well as the new (destination) server
- Make sure you’ve reviewed recent event logs and checked out the health of your source domain controller using DCDIAG
- Your source server should be up to date with all critical & security patches
- Windows Server installation should already be completed on the destination server
- Static IP address should be configured on the destination server
Summary of the steps in this process
- Migrate to Windows Server Standard as your new Domain Controller, without the Essentials Experience role
- Migrate to Windows Server Essentials or Essentials Experience as your new Domain Controller (Optional)
- Update DHCP scope options / DNS
- Transfer FMSO roles to the new server
Step 1. Migrate to Windows Server Standard as your new Domain Controller, without the Essentials Experience role
To begin, simply add the Active Directory Domain Services role to your Windows Server Standard Server. From Server Manager Dashboard, Add roles and features.
Once that is completed, again from Server Manager, find the tasks button in the upper right, and choose Promote this server to a domain controller.
Be sure to select the option to join an existing domain, and provide necessary domain administrative credentials.
Warning: If you are deploying this server as a virtual machine, it is recommended that you store the AD database & SYSVOL files on a non-system volume (e.g. E:\ instead of C:\). Otherwise, you can accept the defaults, ignoring warnings about DNS delegation, etc. and proceeding to the end of the wizard.
After the wizard is completed with its tasks, you can reboot the destination server. There is one more setting to check. On both source & destination servers, from the Control Panel > Network Connections, verify your TCP/IP settings and ensure that both servers are listed for DNS server addresses.
You should also run DCDIAG and repadmin /replsummary to verify the health of the new domain controller.
Step 2. Migrate to Windows Server Essentials or Essentials Experience as your new Domain Controller (Optional)
In order to do this migration, you will need to install Windows Server Essentials or Essentials Experience in “migration mode”–which means you do not manually join your new server to the domain prior to running the Essentials setup–installing/configuring Essentials will do that for you. However, if you already installed Windows Server Standard and ran through the steps in Part 1 above, you can now add the Essentials Experience role using Add roles and features from Server Manager:
After the installation is finished, you have a task to complete in Server Manager: Configure Windows Server Essentials.
It will detect that you are installing it as a domain controller and complete a series of configuration tasks for you in the background–good time for a coffee or tea break.
Note: if you just wanted to install Essentials Experience as a member server, you would join Windows Server Standard to the domain first, then add the Essentials Experience role and run the configuration second. It will detect that you are installing it as a member server, and the configuration will still be automatic. It is now supported to run the “Essentials goodies” such as integrations with Microsoft Online services, in either case.
Step 3. Update DHCP scope options / DNS
Since the old server is going away, you will want clients to stop referring to it for name lookups. If anything is statically configured to reference this computer for DNS, be sure to update those devices. For client connections that receive these settings automatically via DHCP, you can adjust the settings from the DHCP console > IPv4 > Server Options. Remove the old server’s IP, and be sure the new server is listed–if not, then add it now. Also check out the Scope Options in case there are settings in there as well.
On the source server, check the Properties on the DNS server object, and go to the Forwarders tab–make sure the old server is also not being referenced in here. Remove it if so.
Step 4. Transfer FMSO roles to the new server
The easiest way to do this, by far, is PowerShell. From the destination server, open a PowerShell session (Run as Administrator), and type the following command:
Move-ADDirectoryServerOperationMasterRole -Identity “DestinationServerName” –OperationMasterRole 0,1,2,3,4
Replace “DestinationServerName” with the name of your new server.
At this point, you are basically done with migrating the Active Directory & DNS roles to the new server. It is a good idea to run DCDIAG and Best Practice Analyzers (BPA) to verify your setup, on each of the roles you have installed in Server Manager.
Please note: after you complete the rest of your migration (Email, Companyweb, DHCP, files, remote access, etc.), then you will need to remove Active Directory and DNS from the source server. That process will be covered later.
Hi, thank you for a great article. I want to add a 2016 server to my sbs2008 domain. My idea was to add it as a DC only now and then wait with installing the Essentials Experience until the SBS is ready for removal. (I want to have it as an extra DC because warranty is expiring on the old server soon) Reading above I am a bit unsure about the right procedure step 1 vs. step 2. Can I add it as a DC manually now and then after maybe moving FSMO roles etc. to the new 2016 server install Essential Experience later with all its functionality.
Yes, you can add the AD/DNS roles to the server first, and add the Essentials Experience role afterward, even much later down the road if you so choose–and it can be done before or after the FSMO have been transferred. Actually, waiting on FSMO transfer is probably a good thing if the SBS will be around much longer. I am thinking about updating these steps such that the FSMO transfer happens once you’re ready to decom the SBS box–toward the end of the process rather than toward the beginning. Since I usually complete these moves over just a couple of days typically, it doesn’t matter so much, but if there will be many weeks or months before SBS is retired, I would leave the FSMO where it is until which time you’re ready to decom.
Thanks a million, this made it nice and easy to follow.
Hi. What have you found to happen with user profiles (on PCs) after such a migration? I was just thinking of when they login to the new server for the first time. If everyone gets a new SID, I think that means a new profile for every user on every PC.
Does the name of the new domain influence this at all (and is there anything wrong with using the same domain name)?
If a new SID is forced, maybe that’s actually a good (cleaner) thing in an AD migration, especially if it’s a big leap (2003->2016)? (There are workstation tools that are supposed to make dealing with profiles a snap, such as Forensit Profile Wizard, so it wouldn’t necessarily mean a lost day.)
There’s another method for AD migration using a MS tool called ADMT (you mentioned it once in connection with Single Label Domains), but it’s considerably more involved (based on the documentation anyway) than what you’re describing here. It does SID history, but it may not be worth it.
Interested in your thoughts. Thanks.
Hi Rick! In this article, the migration I am describing does not require you to create new user accounts. When you add a new domain controller into an already existing forest/domain, all of the directory information is automatically replicated to the new domain controller, user SID’s are all the same. If you were to stand up a brand new domain, in a separate forest, then you would have the issue you’re describing–I would not use the same domain name in that case. The ADMT would allow you to migrate objects between these forests (requires a trust be setup between them first), and preserve the SID history.
The other method for “new domains” is to “forklift” the objects and resources (e.g. manually create objects 1 for 1 and re-apply permissions and settings, then disjoin/rejoin computers to the new domain). In very small environments this is surprisingly popular, probably because ADMT is a lot of work to setup, and looks scary to a lot of folks besides. The forklift method is also nice in that it gives you a chance to clean up stale objects, attributes, group memberships, Group Policy and so on.
Thanks for the amazing article. My two cents about FSMO Roles and steps to transfer FSMO Roles.
Great article. I’m in the middle of migrating a client off SBS2011 into a real Active Directory environment. I only have an issue with the timing of one of your steps which is the migration of the FSMO roles. I would save this one until last (after migrating ALL other server files, email, web, etc.). The reason being, when you migrate the FSMO roles off a SBS, you have 7 days until the server starts rebooting regularly (every 30 or 60 minutes) because it doesn’t hold FSMO roles.
Funny you should say that, I originally had this step placed at the end, under the decom article, but then I had a commenter on this article ask “where is this step?” Ah well. can’t make all the people happy all the time. I settled on this order, simply because I am usually migrating everything within 2-4 days anyway. But, are we sure this behavior is still the case with 2011? I think that was true in older versions, but I’m not sure it applies anymore. Would be interesting to find out…lab it up!
Great Article Alex, I am planning an upgrade from SBS 2008 to Server Standard 2016 DC.
I will be following your guide in this process. We are moving to on-premise Exchange 2016, and it would appear that ex-merge mailboxes to PST for import into the new Exchange server is our best bet.
i’ll be setting up a lab to test the migration.
Yes, if you wanted to migrate natively from SBS 2008 / Exchange 2007, you would need to introduce a 2013 server first, migrate to that, and then migrate to 2016… But in the case you describe, you would need to completely remove Exchange 2007 from SBS before introducing the 2016 server. This will also remove attributes like proxyAddresses which belong to the accounts, as well as delagets and other permissions/sharing that is setup. So you might need to take notes of the environment, maybe export the proxyAddresses, etc., as well as the PST files. Personally, I would probably choose the 2013 route instead, using that as a stepping stone to 2016, but I have been described as overly cautious by many–just my nature.
Yes, I was thinking of going to Exchange 2013 as a stepping stone to 2016. Plus we still have a few outlook 2007 clients, these desktops will be upgraded to win10 and office 2016 but I will need exchange 2013 in the meantime. I think you can never be too cautious with production server environments.
Make sure that your SBS2008 Forest is at Server 2008 level. Otherwise it will fail even if it is only stated as a warning.
This is false. You can also migrate from 2003 straight to 2016, and therefore 2003 functional level is sufficient. From this source:
Windows Server 2016 requires a Windows Server 2003 forest functional level. That is, before you can add a domain controller that runs Windows Server 2016 to an existing Active Directory forest, the forest functional level must be Windows Server 2003 or higher.
Migrating away fro SBS 2011 has always worried me, especially if it breaks Exchange. I need to separate up SBS 2011 so we have a DC on windows 2012 R2 and initially leave the existing Exchange 2010 SP3 intact. Once the FSMO and other roles have been migrated to the new DC, would you just uninstall SBS 2011 and would this leave the original SBS 2011 server still joined to the domain with Exchange 2010 intact and operational on what would now just be a windows 2008 R2 Server.
Unfortunately if you transfer FSMO and attempt to remove AD/DNS roles from your SBS server before Exchange is decommissioned you will have issues. It is far better to migrate Exchange first, before migrating AD.
I am in the process of migrating SBS2008 and shutting down it eventually. I have already got the 2012R2 machine as the DC with DNS and DHCP moved over. I will be moving FSMO roles and then retiring the SBS2008 for good soon. Now, how do I remove the SBS GPO objects (CSE Policy and User Policy) that come with SBS2008? Thanks for help.
You can just delete the links in GPMC.
Great Series Alex – I’m in the process of moving off a very sick SBS 2008 physical server to a 2016 STD physical server. Email was moved out years ago, Exchange 2007 (a legacy artifact that sat there for years not used, but created mailboxes when ever a new user was added through the SBS Wizard) got removed today after banging on the Exchange 2007 Powershell cmd line for hours, and the Remove Roles Wizard (really? A Wizard – surely something happened to make the job interview for this employee go side ways) broken all to Hell and Gone, so moving the ADCS function and removing the same has been a Goat Rope. All of the work and subsequent posting you have done helps a great deal. I get ADCS running correctly on the new DC, I can move the FSMO roles. The SBS 2008 can then be relegated to the Dustbin of History and be dimly visible in my rear view mirror…hopefully?
I migrated from SBS 2008 to Server 2016 with Essentials role and Office 365 several months ago using your guide. We had to leave the SBS in place for a LOB application, so I left transferring the FSMO roles until the application was no longer needed.
I have am just trying to do this but when I run the powershell command on the new server I just get the following error..
Move-ADDirectoryServerOperationMasterRole : Unable to find a default server with Active Directory Web Services running.
At line:1 char:1
+ Move-ADDirectoryServerOperationMasterRole -Identity “lbtserver” -Oper …
+ CategoryInfo : ResourceUnavailable: (lbtserver:ADDirectoryServer) [Move-ADDirector…ationMasterRole],
+ FullyQualifiedErrorId : ActiveDirectoryServer:1355,Microsoft.ActiveDirectory.Management.Commands.MoveADDirectory
Any ideas what might be causing this?
You probably need some kind of PowerShell update or something on that old box. We’re talking 2008? Not 2011 (which was 2008R2 basically)? I almost never have this issue with 2011, but I don’t really come across too many 2008’s anymore. Note that you can also just transfer FSMO the old fashioned way. GUI offers ways to do this, or NTDSUTIL is probably quicker. I usually opt for NTDSUTIL in older environments, I moved the PowerShell when I started moving people off of 2008R2.
Thanks for the reply, yes it is SBS 2008 not 2011, I think you are right it must be a powershell issue, the GUI method works fine.
However I have now discovered that the SYSVOL and NETLOGON shares/data have not copied over from the SBS server to the 2016 server, so looks like I am going to have to manually set up the shares and replicate the data.
Have you come across this before and do you know the steps to resolve it?
Do not attempt to manually copy this data. You can use the burflags reset method to trigger another brand new replication event, setting the source server as authoritative.
Hi Alex and supporting IT friends,
Thank you for your work on this comprehensive guide. It’s really good.
I’m migrating from SBS2011 to O365 with Business premium license with 29 seats. How should I procceed if I want to end up using Windows Server Standard 2016 with Essentials Experience role?
We do not want the exchange on-prem
My steps are for the moment:
-move the email with remote move (sync once and then migrate)
-setup new server with domain controller/dhcp/dns and windows server standaard with the essentials experience role installed
– decom the SBS2011 server
-Manage users and mailbox objects with the Essentials Dashboard and password sync enabled.
So the question is: When do I start to use the Essentials role? Is that before the migration or after the migration of the mailboxes?
I usually do email first, and then be sure to remove the Azure AD Connect tool which will get installed in order to perform remote move, before removing Exchange from the source environment. Other roles can be completed anytime after Exchange move is done, and you can enable the password sync feature last of all (though these days I usually just install the Exchange hybrid, which is free, and it can go on the DC even). Either way–I usually finish email before going onto the other roles.
HI Alex, great walkthrough for sbs migration!
Part way through this (from SBS 2008 to 2016) and getting stuck on SYSVOL replication – turns out the source server FRS is in Jrnl Wrap Error – 13568 . Being as this is SBS 2008 and there are no “good” DCs to to a burflags auth restore etc from what is the best way or resolving this? Restoring an old backup ? Looking at event logs this has been an issue for quite some time. Have exported policies from GPMC before I started migration. May have access to an old enough backup – but is several months old.
Still using FRS rather than DFS-R? I wonder if a conversion to DFS-R is possible in this state, and if that could do the trick?
thanks for all the valuable information.
Currently we are in the process to move from 2008 SBS to 2016.
We still have the below roles running on our 2008 SBS:
– Print Service
– AD CS
I am wondering whether the Filesharing and Print Service will still continue to work after decomissioning/removing the AD/AD CS/DNS roles?
Is it actually possible to remove AD/AD CS/DSN when still having the other roles active?
Or should AD/AD CS/DSN be the very last?
I would normally finish moving file and print sharing before decom of AD/DNS, etc.
Thanks for this article, it’s very helpful. I wonder if you are still answering questions on it, after all this time!
After migrating the SBS AD to 2016 and removing the old SBS server, there seems to be a small problem. What would you advise about the AD structure as seen in AD Users and Computers? For example, when adding a machine to the domain, sometimes it will end up in the domain\Computers OU, sometimes in the domain\MyBusiness\Computers\SBSComputers OU. How would you advise to fix this? I can see there would be problems applying and linking policies, but in this domain, thankfully there aren’t many in use. Shouldn’t there be just one default OU for Computers? And Users?
Alex, we have a situation where we are performing this very similiar process and both sysvol folders are empty, and there are errors regarding file replication as a result. any thoughts?
Before migrating make sure that you can pass BPA. Then, once you have migrated do the same. If you see empty SYSVOL, etc. you may need to run BURFLAGS reset.
I’m planning on migrating my fathers SBS 2008 server to a new server with Windows Server Standard 2019.
Do the same steps apply for Windows Server Standard 2019?
Mail will be migrated to Office 365 and the new server will have the AD Connect tool for syncing of credentials.
Then later when all files, shares and other services are moved to the new server, I will decom the SBS by moving the FSMO roles to the new server.
Thanks in advance, kind regards,
Most likely it would still work since AD technology is 20 years old and hasn’t changed that much. But I honestly have not (and will not) be deploying any 2019. Moving to full on Microsoft 365 instead of local servers.
This is just a heads up if you are migrating from old SBS 2008 or similar to 2012R2 server AD/DC or newer that uses DFRS. FRS is deprecated. FRS is used in older servers. This explains it better: http://www.rebeladmin.com/2015/04/step-by-step-guide-for-upgrading-sysvol-replication-to-dfsr-distributed-file-system-replication/
I ran into an issue whereby as I was moving the DC and all the FSMO roles to the new 2016 Std server from SBS 2007 server, I noticed the SYSVOL and the NETLOGIN dirs were not migrating over. After checking the repadmin and other tests, researched and found that old server tech uses FRS to replicate, and the newer version use DFRS so it was not working. In my case, I I found an article that manually replicates the directory’s using reg changes. However, I would assume the migration utilty mentioned above would be more helpful.
Hope this helps someone out there.
Yes, most should have gotten rid of FRS long ago, but I suppose it is still possible to come across it. Any proper migration to 2008R2/SBS 2011 should have included move to DFSR.
Thank you for this information. You have been really helpful to me. I have an SBS 2011 server and I plan to migrate it to a 2016 Essentials. I have email migrated to the cloud and Exchange uninstalled. I have the destination server in place, but when I do the install I do not get an option to use “migration mode”. I do the install and click to start the Essentials configuration and it tells me that the domain already exists on the network. How do I properly do the migration in this case? I can’t find anything on my Google searches that answer this.
Okay, It appears that Essentials 2016 does not have a migration mode. I have found the steps for this and it appears to be working fine.
Hello, i’ve got the same problem.
What are the steps for this?
This article implies that the new install will recognize that you are doing a migration because you are on a network with an existing AD domain. However, I don’t think that happens. I studied the steps in the this blog post and https://blogs.technet.microsoft.com/sbs/2014/02/21/deploying-windows-server-2012-r2-essentials-in-an-existing-active-directory-environment/. Following the steps in these articles I was able to easily and successfully migrate from an SBS 2008 to a 2016 Essentials while my 2008 was in the process of failing which made it pretty interesting. When done, I followed https://www.itpromentor.com/sbs-decom/ to finish off the old server.
Thank you. I will try it this way.
Just follow the steps–if it finds the domain that is a good thing (that’s called “migration mode”), if your plan is to migrate the domain roles from 2011 to 2016. If you wanted to start a brand new fresh domain that would be different.
Hi. thanks for the article, much appreciated. I just wanted to know your thoughts on the implications of migrating SBS 2011 to Server 2019, and the deprecation of WSEE, and thus the lack of the “Implement Group Policy” from the Dashboard. Which group policy objects should be removed after the decommission, and which are important to remain; specifically Folder Redirection, default domain policy, WSUS policies, SBS client policies with regards to firewall settings and specifically how this ties in with new WMI filters with regards to Windows 10.
Many thanks, Doug.
Yes, thank you for the question. My thoughts are this: don’t use Windows Server at all anymore, if you can avoid it. Migrate to Microsoft 365 Business.
Thanks for your reply, not sure I understand ?
We already have a new Server 2019 & prefer a site based server not a 365 subscription.
Will your article work for our migration ?
By the time WS 2019 came out I had already moved on to Azure AD / Microsoft 365. Honestly don’t think I’ve deployed 2019 even once. I assume not much has changed from 2016. Legacy AD is a product that basically worked the same way for 20 years. I am happy to say we’re leaving it behind. Others I work with still do some with Server OS, but not me.
Thank you for your guide on Active Directory Migration from SBS 2008 or 2011 to Windows Server 2016.
I have 3 questions.
1. Exchange server 2007 on the SBS server is no longer used as we moved to a 3rd party cloud Exchange services a while ago. Should we leave it in place for the migration or uninstall it first ?
2. Do we need to copy the shared folders & map drives from the old to the new server ?
3. The Server 2019 standard as a different name, will this effect the DC ?
Thanks in advance for your guidance
1. You should remove it
2. Yes move the shared files to your new server, otherwise you would need to keep the old server, right?
3. As long as all the references that point to the server are updated, for example mapped drives, etc., then name change doesn’t matter.
Thank you for this and other articles. As a former MVP back in the Windows NT 4.0 days I know it is a lot of work.