Updated: How to migrate email to Office 365 Exchange Online with zero downtime (the easy way)
Some people will tell you that Hybrid is not a good idea for small business networks, since it is “too complex” or “too messy.” Don’t listen to the naysayers. They are just not aware yet of how stupidly simple it has become, with options like minimal hybrid and the brand new
Hybrid Agent.
Recently(ish) Microsoft improved the Hybrid Configuration Wizard, and made migrations even more simple than they were before, even for small and mid-sized businesses. So this post will stand as an update to all previous posts I’ve had about migration to Exchange Online using other methods like Cutover, Staged or “Classic Hybrid.” In our demonstration here, will be using the so-called “Modern Hybrid” method, which relies on that new Hybrid Agent.
There are still a lot of legacy environments out there, and it is not even a debate anymore as to which migration method provides the smoothest experience to end users (while also being the easiest for admins to complete, end-to-end). So I encourage you to try this out if you’re looking to do a migration sometime soon.
Without further ado, let’s jump in and cover, step-by-step, the migration of mailboxes from Exchange Server 2010, 2013 or 2016 to Microsoft Office 365 Exchange Online.
Setup your subscription (if you haven’t yet)
I assume most of my readers will be looking to migrate into Microsoft 365 Business subscriptions, but any subscription that includes Exchange Online will do for now (and this guide works for any 365 plan/flavor).
You can setup your domain right away and add users when you sign-up, or if you prefer (as I do), then you can skip past these sections to get going without making too many changes.
Depending on which subscription you ordered, you might notice that the initial setup wizard asks for all kinds of stuff (e.g. device management settings)–but as I mentioned, you don’t have to configure them right now. In general I don’t use the wizard, and I don’t recommend that you do, either. This can all be customized later.
For example, once you are into your admin portal, you can still add your domain name(s): go to Setup > Domains. Click Add domain.
I recommend the option to manage your own DNS records–just take the TXT record they give to you, and input that into your DNS provider (GoDaddy, Network Solutions, or whomever you use to manage your domain name). This step will prove to Microsoft that you own the domain name(s) that you are adding. Note it can take some time to verify after you make the changes.
Important: At this point you don’t want to add any users or assign any licensing yet. If you already have assigned licenses, go remove the licensing, at least for the Exchange Online plan. This will remove any mailboxes that were provisioned in the cloud (you don’t want them to be “in the way” when you go to migrate).
Prepare for Azure AD Connect
Let’s say your on-premises domain name is companyname.local—that means users probably sign in with something like [email protected], or companydomain\username. Unfortunately, these identities are meaningless in Azure AD and Microsoft 365 won’t understand them.
In the cloud, we have to ensure that your users can sign-in using their email address as the username, e.g. [email protected]. To get these matching one another on-prem, we might have some adjustments to make. Don’t worry—most of the time they are painless.
To add UPN suffixes on-premises, open the Active Directory Domains and Trusts MMC, and then right-click Active Directory Domains and Trusts at the root of the tree, and select Properties. If it isn’t already listed in here, then enter your external email domain name(s) and click Add. Click OK.
The reason you do this is so that you can go assign users the UPN suffix that matches their primary email domain name. In Active Directory Users and Computers, check the Properties/Account tab on your user objects. Note: It is also possible to bulk-select users and edit the suffix field en masse.
Performing the UPN suffix switch will have no impact on end-user sign-in, except that they could (if they wanted) start signing in with [email protected] instead of domain\username (though both will continue to work).
However, if your on-premises users have a sign-in name like: BobSmith, but their email address looks more like: [email protected], then you should change the UPN prefix attribute on-premises to match the email address also. E.g. BobSmith should become BSmith.
If the prefix values already match, then you should be good to go without making any further changes. But if they don’t match, then this change is going to impact on-premises sign-in experiences, obviously. Therefore, you will need to communicate this change in advance, so that users are aware of when they need to start signing in to the domain using their email address instead of the legacy format.
Install Azure AD Connect
You can download and install Azure AD Connect on either a Domain Controller, or a Member server (at least 2012 R2 recommended) within your on-premises environment. Note that Windows Small Business Server (SBS) and Windows Server Essentials (WSE) are not officially supported. Therefore, use a separate member server in these environments.
You can use the express settings for the fastest configuration. This will copy all your identities into the cloud, and that might include some extras (e.g. legacy service accounts) that you have to subsequently go remove from the cloud, after migration is done and the tool has been removed. That’s okay. Optionally, you can also do a Custom installation, which I describe in my Microsoft 365 Business Admin Guide.
Once this is completed, all of your user identities should be active in the cloud. Test it out by signing into https://portal.office.com with an email and password from the on-premises environment.
Run the Hybrid Configuration Wizard
Now, it is a known fact that hybrid migrations will give you the best user experience, bar none. Those with Outlook will simply get prompted to close and reopen. They will sign into Office 365 using their email and password, and all of their mail items show up like normal. IT doesn’t have to do a damn thing for them (well, some people will still be confused and panic, and not know what to do when it tells them exactly what they should do, but you get my point–it’s still easier this way).
You are ready to initiate hybrid. To start, just download and run the Hybrid Configuration Wizard on your Azure AD Connect server.
You can just allow the wizard to find the optimal server and proceed Next.
You will need to specify administrative user credentials both on-prem and in the cloud, so that the hybrid wizard can connect to both ends and configure things appropriately.
Once it has made a connection, the next step is to choose Minimal Hybrid. You would only use Full Hybrid if you had like hundreds of mailboxes to move over a set of staged out migration waves. Small and Mid-sized orgs can usually accomplish their migration all at once, with Minimal Hybrid. Next.
The other choice to make here is between a Classic and Modern hybrid topology. At the time of this writing, the “modern” is still in preview. I won’t go into the technical details too much, except to say that modern is even easier to use than the classic option, and will probably be the preferred mechanism going forward. Use Exchange Modern Hybrid Topology.
What this does, is installs a “Hybrid Agent” on the server that you’re running this wizard from (you’ll have to accept some EULA terms). The agent will configure and publish an Azure Application proxy–this in turn allows your Exchange migration to be routed via an Azure web service front-end, so Office 365 talks through that proxy, rather than directly with your local server, for its migration endpoint.
Go ahead and finish the wizard. Click Update.
And that should be the end.
Configure migration batches
Now navigate to the Exchange admin center, find recipients > migration. Click the ellipses and go to Migration endpoints.
You can see in the details here that the hybrid wizard has linked the application proxy to Exchange Online–this is how the migration jobs will be carried out.
Now you can create a new migration batch for your users. Again from the recipients > migration tab, pick the plus sign, a select Migrate to Exchange Online.
Choose the first option for Remote move migration and Next.
It is possible to just browse your address book and select the users individually using that plus sign there under Select the users that you want to move, or you can use a csv file with all of the email addresses in it.
After you confirm your selection, the wizard will show you the URL of the migration endpoint. In a classic hybrid scenario, this would need to be configured to point to your mail server’s public address such as mail.companyname.com, and you would have had to prove ownership of the domain(s) again–ick! But in this case we’re using a modern hybrid, so it will be the Azure proxy address that was setup by the hybrid agent.
Even though this looks complex, it is not (it’s easier than it was in the past actually) because you didn’t really need to “do” anything except run that wizard. Next.
Name your batch and complete the wizard. I recommend that you choose the option to automatically start but manually complete the batch. That way, you can come back to the portal when you are ready, select the migration batch, and move the status to Complete on the right.
As mentioned, PC users will need to close and reopen Outlook to sign back in to Office 365 (they will be prompted to do so). Mobile users must delete their email accounts from their mobile devices, and then add them back (preferably using the Outlook app). Microsoft provides some end-user instruction that you can use.
Congrats, you’re in the cloud now. Easiest. Email. Migration. Ever.
Be sure to complete your cutover by configuring your DNS records to point at Exchange, and other follow-up items I will mention below.
Configure DNS records
WARNING: DO NOT PROCEED TO THIS STEP UNTIL YOU HAVE ALREADY COMPLETED YOUR MIGRATION JOBS AND MAILBOXES HAVE BEEN MOVED TO THE CLOUD.
To find the appropriate DNS records, navigate to the 365 admin portal, and return to Setup > Domains.
Pick your domain to continue the setup process and fetch the new MX, autodiscover, etc. records, and get them all configured in your portal for GoDaddy, Network Solutions, or whomever hosts your public DNS for you.
On-premises if you have a DNS zone for the external domain(s) you will also want to update your CNAME for autodiscover so that it points to autodiscover.outlook.com. If you do not have a DNS zone for the external domain on-premises, then you are good to go, as the on-premises clients should already be looking to external DNS for the external domain lookups.
And last but not least, on the on-premises Exchange server, change the SCP to a null value:
Get-ClientAccessServer | Set-ClientAccessServer -AutoDiscoverServiceInternalUri $null
Assign licenses if you haven’t already!
Also, make sure you have assigned the purchased licenses to your user accounts via Users > Active users in the 365 admin center.
A note about SMTP relay (if applicable)
The preferred method for relaying mail from an on-premises scan to email device or third-party application, is to use SMTP submission. See this article for this and the other two options. For example, Office 365 can provide a relay connector to replace the same functionality you used to have with your local Exchange server (but it is not the preferred option).
A note about licensing options
If a user interacts with Office 365 software using Windows 10 and the full installed Office client apps, then you would assign them Microsoft 365 Business licenses. These licenses also include ATP (for extra anti-malware and anti-phishing protection).
If you have users who do not use Windows 10 or the client applications, you do not have to assign them Microsoft 365 Business. If all they need is email and other online apps like OneDrive, then consider Business Essentials for them (or even Exchange Online Plan 1 for email only users). However, be sure to add anything else they use or benefit from, for example:
- Exchange Online Archiving (archive mailbox, legal holds, etc.)
- Data Loss Prevention (DLP)
- Azure Information Protection (email encryption)
- Advanced Threat Protection (ATP) plan 1
- Intune (Device management)
The funny thing is, when you consider everything you might have to add for an “email only” user (e.g. to properly manage and secure them), it can end up being almost as much as just licensing them for the full Microsoft 365 Business anyway.
Shared mailboxes are not real people, and so are generally considered free (you don’t need licenses assigned to them). But, there is a catch–if you do need to protect them for interactive access, then you would treat them like any other mailbox, give them a mailbox license with whatever additional protections you need. For instance, you could purchase Exchange plan 2 if you needed to enable legal hold on that shared mailbox. Add ATP if they also need to receive that protection. Etc.
A note about public folders
If you still have public folders out there that are actually being used, consider migrating to something more contemporary like Outlook groups (or, see if that workflow could live in Teams even).
Otherwise, if you insist on remaining in the stone age, the easiest way to accomplish a migration of some old PF data in the SMB is to just export to PST from the on-premises server, and then re-import them to a new public folder mailbox that you setup in Exchange online from public folders > public folder mailboxes. You may need to reset permissions.
Remove Azure AD Connect and the on-premises Exchange Server
Once you are all done with migration, your choice whether you keep passwords syncing or not. If you do, then that means you always have to create your accounts on-prem, and make certain other changes on-prem. I describe this split-management experience here.
But, if your intention is to migrate all other network components to Microsoft 365, including shared files, etc., then there is probably no reason to keep that relic around any longer. Just find the Azure AD Connect tool under Add/remove and uninstall it. Then you can disable synchronization online also, using this method.
You can also remove your Exchange server at this point, provided that you have moved all mailboxes and removed any other dependencies such as local SMTP relay. Do NOT remove the Exchange server until you have completely uninstalled Azure AD Connect and disabled directory synchronization.
Oh, and once you have removed the Azure AD Connect tool, you can also go into your 365 admin portal, and clean up the active users–delete anything that doesn’t need to be there.
A note about everything else
Congratulations, you are basically done. However, there is still a lot to do, like configure email authentication, setup Mobile device management or Mobile application management, configure your antispam and antimalware settings, including ATP anti-phishing, safelinks and safe attachments, enable multi-factor, and a whole bunch of other things. So don’t stop learning in this environment–there is so much out there to explore. I hope this site has been a good resource for you in doing just that.
Comments (175)
I have a client that has migrate to Office 365 and uses Azure AD Connect to sync the local passwords to Office 365. They have a new standard Windows Server that will be taking over the role of their old SBS server they wish to decomission. How do you handle a situation like that? If the old SBS server is removed will AD still retain the settings to allow adding alias and such for sync to Office 365?
The key is that you cannot remove/uninstall the last exchange server. I always keep it in play as long as Azure AD Connect is around. It is easy to install Exchange even on the new Windows Server Standard edition server. If it is also going to be a DC then you just have to be sure to promote first, add Exchange second. There is no need to have autodiscover, OWA, EWS, etc. published–they do not need to be exposed to the internet. It is simply a management interface / UI. It is also possible to keep the Exchange schema extensions and manage via ADSI edit or the attribute editor tab in ADUC, but that is not officially supported by MS.
That’s the challenge is Exchange in this case it tied directly into the old SBS server, so no way to extra licensing and install on new. Combine that with the fact that they were using Exchange Server 2010 is beyond even extended support and the old server is also in process of failing. It would be a hard sell to insist the customer buy a new version of Exchange when they just subscribed to Office 365. In fact I discovered our team has already removed it so it looks like we will be using ADUC with an unsupported setup. The customer insists on on-prem password sync so Azure AD Connect isn’t going anywhere either. I just hope we don’t run into any major issues.
You do not need to purchase anything–Microsoft provides the hybrid exchange license for FREE. This now happens via the Hybrid Config Wizard, so you do not need to obtain the key and activate your Exchange server separately, as you had to do in the past. See: https://aka.ms/hybridkey
Yes Exchange is free, but tou would still need to buy an os to run the Exchange server (plus have server resources if running in a virtual environment). You might be lucky in that the virtualisation rights to run 2 OS’s per licence will provide you an OS, but that won’t work if you already have 2 servers and the exchange would push you to 3.
Adding an alias to a user id is not difficult with adsiedit or the attribute editor options in ADUC.
Not that difficult and also not supported. You can also install the Exchange UI for management purposes on an existing DC. No need to publish anything externally, it’s just for management. And, it is supported.
Is there a way to do this minimal migration and also set up the send connectors in Exchange on prem and online to allow for mail flow b/w the server and the cloud? With the minimal hybrid configuration, the send/receive connectors are not automatically created, so once we move the mailboxes to the cloud, they cannot receive new mail until the DNS records are cutover.
Do you know a way to do this?
Using this configuration you normally would cut over all users at once.
Hi Alex, Would it be fair to say that Minimal Hybrid with the Modern Hybrid Agent works like a cutover migration however without the need to create a new email profile for each user? This in turn simplifies the cutover migration making it low touch with the user? This allows admins to pre-populate all email into office 365, license users, pick a time to cut all over, change DNS, and users just restart Outlook and they are all set? Finally this does not allow for mailboxes to coexist and this would be accomplished with Classic hybrid using the modern Hybrid Agent?
That sounds about right–it’s for a cutover like (all at once) migration, but without need to reconfigure a new profile. I would do a full hybrid if you need co-existence, and you should still be able to do the hybrid agent with that, which would save some work, but mailflow may still require you to open firewall ports to allow EOP to exchange mail.
If you use this method, can you leave the Exchange Server onpremise? We have a client that sends out several thousand bills at one time (utility company) and wants to relay email through the onpremise exchange server.
Thank you for all your great articles.
Yes, you can leave an on-premises server, and in fact that is a very common deployment (hybrid). The most common use cases are 1. for management of mailbox attributes such as aliases, and 2. local relay.
Hi Alex,
Two questions:
1. Does completing the batch transfer the user’s mailbox connection to Exchange Online? Meaning, if I don’t complete the batch they will still be using their on-premise mailbox? Does it keep syncing all the mailbox changes if not all are wrapped up?
2. Our clients really like the synced password that comes with Azure AD Connect (if they still need AD, and unfortunately, many do). Can I remove the Exchange Hybrid and then just keep syncing users and passwords?
Thanks
1. Yes that is right–when the completion happens is when it makes the flip. If you don’t complete, still on-prem. It runs a delta every 24 hours until you complete (and complete will run a final delta).
2. Unfortunately it is not supported to remove hybrid exchange. You can for instance add a newer instance of exchange server (for free since it is hybrid only) and then decom the old mailbox server. Just re-run the hybrid wizard after the upgrade and before you decom the old server.
hi Alex,
great article. has really helped in planning for our customers migration to O365. so thank you!
a question regarding AD Connect. Some of our customers have only one server on their domain being the SBS server. as AD connect can not be installed on this server what would you suggest the methodology be for this scenario for a hybrid migration? i have done some testing and as AD connect has not been run it would appear that i can not select users to create migration batches from EAC. i am therefore assuming that i would need to add them manually in Azure AD, but this does not appear to work either. where is the migration batch reading the user ids from?
You would want to introduce a member server (even if just temporary) for Azure AD Connect, or migrate off SBS 2011, which is EOL very soon anyway. Otherwise you can do a cutover migration if you aren’t planning to use the Azure AD Connect tool. Or go third party, like BitTitan.
This/these guides are great! I am only confused on one aspect. So when I bring in the new Windows Server 2016 to promote to the new DC which will eventually replace the SBS 2011 – I understand this process. But to keep hybrid exchange, the only instance of exchange exist on the SBS server. So there is a step missing here – do I install another instance of (the free key version) exchange on the new server in place to act as the hybrid so when the SBS is decommissioned there will still be hybrid? If yes, how do I go about performing this – is it like an exchange migration first over to the new server?
Once all your mailboxes are moved to cloud (you can go right from 2010/SBS to cloud if you like), then you can upgrade to Exch 2016, and you don’t have to migrate any data, just keep the autodiscoverinternaluri, etc. set to null. Here is an article describing the upgrade process.
Great articles, thank you. I have a customer who desperately wants to keep their on-prem SBS 2011 around for less important mailboxes and move more critical ones to the O365. This is their only server and they don’t want to purchase new hardware/software, I know it’s wrong, not my call..
So that being said I’ve read the article where you say it’s not supported to install Azure AD Connect on SBS 2011 so I’m only asking if it’s possible to be done and maintain the single SBS 2011 on-prem in a full hybrid environment.
Thx
No, and not for much longer as they go end of life. What could they possibly want to keep mailboxes on-prem for?
I think the driving factor is cost. So I guess I could configure connectors to route emails between the 2 systems but that would be a pain.
I just read that AD Connect is supported on Windows Server Essentials 2019 so that might be a good way to get them moving with minimal cost. I suppose the steps here should be more or less the same using Essentials 2019.
Thanks again
The connectors should not be necessary to create manually. When you install an Exchange Server alongside another they will know how to route mail with one another. So if you have an email hit the 2016 box but the mailbox lives on the 2010 server for instance, it will get delivered automatically. No special config required. When you run the HCW, it will pick the newest version of Exchange to use as its migration endpoint. And you won’t even need to publish that through the firewall or have mail route to the 2016 box at all, if it’s just a bridge for migration and you use the hybrid agent.
Will 2008R2 Standard with Exchange 2010 SP3 work for this? The Microsoft article mentions 2012R2+ as the OS prereq….
It probably would work, but I normally run the tool from a member server that is 2012R2+, if the Exchange server is older that is okay, but I generally have a member server that I run from.
Thanks!
@Michael To save you some headaches. it is possible to install the latest AAD Connect and possibly HCW (haven’t gotten to that yet) on Server 2008 R2 (caveat below), but I had to copy some powershell modules from server 2012 R2 for AAD Connect to work at all.
Of critical importance: you should not install these tools on a server running Exchange 2010. The prereqs for AAD Connect are WinRM 5.1 (updates powershell) and ive seen that break things on Exchange/SBS, most notably involving SBS 2011 console and If i recall correctly Exchange management console.
Hi Alex, great article.
Planning SBS2011 –> O365
1) Will I be able to get a Hybrid exchange licence with O365 Business premium, or do I need an enterprise account (ie. E3)?
2) Where would new users be created after the migration? Want to keep AAD sync for passwords
1. Requires Enterprise (at least 1x “E” license in the tenant)
2. Must create on-prem
Hi Alex,
So what would you suggest for someone that wants to run a hybrid migration from SBS 2011 to Office 365 with a permanent hybrid onsite to facilitate password sync etc.
Is it best to follow the above, remove link to Azure, remove Exchange 2010 and then migrate FSMO roles to Server 2019 and decommission. Then setup a new hybrid exchange onsite with AD Connect?
Also you have commented above you need O365 enterprise license for exchange hybrid but elsewhere you can use anything with exchange online (365 business premium etc)
Thanks
I would just stand up an Exchange 2016 box as a bridge to 365 (the hybrid endpoint), and then after migration, totally remove SBS server. At least one Enterprise license is required, so far as I know, to activate the hybrid Exchange server using the HCW.
Hi Alex,
how would you solve this problem:
SBS2011 migration to Office 365 Business Premium.
Final configuration should be: Server 2019 as DC with password sync to Office365 without a local Exchange Server (non Hybrid).
Which is the easiest way to achive this?
Use BitTitan to migrate. Install Exchange 2016 server after the migration is completed to the new DC (Exchange does not need to be published to the Internet, it is just a management UI). Then remove the SBS server completely after all your DC roles, etc. are moved over. Do not remove Exchange 2010 from SBS until after 2016 is installed in the environment. And do not install Exchange on the new DC until the promotion to domain controller is completed and FMSO roles are moved. Do it in that order and life should be good. You can install Azure AD Connect on the new DC as well to sync passwords, after it has been promoted.
Thanks Alex for the informative and continually updated posts. Much appreciated.
From your above post, can I please clarify the steps to move from SBS2011 to a Server 2016 + O365 Hybrid Exchange Online?
1) Add 2 member servers to SBS2011 domain (16A + 16B)
2) Install AD Connect then run Hybrid Wizard both on 16B
3) Migrate and complete move to online O365. Confirm mail is working
4) Promote 16A to DC
5) Install Exchange 2016 using free Hybrid key (having at least one “E” license in tenant) to 16B and rerun Hybrid wizard
6) Uninstall Exchange 2010 on SBS2011 server
7) Demote and remove SBS2011 from domain
Is that the ordering required?
For step 6A, do you think could Robocopy shared folders to 16B, install SQL Server and rename 16B to same name as SBS2011 server (once removed) for seamless client access?
Again, thanks very much for sharing your knowledge!
Jason
Actually if possible I would not replace AD–only if you have a legacy app that you need to support on prem. You should be able to join computers to Azure AD and move files to SharePoint/OneDrive. Any LOB apps, search for cloud replacements or host on Azure. DHCP/DNS handled by firewall. If you must keep a server around, it is better to promote a new DC before installing AAD Connect.
We had discussed the possibility but a few reasons (office-building centric business, new fibre contract + O365 + cloud ERP upgrade end 2020, available 2016 server, etc) to move email to cloud first and then consider Azure beginning 2021.
I’ll adjust my plan to accommodate your suggestion.
Thanks
Hi Alex – Brilliant article! I am migrating a client to Office 365 as we want to get rid of there old server which is a DC running Exchange 2010. I have installed a server with 2 VMs: a DC and AD Connect. Based on the above article I was going to install Azure AD Connect and then the Hybrid Wizard. In my particlular situation we want to get rid of Exchange 2010 on prem. Do we need to install the Exchange Hybrid? Is that the same as the Hybrid Wizard?
If you have Exchange on-prem and need to move away from it then this is the easiest migration path, running the HCW puts the local Exchange in a hybrid relationship w/ Exchange Online, yes. If you want to ditch the Exchange server in the end, just be aware that you need to remove Azure AD Connect first. If you want to keep AAD Connect then you must keep an on-prem Exchange instance. So, install 2016 before you remove 2010, for example. Then be sure to re-run the HCW for 2016 to become the hybrid server. If you don’t need sync from on-prem anymore then just ditch both Exchange and AAD Connect.
Hi Alex, Hope you have a happy and prosperous 2020! Thanks for the reply. So if we get one Enterprise O365 account, we should be able to install the Server 2016 and licence it using the HCW.
So the process would be:
1.I would carry out he AAD Connect
2.Install the HCW and carry out a modern migration using Exchange 2010
3.Install Exchange 2016 on a new Server OS instance and licence the Exchange using the Office 365 key
4. Remove the Exchange 2010
5. Re-run the HCW for Exchange 2016 to become the new Hybrid
Thanks again for your help
Cheers
Stuart
Hi,
Do you have a good artical how can I add a Exchage 2016 server and uninstal old exchange 2010
after I make migration?
Yes. For a hybrid server (not for full Exchange migration).
Thank You!
Hey Alex,
Great guide. Do you plan to make one for full Hybrid as I my situation I need the full features for users Outlooks Calendars. Or is it much along the same lines as the above.
Regards, Sam.
You need to choose full hybrid instead of express, and there may be a couple other wizard steps. I don’t have any articles planned for full hybrid, no.
We’re a small business with 32 mailboxes for now, including 7 shared mailboxes. We’re planning for a migration to Office 365 and want to keep a seamless experience for our users so we want SSO for email and Sharepoint. So we want a hybrid where only account management will be on an Exchange installation on-premises. We currently have all of our domains that are email related on a UCC. I read somewhere that our internal domain needs to be on a certificate but it wasn’t specific about the full FQDN that should be on the certificate. We’re doing our prep work and are ready to at least re-key the certificate but aren’t certain about that domain for it. Ideas?
It is not necessary to have the “.local” domain included on the UCC cert for Exchange. As long as that domain does not belong to the “accepted domains” list–there is no need for it in Exchange at all. The primary UPN suffix should also be set on each account to match the public email address. After migration to cloud is complete you won’t even need to publish the EAC or OWA externally via the firewall anymore, and the cert is no longer a requirement (unless you are relaying mail locally through the server).
Thanks for the concise answer. One thing I notice is that the main article doesn’t address SSL certificates and the need for them or how to migrate them at all. I saw another article that seemed to imply that the migration wizard would handle that for the domains that have been added to Office 365 and exist on my on-premises Exchange 2010 server. Is that the case? I can’t find anything that directly addresses handling SSL when you have an existing certificate already installed.
It is not a requirement when you do the new modern method. Also, after migration if you want to keep the Exchange server for management and have directory sync remain, it is also not necessary at all. You should not need to publish EAC or anything through the firewall–it is just a local management interface. Cert is not needed since no services will be published externally.
FYI, I’ve been stumped by the fact that Microsoft currently has two articles that directly contradict one another concerning the features of minimal hybrid migration. One is dated late November and states that full, hybrid, and express migrations are distinct types and minimal will allow for continued local management. The other is dated just a few weeks later and has express and minimal being the same thing that only will synchronize once and that’s it. After calling support and speaking to a support technician who confirmed it with an “engineer” the second article does in fact supersede the other and there is no longer a minimal hybrid migration that leaves you able to sync with AD. According to him if I want to maintain a local Exchange server to allow for on-premises management there is no option other than a full hybrid migration.
I have not had this be an issue. When you initiate an “Express” migration, it will use minimal hybrid–and its going to launch the HCW before AAD Connect, but you can also just install Azure AD Connect yourself first, separately and BEFORE ever running the hybrid config wizard. When you do that, then obviously you can keep AAD Connect in place however long you want to. Now, when you run the hybrid config wizard after the fact, it will give you the option between minimal and full hybrid. I have heard and seen nothing about the minimal option being deprecated from the wizard. So I assume your MS Support person is full of it.
And to make it more clear–just install the AAD Connect tool yourself first. That will give you the most flexibility. Run the Hybrid Config Wizard. The option for minimal is still available, yes?
I haven’t run it yet but according to the guy at Microsoft when I do it will give me the two options of minimal and full. But he also says that minimal at this point will act like express did and will only do a single synchronization. Microsoft is driving me up the wall with this.
No that is not true since you will install AD Connect before running hybrid at all–and AD Connect isn’t going to stop just because you ran the wizard.
Thanks for the article, Alex!
2 questions when migrating from SBS2011:
1. Since we still need (I presume) a second Exchange server for transport purposes, will Exchange 2019 be fine, or should we stick with 2016?
2. When using a transport server for migration, which method do you recommend? The preview one or the classic minimal hybrid?
It is not necessary to have a second server when migrating. You just have to run AAD Connect and the HCW from a non-SBS server. You have to go to 2016 if you want to keep a hybrid in place after the fact. I always do minimal for SBS customers since they can be cutover all at once. Full is only used if you are stretching out over several days or weeks. That’s a waste of time, just get it done in one day.
Just to clarify, doesn’t the HCW/AAD Connect still need to be run against a regular version of Exchange, not SBS regardless of classic or modern topology?
We were thinking of either PST migration (it’s a really small company with a SBS box we will decommission afterwards, as well as removing internal Exchange completely after migration) or a minimal hybrid migration. But minimal hybrid needs a temporary transport Exchange 2016/2019 server setup, correct? Thanks for the quick reply!
It is not required to have a different server in the middle. Remember that you are cutting over everything at once, so there is no need for that. Moreover, with the modern method it publishes your virtual directories into Azure using an app proxy, so that it can talk directly to EXO without you having to fiddle with the firewall or certificates or anything. The server where you install the hybrid agent should be the member server where you have AADC and run HCW–not SBS. You can add a 2016 (but not 2019) either before you run the migration or afterward–either way. This is only necessary if you are going to keep hybrid exchange around for management long term, if you plan to retire AADC after migration is done then don’t even bother–it can all be removed at the end.
Thanks, Alex! I think I’m a bit confused as this article (https://www.itpromentor.com/migrate-2010-to-365/) that you have mentioned is outdated references creating a member Exchange 2016 server in a SBS environment for hybrid.
We usually follow your Express migration guide (https://www.itpromentor.com/365-express-migration/) for migrating to O365, but Cutover is different, isn’t it?
If we install AADC on a member server without Exchange 2016 and use the modern topology, will the migration on our end be the same as the classic Express migration but without the need for a temporary Exchange server (create migration batches for mailboxes, then complete them all at once when we’re ready to move to 365)? Thanks.
Older articles are all superseded by the latest–as I say in the articles. The only functional difference between express and minimal hybrid is that express migration has you kick off the HCW before AAD Connect. That’s it. Then it installs AAD Connect for a “one-time” sync. Instead, just install AAD Connect yourself BEFORE you kick off the HCW. That way you have total control over AAD Connect separate from HCW, and can remove it whenever you like, or not at all. Literally just follow the latest article and ignore the others. It’s that easy.
Great article Alex!
I’m preparing for my first migration from E2010 to O365 and have a few questions:
1. in your real world experience at which speed are the mailboxes migrated (assuming that the Internet speed on E2010’s end is not the bottleneck)? I have about 80 mailboxes (6GB average size) and I wonder if they all can be migrated over a weekend.
2. Can multiple accepted domains in E2010 be migrated to a single O365 account?
Thanks
Multiple domains are totally fine, and the sped varies widely based on region, connection, server, etc. I normally just start syncing at the beginning of a week and check it toward the end of a week, give the customer a heads up that it’s done (almost always is), and we schedule something the following week for cutover. I don’t pay a ton of attention to just how quickly it reaches the finish line, but as I said many factors can lead to faster/slower speed. Remember that you can let it sync for however long you want. Even if you didn’t get around to the cutover for a couple of weeks after the initial sync finished it would not be a big deal. When you finalize it does a delta, doesn’t take long.
Thanks for your quick response Alex, I really appreciate it.
Another question: I know that some users already have MS accounts at office.com for which they used their corporate email addresses ([email protected]). What will happen to those accounts after the Azure AD sync and mailbox migration to O365?
Thanks
Before you sync AAD Connect and move mailboxes you should delete those users or at least remove any licensing for Exchange. Reason being–there are cloud mailboxes “in the way” and you won’t be able to migrate the on-prem mailboxes using hybrid/remote move. So get rid of those first, then do you sync and life should be good.
Where can I see those users and delete them before I start syncing AAD connect? Is it the admin.microsoft.com portal that you are talking about? So far, I have created an account company.onmicrosoft.com and added the domains and the only user I see is the global admin. So, I guess I should be OK.
One of the MS accounts I was referring to (and that I know of) was created many years ago for the purpose of registering and activating standalone Office (retail box) purchases at office.com/setup. There might be others that I’m not aware and I don’t see a way to find out if they exist.
Sorry, I obviously don’t understand the difference between user’s personal accounts at office.com (created using company’s email address) and corporate Office 365 user accounts that we’ll end up managing after migration.
My apologies if I’m not clear enough and again thanks for your help.
No worries, if you don’t see any other users listed you should be okay. Let the sync create the users.
We’ve been stuck for a while on a failure while validating the hybrid agent. Even Microsoft support hasn’t had an answer so far. It’s a timeout but what’s causing it has everyone stumped so far. Our Exchange 2010 is on Windows Server 2008. We need to get the migration done and so our first approach was to take a clean Windows Server 2016 VM and run the migration from it, planning on installing Exchange 2016 with the hybrid key a little later to manage users from. But when we run the HCW it fails on validating the hybrid agent. The support tech from Microsoft struck me as someone who isn’t much more knowledgeable than me. Heck, his first few suggestions were things I’d already done. But here’s the error message that has them stumped and kicking the problems to another support group. Have you ever seen one like this before?
10349 [Client=UX, Page=HybridConnectorInstall, Thread=12]
The connection to the server ‘f1961e02-f7b4-4d5c-9f4a-2401ad156ffb.resource.mailboxmigration.his.msappproxy.net’ could not be completed., The call to ‘https://f1961e02-f7b4-4d5c-9f4a-2401ad156ffb.resource.mailboxmigration.his.msappproxy.net/EWS/mrsproxy.svc’ timed out. Error details: The request channel timed out while waiting for a reply after 00:00:09.9983893. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout. –> The remote server returned an error: (504) Gateway Timeout. –> The remote server returned an error: (504) Gateway Timeout., The request channel timed out while waiting for a reply after 00:00:09.9983893. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a
longer timeout., The remote server returned an error: (504) Gateway Timeout., The remote server returned an error: (504) Gateway Timeout.
I am not sure if I have seen that exact error where it calls out increasing the SendTimeout value on the Binding (presumably in IIS?)–but when I have seen it time out before I have been able to simply go back and re-do it and the wizard completed without issue (it was just something it hung up on at the time). If that isn’t working, I have not seen it–but be sure remote management is enabled and working for the Exchange box since you are running this from elsewhere, and you have all the necessary updates, SP3, latest rollups, etc.
Well, something interesting has happened. We noticed that the Hybrid Agent was constantly inactive so we had the wizard install a new one. Now that call to https://f1961e02-f7b4-4d5c-9f4a-2401ad156ffb.resource.mailboxmigration.his.msappproxy.net/EWS/mrsproxy.svc doesnt’ time out but it returns a 403 error with this message: “Error details: The HTTP request was forbidden with client authentication scheme ‘Negotiate’. –> The remote server returned an error: (403) Forbidden.., The HTTP request was forbidden with client authentication scheme ‘Negotiate’., The remote server returned an error: (403) Forbidden.”
Personally I wonder where that address is located. Is it somewhere on Microsoft’s systems? If so, why is the HCW trying to communicate with it using that protocol, which I believe means it’s using Windows authentication?
Thanks for your help Alex! One more question – if just want to continue password sync after migration from Azure AD Connect and remove internal Exchange, do we just filter AAD just just do password sync? Without an Exchange server, do we need to manually add the proxyaddresses of newly created AD users via ADSIEdit or will the account automatically populate on O365 after a sync and we just create an email for them to “create” the proxyaddress? Also, if we don’t have an Exchange server, will O365 let us do stuff like create Online Archives for our users or will it assume we have an internal Exchange server to trigger it from? Same with aliases for their mailboxes.
Should we uninstall/reinstall AAD to do just the password sync after removing our Exchange server, or is there an easier way? Thanks.
To be clear, it is NOT supported to remove Exchange and continue syncing. Either by removing and reinstalling AAD Connect or otherwise. Can you use ADSI edit to manage proxy addresses and other attributes particular to EXO? Yes. Should you? No. Also when you remove last Exchange server it actually tears out all the Exchange attributes so then you are left either having to install at a minimum the schema extensions and reimport all of your exchange attributes again, or, just do the right thing and install a full on Exchange server, even if it’s just sitting on a secondary DC. It’s only a management UI, it does nothing else–you don’t even have to publish it externally via the firewall. Just. Management. (For editing attributes and doing things like you mentioned–any operation like adding archive mailbox, hiding something from address lists, etc.–all requires an Exchange server or manual manipulation of attributes–which is not supported).
Simply follow this.
Thanks again, Alex!
If we want to keep Azure AD Connect around for password sync after the migration, do you recommend installing our hybrid Exchange 2016 server prior to the migration and connecting the hybrid wizard to EX2016, or can we run it against Exchange 2010, remove the hybrid config and then setup Exchange 2016 afterwards? Thanks.
Either works. For what it’s worth I normally upgrade to 2016 after the fact.
Thanks! We’ve decided to do a hybrid config with EX2010 and then setup Exchange 2016 after the mailbox migration. Do we need to disable/uninstall Azure AD Connect’s sync from Exchange 2010 before running the HCW on the Exchange 2016 server, or can we simply run the HCW and it will simply update the settings? We’ll likely decommission Exchange 2010 after hybrid sync is setup with 2016. Thanks.
Install 2016 and then run the HCW to update settings. No need to disable AAD Connect.
Awesome – thanks again!
Another question Alex – we used our Microsoft Volume Licensing Login to create our Office 365 tenant account ([email protected]). Since this email address already exists in our O365 cloud, how can we sync this email account from AAD Connect?
Normally, we let AAD create all of our users/email addresses in O365 when we sync, but we can’t remove [email protected] as it’s also our login for Microsoft Volume Licensing. Is it possible to have AAD associate the user’s internal Exchange account with the already-created cloud account, or should we create an alias and make it the primary and then removing [email protected] from our O365 portal?
AAD Connect performs a soft match based on SMTP address by default, so it is okay if there is already an account up there with the same name. You just don’t want it to have a 365 Exchange Online mailbox attached when you go to do the sync and run the migration. So you’ll want to offline the mailbox first. You can also place it under hold, offline it (it becomes inactive), then after migration, restore the contents of that old mailbox back into the migrated mailbox.
Once again, thanks Alex! One more question – if the UPN prefix of our AD account ([email protected]) is a secondary SMTP alias of the email ([email protected]) will AAD still pull the correct email even though the AD UPN prefix is different from the primary SMTP address? Thanks!
By default it follows the UPN, but you have the option when you follow a custom deployment where you choose the mail (email address) attribute instead of the UPN as the logon name in 365.
Ah, so it will only pull the mailbox if it’s the same primary SMTP as our AD account’s UPN prefix & suffix? We’re going under that assumption and changing AD UPN prefixes that are different than the full email UPN. We’re sticking to defaults as they are well documented. Thanks again!
Hi Alex,
A few more questions…
1. In the article you said:
“I recommend that you choose the option to automatically start but manually complete the batch. That way, you can come back to the portal when you are ready, select the migration batch, and move the status to Complete on the right”
Where exactly is the option to automatically start but manually complete the batch? What about ‘move the status to Complete on right’?
I don’t want to miss these settings and accidentally complete a batch before cutover.
2. Will Outlook 2010 work with the current version of Exchange Online? (Is the Exchange Online version 2016 or 2019?)
I tried to find that information in these two docs but there’s nothing explicitly stated for Outlook 2010
https://docs.microsoft.com/en-us/office365/servicedescriptions/exchange-online-service-description/clients-and-mobile-devices
https://products.office.com/en-us/office-resources?rtc=1
Cheers.
When you step through the wizard you can’t miss the option, as you create the batch. It is also the default option, so unless you select something different you will be okay. When you click on a batch later, the status will be either syncing or synced. Once it says synced, you can click on a batch and one of the options that you will see is Complete the batch. And you should not use 2010. It is not supported anymore (it may “work” but it is recommended to get on the latest client–2010 does not support modern auth for example).
Hi Alex, thanks for great content. Hope you’re on track with the non-buinsess related challenges that appeared in the early 2020.
I would need your view on migration to EXO when EOP on Exchange 2013 is already on. The starting point is: Exchange 2013 + EOP + MX pointing already to EOP + AAD Connect already running + Office 365 Business Accounts already in the cloud (no EXO). All that needs to be migrated to Microsoft 365 Business (EXO in hybrid deployment). What this path should be different from that described in your article above? As the migration intent is to remove Exchange 2013 afterwards, I understand that process of Exchange server decommissioning requires the AAD Connect to be removed first – so no sync from AD to O365 anymore? Right?
That is right, as for the migration piece– I believe you must have hybrid in place already with the EOP filtering mail? If so then just migrate, and O365 is aware of which mailboxes are on prem and which are in cloud. If you do not already have hybrid and just manually created some connectors then you have to create the hybrid first, using those connectors instead of the manually created ones.
Thanks Alex for your comment. I need to buy your content – so many times was checking what’s your way of doing things online. It’s worth every dollar. In my migration case the EOP is standalone, so no hybrid Exchange in place already. Only AAD Connect with PHS. Thanks for your advice! It might be a common scenario for a lot of SMBs going away from Ex2013 / WinServer + EOP + O365 Business to O365. In case when more people are interested in that scenario – maybe it’s a candidate for a separate article. Thanks you! I’m ready to join forces in the M365B Partner Alliance. Mayby we should let Ashanka Iddya know… P.S. The follow-up notification doesn’t work.
thanks for the article. I would like to ask you how you would behave in the migration from a sbs 2011 to 365, with subsequent removal of Exchange and migration to 2 DC 2019. I can use this procedure (all mailboxes must be migrated at the same time right?) And then remove the ad sync, exchange and get the sbs out of the way?
These days I generally do not replace the domain controllers at all. The only reason to keep a DC around is if you have a legacy app that requires a traditional old-world domain for authentication. PC’s would be joined to Azure AD whenever possible.
Hi Alex – thanks for all the great articles! I’ve read all the comments on the SBS-related posts, so I’m hoping I’m not going to ask something already covered!
Short Version: Will your process work with SBS2011 using a Full Hybrid setup?
Here’s my (rather weird) setup – I’d love to hear your recommendation(s)
SBS 2011, with an additional DC running 2012R2.
I have 3 “Accepted Domains” in Exchange, all active, with only 1 AD domain. Meaning:
AD has everyone using user1\domain1 for login
All users can send & receive email on all 3 email domains (i.e. @domain1.com @domain2.com @domain3.com)
SMTP Inbound to Exchange comes in through several Postfix (CentOS) instances. (This CAN be retired.)
SMTP Outbound from Exchange to Internet goes through Smart Host back to Postfix. (This CANNOT be retired.)
So… migration. I really need to keep Outbound SMTP through my Smart Hosts. SMTP Inbound I’m free to use the best option (planning to just route MX direct to O365).
I think this setup dictates Full Hybrid – possibly permanent Hybrid (which I’m ok with). Yes?
I have not considered moving entirely to AAD – so I’m still thinking permanent local DC sync to AAD.
Thanks for any thoughts! (Yikes)
Once you migrate to 365 you do not need outbound to this other provider, do you?? But even then you would set up a connector in 365 for this purpose to send to that third party, not route it down via your on-prem exchange server and then over. So this is not a problem. You should migrate all mailboxes at once and cutover MX to 365–let EXO and ATP handle all inbound filtering, etc. Set up mailflow for outbound as needed on 365. I am not seeing a need for full hybrid, no.
Super, thanks! I’m slowly gaining confidence that this hybrid magic trick is actually going to work! I’m still worried that SBS is going to create an unexpected nightmare…
One more quick note: I’m still expecting a long-ish coexistence scenario. It sounds like a Minimal + Modern Topology might still let me migrate slowly over time, yes? I want to move all my most active mailboxes quickly, but I will leave behind a lot of mailboxes locally.
So, my last question for you: Do you foresee any issues relying on the Minimal setup and Hybrid Agent to maintain coexistence for an extended period? Any gotchas that I should monitor?
Thanks again!!!
Woops… nope… I take it back. Hybrid Agent apparently doesn’t deal with any mail flow, so the extended coexistence might push me down the Full Modern road. But I don’t think that should be a disaster, unless SBS isn’t going to let me do that.
There is no reason to do extended co-existence. It’s not an awesome user experience anyway, even in full hybrid–much better to cut all mailboxes at the same time.
Hi Alex,
Given the situation my migration project has been postponed to a later (currently uncertain) date.
I’m now thinking to go ahead and install/run AADC & HCW, configure/run migration batches and be ready for cutover when it gets scheduled.
What in your opinion would be major disadvantages (if any) of being in this configuration i.e. Modern Hybrid Topology for (potentially) few months instead of few weeks? I’m mainly concerned about user experience that you mentioned.
It’s super easy to cut over every user at once if you’re an SMB. Even larger sized SMB’s. If you move a few mailboxes to the cloud but leave a bunch of them on-prem you will notice that there are some issues displaying calendars and shared mailboxes between the two disparate groups of people. That is probably the biggest thing you will notice–so folks who have resources they are trying to view in both places have to authenticate against both, and you may only get to see free/busy info unless you set up full hybrid with full details sharing settings, etc. Usually not worth the hassle in SMB. Just sync all mail, cut it at one time, and you’re done.
Thanks Alex.
Just to clarify…I was talking about a situation where all mailboxes would technically still be on-prem (i.e. uncompleted migration batches) syncing delta every 24hrs for several weeks.
I suggest that when you are ready to complete the batches just complete them all at the same time. There is no user impact to merely having data syncing in the background. Even for weeks. User impact happens when you complete the batch, and the client side mailbox connection is handed off to 365.
hi, i followed all the procedure but i get this error while moving first mailbox:
Office 365 Mailbox Migration – Target Mailbox Doesn’t Have An SMTP Proxy Matching
I followed a kb adding the missing domain tenant.mail.onmicrosoft.com but after i get this error:
Error: MigrationPermanentException: Cannot find a recipient that has mailbox GUID ”. –> Cannot find a recipient that has mailbox GUID ”
What am i missing?
There are many reasons for failed migration attempts–common ones include that the default email address policy is not being applied to the mailbox (which means that the onmicrosoft alias isn’t assigned). Assuming you get that right, make sure there are no aliases that cannot move to the cloud or domain suffixes that are not verified in the cloud. E.g. you can’t have .local alias, and if you have domain1.com, domain2.com, domain3.net, etc. on-prem as aliases, then the same domains should all be verified in the cloud. As well, if there was an account/mailbox for the user already in the cloud when you went to create the sync that can cause problems. You would need to remove all the cloud-based mailboxes before running sync. I know they have longer than normal wait times w/ all the WFH/COVID onboarding, but use MSFT support as well–they do plenty of mailbox onboarding support and would be able to help you out as well.
Hi Alex,
thanks for your step by step.
I have only one question.
It’s possible to make an migration from Exchange 2010 to Office 365 with Minimal migration (modern) and keep the Azure Ad connect for Sync Password? After that, i can move my exchange 2010 to Exchange 2019 with free licence for manage my tenant?
Thanks for your help, i’ve perform this scenario in the past but with de Full Hybrid option.
Just install AAD Connect before you run the hybrid wizard, then you can keep it as long as you like afterward. FYI I do not believe they are making 2019 available with a free license for hybrid, but 2016 works. This clue makes me think that we should expect to hear news eventually about how we can remove the last Exchange server. Stay tuned!
Hi,
After migration, how can i uninstall hybrid agent? After i uninstall agent can i remove On prem exchange 2010 ?
Can I folow this article : https://www.itpromentor.com/remove-hybrid-keep-sync/ to decomssion hybrid agent?
If you remove AAD Connect properly, shut off directory synchronization in the cloud, and then uninstall Exchange you should be good to go.
Hi Alex,
Hope all is well. Just wanted to say thank you for the hard work on your O365 blogs and it really helps me a lot.
I’m currently trying to migrate on-prem Exchange 2010 SP1 (on SBS 2011) to O365. During the Hybrid Configuration wizard (running on a domain-joined server 2016), after entering credentials for both on-prem exchange and O365, I’m getting an error of “command not recognized. please verify you have the correct management role assigned to your account” on the on-prem portion.
The account I use was a domain admin account, I even added that domain admin account to the Organization Management AD group but no luck.
Does Hybrid Configuration support Exchange 2010 SP1? Do I have to upgrade Exchange SP1 to the latest SP?
Just curious on what are your thoughts on this?
Thank you, sir.
Bia
You must apply the latest service pack and rollup.
Alex, thank you so much for the help. I got past that stage after following your advice. I then ran into another issue where “Minimal Hybrid Configuration” is greyed out, I could not select it. It’s default to Full Hybrid Configuration. I did some research and some says that it might be related to the SSL Certificate, I did get a trusted SSL using LetsEncryp, but still no luck. Please advise.
Thank you.
Bia
It is possible that even though you ran into an issue it completed the configuration. So if it already has a minimal hybrid you can’t add it again. You could remove your hybrid configuration if you wanted to go through it again, but check to see if the hybrid configuration object exists, check for the send connector to O365, check in Exchange Online to see if there is a migration endpoint already, etc. You may already be across the finish line, so to speak.
Alex,
Thank you so much for your help. You’re the man!
I really appreciate it!
Bia
Hi Alex,
First of all, thanks for this great article.
I have some questions:
We have 141 mailboxes (386GB). We would like to migrate all of our mailboxes to the cloud O365. We have an Exchange 2010 SP3 and would like to use it as hybrid server and finally upgrade it to Exchange 2016 (managing mailboxes and SMTP relay for on-premise applications) and remove Exchange 2010 from the system, keep the Azure AD Connect for SSO.
1, Some of our clients use shared calendars and funtions like send as or send on behalf.
Can i use the Exchange Modern Hybrid Topology/Minimal Hybrid Configuration for migration?
2, As I see in the comments above mailboxes stay on-premise till the migration batch will be finished. So, if i start to migrate all of mailboxes above in one batch, they will be switched in the same time to the cloud.
What will happen at the end of running of the mailbox migration batch? Will it be finished automtically or do i have to finailze it with interactions, to make the last delta?
After mailboxes are transfered and before i set MX to O365 what will happen with the e-mails which will come during this process? Maybe do i have to disable the port 25 for that time on my router to avoid mailflow to the old on-premise server?
Thank you.
Gustav
1. The modern/minimal setup is for orgs who want to “swing” all the mailboxes to the cloud in one go. This is very feasible for 141 mailboxes. If you had thousands that may be a different story and you’d be looking at a full hybrid.
2. When you create the migration batch you can pick between automatically finalize or manually complete the batch. Manual is the default and that’s typically what I do as well. As for the mailflow, one of the great benefits of hybrid is that the on-prem server understands exactly where each mailbox “lives” the whole time. So if it picks up any mail after the cut, it will automatically forward that onto 365 and it will be delivered to the cloud mailbox. Thus, it is truly the zero downtime migration method. Users just have to close/reopen Outlook and authenticate to the cloud, as well as update their mobile device by removing/readding the account.
Thank you so much for your answer and help.
Hi Alex,
We have about 300 mailboxes. Our email and domain username naming convention is a bit different.
Our domain name is example.org , same as our website example.org
If we have a user named John Doe, his
domain username is: doej (last name, first initial of first name)
Email address is: [email protected]
If there are two John Does, then his email will be [email protected]
How do i go about making sure that users can still log in using the old username format , but still be able to use [email protected] to sign in to office 365 ?
I plan on migrating everyone online and will not be keeping password synchronization. I know this means more overhead, but we want to completely remove exchange and manage everything email related online.
Second question:
We want to make sure that all users have access to their email while the migration is happening or is done. Am I correct to assume that upon migrating say 20 user mailboxes(for test), the emails from exchange on prem get synchronized to office 365 outlook account until we change the dns settings on the domain so that users receive email only through office 365 ? Can users send emails from their office 365 account before i change the dns records ? I assume no for the second option, but yes for the first one.
Will they also keep on synchronizing from the exchange server to office 365 until we ready to cut off exchange on prem and change the dns records ?
To make the identity piece work, do a custom install of AAD Connect to sync the identities, but choose to use the mail attribute instead of UPN as the identity. This is known as an “alternate id”-which comes with additional considerations for long-term co-existence, but is no big deal since you’re just getting rid of AAD Connect eventually anyway. Many orgs are moving in the same direction–no sync and manage everything in cloud.
Update the SPF record so that sending mail is no issue. The MX can be changed at any time after the migration is completed, and will have no impact one way or another. Even if mail goes to the old server, it will know where to send that mail since it understands the mailbox has been moved to EXO. So inbound (MX) is not a big deal, and you can change it any time after cutover. Once they say “synced” it continues to sync delta 1/24 hours. When you hit complete it will sync the delta once more then cut over to the cloud.
Hey Alex,
Thanks so much for your help.
I was thinking to change the user log on name to match their email(using a script), but if i can use their email address as an attribute, then even better.
When you say “Once they say “synced” it continues to sync delta 1/24 hours. When you hit complete it will sync the delta once more then cut over to the cloud.”
What exactly does this mean ? I am still confused by this step:
I do a remote mailbox move, do the on prem exchange mailbox synchronize to the office 365 cloud outlook account every 24 hours until I hit complete ?
If that is the case, then it’s best to migrate users in batches and then once i verify everyone has been migrated, i can hit complete for everyone:
At this point the on prem won’t synchronize emails to the office 365, and i have to switch the dns record on my domain name so they start receiving incoming emails to office 365, am i correct ?
Thanks again and your blog is so useful – I’m glad i found it.
Don’t over think it. You can literally just sync every single mailbox at once–the batch job will only allow a certain number of threads to move simultaneously anyway. During the sync nothing has changed for users, they keep using mail on-prem. Once it has fully “synced” then you can choose to cut over at any time. Just do all at once. The cutover process will automatically grab any deltas (any mail that came in since the last time is ran its sync). Nothing more you have to do.
Great, thanks Alex.
And what would be the best way to decommission the old server? I want my emails to be only kept in the cloud and no dir synchronization
Uninstall AD connect, remove any relay on exchange online to on prem server then uninstall exchange ?
Do you have an up to date process for this ? I tried to find one but had no luck.
Thanks a lot.
Yes, you can just:
– Remove Azure AD Connect
– Also disable the directory synchronization in Azure AD (PowerShell)
– Make sure any local relays are configured to go straight to the cloud instead of through your server
– Completely uninstall the last Exchange server following the usual steps.
Hi Alex,
Do i have to do something with the Discovery Search Mailbox before or after the finalizing of migration batches to the cloud? After that finilizing i would like to change the MX and modify what are needed and intalling an Exchange 2016 server as a new hybrid server, decomissing the old Exchange 2010 as i wrote it above on June 29, 2020. Thanks for your answer in advance.
There is nothing special needed with the Discovery search mailbox. You can just migrate all the user and resource mailboxes and then you’re done. Install new Exchange server to upgrade your hybrid and completely remove the old server.
Hi Alex,
We are in the process of migration – we learned the hard way that if you select “minimal hybrid” but close the HCW before it actually runs the cmdlets, it thinks you’re already configured as minimal and won’t let us select it when running the HCW. So we’re using full hybrid – are the steps to decommission full hybrid the same as minimal? After moving all our mailboxes up to O365, if we want to switch from our old internal Exchange on full hybrid to a new internal Exchange server with minimal, should we just run the HCW on the new server and it’ll update the pointers, or should we disable sync on the old one first? I presume we shouldn’t uninstall Exchange from the old server until the new server’s sync is up and running? Thank you.
Yeah you can just re-run the hybrid wizard. If you get that “greyed out” option for minimal you can just remove the hybrid configuration manually in PowerShell too. Then when you run the wizard it will work and nothing will be greyed out. But moving to a new server is even easier. Just run the wizard on the new server and it will update the hybrid configuration that you have to use the new server instead of the old one.
Hi Alex,
Thanks for the great article.
Currently migrating SBS 2011 Exchange to O365
After running AD Connect and the hybrid wizard (full hybrid was the only option available), I now have all my accounts in the cloud, MX switched over and end users configured. However, I intend to keep the SBS around for a while longer and do not want a new onsite exchange server. Office 365 must be fully standalone. At a later date I will look at moving fully to Azure AD
As I understand
1. Remove Azure AD Connect
2. Disable the directory synchronization in Azure AD
3. Uninstall Exchange hybrid as mnetioned here
https://docs.microsoft.com/en-us/exchange/decommission-on-premises-exchange
Also, the mailboxes on the SBS are now marked as disconnected, will this have any adverse effect going forward managing the users from the SBS box?
Should not have an adverse effect, no. Exchange and related properties will be removed from on-prem when you remove the last Exchange server. As long as there is no AAD Connect in place this should not be an issue.
I wonder how I am supposed to manage migrated users from the SBS Exchange 2010 while the hybrid config is running?
For example, I need to enable a personal online archive for a migrated user. This needs to be setup from the on prem 2010 Exchange Server, but I’ve now lost that option because the mailboxes are disconnected after the move!
You should get off the 2010 and replace with a 2016. But it is possible to edit the attributes in AD attribute editor directly to enable the Archive:
– msExchArchiveName = (give this any name like “Personal Archive – Username“)
– msExchRemoteRecipientType = (change the value to 3)
Cheers. Grateful for your help.
Alex,
Do we have to set up any SSL certificate before hand if we plan on migrating fully online and not keeping the exchange server on premises ?
Please let me know.
Thanks.
Once you have removed 100% of mailboxes and other dependencies (e.g. local SMTP relay) then the certificate is optional.
Hi Alex,
If we keep on-prem Exchange and continue using it as local SMTP relay, will it still be delivering email to Exchange online mailboxes after cutover? If so, I guess that the Hybrid wizard removes migrated domain from the list of Accepted domains or at least changes it to non-authoritative. Is that correct?
Also, will Exchange online accept emails sent through on-prem Exchange if senders email address has the same domain name?
Thanks.
Yes mail-flow from on-prem to cloud continues to work for local relay or otherwise. Actually it uses a different method than what you describe. When you migrate a mailbox the property called “targetaddress” gets updated to [email protected] and then the hybrid connector for tenant.mail.onmicrosoft.com therefore routes the message to the destination mailbox appropriately.
Hi Alex, you have a great Blog, thank you for all the information. I would appriciate your help. I have a customer that want to join the Microsoft 365 world. The actual infrastructure is this: Microsoft Active Directory in the functional level 2016, and an Local Linux Server than can communicate just over IMAP. The goal is to install Azure AD Connect, so the users do not have to have two different accounts (local and Cloud), and create a hybrid Deployment. I plan to install an Exchange Server 2016, and to use it just for Management. I Know we can do this with a free Licence. My doubts are:
Do i install the exchange first, run the HCW and than install the AAD connect, ore use a different sequence? What is the best practice to do this?
You must install Exchange, then ensure all your mail attributes are imported, then run Azure AD Connect, then HCW.
thank you for your answer. what do you mean wiith make sure all mail attributes are imported?
So for example if you have alias addresses, those have to be populated and match. That field is called “proxyAddresses” in the local AD database.
So for a customer that currently has 35 users on SBS 2011, about 20 users are off-site/email only so they shouldn’t need a local AD user account after their mailboxes have migrated to O365.
So my questions is, after we’ve moved all the mailboxes can we disconnect the local user accounts and remove them from local AD. The end goal being to use Server 2019 essentials to replace the SBS 2011 server AD with fewer than 25 users.
Thanks!
With that small of an org it would make more sense to migrate to M365 Business Premium and do cloud-only, Azure AD Join the workstations. No on-prem domain. But if you decide to keep on-prem server, I do not recommend mixing and matching on-prem and cloud users. Better to go 100% hybrid or 100% cloud only IMO. You will run into things such as groups that originate on-prem–cannot add cloud-only users to those groups, for example. Then you have to convert some of those groups to cloud-based groups instead, etc. if you want it to work. Hybrid complexity is not worth the effort for most SMB’s.
Hey, Love what your doing with these guides. More than school ever taught me.
I am migrating to Office365 Exchange Online and was wondering what exchange objects migrate? Like we have Distribution Lists for Exchange 2010 but I heard they dont have those in Exchange online.
Do you have a list of what objects are different in O365 and if they’re not in O365 comparable objects to replace them with. Like I know DL’s are now Distribution Groups in O365.
Everything migrates just fine if you do it correctly ;)
Normal DL’s will migrate without issue. The “Dynamic” Distribution lists is maybe what you’re thinking of–those are the only objects which must be removed on-prem and re-created in the cloud fresh. As well, it is preferred in some cases to replace DL’s with Microsoft 365 Groups, and take advantage of all they have to offer, over and above a traditional DL (for example attach a team in Microsoft Teams to organize communication into channels and threads, vs. just another email blast). But that is more of a “transformation” effort vs. a migration effort–can be done in tandem or after migration is complete.
Hi Alex,
I started migrating mailboxes and I realized that synced mailboxes did not appear in O365. I assume that they will appear once the migration batches are complete (finalized)?
Will it be OK if I migrate a test mailbox and complete migration (before cutover) just so I can test Outlook connectivity to O365 mailbox and mail flow from on-prem Exchange to O365?
Thanks
You could take a dummy account and migrate it, sure. And that is correct, the mailboxes only appear cloud side once batch is completed.
Hi Alex,
thanks for all this valuable information. I always love to read through all the packed information and comments. Great Website!!!
When looking at this list of items that we would be missing with Minimal Hybrid I was wondering what exactly the impact of these two is: https://practical365.com/exchange-server/choosing-between-minimal-and-full-exchange-hybrid
– To maintain internal headers on emails, use features like mail-tips cross-premises, voting messages and out of office auto replies -> Will out of office auto replies not work with Minimal Hybrid?
– To use advanced integration, like Skype for Business presence, Teams integration into Exchange 2016 mailboxes or cross-premises eDiscovery -> We use Teams Integration at the moment. Will that not be possible anymore with Minimal Hybrid?
Appreciate your thoughts on this!
Basically think of minimal hybrid as like a fancier version of cutover migration. That’s the only reason you would ever use it–you are going to tee up the migration in one giant batch, or a couple of batches, and every mailbox will be moved at the same time. If you need to stage out the migration and maintain cross-premises functionality of any kind between on-prem and cloud (co-existence, two-way mail routing, Teams integration, etc.) then you need full hybrid.
Hi Alex,
I did my first minimal hybrid migration a few weeks ago and I just wanted to thank you for all your answers and willingness to help. I’ve learned so much from this article and comments. I know there’s so much more to learn from you about M 365 migrations and configurations and since am a ‘PDF guy’ I’ll go shopping now. :)
I’m sure I’ll have more questions for you when dealing with post migration and O365 configuration tasks.
Take care.
Hi Alex,
Just wanted to confirm the order in which AADC and HCW should be removed after migration, if that matters. According to one of your older articles it should be:
1. disable AAD sync in O365
2. uninstall HCW
3. uninstall AADC
4. uninstall on-prem Exchange
Is this still your recommendation?
Thanks
Yes, that would be ideal.
Thanks Alex.
I’m also considering to keep the Exchange (2010) around for a few more months as a SMTP relay. In that scenario, we’ll disable AAD sync and remove the AAD connector but I’m not sure whether to keep the HCW installed or remove it?
Thanks
Why not just move the relay to 365? 2010 is no longer supported. Bad idea to keep.
Hi Alex,
My next project will (hopefully) be migration of Exchange 2010 located in a resource forest (on-prem) to M365. Customer is leaning toward keeping their Exchange server on-prem and upgrading it to 2016>2019 but I’m trying to persuade them to migrate to EOL.
Have you covered this scenario in any of your articles? (Domain A – user accounts domain, domain B – Exchange resource forest…migrate linked mailboxes from E2010 to M365).
Thanks.
No, and in fact I have never encountered a customer in the SMB space set up with a “resource forest” separate from the primary domain. But someone else asked about this recently as well. Sounds dumb, but it must have been a practice that was circulating at one time. For a long time now MSFT has recommended one forest, one domain. But in the case that you are citing, two comments:
1. Unless you are a fortune 100 company there is zero reason to consider hosting your own Exchange servers anymore. Slap them in the face for me.
2. I would just do a third party tool like MigrationWiz on that, personally. Then throw away the resource forest at the end of the project.
In this case, the reason for this kind of setup is that the account forest domain has ‘_’ (an underscore) in its name which was a show stopper when they wanted to upgrade Exchange 2003 to 2010. That’s when the resource forest was added as it was too much pain to migrate them to new local domain first.
Anyway, I was hopping I could somehow use the native minimal hybrid method to migrate linked mailboxes to M365 in this scenario. I can definitely see difficulties with AAD connect syncing user account from both domains. Will check the Migration Wiz out…and yes, I will slap them in the face if they keep insisting on leaving Exchange on-prem ;)
Love it.
Alex,
Question regarding full hybrid migrations. If I use full hybrid with the end goal still being all mailboxes in cloud, are there any additional/different tasks I’d want to do at the end to ensure my onsite exchange is operating only for the purpose of configuration/management? My reasoning for going full hybrid vs. minimal is the size of the migration and wanting to have adequate time to complete it in multiple batches, without users suffering feature/performance issues. Thanks!
I don’t think so; I mean I would remove it from the Internet (close any firewall rules that allow traffic to internal Exchange server). But that’s about it. PS–I have used the minimal hybrid for up to 2K mailboxes, and went all in one go, without major incident or pain.
Thanks, and that’s good to know. Do you see much value in third party tools like BitTitan for these type of migrations?
I only recommend two types of migration:
1. Hybrid / remote move method (if it is readily available)
2. tools like BitTitan or Skykick
Any other methods just add unnecessary time and work to the project.
I should have worded my question better, apologies on that.
BitTitan can be used to perform a hybrid migration, do you see any value in paying to use it for that, or would you just use the built in functionality of Microsoft 365 for a hybrid migration? I use BitTitan for all my cutover migrations, but I haven’t discovered yet what value that tool adds in a hybrid migration.
I can’t think of any benefits personally.
Thanks for the guide! Regarding following this guide to setup the minimal hybrid on Exchange 2016, what is the best way to first decommission Exchange 2010 running the full hybrid (not minimal)? After installing Exchange 2016 on the new server, can I follow your earlier guide here (https://www.itpromentor.com/remove-hybrid-keep-sync/) not including the Essentials part at the end to remove the full hybrid on 2010, then run the HCW on 2016 to setup minimal hybrid, than uninstall Exchange 2010?
You should be able to remove the oldest server after the newer one is in place and everything including hybrid configuration has been moved over to it, yes.
Great, thanks! So I:
1. Install\setup Exchange 2016 server
2. Remove the hybrid configuration, inbound\outbound connecters, and remove the cloud sync O365 account from the Users Page (or do I leave the sync agent on O365 as the HCW will update it?)
3. Setup HCW on Exchange 2016
4. Remove old Exchange 2010?
Thanks again!
Yeah you should not need to do anything with the directory sync account; that is left alone and does not really play a role in hybrid exchange config. That account does not require a mailbox on-prem or in cloud. It’s just a normal service account.
set authentication method to Basic. Here are the settings on the Exchange 2016 server:
I have SBS 2011 (Exchange 2010 SP3) with PCs running Outlook 2007. If I install Exchange 2016 on another member server for the migration, will the Outlook 2007 clients still receive email during the migration period? I read one article that mentioned on the 2016 Exchange server to set the authentication method to Basic so the Outlook 2007 clients can receive email. Is this correct or will the Outlook 2007 clients receive email anyway during this period?
2007 clients?! Wow. I have no idea. Upgrade those clients, son!
Hi,
I tried migrating an SBS 2011, but the Microsoft hcw wouldn’t work.
I believe because admincount of an SBS is >0, as its a DC.
(I wound up using the CodeTwo tool to copy emails)
Have you run into this issue, any suggested alternate workarounds?
Good Article, thanks
Roger
Do not run HCW on SBS, normally you would install a “bridge” server and run the HCW there; e.g. install Exchange 2016 to be “hybrid only” on a member server (they provide free Exchange license for that purpose).
Hi Alex
Thanks a lot for all of your very helpful articles, I am about to migrate an SBS 2011 to O365, all users have been created previously on O365 portal and they are using Teams and OneDrive and all have Business Standard license, I am wondering if I can use this hybrid method or because of existing users on O365 I should stick with cutover migration and not to run AdConnect.
Thanks is advance for your help
Either method works. The key piece before running the AAD Connect tool would be to make sure there are no mailboxes for the users in the cloud (remove the licensing specifically for EXO leaving the other stuff), if you decide to go hybrid route. Otherwise you could just use like BitTitan MigrationWiz or Skykick or similar, which is also okay.
Hello Alex,
Thanks for all the information about migrating to Microsoft 365, best practices, and keeping your notes updated.
I have a couple of questions for you.
I am looking to perform a migration, where the local exchange databases are between 250 and 300gb total. The single largest user’s mailbox is around 30gb.
I expect, with the steps you’ve listed above, the local user email data, starts copying/moving to the tenant with the “batches” process. Can the local user still be active with outlook/email activities, while and after this batch process takes place?
I am essentially looking to be able to move/copy all old email data, older than say 90 days to the 365 tenant a week or so prior to cut over day.
Then on cut over day make the final copy of data that is recent.
Is this type of staged data copy available with the express/ modern hybrid methods?
The step that you mention where the users would be prompted to restart outlook after the move, to update outlook to pull from the 365 account, will this prompt only be after all user email data is migrated?
Thanks,
Eddie
Yes you should be able to do the migration jobs while users continue to work. I have seen only a couple of instances where there were bandwidth or resource constraints on the server where we had to pause the jobs during work hours (which is easy to do in the portal–there is a pause button). Most of the time I just create the jobs and let the batches copy all during the day/night until it is complete.
At what point are the users prompted to close and reopen Outlook? Does this happen during the batch migration process or does that not occur until the status is changed to Complete (assuming the option to manually complete the batch was selected).
Not until you “complete” the batch (assuming you choose the option when you create the batch to complete manually rather than automatically).
Hi Alex,
Excellent work as always – We are migrating a customer approx 80 users from SBS2011! (Finally) to M365. Eventually, they will be a cloud-only customer however it may take 12 months due to LOB apps etc. Can we install the minimal Hybrid tool on a member server without installing Exchange 2016? I raised a case with Microsoft Pre Tech and the representative said it’s not supported and we had to install Exchange 2016.
Thank you
Thank you
Correct, for SBS, you would want a “bridge” 2016 server.
Hi Alex, thanks for making this article. My internet is pretty slow so i think about spanning over a week.
Plans to start the batch set with manual completion on a weekend, by the following weekend manually complete the batch. A week should be enough time to transfer everything.
During that week, new emails for already migrated mailboxes would be sync’d over upon batch completion?
Just to be clear I should not complete batches until I’m ready to change mx record to avoid missing new emails. right?
THANKS! and sorry for my denseness
No worries, and you have it pretty much correct. The good news is that once a mailbox is cutover to the cloud, the on-prem server is aware of this move. So if a piece of mail is still delivered to the old server, it will know how to forward it to 365 (it uses an attribute called targetAddress which gets populated when mailbox move is complete).
Great article , also I would to share that it is now easy to migrate email to Office 365 Exchange using third party tool like Gs Richcopy 360 and ShareGate , it is just few steps with time saving