How to link an existing on-premises AD Account with an Office 365 Exchange Online mailbox
I see this issue a lot out in the field. Admins sometimes create a confusing mess out of their Hybrid Exchange environments, because they don’t create users in the “right way.”
In a hybrid environment, users should (ideally) be created from the on-premises Exchange server, not from the Office 365 portal, and not even from Active Directory Users & Computers. Better is to do it right from the EAC on-premises (New > Office 365 mailbox).
I know, it’s so convenient and habitual to create a new user account by simply copying an old one out of ADUC. But guess what else is convenient? PowerShell. And if you have a good script that is using the New-RemoteMailbox cmdlet, among others, then you aren’t going to miss certain crucial Exchange attributes (which is what happens when you are blindly copying pre-existing user accounts via ADUC).
In an upcoming post, I will share a more detailed automation script for doing this the proper way, in bulk (including mirroring group memberships from a template user & even adding your MSOL licensing). But here is a one-liner to get you started, anyway (equivalent to the above GUI method but allows you to add accounts in bulk):
IMPORT-CSV NewHybridUsers.csv | FOREACH {New-RemoteMailbox -Alias $_.Alias -Name $_.DisplayName -FirstName $_.FirstName -LastName $_.LastName -OnPremisesOrganizationalUnit $_.OU -UserPrincipalName $_.EmailAddress -Password (ConvertTo-SecureString -String $_.Password -AsPlainText -Force) -ResetPasswordOnNextLogon:$true }
You would of course require a CSV file named NewHybridUsers.csv that has these attributes listed out, with one user described per line.
Alias,DisplayName,FirstName,LastName,OU,EmailAddress,Password AWilliams,Ash Williams,Ash,Williams,corp.local/users,[email protected],this1$myB00m$tick!
Note that in this example, the user would have to sign into the on-premises domain first, to reset their password, before syncing to the cloud and logging into their 365 services. (Also you have to license the account once it syncs–the next script I share will do this for you–stay tuned for it).
What to do if your stuff is already borked
Here is what you need to do, if you have already created a user account, for example, via AD Users & Computers, and then the account was subsequently licensed in the cloud, and given a mailbox (but without the on-premises EAC being aware of it). When you look at the list of mailboxes in the on-premises EAC, one or several accounts are missing. Start by connecting a PowerShell session to Office 365 Exchange Online.
Then run this:
Get-Mailbox user | fl ExchangeGuid
You need to copy this GUID and paste in it later–it has to be matched & input into your on-premises account’s attributes. Open the Exchange management shell on-premises and enter:
Enable-RemoteMailbox username -RemoteRoutingAddress [email protected] Set-RemoteMailbox username -ExchangeGuid <ExchangeGuid from above>
This will “hybrid mail-enable” the on-premises account and add the RemoteRoutingAddress (targetAddress attribute), for mail flow and coexistence with Exchange Online. Furthermore, you will have the same GUID on-premises as you do in the cloud to represent that mailbox, which makes it mobile between the environments (so you could pull it back down to on-premises if needed).
Comments (54)
Perfect. That last piece about the borked on-prem AD user object was exactly what I needed.
Thanks for the helpful info.
Thanks this worked a treat
The information to resolve a borked user was exactly what I needed to sort out a user who had previously been migrated to O365, but their AD object subsequently “lost” all the MSExchange attributes. Thanks.
Good article — and I don’t disagree with anything, except your assertion that this is “the right” way.
This is actually the entirely wrong, backward, nonsensical, stupid way of creating users that Microsoft has forced us into! It is entirely wrong, but the way we have to do it for things to work.
The “right” place to create users is most definitely AD Users and Computers. It is supposed to be *the* AD tool for managing all of your AD users. Then some misguided Exchange developer at Microsoft comes along and breaks stuff so that we now have to use a different tool for creating mail-enabled user accounts.
Remember the good old days, when Exchange integrated correctly with AD Users & Computers?
Wish Microsoft would fix this bug. Until then, we are stuck creating users the wrong way.
Now add in O365 and AADSync, and it gets EVEN MORE WRONG! All of our mailboxes are in O365, and all of our users are in AD Users & Computers. Yet somehow Microsoft thinks it makes sense that we use an on-prem Exchange server to create user accounts? What???!!! Entirely the wrong way to create new users.
Maybe you should become a developer. ;)
Thank you very much! The bottom section got me on the right track because I was definitely not doing things the recommended way before.
You are welcome!
Thank you very much to share this, Alex!
Question: is the procedure the same to do this for a shared mailbox?
You could follow the same, yes, however–it will not show up in the on-premises server as a shared mailbox specifically, even if it is converted or marked as shared online. It would still show up under recipients as an Office 365 mailbox. You can pull a mailbox down, convert to shared, and migrate up–that would have the effect of showing up correctly on each side. In most cases where 100% of mailboxes live cloudside, it doesn’t matter that much.
I actually stumbled upon this yesterday, so I think it may work now on shared mailboxes as well: https://support.microsoft.com/en-us/help/4133605/cmdlets-to-create-modify-remote-shared-mailbox-in-on-premises-exchange
Good one Alex this really helped. but I have another question. let’s say that we don’t want to have a hybrid exchange but still want to synch the AD users to O365.
Q1 – How do we assign mailboxes?
Q2 – We already have a set of cloud users, the plan is to remove these cloud users and create them in AD and synch them back to O365. With this how do we connect back their existing cloud mailboxes to the newly created AD synched accounts?
It is not supported to run without the hybrid exchange if using AD connect and Exchange Online–they require it
This is what I want the answer to also. Basically associate a on-premise user with a O365 user.
Thank you for getting back. let’s say we deploy the hybrid exchange.
Q1. How can we connect the cloud mailboxes to the AD Synched users?
Let’s assume that we have a cloud only user called Roger David, now we create this user on AD with the same name and synch it to office365/azure ad. how do we connect his cloud mailbox to his AD synched account?
Thanks.
It should match up via soft matching of SMTP address, however you can also hard match it if needed. To tell the on-prem hybrid server about the cloud account, you would use the enable-remotemailbox cmd.
Any idea when the ExchangeGuid value of RemoteMailbox is updated while we migrate a user from on premise to cloud. We could find a lot of users with “00000000-0000-0000-0000-000000000000” as the ExchangeGuid. I am planning to pull the original ExchangeGuid value from ExchangeOnline and update it on premise as we are facing automapping issues for these users/SMB.
If you are in a hybrid situation then do not monkey with the guid values. The guid will follow the mailbox to the cloud. Just use the built-in tools to do the work, do not over complicate it or attempt to go under the hood and fiddle with stuff. That’s usually how problems are created.
Hello.
Excellent article.
What about distribution groups that have mailbox?
Thanks
Hello again.
I think it will be?
For distribution lists (synchronized): Get-DistributionGroup USER | fl ExchangeObjectId
For “Office 365” groups created only in Office 365 and not synced: Get-Group USER | fl ExchangeObjectId
For the latter, I can never have a similar procedure, right. These groups can only exist in Office 365 and they are never synchronized with Exchange Hibrido On Prem, correct?
Thanks
Right!
Thank you
Hello,
I have this problem…
1.- Hybrid scenario (Exchange 2010 On-Premises and Office 365 mailboxes).
2.- I deleted a user from mi AD and remove Office 365 Mailbox (2 days ago).
3.- I recovered Office 365 user mailbox.
4.- I don’t have recovered AD user.
I need to recover AD user and mailbox.
I don’t know how to proceed…
i must create a new user in AD?, (don’t have enabled AD recycle bin)
how can i link recovery mailbox to this “new” user in AD?
Thanks.
The data associated with the user is different from the user object–and if I understand you right you have already recovered a mailbox from O365–presumably to a new user account in the cloud? Then you can create an AD user, make sure they have UPN and email attributes set to match, then add that user to the scope of syncing objects and it should link it up. If not, you can always use the hard match technique.
My problem is system wich has recreated Exchange 2010 mailboxes for users wich are already migrated to o365. So it basicly broke connection of ad object and o365.
If I try to enable-remotemailbox I get this :
This task does not support recipients of this type. The specified recipient DOMAIN/OU/USERNAME
is of type UserMailbox. Please make sure that this recipient matches the required recipient type for this t
ask.
+ CategoryInfo : InvalidArgument: (domain….USERNAME:ADObjectId) [Enable-RemoteMailbox],
RecipientTaskException
+ FullyQualifiedErrorId : 8CE6E806,Microsoft.Exchange.Management.RecipientTasks.EnableRemoteMailbox
+ PSComputerName : computername.domain
Because these a azure ad sync objects, I can’t remove it from o365 without a removin it from AD. Removing license doesn’t help, it doesn’t actually remove mailbox.
You must remove the on-premises mailbox when the type is UserMailbox that means there is a mailbox (or it believes there is one) on-premises. Or, just get rid of sync and go cloud-only.
Can you help me with this? I have exchange 2010 and o365 enviroment with Azure AD sync.
I have a system wich creates new users, with exchange 2010 mailboxes. Somehow it does it when jobtitle etc is changed if it noticed that there is no exchange 2010 mailbox.
It broke several AD accounts connection to o365 exchange. I can’t figure out how to fix this. I can migrate them to cloud as they already are there. Most of enable-remotemailbox, disable-remotemailbox, etc all requires that connection is OK.
When you create accounts on-prem do NOT assign mailboxes to those accounts. You can just create them in ADUC and then run Enable-RemoteMailbox afterwards (do not create in Exchange 2010). If there is an automated task or something that looks for new accounts and sets up on-prem mailboxes, find and remove that task so it no longer runs. Another option is to create new accounts using New-RemoteMailbox instead of creating the users in the traditional way. That will create an account on-prem but connect it from the start to a 365 mailbox.
Hi Alex. First and foremost, thank you for this article as well as many others I have used of yours in the past! My question somewhat relates to this as searching for it brought me here. We migrated off of Windows SBS a few years back. I migrated all the Exchange mailboxes to O365 and then shutdown our on-prem Exchange server. We do run ADUC on prem though and I built an entirely new domain rather than migrating the SBS domain. Because of this and a few other reasons, both ADUC and O365 have been completely separate. I create the user in O365, then create the user in ADUC using the auto-generated password from O365. We’re quite small so I only create 5 accounts a year at most. I want to setup AAD connect and connect the ADUC accounts with their respective O365 accounts so that when a password change occurs on-prem, it is sync’d to O365. I need the accounts to have the same password as we are adding MFC devices that use Scan to MyDocs, Scan to Email and Scan to SharePoint. My plan this week is to setup a test OU, a few test accounts and then kick off the sync but I was curious if there were steps I could take to ensure the accounts are merged or connected rather than duplicates being created. The ExchangeGUID for example may be one I need to manually configure in ADUC prior to a sync. Thank you in advance!
It should not create duplicate accounts–it will use the SMTP matching method by default, and that is usually adequate. The Exchange GUID would only need to be set on-prem if your intention was to pull the mailboxes back down to the local environment (Off-boarding). I never do anything other than to ensure the primary SMTP value is set and unique across the organization, and that the UPN matches the email address.
Hello Alex! So all of my users have the Email field set on the General tab of Properties in ADUC and is unique. Other than that, I could just kick off the sync and it should match/connect the ADUC users with their O365 mailboxes? Thank you again.
The UPN is also matching the users email address.
Should work then. That’s all I ever do. when UPN’s match and there are no duplicates in the directory, there is a very high chance you don’t have any sync issues.
Hello Alex,
My first two test users worked flawlessly but my third user did not. The first two users were created after the old exchange server was already decommissioned whereas user 3 was migrated from Exchange 2010 to the cloud. The UPN and SMTP fields match but AAD connect tosses an error: AttributeValueMustBeUnique.
I’ve looked at every property in ADUC Attribute Editor and do not see anything off except the user has MS-DS-ConsistencyGUID is not set. Other users have this set but not sure that is even related. I noticed that users that were migrated to O365 have X500 addresses in the Exchange Online properties but users created directly in O365 do not. Any suggestions are greatly appreciated. Thank you again!
I got it fixed :)
https://www.petenetlive.com/KB/Article/0001588
This little tool fixed it quickly. Thank you again Alex!
This was very helpful. Thank you. I was thinking only powershell was the only way to fix this and with those commands it made it easier.
Alex,
I have the scenario you describe with regards to things being already borked. I have a bunch of AD users that were synced to 365 and have licensed 365 mailboxes. When I logon to my Hybrid Exchange server, the user is not listed because the AD accounts existed before the Hybrid Exchange server. My assumption is that I have to generate an Exchange mailbox for each user first as “Get-Mailbox [email protected] | fl ExchangeGuid” throws “The operation couldn’t be performed because object ‘[email protected]’ couldn’t be found on ‘exchange.server.com’.” After I generate the mailbox, the user will have an ExchangeGuid. I ran Enable-RemoteMailbox username -RemoteRoutingAddress [email protected] and the user appeard in my Hybrid Exchange server, but I have no GUID to give them. As such get-remotemailbox | fl ExchangeGuid returns all zeros. Please, any help would be appreciated.
Well, I tested this theory and that didn’t do it. Even though the user now has a GUID, I get, “This task does not support recipients of this type. The specified recipient domain.com/Company/OU is of type UserMailbox. Please make sure that this recipient matches the required recipient type for this task.” So much for that theory.
You don’t necessarily need the GUID of the mailbox to live on-prem. All you would need to to is have it aware of the fact that a mailbox exists in the cloud, with the enable-remotemailbox cmdlet, doesn’t matter what GUID says. What you want to avoid is actually having a mailbox on-prem that corresponds to the user account, and also have a mailbox in the cloud; then it gets confused.
New user was created in ADUC on-prem. Before on-prem Exchange mailbox was created the new user was synced to AAD and a license assigned in 365. This created a 365-only mailbox. I tried following the commands under the “…Borked” section above and am told that Enable-RemoteMailbox is not recognized as a command in Powershell. I am certain I am connected to Exchange Online Powershell. Everywhere I’m reading says Enable-RemoteMailbox is not a command available to Exchange Online Powershell. So how do I run these commands to get the 365 mailbox to sync back to on-prem Exchange (hybrid mode enabled)? I need to add a new email address for the user but 365 won’t let me do it since our local AD is synced to AAD.
Please forgive my previous stupid user comment, I totally neglected to see this line in your post: “Open the Exchange management shell ON-PREMISES and enter”. D’oh! Sorry, long day.
Great guide, Alex! I you just saved a user that I borked!
Awesome guide and your site is a newly discovered resource for me.
We have a hybrid setup.
I have a situation where certain users are not showing up on the local on-prem Exchange 2013 server under recipients.
We have two domains in our single forest. I will call our primary domain abc.com and the second domain xyz.local.
The users in the xyz.local domain just recently were added as cloud only 365 users and this past weekend, I merged their local domain accounts with their 365 accounts and modified Azure AD Connect to sync with both xyz.local as well as abc.com. Azure AD Connect syncs are working.
The users who do not show are all in the xyz.local domain. It is like the on-premise exchange server is not aware of the Active Directory partition that contains the xyz.local domain.
I tried to modify some of the attributes in AD on some of the users in xyz.local and then they started showing up in recipients -> mailboxes in the Exchange admin center for the on-prem Exchange server.
These are the attributes I modified, matching them with attributes from a user in abc.com:
targetAddress to [email protected]
msExchRemoteRecipientType to 6
msExchRecipientDisplayType to -2147483642
msExchRecipientTypeDetails to 2147483648
msExchVersion to 44220983382016
I am not sure if it is just one of the above attribute changes that allows the user to start showing in the on-premise Exchange server recipient mailboxes, or a combo of attributes.
However, once the user from xyz.loca shows up, I get an error if I try to view or modify any properties via the Exchange admin center (on-prem):
The call to Microsoft Exchange Active Directory Topology service on server ‘TopologyClientTcpEndpoint (localhost)’ returned an error. Error details No suitable domain controller was found in domain ‘xyz.local’. Errors: .
I am wondering if you might have any advice. It seems like maybe the on-premise Exchange server just needs to be made aware of xyz.local. I did a lot of searching and have not been able to figure out if there is a setting in EAC or a PowerShell command that I should run in the Exchange Management Shell. Any help would be much appreciated.
Whenever I see multiple domains or forests I always start by removing one of them, and getting down to a single domain/forest. In the SMB a whole other domain or forest is rarely required (usually it was overcomplicated or exists for some legacy reason that is no longer relevant like an old half-completed MA). One-to-one is the simplest. There is support for doing some other stuff now (used to be only 1-1). But refer to this article because there are still constraints on what you can do: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/plan-connect-topologies
It changes if you have AD FS too; so for example there is more you need to do to get a second domain added, particularly if it is a top-level domain and not a “child” domain. See: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-install-multiple-domains
But in your shoes I would be looking real hard at whether we could just discard of a domain altogether, and to that end, even just go 100% cloud accounts and get rid of hybrid identity. This is more possible than people realize these days and really simplifies things in a hurry. I do not recommend long term hybrid for my customers (it is a useful migration tool but after that not worth it–again, just IMO).
Thank you for the reply Alex
xyz.local is not verified in Office 365. It is not a domain that can be registered and therefore, no DNS and no txt records. .local is not an available top level domain in the realm of public domain names, (as far as I know…) However the users in the xyz.local domain do have email addresses using a domain that is verified in Office 365. (I will call it xyz-corp.com here to keep the real name from prying eyes.) xyz-corp.com is verified in Office 365 and xyz-corp.com has been added as an Alternative UPN suffix in Active Directory Domains and Trusts, so it can be used for the UPN and email address for users in the xyz.local on-premise Active Directory.
xyz-corp.com as also already added to the list of “accepted domains” in the Exchange admin center. xyz.local was not, so I added it, but I am not sure if it will make a difference since it is no longer used for the UPN.
All of the remote mailboxes do have Exchange GUIDs that match between local and cloud. The recent “merge” of cloud only and local AD accounts in the xyz.local domain was accomplished with a soft match by setting the UPN to be the same in AD and 365 as well as setting a proxy address in AD using the format of “[email protected]”
After some extended Google searching, I came across a social.technet post that helped me fix the problem with the ” ‘TopologyClientTcpEndpoint (localhost)’ returned an error ” issue.
1) Since the xyz.local domain did not have any mailbox enabled users when Exchange 2013 was originally setup, I needed to run the Exchange setup with the following switches: /PrepareDomain:xyz.local /IAcceptExchangeServerLicenseTerms
2) I had to edit the Default Domain policy for xyz.local — Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment > Manage auditing and security log — This security policies setting needed to have the Exchange Servers Group added from the primary domain. A few minutes after that was set, the error
After some convincing, our IT manager is agreeable to changing our primary domain name in AD to a new name that is inclusive of all users. (We are split up between several sister companies and our primary domain name only reflects the name of one of the companies. ) Once we make this change in the near future, that will help with several issues, (like split brained DNS issues — our primary domain name in AD and our public domain for web sites and email addresses are the same.) We can put everyone on a single domain as you suggested. Now if Microsoft would just let us change our tenant name. :(
Thanks again for your advice!
Changing domain name is a tricky thing; usually best to migrate into a new domain with the new name you want. The “rename” operation has all kinds of limitations for support, especially if there is an Exchange organization present. So be aware of that before you start.
Thanks for sharing this technical information, in addition to the solution, it makes us understand how our hybrid scenario works.
Hi Alex,
We recently ran into some big issues due to shared mailbox accounts being incorrectly created. Unbeknown to me, our service desk creates AD accounts on premise, waited for a sync and then created the shared mailbox in Exchange Online. To make matters worse, some shared mailbox accounts were left with enabled AD user objects and licensed in O365.
We upgraded AD Connect from an older 1.5.3.0 on 2012 R2 to the latest version on 2019. The upgrade was done using a swing migration with a PowerShell script to migrate the AD Connect settings.
On the day of AD Connect upgrade, everything seemed fine (objects synced and users were accessing O365 as normal). The next day, a number of shared mailboxes stopped working (they were just inaccessible from Outlook and OWA).
On further review the AD Connect upgrade, post sync seemed to have updated the msExchRemoteRecipientType for several thousand users.
We also noticed thousands of accounts with missing AD attribute values for ms-Exch-Guid on premise.
To fix the issue, we’ve done the following:
1. On our Exchange 2013 hybrid server use the Exchange PS cmdlet to set the GUID on-premise to match O365.
2. Set the remote mailbox property for shared mailboxes “set-Remotemailbox -Type shared”.
Have you seen this sort of behaviour before and any advice on performing a root cause analysis?
Thanks
Peter
Has anyone come up with a solution to automate this process. Unfortunately we have systems in place that will programmatically add a user into AD when our Hiring team adds the user into one of their systems. This has caused us to manually have to add quite a number of users.
I want to create something in powershell that wiill be triggered via scheduled task when a user account is moved from one OU to another. When a user account is generated in AD they’re always placed in the same OU. When the user is moved to another OU, I want the scheduled task to trigger to run the powershell script that will handle this task for us.
I have a hybrid 2010 setup and all the mailboxes migrated to Office 365. I am planning to decommission my Exchange server and install Exchange 2016 for Exchange attributes.
The issue I was facing was that found some user’s mailboxes are present in Exchange 2010 although the user’s mailboxes have already been migrated to Office 365 and working fine without any issue.
Kindly suggest how can I remove the on-prem user’s mailboxes that have no effect on Office 365 mailboxes.
Should be able to disable the on-prem mailbox without causing an issue if the user is already using their O365 mailbox. Make sure the alias addresses stay in place after the change (copy them out first in case you have to put them back). Autodiscover and SCP should both point to O365 so that the user does not pick up the on-prem mailbox; just verify before you make the change that in fact they are using O365 and not on-prem to be sure.
Thank you so much to save the time for recreating a user mailbox..
thanks a lot for sharing the useful information. I am happy to give as 5* and subscribe the blog. :)
May I ask a quastion:
I had given an environment, where another admin made some mistakes. It is an AD with Exchange 2013. They already used 365 parallel (so different accounts). THey then connected local AD with 365 via SMTP matching, but… they didnt do an Exchange Hybrid, instead they exported an imported mailbox information from local exchange to the online mailboxes. MX etc. is already changed to Exchange online.
What can I do now to clear the mess? Forcing a hybrid connection (problem is mailbox information is already used in exchange online) or should I die hard deinstall the exchange onprem?
It is supported to do hybrid w/o Exchange now, but be sure you do it right. See the article below.
https://practical365.com/removing-the-last-exchange-server/
Thanks for your reply.
Question is, what is to do, when someone export-import the mailbox data from a local onprem exch to an exch online mailbox, but having adconnect in place. For my understanding to correct way would have been to do the hybrid and migrating the local mailbox to exchange online. What I see now is, there will be still a local mailbox on the exchange and a new mailbox in exchange online (with the content of the local mailbox via export-import). I want to untie the knots from this strange situation happened.