Checklist: Preparing for the Migration from SBS to Office 365 & Windows Server 2016

Before you begin your migration from SBS 2008/2011 to Office 365 and Windows Server 2012 R2 or 2016, it pays to set aside 2-3 hours to review the existing environment, look for pitfalls, and set out your plan of attack. This is a checklist that helps me do just that.

1. Planning: Begin with the end in mind

Some of the oldest sage wisdom is still the best. Review your migration path and network architecture options.

• Do you require Windows Server Essentials or Standard Edition?
• Will your new server be located On-premises or in the Azure cloud?
• Which Office 365 plan do you intend to buy?
• Which migration method do you plan to use for Exchange mailbox data?
• Are you going to enable full Directory Synchronization, or just use Essentials integration?
• Will you be adding redundancy / fault tolerance to your design?

You might also consider using Visio or similar software to draw up a diagram of where you are ultimately headed. It acts as a good goal post, and serves as network documentation at the end of the project, as well.

2. Backups: Confirm good backups before you start

Ensure your backups are working & up to date. If you do not manage a third-party backup, then from the SBS Console in 2008/2011, navigate to Backups & Server Storage. You can configure backup on a schedule or take a one-off backup to an external drive. Even with third party solutions present, I will do this anyway as extra insurance.

3. Run Windows Updates

From the Control Panel, run Windows Updates on the source server. Make sure you have the latest service packs & update rollups applied, and that your critical and security patches are up-to-date.

4. Diagnostics: Download & Run BPA

The best way to run diagnostics is to use tools such as DCDIAG and BPA (Best Practice Analyzers). These will alert you to any obvious issues in your environment, as well as provide links or tips about how to remedy them.  It is worth cleaning this up in advance of your project, as much as possible.

• SBS 2003 BPA tools are here
• SBS 2008 BPA tools are here
• SBS 2011 BPA tools are here

5. Review Group policy, then back it up

SBS comes with some pre-configured Group Policies, and they probably include things like redirected folders and some other stuff. Look in the Administrative Tools > Group Policy Management console and make sure you get an idea of what special settings are being applied, and the file paths that are being referenced and where. Go ahead and back up the GPO’s while you are in here. Right-click on Group Policy Objects, then Backup all…

Later, SBS policies will be removed and replaced with the WSE policies in Windows Server Essentials, or just by creating your own in Windows Server Standard. But it is always good to have these backed up just in case you need to restore or refer back to them.

Note: If you are migrating from SBS 2003, check for the Logon as a service account setting under the Default Domain Controllers Policy. Right-click the policy and choose Edit. Navigate to Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment. Clear the Define these policy settings check box. This setting will remain on the old SBS server, but should not be applied on the new replica domain controller.

6. Review Logon scripts (will be removed later)

Sometimes logon scripts are defined in group policy, other times you will find them in the properties of a user account object (Profile tab) in Active Directory Users & Computers. Also check \\sbsserver\SYSVOL\domainname\scripts. You will remove all references to these and other logon scripts during the migration, unless you are aware of custom configurations that you know should be kept.

 7. Review mailbox sizes & archive

If any of your mailboxes exceed about 15-20 GB in size, it can really stretch out your Exchange data migration timeline. I recommend archiving old items in these mailboxes to help drive down the amount of data that you need to migrate. To quickly see mailbox sizes listed in descending order of size, run the following PS command from the Exchange Management Shell:

Get-MailboxDatabase | Get-MailboxStatistics | Sort-Object TotalItemSize –Descending | ft DisplayName,TotalItemSize,ItemCount

Have your “heavyweight” users follow instructions to archive their old items; they can be re-imported post-migration, if so desired. Note that mailboxes have an overall limit of 50 GB in Office 365.

• Outlook 2010
• Outlook 2013, 2016

 8. Enable Remote Management

Although this is not strictly necessary, it can be helpful to have Remote Management enabled on the source & destination servers. In SBS 2011/ 2008 R2, you can enable this from Server Manager, or with PowerShell (as Administrator):

Set-ExecutionPolicy RemoteSigned -force
Configure-SMRemoting.ps1 -force -enable

In Windows Server 2012 R2 or 2016, you can run:

Configure-SMRemoting.exe -enable

9. Plan for time synchronization

When you install a replica Domain Controller to replace your source SBS server, if the time is out of sync between your servers by more than 5 minutes, your domain will become… sort of… how do I put this? Worthless.

Your new server will likely be built on Hyper-V, and by default virtual machines running on the host will sync their time settings to the physical server’s hardware clock. This can cause problems with existing Domain Controllers whose time does not match up to that hardware clock. I like to disable Integration services time sync, and make Hyper-V hosts sync with the primary Domain Controller. Furthermore, I set the time authority to sync with a source outside of the network.

If you wish, you can find a fix from Microsoft that will set an external NTP sync partner for your server.  See also: My best practices for time synchronization with virtual Domain Controllers.

10. Contact Line of Business vendors

Who is going to help you move that CRM app, or your Accounting software? Be sure you make contact with these support resources in advance of the project. Sometimes they will provide you with “link support” to articles that will guide you through the process, other times they may have remote support available for completing the migration using screen sharing software, or executing the migration with you over the phone.

11. Map out Roles & Services

Which roles & services are you using on SBS?  How do they map to the new deployment? Will you still need on-premises file shares, or do you plan on moving 100% of documents to SharePoint and OneDrive for Business? Do you still require VPN & Remote Web Workplace / Remote Web Access, or will those features be obsolete moving forward with Office 365? Do you need to contact any Line of Business application vendors? It is worth taking time to make a checklist similar to this:

12. Create a schedule

What gets scheduled gets done. If it has no deadline, the project will drag out forever. In my experience, most Small Business Server migrations can be completed in a single week, but some will take up to two weeks, especially if SharePoint or other Line of Business applications are involved.

For each of the major tasks involved, set aside time during the week(s) to get it done. Here is an example* schedule for a simple implementation of Office 365 for Email + Windows Server Standard / Essentials Experience for everything else:

*Note: This is just one example. Your own situation might be different, and require a different schedule. In general, I prefer to setup the Office 365 portal & Exchange Online migration batch as soon as possible. Then you can focus on migrating server roles & data while you wait for mailboxes to sync to the cloud–which can take (in some cases) several days to complete.

Conclusion

What do you think? Have I overlooked anything–should anything else be added to this list? A little bit of preparation goes a long ways toward a successful project. I hope you’ve found this overview helpful. Good luck with your own migrations!