How-to migrate Email from Small Business Server 2008/2011 or Exchange Server 2007/2010 to Office 365 with Zero Downtime
Update: Please refer to this newer article. Some of the details here are very dated–like there is no hybrid key anymore–and the activation only works on 2016, not 2019, plus we have minimal hybrid now, etc., etc. A “minimal hybrid” approach is preferred if you’re just doing a quick migration of a small org (under 300 users).
If you are coming from Microsoft Exchange Server 2007, 2010 or Windows Small Business Server 2008, or 2011, then you will be able to take advantage of Remote Move or “Hybrid” migration. Which is excellent news, since it means you will have a very smooth migration experience with no downtime for your Outlook users.
If you do not plan on keeping your Exchange or SBS server around after you finish the migration–no worries! It is technically supported to migrate off this platform and even fully remove all legacy Exchange servers from your environment.
A Hybrid migration has many benefits—mainly, there is no need to visit each user and reconfigure their Outlook profile—this is handled by Exchange. Additionally, for a large number of mailboxes, you will be able to move users in batches—one department at a time for example, and stage the migration over several days if needed.
The purpose of this article is to help you make your hybrid migration a SUCCESS! Here are the migration steps:
- Prepare for the migration & install Exchange
- Configure Directory Synchronization
- Create the hybrid connection
- Create Remote Move migration batch
- Migrate Public Folder data (if applicable)
- Finalize the migration batch & activate mailboxes
- Complete Office 365 setup & cutover DNS
- Post-migration tasks
Step 1. Prepare for the migration & install Exchange
A. Prepare for the migration
If you haven’t already, go ahead and sign up for an Office 365 account online and verify your domain. Also: so many pitfalls can be avoided by taking the following precautions:
- Have a good backup before making any changes–Active Directory as well as Exchange
- Ensure your source server has the latest service packs / updates
- Run Best Practices Analyzer to identify potential issues with the existing configuration
- Review the steps in advance and communicate the plan to stakeholders / end users
If you do those four things first, you will be able to avoid many issues, and recover in case of unforeseen problems.
B. Install Exchange 2013 or 2016
1. On a new virtual machine, download the latest cumulative update, extract it on the server, and install Exchange 2013 (if coming from 2007 or SBS 2008), or Exchange 2016, accepting defaults. Note that you may also need to download and install this prerequisite. Reboot after all installations are completed.
2. You will want to rekey your existing UCC certificate to include the name “hybrid.company.com” as well as the “autodiscover” and “mail” namespaces. Export and import this certificate so that both servers have the same certificate. Make sure you have firewall rules configured (25, 443), and a DNS (A) record for “hybrid.company.com,” pointing to the new hybrid Exchange server.
3. Update the SCP to autodiscover.company.com, from PowerShell:
$ServerName= “EXCH13”
Set-ClientAccessServer -Identity $ServerName -AutoDiscoverServiceInternalURI https://autodiscover.company.com/Autodiscover/Autodiscover.xml
4. Set the virtual directories on the new hybrid Exchange server to use “hybrid.company.com,” and enable Basic authentication on the EWS directory:
$ServerName = “EXCH13”
$HybridFQDN = “mail.company.com” or “hybrid.company.com”
Get-OWAVirtualDirectory -Server $ServerName | Set-OWAVirtualDirectory -InternalURL https://$($HybridFQDN)/owa -ExternalURL “https://$($HybridFQDN)/owa”
Get-ECPVirtualDirectory -Server $ServerName | Set-ECPVirtualDirectory -InternalURL “https://$($HybridFQDN)/ecp” -ExternalURL “https://$($HybridFQDN)/ecp”
Get-OABVirtualDirectory -Server $ServerName | Set-OABVirtualDirectory -InternalURL “https://$($HybridFQDN)/oab” -ExternalURL “https://$($HybridFQDN)/oab”
Get-ActiveSyncVirtualDirectory -Server $ServerName | Set-ActiveSyncVirtualDirectory -InternalURL https://$($HybridFQDN)/Microsoft-Server-ActiveSync -ExternalURL “https://$($HybridFQDN)/Microsoft-Server-ActiveSync”
Get-WebServicesVirtualDirectory -Server $ServerName | Set-WebServicesVirtualDirectory -InternalURL “https://$($HybridFQDN)/EWS/Exchange.asmx” -ExternalURL https://$($HybridFQDN)/EWS/Exchange.asmx -BasicAuthentication $true
5. Set OutlookAnywhere to use the “hybrid.company.com” name, also. I use Basic authentication in this example (works with most firewalls/proxy settings).
Get-OutlookAnywhere -Server $ServerName | Set-OutlookAnywhere -ExternalHostname $HybridFQDN -InternalHostname $HybridFQDN -ExternalClientsRequireSsl $true -InternalClientsRequireSsl $true -DefaultAuthenticationMethod Basic
6. Configure an Internal Relay SMTP connector by navigating to mail flow > receive connectors. Create a new connector on the hybrid server. You need to select Frontend Transport & Custom, and step through the rest of the wizard. Secure externally (by IP address). Include IP addresses that were on the old relay connector. You should also edit the connector and make sure the security is set to include Anonymous permission groups. Devices or apps that relay will also need to be updated to point at the new server.
7. Obtain a hybrid license key from Microsoft, and activate the server. This assumes that you have already purchased your Enterprise Office 365 licenses.
Step 2. Configure Directory Synchronization
A Remote Move migration requires that you enable Directory Synchronization. This will sync all of your existing users into Azure Active Directory for your Office 365 tenant. It also means that your users will be able to maintain the same credentials in the cloud as they have on-premises.
A. Set UPN suffix to match the email domain
Before you proceed to install the Azure AD Connect utility, just be sure that your on-premises users have their UPN suffix set to match the email domain name (e.g. company.com instead of company.local). In Active Directory Users & Computers, check the Properties / Account tab on your users:
If you do not see an option for the email domain name, then you might have to add it from Active Directory Domains & Trusts console. Right-click Active Directory Domains and Trusts, and select Properties. Enter your email domain name and click Add. Click OK.
Note: For best results, the naming convention of the user accounts should also match the Email addresses (e.g. [email protected] vs. domain\MJohnson). If this type of change is required in your environment, it may affect how users log on to Windows in the existing domain.
B. Install Azure AD Connect
Download and install Azure AD Connect on a member server in your domain (some pre-reqs apply) that you plan on keeping around for a while. I usually just install this on the hybrid server. As you complete the wizard, be sure to select the option for Hybrid Exchange, so that it will export the appropriate attributes to Azure Active Directory. Sync your users and make sure they show up in your portal.
Note: At this point in time, do NOT assign Office 365 / Exchange Online licenses to your users.
Step 3. Create the hybrid connection
A. Run the Hybrid Configuration Wizard
We are ready to run the Hybrid Configuration Wizard. You need to download this tool from Microsoft, and run it on the local hybrid Exchange server. Note that if you are launching a shortcut to the Exchange Administrative Center and configuring the Hybrid connection from there, you should update the shortcut to use the Internet domain name (instead of “https://localhost…”).
- This wizard will ask for your local and remote administrative credentials for your on-premises domain and the Office 365 portal.
- Be sure to select the Deliver Internet-bound messages directly… option, unless for compliance reasons you need to relay all mail through the on-premises server throughout the migration.
- Complete the wizard.
Notes on troubleshooting: In case the Hybrid configuration wizard fails, try the following steps.
- reboot the server
- ensure your patches are up to date
- disable SPAM filters and other 3rd-party security software
- double-check your firewall settings
You may even want to open up the firewall a bit in case it is locked down. For example, instead of using an SMTP proxy rule, where it might be applying some software filtering at the perimeter, you could use an SMTP filtering policy instead (simply allowing traffic through–at least from Microsoft IP’s). If none of that works and you are getting a specific error code, Google it or call MS support.
Step 4: Create Remote Move migration batch
You are ready to begin moving data! You also need to create a migration endpoint. Go to the Exchange admin center in the Office 365 Admin portal. Navigate to recipients > migration and find the ellipse (see screenshot):
Step through the wizard to define your on-premises Exchange server as the migration endpoint. Use the Exchange Remote option since this is a hybrid deployment.
After the endpoint is defined, choose the plus symbol and select Migrate to Exchange Online from the drop down.
Select Remote Move migration and step through the rest of the wizard to select your users and begin moving data.
At this point I let data finish syncing, with the option to finalize/complete the migration batch manually at the time of my choosing.
Step 5: Migrate Public Folder data (if applicable)
For migrating Public Folder data, I find that the easiest method tends to be a quick PST export/import process using an Outlook client. Otherwise, you can try the batch method that Microsoft recommends. The batch migration process is somewhat more complex, and I find PST is often faster/easier to do in a Small Business setting. You will need to manually reset permissions after the PST import.
If you have Public Folders to migrate, you need to create a Public Folder mailbox in Exchange Online. Go to Exchange admin center > public folders > public folder mailboxes.
Step 6. Finalize the migration batch & activate mailboxes
If you were able to use the migration batch successfully, you will need to return to the Exchange admin center in Office 365, and complete it. Go back to recipients > migration. Select your batch(es) and move the status to Complete.
Also, in case you haven’t activated your users’ licenses yet, return to the Office 365 Admin center, bulk-select your Users, and click Edit product licenses to apply the Office 365 / Exchange Online licensing. This will activate the cloud mailboxes.
Step 7. Complete the Office 365 Setup & cut-over DNS
As soon as you’ve finalized the migration batch, you are ready to complete the Office 365 setup process you started earlier by verifying your domain. Return to the Office 365 Admin center > Settings > Domains to complete your set up. You will be required to enter additional DNS records with your domain registrar / service provider.
Once you have added the records, simply follow the link at the bottom of this page that says, Okay, I’ve added the records. At this point, mail will no longer be delivered to your on-premises Exchange server, and you are done!
Step 8. Post-migration tasks
As I mentioned, the best part about using hybrid /remote move migration is that users will not be required to setup a new Outlook profile! They will receive a message similar to: An administrator has made a change that requires you to close and reopen Outlook. Upon doing this, they will be prompted for credentials. They should enter their email address as the username along with password, and choose to remember the password. That’s it! So. Much. Better.
A. Reconfigure mobile devices
However, users will still be required to reconfigure their mobile devices. In most cases, this just involves removing and then re-adding the Email account. Assuming you have autodiscover configured properly, this should be pretty straightforward.
If you have to enter manual settings, you would use outlook.office365.com for the server name, and re-enter the email address again if asked to provide a domain\username.
B. Adjust SPF record for SMTP relay (optional)
If you want to continue using your local Exchange server for SMTP relay (scan to email, line of business apps that send email, etc.), then that is completely supported, however just be sure your SPF record includes both the local external IP, as well as Office 365, like this:
v=spf1 ip4:[ExternalIPAddress] include:spf.protection.outlook.com -all
C. Remove Exchange (optional)
Otherwise, if you plan to remove your legacy Exchange server now that the migration is completed, you have an additional procedure to follow, which involves moving the SMTP relay service, and temporarily disabling Directory Synchronization during the Exchange uninstall process.
In Conclusion
If you made it this far, congratulations on the migration! Don’t forget to keep improving–explore what else is new in Office 365. Maybe you will want to configure Mobile Device Management (MDM), Multi-factor authentication (MFA), or turn on Email encryption with Azure Rights Management (RMS). Or check out other add-on features such as Advanced Threat Protection (ATP) to help with emerging / zero day threats.
All of these technologies would have likely represented separate third-party products / investments in the past. Now you can leverage the power of the Microsoft Cloud to easily & cost-effectively deliver them from one place to your end users. How about that?
Comments (107)
You mention needing Exchange 2013 or 2016. Is this true if you are coming from SBS 2011 (Exch 2010)?
The reason I recommend an Exchange 2013 or 2016 server is simply because I assume that you will be keeping it around for a while, whereas you are more likely to be decommissioning / retiring the SBS2011 / Exchange 2010 server (Microsoft’s official stance is that you must keep an Exchange server for management). However, it is possible to use the Hybrid Migration Wizard from any 2010 environment w/ SP3, without adding an Exchange 2013 or 2016 server. Eventually in this case, you will want to follow the instructions to upgrade your legacy hybrid server.
I currently have two email domains on my SBS 2011 server. All users get email addresses for both domains, but we configure each user’s Reply to: address to reflect the email domain for the company they work for.
Business is two different companies owned by the same people, working out of the same physical location.
Do you have any thoughts as to the best way for me to migrate these users?
Yes, you can migrate them exactly as-is. (1) You would just add both UPN domain suffixes via AD Domains & Trusts, and assign the suffixes to the accounts (whichever each user treats as their “primary” SMTP alias). (2) Then, you would verify both domains in the Office 365 tenant (you can add multiple domains through the admin portal after you setup the first one). (3) You would turn on Azure AD Connect, and the accounts should sync up correctly. When you migrate, they will retain their primary SMTP address appropriately, along w/ any configured aliases.
Some things to consider:
As Alexander mentions in his article. AADC must be installed on a member server. The server must also server 2008 or newer.
Also, when setting up AADC you will likely want to narrow the scope of what you synchronize. AADC will sync quite a few items if not limited. I suggest specifying the users you want to carry over via security group membership. Note that this must be done during the configuration of AADC and cannot be done after installed.
If you are able, a hybrid migration is awesome. No reconfiguring Outlook profiles. The only chore is for helping users connect smartphones.
An interesting pitfall I ran into was I recently migrated a customer who had an existing Office 365 environment (but for other businesses). Prior to bringing me on the task to migrate a company to their instance, they had manually added users and licensed them so they showed up as in cloud. This messed up internal mail flow as existing users in Office 365 (in a sister or parent organization) couldnt reach the company that they tried adding on their own as it routed to their newly created mailboxes that no one used yet. Long story short, they unlicensed and delete the users. What this meant for me down the road is that as I brought these users in and attempted to migrate theit mailboxes, it said a mailbox existed already (after applying licensing). The people before me didn’t do a permanent delete on the mailbox item and my batches were failing because of it. I had to redo all of the migration batches because of this information they neglected to tell me. To fix it, I removed users from the sync scope and this caused the users in Azure to go to the recycling bin. I then used Azure PowerShell to delete their account from there. Lastly I deleted theit disconnected mailbox (phew).
Quite the ordeal.
Best of luck on your migration!
??
Why so an migration, for small business it would be better i install a new server with the same accounts an migrate all. Shares etc.MS migrate hier migrate there it’s just silly and may need a days, wenn not months i some bigger company . Errors are programmed.MS just can’t do Windows 10 to Windows 10 Creators clear , Servers it’s just silly.
And the Company want that this can be done in some 2-3 DAys.
Sorry, this comment is a bit hard to understand… It should not take long to achieve the work required to have the migration all staged and ready to go, maybe a single workday, or less. But, how long it takes data to sync into the cloud is totally dependent on the internet connection at your customer’s site–and you have no control over that. It takes the time it takes–once it is fully synced, you can schedule cut-over procedures, maybe another couple hours of work there. Your time investment shouldn’t be too large, but again waiting for data to sync is the bottleneck.
Hi,
Does anyone know if the server essentials role has a limit on the number of O365 users it can work with? I thought I saw somewhere it was a hundred, but I’m having trouble confirming that.
I have a client now with over a hundred Exchange 2010 boxes, and this seems like a great solution for clients who do not want to maintain an Exchange system on prem, but if there is a limitation with this role, I’d have to use the unsupported configuration of keeping ADConnect in place afterward.
In Server 2012 R2 the limit is 100 users for the Essentials Experience role. In Server 2016 this limit has been raised to 500 users. See here.
Hi Alex,
Thanks for the guides, just wondered if you or anyone else could clarify some points that I am not clear on. This is my first attempt at a hybrid migration after many cutover migrations for smaller companies, I am moving SBS 2008 to Office 365.
1. When installing the 2013 server which roles need installing, is the client access and mailbox roles?
2. When configuring the external access for hybrid.clientsdomain.com does this require 2 public IP addresses so that both servers are accessible from the internet, or does mail flow and services switch to the hybrid server?
3. Could you clarify the steps for creating the receive connecter? In particular “Include IP addresses that were on the old relay connector”
Thanks
Jonathan
1. Yes, both CAS and MBX roles should be installed
2. You can do it either way. You can have both names published in co-existence, or you can cutover frontend/CAS role to the hybrid server, in which case you don’t need to add the “hybrid.” SAN name to the certificate at all (it would just take over as “mail.” or whatever).
3. If you have a relay connector configured on the old server that relayed mail from local apps, scan-to-email copiers, etc. then those would need to be added to the new recieve connector (create a frontend / custom type of connector on the new server). You have to specify which IP’s are allowed to relay through it, just like on the old server, assuming that is configured (if not, and you don’t have this need in your environment, then ignore that step).
Can you clarify this further?
For #2, you say you can have essentially the same SSL cert for both servers, using the same names. Which one can get the incoming email, the old on prem or the hybrid Exchange one? If so, and the email flows to and out of the old on prem, does that mean any emails coming in will also go to the cloud account as well until you are ready to cut over the migration? I am considering this for an SBS 2008 migration to cloud, and I am trying to understand the logic of the mail flow. I also thought a cert could only be keyed for a given server and not for different ones.
I trust the Hybrid license applied to the hybrid Exchange server is perpetual? So in reality, even if you get rid of the on prem SBS 2008/Ex2007 server, it can still be used for managing mailboxes on cloud with AD Azure, of course?
And does the Hybrid Exchange contain any of the user’s mailboxes, or is it simply a go between for the on prem 2007 and cloud mailboxes?
Thanks.
DG
1. All mail can remain on the old server if you want, mailflow does not need to be switched to the hybrid server. The only relay in that case from the hybrid server will happen once the mailbox has been moved to the cloud (there are connectors created that relay emails from on-prem servers into O365). 2. You can export and import certs from one server to another and run them on both servers simultaneously–that is completely supported. you may generate and complete a request from one server specifically but once you have it installed you can export/import to your heart’s content. 3. yes the hybrid license is permanent–it does not cover mailboxes on-prem, just hybrid functionality/management UI.
In your reply to Jonathon on Oct 16, items 2 and 3:
For item 2, when you say ‘you can do it either way’, do you mean I could setup a separate public IP for the hybrid server and leave the old server in place, and they both can work? (I have two routers and can do this on the other one and leave the main router in place for the existing email.) I have an SBS 2008 server to migrate, and it would be preferable to leave it alone as much as possible until the migration is completed. Also, I did not know a UCC or SAN cert could work for two different servers. I have one on the existing server with webmail.xxxx.com, autodiscover.xxxx.com, and servername.xxxx.com. Are you saying I can just import this to the hybrid server and use one of those names without re-keying?
For item 3: Assuming item 2 can be done and the existing SBS server can continue with emails and relays, would this still matter until the migration is completed?
I assume from all the above items you pointed out (and very well I might add), this will make SBS 2008/Exchange 2007 a ‘hybrd’ by putting Ex 2013/2016 as the go-between. So no 2007 mailboxes get moved to the hybrd; it just acts as the go-between for the 365 migration. And with the hybrid approach, 2007 mailboxes stay in place, but they can sync to 365 at same time until the cut over occurs?
Just need clarification. I’ve put AD Azure in place. I have been attempting to use the Migration wizard on 365 to create an endpoint for the SBS 2008 server but it will not accept the credentials. Been working with MS support on this for weeks, and no go. This would be for a staged migration mind you, but its looking more and more like I have to approach this with your hybrid approach.
DG
In reply to item 2 – yes, two separate IP’s works; you can add new names to a UCC cert and have the same cert on both servers, or if you have enough names to divide between them that is okay also
In reply to item 3 – for sbs 2008/exchange 2007 it should be a 2013 as the go-between or “bridge” and all mailboxes as well as relaying can remain entirely on the old box
To create endpoints, be sure that autodiscover is working properly using the exchange connectivity tests and also ensure you have the MRS proxy service enabled on the endpoint–if those aren’t in place then endpoint will not create properly
Alex,
I’m migrating from SBS 2008 w/ Ex2007. I’ve installed the latest CU for SP3 and preparing to build my hybrid exchange server.
Do I understand your article correctly in that I can stand up a 2012 R2 server, with Exchange 2013 then install the AAD Connect on the same server?
Then once complete, decom ex07 and migrate SBS following your other outstanding guide
Then keep the hybrid in place with Ex13 and AADConnect and all should be well with the world
thanks
Joe
That is correct.
Hi. Great article. I have one more question.
I am going to be moving mail to the cloud. The current setup is SBS 2008, and thus Exchange 2007.
You said “install Exchange 2013 (if coming from 2007 or SBS 2008), or Exchange 2016, accepting defaults.” I am going to use an Exchange 2013 eval download and then license it with the Hybrid one. I ran the install on a domain-joined VM 2012R2, and in the Prerequisites Analysis I get the following warning:
“Setup will prepare the organization for Exchange 2013 by using ‘Setup /PrepareAD’. No Exchange 2010 server roles have been detected in this topology. After this operation, you will not be able to install any Exchange 2010 servers.”
What worries me is the PrepareAD that will prepare the current SBS 2008 schema, I assume. Will this not affect the current Excahnge 2007 and SBS 2008 AD schema adversely, or is this normal? Should the server not be domain joined?
Your clarification is most appreciated. Thanks again.
DG
The 2013 installation is going to extend the AD schema. This is expected, to hold new information relevant to Exchange 2013. 2013 and 2007 can co-exist, whereas 2016 would not work. The server must be a member of the domain before proceeding with Exchange install.
One more question; so extending the scheme on an existing SBS 2008 network for the Ex 2013 Hybrid will not affect ANY current AD functions, including the Ex 2007 in place? It simply adds the schema needed for Ex 2013, but does not alter anything already in place and running. I have to ask to be sure.
I ask because I cannot have any down time or weird issues from adding the Ex 2013 schema to the existing SBS 2008.
DG
Correct extending the schema does not do anything impactful, it just makes it possible to add a 2013 server to the environment. Once you start adding that server into the mix after that, that’s when you need to be sure to update SCP, Outlook Anywhere, Virtual Directories, etc. But extending the schema is just a pre-req to get rolling.
HI. If you have an Ex2007 server and already have an autodiscover.xxx.com address configured, how does the hybrid Ex2013 work in this instance?
Please assume the plan is to keep using the on prem Ex2007 server as is until the migration is completed: The cert is on both servers, but if the current autodiscover is configured and then you add one for new hybrid, won’t this mess things up?
Also, if you have one router serving the on prem Ex2007, then that is already using port 25 and 443. I am trying to understand (without having to get another router and external static IP for the DNS A records) how the hybrid server would function if it also needs the port 25 and 443 ports?
Thanks.
DAG
I get this question a lot and it may need its own little write-up, but in short, if you only have a single external IP to work with, then you would need to cutover the CAS role, autodsicover records, etc. to the 2013 server, and have all transport / web access switch over to that, just as though you were going to migrate to the 2013 server. But then instead of migrating mailboxes to 2013, you just migrate them to 365 instead. There would not be any conflicts with having the cert on both servers, the DNS record will point to only one or the other server at a time. When you cutover to 2013, it becomes “in charge” of the client connections. If you had two external IP’s to work with, then you can leave everything as-is on the old box, and just let the new server use a name like “hybrid.company.com” and that becomes the migration endpoint, and autodiscover location (but OWA, etc. can stay on the old server).
Alex,
Did you ever write this article you mention in reply23? …(with more info on the different options to migrate when using a single external IP address vs when you have multiple IPs).
I currently have a single external IP, but can add a range from my ISP. However, that would be another whole unrelated task to purchase that and configure the router etc.
If it greatly simplifies things it might be worth while embarking upon that journey, but could just be a distraction which slows down our migration. Basically better understanding the implications both ways, and the options / limitations each provides (single vs multiple IPs) would help me make an informed decision on whether it is worth adding multiple IPs with the added the setup time and costs (or not).
Thanks.
Mike
So many companies out there only have a single IP–it is totally possible to work within that constraint. If you need to insert a new hybrid server, you would just need to cutover frontend services to the new server. It is not necessary to move mailboxes to the new server, just have the NAT rules on the router/firewall pointing to the new hybrid. Otherwise, if you have 2010 or 2013 already, then it is no problem to configure hybrid directly on there, migrate, without adding a server and then trying to put new public IP’s in place.
I had the same dilemma this week performing a migration from SBS 2011 to Office365 with a Hybrid Exchange 2016 server. The company itself had plenty of external IP addresses, but the firewall that was in service wasn’t capable of binding multiple IP addresses to the single WAN interface. It was just an old, junky D-Link that shouldn’t have been there. In fact, part of my gig with the office is to replace the firewall with a new, more capable one. However the e-mail was more important, and I was unable to coordinate time to swap firewalls. So I did something a bit crazy!
On the D-Link, the firewall naturally forwards port 25 and 443 to the SBS 2011 server sitting on the LAN. I opened port 2525 and 4443 and forwarded those to the hybrid server, also sitting on the LAN. “But wait!” you think to yourself. “That’s not helpful. No client or mail server will use those ports!” You are correct. Enter: Haproxy!
I spun up a small cloud server running CentOS and installed Haproxy on it. I created a `tcp mode` frontend / backend for each port. The DNS records for “hybrid”, “autodiscover”, and “mail” all point to the IP address that my temporary haproxy server has, and haproxy is listening on ports 25 and 443 with a frontend clause. It then proxies back to the D-Link’s public IP address over ports 2525 and 4443 respectively. It’s fast and works. Yes, it’s a bit ghetto, but it’s the best I could do without a full Exchange migration from SBS 2011/Exchange 2010 to Exchange 2016, which I was very much NOT interested in doing at this stage of the project.
SBS does not support trust relationships. How do you get around that? During the hybrid setup, it attempts to create a federation trust. This is not supported in SBS.
Well, this is one reason I would use a “hybrid” server as a bridge, as described in this article. However, express migrations do work (which is “hybrid lite”). Even though they say it is not supported, it will work since it really is just an Exchange 2010 Standard server under the hood. But, it is not supported, so I don’t recommend it (using a hybrid server in front of the SBS box is the preferred method).
Is it possible to use only a SBS 2011 Standard Server for Hybrid migration if you intend keeping it for at least a year? I’ve seen several posts that suggest lack of support for Intra-Forest Trust prevents it working and your (excellent) article only describes the process using a second server. Microsoft support didn’t know and referred me to your page :-)
Interesting question. My belief is that this would most likely work, since I have completed hybrid (or express) migrations from SBS 2011 directly, but then decomissioned the server shortly afterward. However, I also believe it would be unsupported to run in this configuration (hence MS would probably be unable to help if you had an issue down the road, and they would refer you to some other dude’s content–maybe mine). For reasons of support and ease of transition, I like to use a hybrid server when it comes to SBS. The only time I don’t is if they are just going to dump their on-premises stuff right after the migration (cloud-only / no on-premises footprint post-migration). If you are going to have an on-premises footprint, then yes you’ll want Windows Server Standard with Azure AD Connect and a supported version of Exchange server.
Hello again. I have followed your instructions above and appreciate all the very wise things mentioned. It helped a lot. I am at the point now with my migration where I am 90% confident of beginning my migration from SBS 2008 via Ex 2013 in hybird mode to 365.
I found that with a test account moved to cloud, that mailbox calendar sharing is tricky to do with existing on prem users. Basically I found out through various articles that giving an on prem user Full Access (and as long they are in sync with AD Azure) that calendar sharing continues to work, but is a bit extreme. The basic suggestion is to move if possible any users who need\have existing permissions to share calendars at same time to 365 to avoid this. If there is any clarification to this, please advise.
This brings me to my next point and questions. I have probably 40 users and a few public folders to move. Not huge, but these users heavily rely on email for their work, so I wanted to go with the least disruptive move as possible. My thinking was move users perhaps in groups, 5 or 6, and then let things live on both on prem and cloud and slowly and surely complete the move to cloud. So having said that, I am confused by the Move and Migration Batch functions.
If I move a user but decide to manually complete the batch at a later time, does this mean the user’s on prem mailbox will get syncd with the cloud mailbox ‘in waiting’ until I decide to finalize the batch and license the cloud mailbox? If this is the case, is there some sort of incremental/delta sync that occurs until I am ready to finalize the batch, and what would be the interval for those syncs?
If the incremental syncs of new mailbox data occur on a regular basis until ready to complete the batch, then is it theoretically possible to move all the on prem mailboxes to cloud with a manual completion so that the majority of email data can be ready to go on the cloud side when finally ready to complete the batch – thus only having to move a fraction of the data instead of full mailboxes? Is this what others have done in this scenario?
Again, thanks so much for your expertise and these articles.
DAG
Sorry for the delayed response here, I’ve been out. But, yes it is completely possible to sync in smaller batches, and leave them all at “manually complete.” What this does, is it will run an incremental every 24 hours on each batch. That way, when you go to “complete” the batch, it only catches up deltas and flips everyone over at once. This is by far the easiest and least disruptive, especially w/ ~40 users. I tend to help 10-15% of users the day following cutover with something minor. It’s pretty painless overall, with the hybrid (permissions & delegations should be maintained on mailboxes, etc.). If you migrate public folder data via PST then there may be some permissions resets to do there. Best of luck, sir!
Hello again Alex.
So, if I divide the 40 users by their logical (and calendar sharing) groups and make each of these groups its own Migration Batch, say 4 users per batch, I can create 10 batches, make it a manual Completion, let them all sync up, and then do one group at a time to manage any issues (and the mobile device change overs)?
The total email data for these users is at about 170GB, and they are heavy users, so I imagine the above scenario is doable?
Many, MANY, thanks!
DAG
40 users is not bad, and you can complete all of these at once in my opinion, and just be onsite or available for the client on the cut-over day, to help w/ any issues, mobile phone reconfiguration, etc. I hardly have to help people. You could do smaller batches throughout the day if it felt more comfortable for you, but I usually count on helping about 10-15% of users with something “amiss” and it’s usually simple.
About Assigning License to Users..
Now you can assign Office 365 licenses to users as soon as you have completed Alex step 3 (HCW).
When AADConnect and Hybrid Config are in place, assigning O365 license won’t create the cloud mailbox. Instead a message in user properties will inform you that the mailbox is on premise.
This way you can deploy and activate Office Apps leaving mailboxes on premise (Exchange 2013 Hybrid). This was important for me as the customer was using Outlook 2007.
Alex, I wanted to express my sincere thanks for your fine articles and the help you have given me in migrating my clients SBS 2008 Ex2007 to O365 via the hybrid Ex2013 method in this article. I am almost done all of it.
I am nearing the point where I would like to do the following:
– Keep the Hybrid 2013 server in place for onsite SMTP relays and management;
– Keep AD Azure for syncing passwords to accounts;
– Turn off and eventually get rid of the SBS 2008/Ex2007 altogether by moving the AD to a 2016 Standard environment. Basically, killing SBS 2008!
I know you have the other article on using Windows Essentials Experience to create a management link to the o365 accounts, but I like the one way sync from the AD on-prem to the cloud, and thus managing things from on prem instead of only in the cloud.
Can you guide me (again!!) about how to do this with destroying anything?
Thank you so much! I could not have done it without your help.
What you describe is basically what I do for my clients–I keep Azure AD Connect and on-prem Exchange for management only. Hardly use the Essentials in practice, but it is just another option out there. I have a link on my page to migration guides, and that should help with the AD side of things.
It’s interesting, that there is no official document from Microsoft that Hybrid-Mode with SBS and Office 365 Exchange works.
We are currently searching for a good possibility to migrate SBS 2008/2011 to Office 365. We often don’t have many users but something a significant amount of Mailbox size per user.
Is there a best-practice way to migrate SBS 2011 to Office 365 when there is no possibility to create an additional Server and install Exchange 2016?
Only Exchange should be migrated off SBS 2011 and Exchange-Services should be stopped after Migration. Can we install the Tools on SBS 2011 and handle it like normal hybrid migration in this case or are there any problems if we do so and don’t install another Server with Exchange 2016 for Hybrid mode?
You have to realize that you are not in hybrid mode “with SBS”–SBS is just the mailbox database. The hybrid wizard would be run against the 2013 or 2016 Exchange server. Therefore it is still supported, but it is not a scenario that MS gives us any detail about, I have just had a lot of luck with it. However, for a situation where that is not possible–you can do cutover method, or a third party tool like BitTitan’s MigrationWiz and Deployment Pro.
Thank you for your reply.
Is express migration with sbs 2011 also possible with a second server installed without a newer version of exchange?
Idea is to give the customer a borrowed server which is only used during migration with a newer server version installed, if he doesn’t have the resources for that.
Hybrid (either minimal/express or full) is not supported with SBS, so it is necessary to have a server “in between”–Exchange license is provided for free, but the Server OS license is not.
So Exchange needs to be installed on the server that is in between in any case?
Correct, hybrid is not possible without a supported Exchange server between SBS and 365. The good news is, you don’t have to move mailboxes from SBS to the hybrid server, you just need the server to make the hybrid connections possible using the HCW.
Isn’t Exchange 2010 on SBS a supported Exchange Server?
I’m a Little bit confused.
SBS is not officially supported for use with Azure AD Connect or Hybrid Configuration Wizard. So it would be necessary to run these tools from a different server. You could perhaps try the HCW on SBS, but don’t be surprised if you run into problems. To avoid supportability problems, I normally stand up a Windows Server Standard server, install the free Exchange for Hybrid, as well as Azure AD Connect, and then run the Hybrid Config Wizard. This should keep you in a supportable configuration.
I understand, that I can’t run Azure AD Connect or Hybrid Configuration Wizard on SBS.
Question was just, if I Need the Exchange 2016 on the separate Server.
I will dump the Exchange 2010 on SBS 2011 after Migration.
For this purpose it would be great if I don’t need to install Exchange on the separate Server and just need another Server as Domain Member on which I can run the Hybrid Configuration Wizard.
In your Blog Article for Express Migration it’s described this way. Only installing a newer Member Server without Exchange and running HCW on it against the Exchange 2010 on SBS.
Would make it easier in this Scenario if a new Exchange 2016 doesn’t need to be installed and configured to migrate 15 mailboxes.
What’s not clear to me is only if Exchange 2016 is needed on the newer member-server or not or if I could to a Migration without the Exchange 2016 but with a new Server installed.
It is necessary to have either a free Exchange 2013 or 2016 instance in order for the HCW to complete its setup tasks. One of the tasks is to create federation to Office 365. Federation is not supported on SBS, therefore the “bridge” is necessary–you gotta have 2013 or 2016 between you and the cloud.
I’ve a SBS 2011 and Setup my Hybrid-Server with Windows Server 2016 and Exchange 2016 successfully. I set all directories of the Hybrid-Server to hybrid.domain.com.
The old SBS 2011 Server is still on remote.domain.com.
The SBS 2011 has corresponding certificates for remote.domain.com and the new Hybrid-Server hat certificates for autodiscover.domain.com and hybrid.domain.com.
I’m planning an Express Migration on this because there are only 15 real users on it.
The hybrid configuration wizard and the Synchronisation with Azure AD also ran successfully.
There are 2 Internet Connections. remote.domain.com uses one Connection and hybrid.domain.com and autodiscover.domain.com uses the other one.
Now I’m ready to create a Migration endpoint. The Mailboxes are still on the old SBS 2011. When I use the E-Mail-Address of a users, that should be migrated and my credentials for the server it suggests “remote.domain.com” as Migration endpoint. But that is the old SBS 2011 and not the Hybrid Server.
When I manually fill in hybrid.domain.com it tells me that it can’t connect to the Migration endpoint.
Any idea on that?
What I also noticed is, that when I access https://hybrid.domain.com/ews with credentials of a user who is still on SBS2011 it Redirects to the internal Name of the SBS2011 which can’t be accessed because it’s a non public Name.
You can use the remote. alias as your endpoint for data copy–that is okay since the mailbox replication service will copy from the mailbox server. If your redirection is not working for OWA, be sure that you have your virtual directories set up properly–the internet-routeable FQDN name should be used for both the external and internal URL’s.
I found the issue.
The Proxy was not working even if it stated it is activated.
According to this article:
https://support.microsoft.com/en-gb/help/3063913/the-remote-server-returned-an-error-403-forbidden-error-when-you-try-t
I’m preparing for a hybrid migration sbs 2011 to o365 using the method above. One thing that i cannot find confirmation of is that the free hybrid exchange license that i would put on a separate server would be free with sbs 2011? Everything i’ve seen online so far only makes reference to exchange 2007 or earlier?
Also do all of the office 365 licenses need to be enterprise or can business premium be used too?
The free hybrid license is free because of enterprise licensing in Office 365, but you only need one license to be E1 or E3 for instance, to qualify for the free hybrid key. It does not matter whether you install this alongside SBS 2011 or some other existing Exchange deployment.
Hi,
nice article and I am middle in it right now.
We have a SBS2011 and I have installed a new Hybrid server with Exchange 2013 and keep the install defaults as you described but are the defaults okay? The Defaults are the Management Tools and the automtically windows server/feature roles for Exchange. So no Mailbox role or client access role or others.
I have got the Exchange Administrative shortcut but when opening :
https://localhost/ecp/?ExchClientVer=15
I will get the This page can’t be displayed error so I think I have to install some roles or something and hope you can help me woth this.
Br
Niels
You need to install the full boat of roles, like you’re doing a full-on Exchange server. But you only license it for hybrid with the key. It does however require the roles.
Hi Alex, last week i have made a comment but i haven’t had answer on that one and the comment isn’t posted, so have you blocked that one? I hope you still have it in your email so maybe you can answer it.
BR
Niels
Sorry man I’ve been terrible at moderating comments lately. I’ll see if it turns up here as I continue working through my backlog (I was on a LOOOONG vacay recently).
Hi Alex. Just letting you know that with your helpful article, I have successfully migrated my users to 0365 and emails are now using the cloud SMTP and MX records to send and receive email. I am keeping the E13 Hybrid server in place along with AD Sync too as I think these are valuable and also I can relay local devices email through it. I will be removing the SBS 2008/E2007 server soon, as it is no longer needed.
My question now is, with the DNS records all set externally, should I add the company’s external zone (xxx.com) to the Local DNS records and create an Autodiscover CNAME as MS dictates for the external one? (We do not use Lync or Sharepoint, so only the email is my concern.) Given the scenario above, what do you recommend? Research gives me many muddles answers, but prefer someone with experience in this to address.
Is there anything else I need to adjust? I read that I may have to change the SCP records to point to the cloud, but am totally unsure about that.
Thank you so much!
DAG
Typically there is no reason you should need to have a zone describing the external domain name–that can be resolved the same as anything else on the interwebs through public DNS. Many orgs used to host sites internally and have those addresses resolve to an internal IP rather than an external one. But is is also possible even in those scenarios to design your firewall rules to allow loopback connections, and then it is not needed.
Hi Alex,
thanks for your answer. I have setup a Hybrid Exch 2013 server and I am now migrating a test account and when I hit Finish batch in Office 365 migration I can see the mailbox in Office 365.
Mailflow is working but there are 2 little problems. 1 is the Shared calendar that is not working anymore but I saw already in this FAQ that it is advised to migrate the users together abd click afterwards on Finish batch, so they are then all in Office 365 and it is (probably) working again.
But on my Phone (android) the mail sync stops and when I delete the profile and add again with [email protected] then it won’t connect automatically again, so I think I have to configure server address manually or something? Or does autodiscover comes in right now because I haven’t reconfigured the dns autodiscover record.
What I have done is Set the virtual directories on the new hybrid Exchange server to use “hybrid.company.com and the SCP to mail.sbsserversetting.com (record how it is set on my SBS) . So I did not change the autodiscover DNS records outside so it is still pointing to mail.sbsserver.com (old) and not to the new hybrid.domain.com or should I now already point it to outlook.office.com??
(not everyone is on Office 365 yet)
Hope you can clearify this.
br.
Niels
Best practice would be to point autodiscover to the hybrid exchange server inside and outside the network–the Hybrid server will be able to configure clients to reconnect to the correct location, provided that autodiscover is properly configured for the org.
Hi Alex
Will Outlook and mobile clients start communicating via the hybrid server as soon as they pick up the autodiscover DNS entry change?
Need to know when I will need to start helping with reconfiguring mobile clients (You mentioned Outlook changes should not be needed)
Regards
Charl
Once you hit complete on a migration batch, mailboxes will start completing–it takes a few minutes to catch up the delta, but usually within a few minutes from there, people will start getting prompted to close/reopen Outlook. The mobile devices typically require you to remove/re-add the mail profile so that they can pick up the change.
Thanx Alex
So I can change the autodiscover DNS inside and outside the network without disrupting the existing mobile connections and Outlook and mobile devices will only change configs / need attention once I complete the migration batches?
No, you would not cutover DNS records until you have cutover mailboxes. Typical hybrid deployments leave all records pointed on-premises, and only move records after 100% of mailboxes are in cloud.
Hi Alex
Sure, will only change autodiscover to Office 365 servers when mailboxes moved.
To clarify ito my concern: Your guide notes:
>>>>>
3. Update the SCP to autodiscover.company.com, from PowerShell:
$ServerName= “EXCH13”
Set-ClientAccessServer -Identity $ServerName -AutoDiscoverServiceInternalURI https://autodiscover.company.com/Autodiscover/Autodiscover.xml
>>>
Will the above not cause any interruptions on Outlook or mobile devices?
Thanx again
Charl
No it should not–the value should match whatever the SCP is set to on the source server.
Hi Alex,
Just completed the switch of 97 mailboxes totalling 370Gb from an SBS2011 to the cloud! Couldnt have done it without this guide, so thanks very much!
Question: I now see all my user mailboxes as disconnected in exchange on the SBS and i’d like to clean them up to free up space as we are not quite ready to fully decommission the SBS yet. Should i just uninstall Exchange2010 from the SBS and leave the Exchange2016 install on my 2nd server for the hybrid stuff for the time being?
Eventually i would like to switch to a full cloud setup and use the Essentials Experience for user/password sync to Office 365, im just not quite sure what order to remove things in or which guide to follow next!
Many thanks,
James
Yeah you can remove the Exchange 2010 box, and keep the hybrid.
Hi. Thanks for all the articles. Now, I know you said multiple times to add additional EXC13, but you also said (on 20171209) “…I have completed hybrid (or express) migrations from SBS 2011 directly…”. I understand it is not supported because of OS edition, but have you ever completed full hybrid migration from SBS11 to O365 directly? Or you completed express hybrid migration directly from SBS11 to O365? Thank you. Can you shortly mention issues, if you had them, with full hybrid migration directly from SBS11 to O365?
Certain things are not supported (Exchange federation relationship) with SBS to Exchange Online, so I tend to always recommend you use a bridge with Exchange standard (2013 or 2016) alongside the SBS server.
Hi Alex,
First of all very nice guides you made!
I’m going to dive to a similar scenario of this guide, but I’ve a simple question of which I didn’t find answer:
– I’ve an exchange 2010 on a sbs 2011 and I’m going to migrate to 365
– After the migration of all mailboxes and clients I want to unistall the exchange 2010 and keep exchange 2016 hybrid (as you suggested to install and keep in this guide). So, to uninstall exchange 2010 do I have to follow all this guide: https://www.itpromentor.com/sbs-remove-exchange/
Or just simply hit the last uninstall command of the guide: setup.com /mode:uninstall ? Because I want to be sure to not “destroy” the hybrid 2016.
Many thanks,
Cesare
Since it is not the last exchange server, just a typical uninstall procedure should be good.
Hello Alex, many thanks for the reply.
I’ll look forward to do that!
Hey Alex
First, your site and articles are a wealth of knowledge and have helped me in prior incidents but I have one client where I’m very confused as to what order things should be implemented.
Client has an SBS 2011 server currently configured in Hybrid Mode with AD Sync working. I used the Microsoft batch cutover tools to migrate all mailboxes and it’s been in place for a few months. Now we want to remove the SBS server and our end goal is to end up with (1) Server 2016 for AD and (1) Server 2016 with Exchange 2016 using the MS Hybrid key and continue to use AD Sync for Username and passwords.
I’ve read just about every article you have dealing with Hybrid setups and Office 365, I even have two tickets in with Microsoft support – which BTW they are conflicting with each other in the migration process moving forward.
I’ve been told that when I migrate AD to 2016 it is going to break the ImmutableID on the office 365 side and that my users will NOT be able to “see” their office 365 mailboxes until ADSync is re-run with some special parameters. I have the documentation from MS but my question is what order am I to migrate in?
Do I upgrade my AD 2016 server first, migrate roles, then Exchange 2016 server, then AD Sync then Hybrid Wizard?
Or
Do I bring install / spin up my Exchange 2016 server first, then AD, then AD sync and then Hybrid wizard? I’m very confused as to what order I am preforming things to end up with AD 2016, Exchange 2016, AD Sync to Office 365 AND finally removing the SBS server. Any insight you could provide would be much appreciated.
I usually take care of Exchange first, and Active Directory second. You cannot “demote” the SBS server until you have removed Exchange from it. Therefore, you will need to leave Exchange in place before removing AD. Now, in reality you could have co-existence of both, but the point is, what will break the AD Connect linking would be removing Exchange, when there is no new Exchange server present. So, as long as you install an Exchange 2016 server and re-run the hybrid wizard, then there will not be an issue as you described. After you have 2016 being the new hybrid end point, then Exchange 2010 can be removed, and then you can safely remove AD from the original server.
Thanks Alex!! Much appreciated for the feedback and tip.
Hi Alex
Thank you for the guide, it’s a great help.
On the VM with Exchange 2013/2016, will it only be acting as the transferring server or will I need space on it for my entire mailbox store?
Regards
Charl
It does not need to have space for any mailboxes, and in fact, if using the “free” hybrid license it is not within the EULA to use it as a mailbox store (although it does require the mailbox role to be installed, it is not used like that).
Thanx Alex, appreciate. Charl
Hi Alex
I’m in process of setting up hybrid migration but confused as to whether Office 365 Business Essentials licences will work for the migration with regards to Active directory sync. According to
https://products.office.com/en-us/business/office-365-business-essentials
All Office 365 for business plans include:
Active Directory integration – Manage user credentials and permissions. Single sign-on and synchronization with Active Directory
While other sources state that only Office 365 Enterprise plans include AD sync.
Question is, can I use Office 365 Business Essentials licences for the hybrid migration?
Thanx again for your help.
Charl
AAD Connect works with the business and enterprise plans.
I’m migrating our charity from SBS2008 to hybrid Office365 / AzureAD. We will remain in hybrid state at least for the time being – although the long term status of on-site servers is undecided as yet. I have therefore installed a Server 2016 instance as a member of the domain, but have not yet installed Exchange 2013. I was going to install AD Connect next to start syncing passwords, and look at Exchange as a later step when we are ready to consider mailbox migration (and decide whether we will stay in hybrid or start turning local stuff off). However having stumbled across your excellent guides, I see that you are recommending installing and configuring Exchange 2013 first. Is there a problem with doing it that way round, or should I really pause with the AD Connect part until I’ve followed your guide to install Exchange 2013? Also, since Active Directory was previous upgraded from SBS2003, I suspect there is a lot of obsolete dross in there…. is there any form of Active Directory cleanup you run or recommend, before turning on AD Connect, so that we don’t migrate any clutter not required into the cloud?
You can install it before or after adding another Exchange server. There would not really be any cleanup per se, but it is possible for instance to filter by OU or attribute in Azure AD Connect, which limits the objects you choose to sync. That can be helpful for keeping it decluttered.
Great article. I have an issue. Client has an SBS 2011 server with about 20 users. I had planned to use SkyKick to run a cutover migration, but discovered at the last minute that their is a LOB application that uses POP3 to pull information from an on-premise mailbox. Only problem is, the software is so old that it can’t use SSL which is a requirement for Office 365. We tried using stunnel as a workaround but were unsuccessful getting it to work. So I’m thinking my only choice is to run in a permanent hybrid mode with this one mailbox onsite and everything else in the cloud. Could we keep the SBS 2011 server in permanent hybrid mode (at least until this app goes away) and host just this one mailbox? Or would it be better to deploy a hybrid Exchange 2013 or 2016 server in the on-premise domain?
SBS does not officially support hybrid (plus it will leave support soon anyway), so better to go with a newer 2013 or 2016 server.
Hi Alex. I hope you can help me. Following your article i think to the nose… and i’ve come across a sumbling block, hope you can help.
I’m at the point where i want to start the moving.. but before i do i wanted to test that incoming mail to my Hybrid 2013 server will still direct mail to the mailboxes on the 2008 sbs server. So as you mention. I’ve setup hybrid.companyname.com and a forwarder on 25 and 443 to the 2013Exchange server on a different IP in the range to the normal setup.
I’ve then composed a simple email in telnet and all appears well… but the user doesnt recieve my email. It appears on the 2013exchange server under the tools> queues as it’s retrying to send.
I’m not sure what i’ve done wrong but something isn’t working.. any pointers i can check for?
Well, I don’t know what the issue is without running through some troubleshooting, but here is a good article==make sure you review it: https://practical365.com/exchange-server/no-need-create-connectors-internal-exchange-server-mail-flow/
This one might be helpful too: http://msexchangeguru.com/2013/07/29/troubleshooting-mail-flow-issues/
Good luck sir, keep fighting the good fight.
Thanks. Very Helpful. I decided to just move everyone at the same time over a weekend (this weekend infact!!) However i have a small problem. The first 2 machines i’ve loaded Outlook 2010. They have changed the config perfectly as you mentoned in step 8. But now it appears to have stopped working… the last 5 machines i’ve checked have not worked and outlook just states it’s disconnected. .. any ideas what might be causing that? If i upgrade to Office 365 it states that it can’t connect to the old sbs exchange server? Help!!!!
If everything is now cut over, be sure the on-premises autodiscover records, etc. are also updated–to point at Office 365. You can null out the SCP, too. There is no reason they should refer to the on-premises server if the mailboxes now live in the cloud, so you can just remove the references that would normally point clients to the on-prem server (DNS, and SCP).
What’s your thought if I’m only moving 6 users to Office 365 from SBS 2011? Should I still do the recommended express migration (and since it’s SBS 2011 I would need a 2016 Exchange as bridge), or simply do a cut-over?
I would probably do BitTitan Migration Wiz for something like that.
Thanks for the article Alex, but is it possible for an updated 2019 version? We recently did a migration from SBS 2011-O365 and ran into quite a few pitfalls regarding setting up autodiscover to point at the new hybrid server and whatnot.
Exchange Server 2019? You should deploy either 2013 or 2016 as a bridge to 365 for hybrid. The steps are still the same. I do not think most organizations in transition from legacy on-premises Exchange servers (2010, 2013, 2016) will be deploying 2019.
Hi,
really nice walkthrough but with Server 2019 it would become more easy, as Server 2019 Essentials now supports AAD Connect (https://docs.microsoft.com/en-us/windows-server-essentials/get-started/what-s-new-19)
So would it not be more like this now:
1. If coming from SBS 2011 – NO need to install Ex2013 or 2016
2. Install new 2019 Server
3. Install AAD Connect on Server 2019
4. Install HCW on Exchange 2010
5. Migrate
6. Deinstall Exchange 2010 from SBS
7. Demote SBS 2011 Server
Regards Timo
Hi Alex,
As always, thanks for the articles, they’re excellent.
We are migrating to Office 365 from SBS 2011. I added an Exchange 2016 server and ran the hybrid according to your instructions. It all went well and then I migrated a user to Office 365 and closed the batch.
Now that user can send email out to other employees (in the on prem servers) and to the outside world. But I cannot get email to go back to that user. Sending from on premise and from outside gets the same error “[email protected]
Server at company-mail-onmicrosoft-com.mail.protection.outlook.com returned ‘400 4.4.7 Message delayed’
Server at company-mail-onmicrosoft-com.mail.protection.outlook.com (104.47.44.36) returned ‘451 4.4.395 Target host responded with error. -> 421 4.4.1 Connection timed out’
Any thoughts? I’m not finding a lot of stuff online. Mail flows into the on-prem servers from outside.
You have to run the full hybrid if you want to enable cross-premises mailflow and setup for longer term co-existence. But most small businesses who are using the hybrid just to migrate will cut all users over at one time. It is possible to run the full hybrid, and you will want to ensure your firewall has rules inbound that allow mail from not only your antispam provider, but also Exchange Online. Then, you would test maiflow on a test user that you migrate, to ensure that you don’t have any issues w/ cross premises mailflow before migration of real mailboxes. But to quickly migrate, just a minimal hybrid, sync all mailboxes, and cutover DNS records, complete batches for everyone at once.
I did run full hybrid and there were no errors. Mail flows inbound from my test 365 user to on premise mailboxes but not outbound to the 365 test user. It times out after 24 hours and the NDR says timed out. I’ve checked all the connectors and it all seems good but now I’m stuck deciphering why it’s not flowing.
So you have a connector that allows outbound for tenant.mail.onmicrosoft.com, and that connector is having issues? I have seen that, check this article, and see if it helps resolve the issue. Another thing you can do is modify the connector and input the smarthost as your MX record for 365. https://practical365.com/exchange-server/messages-queuing-error-451-4-4-0-dns-query-failed/
We fixed that outbound connector by checking the “Proxy Through Client Access Server” box on the Outbound to Office 365 send connector. Mail flows both ways no issue. Now I’m having trouble with calendar sharing back and forth. Cloud mailbox can’t see on prem calendars at all. On prem mailbox can see only “Busy” from cloud mailbox.
Yes that happens a lot. The way it is advertised it should “just work” in a hybrid environment, but usually I find it takes massaging (and then only works so-so). Make sure there are no issues with communication between Office 365 Exchange Online and your local server (I usually whitelist the EOP IP’s in the firewall’s IPS settings, etc., etc.). After that, double-check the sharing settings under Organization. Also, I have sometimes found it necessary to “re-share” a calendar.
Hi Alex,
Thank you for your effort with this.
Like the last comment – would it be possible for you to provide specific details on ONLY the SBS2011/Exch2010 migration? It appears that the process is very different, especially not needing a separate Exchange server configured. I guess I am unclear on where the separate requirements stop, if trying to migrate SBS2011. For example, do we still need separate certificates in this case?
If you have a link to specifically a SBS2011 to O365 REmote Move migration, that would be fine too.
Many thanks,
Ryan
It is even easier nowadays with the new hybrid wizard. Here is an article you can follow. It is not necessary to have a second server or cert. Just migrate in place straight to the cloud.
Unfortunately my test of this process has failed. I have followed the instructions as much as I can – there are some changes around licensing etc.
However, I am now no longer recieving email on-premise. I have tried to migrate a single test mailbox, successfully. However since then, the onpremise SBS2011 has not received email. Can I change the MX record to EOP before I start moving mailboxes?
If I send a test email from exchange online migrated mailbox, to a onpremise address, the email does not arrive.
I am not sure how to troubleshoot – can anyone assist?
Sorry to hear that Ryan. I have myself used this process many times. I have an updated version of this article out there as well, this one is a bit older. But, you should NOT change MX records until you have moved every single mailbox. Also, you have to understand that there are two types of hybrid moves now. The method that all SMB’s should use is to sync all the mailboxes and do cutover all at once–that’s when you change MX, not before. If you want long-term co-existence with cross-premises mailflow that is a “Full hybrid” not “minimal hybrid” which is what I recommend to move everything as quickly as possible and just cutover. To setup full hybrid, you would use that option in the wizard instead of minimal. Also, you would want to test cross-premises mailflow. Your firewall needs to accept incoming mail from EOP IP addresses, which are published online. Your certs have to be good, etc. Make sure autodiscover is working properly, etc. But remember, this is not a recommended configuration for most SMB orgs–the only reason you would establish full hybrid is if you are moving hundreds or thousands of mailboxes. If less than a couple hundred just cut them over in one fell swoop, using minimal hybrid. That means you do NOT have cross-premises mailflow between cloud and on-prem mailboxes. Mail continues to be delivered on-prem until sync is done and you are ready to make the cut.
Thank you for creating this site! It’s been invaluable for migrating clients from old servers.
I’m looking to migrate from SBS 2008 to Exchange 2013 and eventually Office 365. However, I’ll need to stick with SBS/2013 coexistence for a few months before moving to Office 365. Can this be done? Will my client still be able to create users in the SBS Console with Exchange 2013 in the mix?
Also, I’ve read elsewhere that I’ll need to manually create mailboxes in Exchange 2013 for each user in SBS. Is that true?
Yes, sort of. When you have 2013 installed, you will have a new Admin interface (don’t bother using the old UI). From there, you can create new mailboxes (which also creates the user in AD at the same time), and you will have a drop down with two choices–one of those is Office 365 mailbox. So the mailbox does not actually get provisioned on-prem, instead the user account gets provisioned with instruction to the cloud that tells it to provision a new mailbox in 365 (it gets the instruction when Azure AD Connect runs its next sync–so be sure that Azure AD Connect is running and syncing the OU where users get created). The same magic is accomplished in PowerShell using New-RemoteMailbox. Or if someone already created an account in AD without using the Exchange UI, you can still tell it to provision a new mailbox in the cloud using the cmdlet Enable-RemoteMailbox. See the docs on those cmdlets for the various switches and things that you can use along with it.
Thank you for this valuable article. I’ve successfully used it for a couple of migrations so far.
Question: How can I migrate from a single Active Directory to two different Office 365 tenants? The current configuration is a single AD domain (2008), two different emails domains on a single Exchange server 2010. We like to have each email domain to have its own Office 365 account.
Thank you in advanced