How to: Express Migration to Office 365 Exchange Online
For a long time, I have been advocating for hybrid style migrations from Exchange On-premises to Exchange Online with Office 365, regardless of whether you are a small, medium or larger-sized enterprise. The reason being, it is a much better end user experience, and does not require manual reconfiguration of Outlook clients.
A seamless switch-over experience can also be achieved with third party tools, but if you are coming from On-premises versions of Exchange 2010 or Small Business Server 2011, for example, there is no reason not to take advantage of hybrid, saving money for other projects and initiatives. Even with Exchange 2007, it would be possible to install a 2013 server to act as a temporary hybrid “bridge” so to speak–and I do this all time.
New Express Migration method for Small Businesses
For small businesses, the argument/complaint I always hear is that setting up a hybrid relationship with Exchange Online is “too complex,” and thus we have many people opting for more manual methods such as PST export/import or cut-over. Those are okay migration paths, but I personally think that it is more work in most cases than just setting up the hybrid scenario.
It seems that Microsoft now agrees with me–hybrid is going to be an easier path for most small businesses with the addition of “Express migration” to the list of options. So, the argument that “hybrid is hard” will no longer be valid.
Here is a link to the blog post from Microsoft announcing and describing this new option.
However, I find it is a bit lacking in some of the detail required for both preparation and execution/finalization of the mailbox moves. Â So, to rectify, here are some “cliff notes” to help you:
Step 1:Â Prepare for the migration
If you haven’t already, go ahead and sign up for an Office 365 subscription online and verify your domain.
Next, ensure that your external domain name is added as an Alternative UPN suffix in AD Domains & Trusts. Right-click Active Directory Domains and Trusts, and select Properties. Enter your email domain name and click Add. Click OK.
The reason you do this is so that you can 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:
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.
Last, as always, make sure you are up-to-date with the latest service pack & update rollups for Exchange (SP3 at the time of this writing, for Exchange 2010).
Step 2: Begin migration steps from the Office 365 portal
Navigate to Users > Data migration and choose Exchange. This requires that you already have SBS 2011*, Exchange 2010, Exchange 2013 or Exchange 2016. You will be prompted to download and run the Hybrid Configuration Wizard. This must be run from inside the on-premises network where the Exchange server lives, on a domain-joined Windows computer or member server.
*For SBS, you must still install a hybrid 2013 or 2016 server between SBS and the 365 cloud to act a bridge–as previously described on my blog.
Step 3: Hybrid Configuration Wizard & Azure AD Connect Setup
This process is pretty well covered by Microsoft, and I don’t need to repeat it here. Basically you can select the defaults in most cases, selecting Minimal Hybrid Configuration, and the option to Synchronize users & passwords one time. Just be sure to run this against a member server, not on the domain controller (it is not supported to run the Azure AD Connect tool on SBS anyway–so be sure it is a 2012 R2 or 2016 member server).
When you select Minimal, you are enabling the “Express” migration features, but you won’t have super rich co-existence like you get with a full-on hybrid. Â If you have a small number of mailboxes (like 50 or less), and plan to move all users very quickly, then this is perfect.
I also like the option to synchronize users & passwords one time, which will basically install Azure AD Connect for the purposes of migration, running just one sync (instead of having the sync be perpetual–which is what happens if you choose to set it up on your own).
The one-time option is ideal, because it leaves an open choice for you to pick how you want to manage identity & passwords after the migration is over–you will not be locked into a hybrid environment. Some small organization admins would rather not keep a hybrid Exchange server around forever–and that’s okay with this option, because you will be able to remove your legacy Exchange server completely, if you so choose, without replacing it. If you do decide to keep Azure AD Connect installed separately and syncing, you will also need to have an Exchange server for management purposes.
Note: You can choose one of three methods to manage users when you are done with this migration:
- Cloud-only: Just remove your Exchange server after the migration is over. You can then manage new users, passwords, etc. in the cloud through the Office 365 portal (no more connection with on-premises accounts)
- Microsoft Essentials Dashboard Integration: Enable this integration to synchronize passwords and have on-premises tools for administering users & mailboxes, without an Exchange Server.
- Azure AD Connect: This tool can be installed and activated again if you so choose, which also requires a long-term on-premises Hybrid Exchange server to remain in place. Â This will synchronize passwords or allow you to choose other options such as Single Sign-On.
Step 4: Add licenses to the users in the cloud
Here is one place Microsoft’s article misses a little bit, I think. They do mention that you need to license your users before migration, but that is not laid out very explicitly. After you finish setting up the Hybrid Configuration Wizard & Azure AD Connect, but before you kick off any migrations–that is the proper time to license users.
From the Office 365 Portal, go to Users. Select an active user, and choose Edit next to Product licenses.
Note: If you licensed users prior to running the HCW & AAD Connect, you will have issues with migration, because mailbox objects will already exist in the cloud, however you are only allowed to have one mailbox per user at a time between on-premises and Exchange Online in a hybrid scenario.  Therefore, do not license users until the synchronization is completed, because Exchange Online will be aware of the on-premises mailbox by then (but not before), so a cloud mailbox will not be created.
Step 5: Begin migrations
This is the “exciting part”–you can return to the Users > Data migration screen, select the users you would like to migrate (they recommend starting with just a couple to validate the process), and click Start Migration.
When migration is completed, users will be prompted to close and re-open Outlook, at which point they will be reconnected to their cloud mailboxes, and prompted to authenticate using their email address and password.
Hint: if you experience continuous password prompts in Outlook after migration is completed, close Outlook. Go to Control Panel, open the Credential Manager and clear out any entries for Outlook/Office products. Open Outlook again and you should be prompted. Ensure you are using the full email address (same as would be used to sign into OWA for Office 365) and the correct password. Tick the box to “Remember password.”
For public folder data (if it exists) I usually recommend exporting this to PST from an Outlook client, and re-importing it to the cloud in the form of a public folder database, or into a simpler shared mailbox. This works 98% of the time for most small businesses, but it is not always possible. Advanced public folder migration scenarios are not covered here.
Step 6: What to do after data migration is completed
Unfortunately, that’s not the end of the story, even though the article by Microsoft makes it appear that way. Â There are a few things you’ll want to do in order to finalize the migration and prepare for the removal of Exchange from your environment.
A. Update DNS RecordsÂ
As soon as you’ve finalized the migration, 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, mail will no longer be delivered to your on-premises Exchange server–it should go straight to Exchange Online.
On-premises, open the DNS management console on your Active Directory server. If you have existing (A) records for autodiscover, remove them first. Expand the DNS zone for your (external) email domain name, and edit or add the CNAME record for autodiscover, and make it point to: autodiscover.outlook.com
You can verify it is working by clearing the DNS cache on the server and then pinging autodiscover.yourdomain.com. Â It should return a value for one of the Microsoft datacenters, such as nameast, namwest, namnorth, etc.
You can add the other DNS records if you choose to use Skype for Business, Intune, etc., but these records alone would be sufficient for the purposes of email migration to Office 365.
B. Changes to Exchange Server
If you plan to retire Exchange on-premises, you will have a couple small adjustments to make to ensure that clients no longer attempt to connect to the local Exchange server, before removing it (I usually wait at least a week or so post-migration before removing Exchange completely–just in case you’re missing some data on the cloud side of things).
SBS 2008/2011 or Exchange 2007/2010
Open the Exchange Management Shell and type the following:
Get-ClientAccessServer | Set-ClientAccessServer -AutoDiscoverServiceInternalUri https://autodiscover.outlook.com
And press Enter.
Next, to disable Outlook Anywhere, simply type the following into your Exchange Management Shell:
Disable-OutlookAnywhere –Server <ServerName>
And press Enter. You’re done.
C. Replace SMTP relay function
You might also want to add an SMTP relay connector to Office 365, if you were previously using your Exchange server to relay mail from on-premises LOB apps, or from scan-to-email devices, etc. Office 365 can provide a relay connector to replace this functionality.
1. From the Exchange Online admin portal, go to Exchange Admin Center > Mail flow > Connectors. Use the “plus” symbol to add a new connector, choose From: Your organization’s email server and To: Office 365. Step through the wizard, specifying the external IP address(es) of your organization under By verifying that the IP address… and clicking the “plus” symbol. You can leave default values in the rest of the wizard.
2. Ensure that your spf record in DNS includes spf.protection.outlook.com as well as ip4:<YourExternalIp>:
v=spf1 ip4:[ExternalIPAddress]Â include:spf.protection.outlook.com -all
3. Check that your firewall allows SMTP (25) outbound from the device(s) that require access to the connector.
4. On the device itself, you will need to change the SMTP or smarthost address from the internal Exchange server’s IP to the host of your MX record (e.g. companyinc-com.mail.protection.outlook.com). You can ping this address to obtain an IP if the device only accepts inputs of IP rather than hostnames.
D. Remove Exchange Server
You can now follow uninstall procedures for Exchange. These instructions are valid for any Exchange 2007 or 2010 install.
Final Notes
Remember, this new “Express” method takes some of the legwork out of a traditional hybrid migration, making it an easy choice for small businesses. Â Also, you will have a choice to make in the end, about how you want to manage user accounts & passwords.
If you choose to add back Azure AD Connect, then you will also need to keep a hybrid Exchange Server around for management purposes. Â Otherwise, you can remove Exchange completely as described here, and enable password sync with Windows Server Essentials integration, as an alternative that does not require Exchange Server. Or, you can just leave everything as-is, and manage users & passwords in the cloud, separately from your on-premises environment.
Comments (88)
Hello,
First of all thank you for all your guides! They are very informative and helpful in the decision making process.
My question is about user licensing before setting up Hybrid:
– I have 4 users with @xyz.onmicrosoft.com. I use their licenses just to use Office apps, they haven’t got any email usage in their online accounts. Will I have a problem when I initiate an Hybrid migration? What are the steps to make sure I can start a clean migration and wont have any issues?
I will be migrating from SBS2008 and would like to go the hybrid path.
Thanks,
Joao
Sounds like you have users that already have cloud accounts, and presumably also on-prem accounts. However, there is no real data in the cloud yet, just using it for licensing. And no mailbox licensing has been assigned, correct? You have two options, then:
1) You can setup the Azure AD Connect utility and attempt to soft-match or hard-match the accounts, and then initiate the hybrid mailbox migrations after you’ve confirmed the users show up as “Synchronized with Active Directory” instead of “In Cloud.”
2) Just to be safe, since there are only four users anyway, you could remove these accounts and start fresh, allowing the Azure AD Connect utility to provision the accounts directly from the synchronization, and then re-assign the licensing to them. Users of course would need to sign-in to their Office 365 apps/subscription using the new ID/credentials (which should be configured to match the UPN suffix of your email domain name).
And one more thing–you won’t be able to do hybrid directly from SBS 2008–you would need to install an Exchange 2013 server first–you don’t need to migrate your mailboxes to this server, but it has to act as your hybrid endpoint for the purposes of migration.
Hi,
Thank you very much for your feedback. Very helpful! I think I’ll be trying to start fresh then. Regarding Exchange I’m setting up the infrastructure to install Exchange 2013 with Hybrid license and still deciding which hybrid i’ll follow.
Thank you,
João
Thanks Alexander for this great article.
Express Migration look like a Minimal Hybrid without need to keep AADConnect.
Do you know if we can do Express Migration without Autodiscover set in public DNS and in public certificate?
Thanks!
You will want autodiscover records setup in order to successfully perform a hybrid migration, even of the “minimal” variety. Here are the pre-reqs.
Great article Alexander!
I want to migrate mail from SBS2011 to Office 365 and later after de-installing Exchange 2010 from SBS2011 move to server 2016 Essentials. First step is done, but I have some issues with AAD syncing.
I have used ‘Minimal Hybrid configuration’ -> ‘one-time sync option’ with ‘express Migration’ for SBS2011 with Exchange 2010.
‘Express Migration Tool’ is installed on 2008R2 server (member of domain servers) otherwise I could not install AAD Connect (installed with default options).
After successfully moving all mailboxes to Office 365, the on-premise mailboxes are disconnected in EMC and all mailboxes work fine in Office 365. But the AAD Connect is still in sync between on-premise and Office 365. The password sync is not just one time, as it should be, but it keeps synchronizing. The property of members in Office 365 is ‘Synchronized with AD’ and not ‘in the Cloud’.
Which steps are required to finish the express migration?
Do I need to remove the migration connector in O365 Exchange admin ?
Is it a good idea to break AD sync and then remove Exchange 2010 from SBS2011? (My final goal is dismount SBS2011).
Thanks a lot
Hi Tomas, You can refer to this article, where I describe how to decommission a hybrid relationship including removal of Directory Sync. If you keep the sync, they want you to keep an Exchange server, so yes removing sync is the best option for you if the goal is to get rid of Exchange completely. You can optionally have a password sync option with the Essentials integration, which is described in that article as well, but it is optional to do so.
Great article, Thanks!!!
I have an SBS2011 and the express was easily.
No there is the point to remove the Exchnage 2010 but i want to Keep the sbs2011 without te Exchange Server. The question is now what is the best way to go further.
What is next…. This? https://www.itpromentor.com/sbs-remove-exchange/
or this https://www.itpromentor.com/remove-hybrid-keep-sync/ Point 1,2,3,4 ???
When I remove my on-premise Exchnage Server, do i loose something like Groups or other attributes?
Great articles!!!!!!!!
Thanks
If you remove the Azure AD Connect / Directory Synchronization completely from the picture, then you can safely remove the last Exchange instance from SBS without adversely affecting anything. However, if you want to keep the password sync going, then you can either 1) add a new Exchange 2013 or 2016 server to replace 2010/sbs before uninstalling the Exchange role from the SBS server, or 2) use the Essentials Experience, as I describe in the article you have referenced to replace the functionality of password sync. Either way will allow you to completely remove Exchange from the SBS box.
I’ve never seen any iteration of Dirsync, ADConnect (etc) sync AD passwords with any flavor of SBS. Microsoft has confirmed this is not supported. The directory objects will sync but not the passwords. Does this method get around that some how?
Yes, all you have to do is ensure that you do not install Azure AD Connect on the SBS server, which is not supported. All you need is any other server joined as a member of the domain, and install the agent there. Typically, I like to install Exchange 2013 or 2016 as well on the member box, and use this as my bridge to Office 365. But technically it is not a requirement in order for hybrid migration to be successful.
Hi Alex,
Nice write up and blog!
I have a question what changes does the new Hybrid Express migration make in an Exchange 2013 organization ?
Full hybrid creates an Email Address Policy for Remote Routing Address and stamps all recipient with a onmicrosoft.com email alias addres, does the Express migration also do this? And the Full Hybrid also creates Send/Receive connector, does the Express does this also? And lastly does the Express need MS Federation GW and EWS like Full Hybrid does ?
Express basically leverages the minimal hybrid configuration option, which does everything that full hybrid does, except secure (TLS) mail flow between on-premises and cloud, and any Exchange Federation features such as free/busy. The MRS is still required to move mailboxes, and mailboxes that have already been moved will have their targetAddress property updated for the onmicrosoft.com alias. Basically you can think of it like the bare minimum features that would be required for onboarding mailboxes to Exchange Online, without the parts required for medium or longer term co-existence.
Thanks for you detailed answer. But does it create a send and receive connector between Office 365 and on-premises Exchange ? And the Targetaddress that is set, is that an extra mail alias for the user for mail flow to Office 365 ?
So the connectors that would otherwise be created in a full hybrid are NOT necessary in this case, because we do not need TLS secured mailflow between on-prem and cloud environments. However, you will notice that:
1) The MRS proxy will be enabled
2) Two remote domains will be created for tenant.mail.onmicrosoft.com and tenant.onmicrosoft.com, as well as a new accepted domain for tenant.mail.onmicrosoft.com. As part of that, the proxyAddresses attribute is updated to include the coexistence alias. Note, that the users must have the option to automatically update their email address based on email address policies. If that option is not checked, then you’d have to manually enter the coexistence address under proxyAddresses for users migrating to 365.
3) Once you actually migrate a user, the “targetAddress” property will be updated with that coexistence alias, so that mail sent from the on-prem exchange server will continue to find its way to the Exchange online mailbox.
Hi Alex, sorry for bothering you one last time.
Does the Express Migration make the changes below in Exchange ?
– Edit and update all email address policies with .mail.onmicrosoft.com ?
– Stamp recipients in organization with .mail.onmicrosoft.com proxy alias ?
– If a mailbox is moving to Office 365 is content synced every 24 hours ?
– What happens when mail is send to a user which mailbox is moving to Office 365 ?
It sounds like you are pretty familiar with the changes that are made with hybrid already, and the answer is yes–this works exactly the same way. Because the recipients will have the alias added via the email address policy updates, mail will continue to flow between on-prem and cloud mailboxes. Therefore it does not need to sync every 24 hours after it is done migrating, as new mail items delivered to the on-prem server after migration would be forwarded onto the cloud mailbox via the alias in real time. Whether you choose the minimal or the full hybrid option this is true, but with minimal it will not be delivering that mail via TLS (so it will not be encrypted between your server and Exchange Online). When you run the wizard you can select either minimal or full hybrid. The express option (syncing users only once) is only available if you choose the minimal hybrid route. Even though it is only synced one time, it is still a minimal hybrid configuration that uses the same technology to migrate the mail and keep mailflow between organizations. Technically, even though I liked the express option at first, in practice I always recommend that my customers keep AAD Connect for its many other benefits, so I usually setup a full sync with Azure AD Connect, and choose minimal in the Hybrid Configuration Wizard, then create my migration batches in the EAC (unless there is a need for longer term co-existence, free/busy, encrypted mailflow, etc.–in which case I choose full). I don’t find that the minimal w/ one-time sync provides that many benefits, vs. just keeping AAD Connect and leaving a management interface for Exchange behind somewhere in the environment.
Alex, I have done litterally dozens of “full” hybrid migrations since Exchange 2010 era. But for a new customer that wants to migrate fully to Office 365 (Cloud user and not Synced users) with 1400 mailbox the Express migration sounded like the way to go. But unfortunately their current Exchange 2013 Organization is a hosted multi-tenant Exchange Organzation. So the hosting company will not allow changes being made in their Exchange Organization (email address policy updates, add proxy aliases, new remote domains etc). As described perfectly by you there are changes being made (as described) so I guess the hosting company don’t allow us to use the Express Migration. Looks like we are stuck to Cutover Migration that does not make all those changes in the multi-tenant Exchange Organization.
Only thing that rests me to do is to Thank You very much for all your valueable information and time. It is really much appreciated. Will keep following your blog for sure!
FYDIBOHF23SPDLT :-)
Ah yes, that makes sense–I have wanted to use hybrid in so many cases like this myself. But in this situation, I usually turn to BitTitan’s Migration Wiz + Deployment Pro. Saves tons of work, totally worth the cost IMO. I usually just explain the circumstances to the customer and say that we can, for an additional fee, make this way less painful (and it’s only painful because the current provider does not support certain changes for best compatibility with 365–therefore we require a third-party tool with a one-time fee to get it done). Otherwise labor is much more costly, or you give the users some self-service instructions which can also be a headache to manage.
Hi
Great article BUT Most environments have more than 2 exchange 2010 OR more than 2 exchange 2013 servers.
Let’s say these are your records & you have 2 multi-role exchange servers:
autodiscover.SMTPDomainName.com
OWA.SMTPDomainName.com (for owa, owa, ecp, AS..)
1. If using an existing exch server to install hybrid wizard: What roles must the exchange server that is hosting the hybrid wizard have? CAS/HUB in 2010 OR CAS/Mailbox in 2013?
2. If using an existing exch server to install hybrid wizard: Where do you point above records internally & externally during the co-existence phase?
3. If using a NEW exch server to install hybrid wizard: Where do you point above records internally & externally during the co-existence phase?
Sorry but your article doesn’t clarify that.
Thank you
Hey Mikey: Actually, most environment that I am talking about would have a single Exchange server, not multiple. E.g. Small Business Server or a small organization of 300 seats or less usually deploys a single Exchange Standard server, in my experience. There are of course exceptions to that. But this article is particularly about the “express” option, which I would only recommend for smaller sized organizations making a move toward a “cloud-only” environment, e.g., single server setups most likely. In 2010 the key roles that are used in hybrid were hub/cas and the key roles used in 2013 were cas & mailbox (full install). Of course in 2016 you just have the one (mailbox) role. During co-existence, the on-prem servers handle everything just as before; it is your choice for example whether you want OWA access to switch from an existing 2010 or 2013 over to something newer like 2016–it makes no difference where this function lives. The hybrid configuration wizard will automatically choose the newest server version in the environment to be the hybrid connection point. You can either switch your front-end services such as autodiscover, owa, etc. over to a new 2016 server as though you were migrating to it, and then move mailboxes to 365 instead (a common method), or leave everything as-is, and just have a separate “hybrid.” alias on a new 2016 server off to the side with a new external IP, and allow the old system to remain being accessed during co-existence without referring to the new server. The hybrid server does become your “endpoint” for migration (it runs the mailbox replication service to 365). So for larger deployments I usually recommend:
1. Deploy new server (2016 most likely)
2. Either cut the existing front end/OWA services & autodiscover over to it OR give it a separate new name such as hybrid.company.com that is accessible inside & outside the network w/ this name included in the UCC cert
3. Run AAD Connect & Hybrid Config Wizard
4. Migrate mailboxes to 365, etc., etc.
I don’t recommend just creating a longer-term hybrid from existing 2010 servers–it is much better to just have a newer hybrid server in place, since you will need to remove 2010 sooner or later anyway as it falls from support, and you can get 2013 or 2016 for free if it’s just being used for hybrid.
Hi
I really appreciate your response.
BUT ….
if you have a NEW dedicated hybrid server; do you need to point any of the internal records (Such as OWA, autodiscover.SMTPDomain.com) to this specific server?
What if you use an existing exchange server. do you need to point any of the internal records (Such as OWA, autodiscover.SMTPDomain.com) to this specific server?
I do not believe it is a hard requirement to do so, but it is important that auto-discover is indeed working in the environment. Exchange 2010 (SP3) and newer will be able to natively tell the client that their mailbox has been re-located to Office 365. I usually just move the autodiscover function to the new dedicated hybrid, but I think that step is optional (makes sense to me since I usually remove the legacy Exchange when I’m done anyway).
When do I add licenses to the users in the above steps. Before or after step 5?
Hm… Start by following the order I recommend and let me know how that goes.
hi again
Microsoft does NOT recommend decommissioning the on-premises exchange environment after all users are migrated to the cloud with hybrid unless you don’t care about password sync.
https://technet.microsoft.com/en-us/library/dn931280(v=exchg.150).aspx
https://blogs.msdn.microsoft.com/vilath/2015/05/25/office-365-and-dirsync-why-should-you-have-at-least-one-exchange-server-on-premises/
What gives? What is your take on it?
It is true that this is the official, published opinion of Microsoft. However, I have been speaking with Exchange Online support team, and on two separate occasions recently they have confirmed it is supported to use Azure AD Connect with password sync, and yet NOT maintain an on-premises Exchange server. So that is different than the published “official” stance, but, there is also a lot of customers wanting to ditch Exchange on-prem. So, they seem to be coming around to this point of view on the support side. I just wish they would publish something to this effect, because otherwise it seems to just be “word of mouth” type of thing–and many orgs will not necessarily get behind that (they want it in writing). Remember: you will need to make certain changes (e.g. proxyAddresses) on-premises in ADSIedit or similar, without an Exchange server.
Hi Alex,
Thanks again for the great article. I have a question though. We are migrating from SBS 2011 and only have the single server on the network. For the express migration since we can’t run AD connect on the SBS box and we have no other members servers running on the network, can the Express migration and AD connect be run from a domain joined WIndows 7 computer. If not, could I temporarily install a WIndows Server 2012 on the network to do the one time synchronization and then remove it?
Thanks in advance.
You should install this on Windows Server Standard or better–it can certainly just be a trial/temporary VM, that is discarded after you are done.
Ok, thanks for the info. I will setup a windows Server 2012 R2 standard to do the migration. My colleague did it on another system but ran the express migration from the SBS server itself. It did synchronize all the accounts and passwords but did not do it for just the single time. It is continuing to synchronize the accounts and I am a little concerned about removing the AD connect and the ramifications since it was run on the SBS box. Do you see any issues in removing AD connect in that situation?
Thanks,
Steve
You can remove Azure AD Connect safely, and then decom. You should also disable Directory Synchronization in the Azure AD portal, after AAD Connect is uninstalled.
Having issues with the EndPoint not getting created by the wizard. Tried creating it manually, which is successful, but when I go to migrate a user it says there are no EndPoints. Thoughts?
Make sure the MRS service is enabled, autodiscover is properly configured, and of course, try using The Remote Connectivity Analyzer: https://testconnectivity.microsoft.com/
Great info, thanks fora that, I have to migrate about 300 users to O365 from Exchange 2010, but it will be possible keep sync the acounts and passwords with Azure AD connect after all mailboxes be on O365?
Thanks in advance.
Juan.
Instead of doing Express, just go for full hybrid with that many users. It’s not that much more difficult to setup, and you’ll get better coexistence features, as well as a full hybrid configuration and Azure AD Connect.
Looking to do this Express migration with SBS 2011 Standard. Can you verify this piece of the puzzle? “When migration is completed, users will be prompted to close and re-open Outlook, at which point they will be reconnected to their cloud mailboxes, and prompted to authenticate using their email address and password.” So this automatically happens once their mailbox migrates to O365 but when they close Outlook and reopen again does it create a new profile? Or keep the existing one? We are sick of doing the desktops touching as well so the hybrid solution seems sweeter the more I read about it.
The profile remains the same, it just redirects to the cloud mailbox. So all of the normal signatures, other settings, etc. come along for the ride! It is a pretty sweet deal all around.
Yeah that saves tons of time. It won’t affect the domain logon to the computers? And the password they enter is the same as their domain one? The environment we have is a bit nutty. They have about 5 different email addresses under their mailboxes since they kept changing their mind on email addresses. So for example: [email protected], [email protected], [email protected]. And the domain logon would be joe for the user name to the domain. I was thinking of doing the full hybrid since they have archives in the mix too but we aren’t keeping Exchange on site afterwards although I see on your other post that you can remove it through additional steps. I assume the Hybrid Express won’t move the Exchange archives? Thanks for your help.
Even with minimal hybrid, you can setup a migration batch using the Exchange Admin Center in Office 365, picking the Remote Move option. Once the Azure AD Connect & Hybrid Wizard steps have been completed, you will be able to move mailboxes, including Archive, to the cloud. For best results, I like to match the domain logon name to the primary SMTP address, but changing the suffix is sufficient to get the job done.
OK. Yeah, I can’t see the client wanting to put their full name when logging on to a PC unfortunately and all the primary addresses are their full names. Wouldn’t it also create a new profile on the PC? Actually I guess not. I have changed names in the past with no profile change. I’ll stick with the minimal express route. Thanks for the fast replies. I’m glad I found your site.
Actually one other question which may be silly but when moving the archives do they have to purchase the EOA or can you tell the archive to be put in the InPlace-Archive?
Archiving is available with certain Enterprise level plans such as E3, but in other cases you may have to purchase the Archive feature as an add-on. See here.
Ok thanks! They have the E3. You mention the minimal hybrid earlier, but I see it doesn’t support Exchange 2010 which is on the SBS 2011. Good info to move forward. Appreciate it.
You can indeed use the minimal hybrid (which is what Express migration is doing) with Exchange 2010.
Curious…under the screen User Sign-In, do you prefer password synchronization or would pass-through suffice?
Most orgs in the SMB space are better off with password sync. The pass-through option will mean that every cloud sign-in is dependent on the local domain controller being up and available. Typically, having this dependency on the on-premises systems is not advisable, unless you have planned for high availability (failover internet, highly available VM’s, etc.)
Hi and thanks for a very good article-
One simple(and maybe stupid) question though
I’m running the minimal hybrid configuration and have started the Azure AD Connect wizard. On the last page of the Azure AD Connect wizard i have to choose Exchange Hybrid deployment or not… Should i tick of this Box? Im going to migrate my mailboxes and then remove the Exchange server for good.
Honestly I don’t think this will make any difference (checking vs. not checking that box). Since you are only intending to migrate the mailboxes and then remove Azure AD Connect as well as the Exchange server when you are done, there is no reason to indicate hybrid Exchange, IMO.
Love the site, but this article needs a health warning about the Minimal Hybrid route if your source server is not at the right version.
In summary – if you run Minimal Hybrid and aren’t on the right source version, you will be prevented from doing a cutover instead for a period of up to 24 hours. Yes this has screwed up plans again on a migraiton already delayed a week waiting for Microsoft to fix a migraiton bug, EX124276.
My conclusion is that the source Exchange Server probably needs 2010 SP3, just as with the full Hybrid route, although of course Microsoft don’t bother to include this little nugget of information in their docmentation. 2010 SP2 may work; the specific command ours failed on was introduced in SP2; but I suspect it would have failed on something else later had that command run.
Unluckily for us we were running 2010 SP1.
If you are, and you run the Hybrid Configuration Wizard, it will do two things. Firstly, it will fail. The error shown in the interface is unhelpful. Against the on-prem exchange it will fail with four red dots and “Command not recognized. Please verify you have the correct Management Role assigned to your account”.
This is not actually a permissions problem as hinted. The command that actually causes the error can be found by looking at the logs in “C:\users\\AppData\Roaming\Microsoft\Exchange Hybrid Configuration”. Find the latest timestamped .xhcw file and open it with Internet Explorer.
There you will see a line with the commandlet that failed. In this case it was Get-HybridConfiguration.
The TechNet article for Get-HybridConfiguration shows this command did not exist until SP2, therefore SP1 will never complete the Minimal Hybrid/Express Migration.
https://technet.microsoft.com/en-us/library/hh529917(v=exchg.141).aspx
“Oh well,” you’ll say, “Minimal hybrid would have been really nice, especially the auto-updating of clients, but we’ll just have to go cutover instead.” Fine plan, but not so fast there.
Microsoft have another unpleasant surprise for you here.
When you run the wizard sets the DirectorySynchronizationStatus flag in your online tenant to Enabled. Yes of course it does before even bothering to check whether it will work. You can verify this in a PowerShell Connect-MsolService session by running Get-MSOLCompanyInformation | ft DirectorySynchronizationStatus.
If you try to create a Cutover batch, you’ll get an error that tells you you can’t do that because Directory Sync is enabled, including a link to click for more help which doesn’t actually contain any information about the issue.
If you try to turn it off from MSOL with Set-MsolDirSyncenabled -EnableDirSync $false you’ll get an error telling you can’t turn it off! That’s right, to stop people toggling their synchronization willy-nilly, Microsoft don’t let you turn this off for a variable period that appears to be up to 24 hours. That information courtesy of this page:
https://www.michev.info/Blog/Post/1797/you-cannot-turn-off-active-directory-synchronization
So proceed with extreme caution if you’re not on SP3.
In fact I just tried the Cutover option again and the radio button is now grayed out… this goes from bad to worse.
I will add a note about that! Yes, as with ANY migration, be sure you are up-to-date before you begin. If you are using hybrid cutover is not an option, as it works differently, namely the mailbox GUID is synced in hybrid via Azure AD Connect, whereas in cutover, a new mailbox is created with a totally unique GUID. Also, if there is already a mailbox created in the cloud for some accounts, then it isn’t possible to turn on Azure AD Connect and have it sync, so that you can do a remote move migration. So these are mutually exclusive options.
Thanks Alex. I really think MS should be saying “2010 SP3” on the page for this. They do list that for full hybrid. They market this as a quick easy option for people who don’t want or need hybrid – they do not stipulate that the source Exchange needs to be fully updated.
Also I appreciate they’re hybrid and cutover are mutually exclusive options. But since I can’t have hybrid… I’m going to go cutover. But because MS have turned on Directory Sync *before* checking whether it can be used, I’m stuck waiting until they allow Set-MsolDirSyncEnabled -EnableDirSync $false to work.
UPDATE: I just tried to disable the sync again (it had never happened, it was just turned on) and it worked. Hurray. However, I wasn’t able to create a cutover batch through the web GUI. The radio button was just greyed out. The migration endpoint for the on-premises server still existed from my earlier failed attempt at creating the cutover batch.
I was able to create the batch in PowerShell with
New-MigrationBatch -Name CutoverBatch -SourceEndPoint OnPrem -AutoStart
Let’s hope it works. . .
hi
very good article. How long would it take migrate in total of 50 exchange 2010 mailboxes to office 365 by using. would you be able to tell an estimate time ?
The time depends heavily on the bandwidth, etc. at the site. I suggest setting aside a day to get the setup done (more if you have to update service pack, etc., less if not). And then, you will kick off migration, sometimes there are errors to correct/sweep up while those begin syncing, so add another day there. Now you wait (again it depends on how much data, how good is bandwidth). Once synced, you can schedule a ‘cutover day’ with the client. I usually go through cutover procedures first thing in the morning and help users as their profiles switch over to O365. I just charge a whole onsite day for that day. There may be an additional few hours to throw in for fielding help requests that come in after the fact.
It appears that the Hybrid Express only migrates one email address… I don’t see where I cna sync additional email addresses with out going to a full hybrid. Am I missing something?
That would be really dumb. You obviously are missing something. You should be able to sync other mailboxes, assuming you have your entire directory synced, and it can see the full GAL you should be able to pick any/all addresses. But you know you can also just use the migration wizard right from EAC online, recipients > migration. Once the sync and hybrid config wizard has run, you don’t have to use the horrendous interface in the default admin UI. Go to Admin Centers > Exchange.
Hello Alex,
Thx for the great tutorial.
I made a copple of test with 5 mailbox and 1 onpremise public folder, 4 user moves to the cloud, setup with powershell to use remote public folder all work fine.
The only problem is that i cannot configure calender permission across onpremise and hybrid.
Is this normaly?
What happen wen i have a company wit 30 mailbox that use the calender across the user,
Wenn i move 10 mailbox to o365 for this user is possible to access to the onpremise calender?
If not is bether create a full hybrid and after finish the migration remove this?
Thx
You would want full hybrid, also it is necessary to go into the organization sharing and edit the properties so that users can share full details.
Thanks for the excellent article Alex,
In the article as well as back on March 15, 2017 you mentioned that in order to keep AAD sync running you’d need to keep an on premise Exchange (2010 in our case) instance running perpetually to keep passwords in sync.
It seems like (at least with no SBS in the picture,if that matters) you could install AAD sync on any member server even before running HCW and get password syncing between on-prem and the cloud going? With this type of AAD on member server setup would expect to be able to run the minimal setup via HCW and keep passwords in sync even after the migration has completed while also decomming all on-prem Exchange?
Here is the problem, Garret. It is NOT SUPPORTED to remove the last Exchange server from the environment, if Azure AD Connect is still in place. Doing so is actually somewhat problematic since you can end up removing Exchange properties (aliases, etc.) when you remove Exchange, and the users in the cloud are adversely affected, since the changes are synchronized from on-premises. It is necessary therefore to remove Azure AD Connect first, before removing Exchange. If you were to put Azure AD Connect back in place you would want to make sure all your aliases, etc. were accurate in the on-premises directory again. Now, it is not supported to have this synchronization without some kind of on-premises Exchange server because you cannot edit the Exchange-related properties of a user account without something such as ADSI edit or whatever–and MS does not want you doing that. Hence they say to use the Exchange management console. For this reason, they also provide a free hybrid Exchange license to Enterprise customers (E1, E3, E5, etc.) because they are more likely to be using Directory Synchronization. I have written on this before also at great length.
Understood and I appreciate the response Alex,
One other item I have noted as I research the express migration process is that some blog posts seem to say that you need a legitimate/trusted/not expired 3rd party certificate to run even the express version of HCW. Have you found that to be true? My current cert is expired and I would prefer to avoid buying one just for the migration. I’m planning on migrating over a weekend so I would not need any extended O365 On-Prem mail flow that would necessitate a cert it seems?
Thanks.
Garret
I’m not sure, I’ve never been without a real certificate before in that situation. You could try to run it and see if it bombs I suppose.
On the options of Cloud Only, you do need to disable the DirSync. I connect to Azure AD and run
(Get-MSOLCompanyInformation).DirectorySynchronizationEnabled to verify it’s still enabled.
Then I run
Set-MsolDirSyncEnabled -EnableDirSync $false
to turn it off.
Also on another subject, my client had mail enabled public folders and they weren’t rec’ing external email. Besides setting all the permissions and SMTP addresses, I had to set the accepted domain to Internal relay to get the mail to flow.
Good write-up. Have enjoyed your posts. ThanksQ
Great article here, Alex!
Question for you – and thanks in advance!!! here’s my scenario:
We are currently using Office 365 Business Premium/Essentials at our company of about 60 users (let’s call it Company A). We recently acquired a company of about 25 users (let’s call it Company B) that has an already existing Exchange 2013 server on-prem. We would like to migrate that company’s mail services from that on-prem server to our current Office 365 account using Express Hybrid.
There’s no AD syncing being used at the moment in Company A’s Office 365, so from what I understand this should be a fairly simple migration. I was considering using the Express Hybrid to migrate mailboxes up, but I’m concerned that might affect Company A’s current Office 365 mailboxes/accounts.
Basically, we’re looking for some advice on how to add a new company to an already existing Office 365 account and migrate up from on-prem Exchange. Is Express Hybrid the way to go?
Thanks very much!
Dan
Typically I’d use a third party tool like BitTitan’s Migration wiz for mergers/acquisitions, however since you do not already have a hybrid in place this could be possible. But I would also decom the dirsync and hybrid connections after you are done with the migration. It should not affect the existing mailboxes, since there are no identities in the Company B’s AD that correspond to your accounts. I would check to see if there are contacts, however that refer to accounts. When you join the 2 orgs together, you’ll want to move the groups and aliases for those contacts onto the corresponding mailboxes instead, removing the contacts (because now the mailboxes will be in the same org rather than in different ones, so contacts to represent those destinations won’t be necessary). Be careful, because sometimes there are legacy X500 aliases and so on, which also need to be preserved/moved to the mailboxes.
Hi,
It’s Great article.
I’ve got question: Can I change sequence and before install and start Hybrid Configuration Wizard, I’ll install, configure and sync Azure AD Connect with Office 365 tenant ?
Best regards
Sebastian
Yes, that is the typical process–Azure AD Connect is installed before the hybrid wizard does it’s thing to create hybrid connectors, etc.
What if you’d like to upgrade their Office 2010 to Office 2016 (365) apps as well and do an Express Migration? When would be best to do that, before or after the Express Migration?
Personal preference.
In step 5, before we update DNS records, the article says
“When migration is completed, users will be prompted to close and re-open Outlook, at which point they will be reconnected to their cloud mailboxes, and prompted to authenticate using their email address and password.”
Does this mean that users will be connected to a cloud mailbox even before we update the DNS records? Does this happen after all the selected mailboxes are migrated, or per mailbox? Also, before we update DNS records but after the migration finishes, will the on-premise mailbox continue syncing to O365, so if we don’t update their DNS records right away, then they won’t notice any missing mail? Thanks.
With hybrid it is not possible to miss mail. And you can do the DNS cut at anytime. Users will be redirected to the 365 mailbox even if DNS records have not been cutover yet, but mail delivered on-prem will be automatically forwarded to the cloud mailbox if it arrives on premises.
Hi Alex,
So I’ve got SBS 2011/Exchange 2010, Server 2016 as a member server with AAD Connect running on it. The users accounts have sync’d in my Office 365 tennant OK. I’ve run the Office 365 Hybrid Configuration Wizard on the SBS2011 server and it completed successfully. However in the Office 365 mail migration advisor on the “Verify hybrid deployment” I’m getting an orange warning about “Make sure you’ve run the Hybrid Configuration Wizard on-premises before proceeding…” and when I skip ahead to the next tab and try a test migration it doesn’t work – I see it briefly say “starting” and then it changes back.
Any ideas as to how I can troubleshoot this?
I would attempt to do a normal remote move migration myself in Exchange admin center. Make sure an endpoint is setup and then go for it in there, see if it works. If not, run hybrid config wizard on prem again, see if it tells you anything different.
Hello
Am I right in understanding that all the office365 migration methods require a public ssl certificate?
I am trying to migrate my test lab Exchange 2016 to Office365 but the hybrid express migration failed with a few errors related to ssl/tls not found.
The only way I can see it working without a public certificate is by using the method to setup an empty office365 E3 account and then importing the PST files into desktop outlook and then it syncs up to the microsoft server??
Any suggestions without using Public Certs would be appreciated.
Thanks
Hm, I have never migrated a non-real environment without an actual certificate. Maybe the new hybrid agent wouldn’t care about the cert? It is possible. Did you try that method?
Hi Alex,
Thanks for your awesome guide. Do you know if I can move my users in batches, I have around 150 mailboxes and I would want to migrate around 10 – 20 at a time, does the express method allow this (I really don’t want to go down the hybrid route?)
My other question is do I have to run the One time sync as I have already manually created the mailboxes in Office 365?
Thank you
With the express option you would want to sync and cut over all the mailboxes at one time. If you want to go batch by batch then you need full hybrid.
Got a 50 user SBS 2011 to do soon, only issue i have is they already have another CSP who provided 15 users with Dynamics CRM Licences, So 15 users are already setup in the admin control panel, will this matter when i first do the AAD Connect and it tries to create the existing 15 users, should i still be able to licence all the users.
It should perform soft matching but you can optionally hard match them.
Hi Alex,
if I understand everything correctly, I can also select the minimum hybrid configuration even if Azure AD Connect is already installed and running.
Which option do I choose when I need to answer the Azure AD Connect question in the HCW … “Synchronize my users and passwords one time” or “I will install azure Active directoy connect later on my own”.
For me both Options do not really make sense if Azure AD Connect is already in place with user and password sync.
Thanks
Thorsten
This question will not appear if you just have Azure AD Connect installed in advance. Then it won’t bother you about the sync question.
Thanks Alex!
Alex,
I have a Windows Server 2016 Standard install with Exchange 2013 SP3 on-premise supporting 85 users. I want to migrate the email to Exchange Online (Office/Microsoft 365) and de-install/remove the on-premise Exchange Server entirely. We have no Office 365 currently. I do want to retain password synchronization between users logged into on-premise workstations and the Exchange Online accounts i.e. user has same password for logging into the domain as for their email.
Is it possible to:
Use the Express migration with one time synchronization to migrate the email accounts.
De-commission/get rid of the on-premise Exchange server.
The question is what I do next to setup / retain password synchronization: Do I…
1 – Add the Server Essentials experience to the existing Windows 2016 Server to enable password synch
OR
2 – Install Azure AD Connect (but do not select the Exchange Hybrid deployment option) to enable Password Hash Synchronization with Seamless SSO (PHS)?
I can see that with both options I will have a time gap whereby synchronized passwords would not exist whilst I install the option but any thoughts on if either option is feasible?
Thanks
It is not recommended to use the Essentials Experience anymore. They are not keeping it up. Azure AD Connect is the way to go if maintaining a hybrid/password sync is important to you. Otherwise SMB’s should consider moving to cloud-only accounts and Azure AD Joined workstations. Kick that old server habit to the curb!
Alex,
thanks, I did not know that MS were ceasing further development of the Essentials Experience.
Unfortunately because of a number of existing desktop based applications that need on-premise Active Directory to operate we have to keep our on-premise AD for a little while longer (we are currently looking at Cloud alternatives for these LOB Apps).
So if I am going to be able to move the Exchange Server to the Cloud and still retain synchronization of passwords between on-premise AD and Exchange Online, that appears to leave the Express migration option and then afterwards establishing directory synchronization using the Azure AD Connect tool as the only option.
However, I keep running into warnings about not being able to totally decommission the “last” on-premise Exchange Server (we only have one) because of issues with object rights.
Any idea if that would apply to my scenario where I do not want to establish an ongoing Full Exchange hybrid arrangement, i.e. just move the mailboxes in one go?
Install Azure AD Connect separately before doing migration and there is no need to use the express method. Just do it following this. You can still choose minimal hybrid in the HCW, so no worries there. Then just install a 2016 server anywhere–even on your DC, before you decom the other server following this. That allows you to keep sync going and stay supported, and still remove the old Exch box.
Alex,
I think you may have provided an answer in another Blog of yours:
https://www.itpromentor.com/dirsync-no-hybrid/
So it looks like I can completely remove the on premise Exchange Server, establish Directory Synchronization using Azure AD Connect (or maybe leave it in place when using the Minimal Hybrid migration option) and then live with the limitations / changes in procedure like having to use ADSLEdit tool to add email aliases.
Am I on the right track?
That is unsupported but many people do it anyway.