[Update]: This post was updated on January 27, 2021.
Once you have completed a hybrid configuration in your company, it turns out that the job is not done yet. After a quick verification whether the hybrid is set up correctly, you notice that some of the users are not synchronized properly. And if that is the case, you need to do some additional adjustments. If you hit the roadblock during the synchronization it is most probable that the problem will be related to user synchronization between local Active Directory and Azure AD. Common causes for this are:
- Lack of rights to Organizational Units (OU) or AD objects (users, groups or computers) for a service account used by Azure AD Connect (AAD Connect)
- The improper scope of objects synchronized with Office 365. In other words, perhaps an OU that contains a certain user object, group or computer was not selected in the AAD Connect configuration wizard.
You can encounter these problems when you run the synchronization from on-premises AD to Office 365. But this can also happen the other way round when you run the synchronization from Office 365 to on-premises AD or in both directions. Look at the most common scenarios here:
- A user has an Office 365 account and no local AD account;
- A user has an account in Office 365 and in local AD (this user had two accounts before the hybrid configuration was implemented to have access to services offered by Office 365);
- A user has an account in Office 365 with an Exchange Online license assigned as well as an account in local AD with an on-premises Exchange mailbox (a single user has two separate mailboxes).
In this article, I will show you how to manage these situations in an environment with hybrid configuration and Centralized Mail Transport enabled.
A user has an account in Office 365 but not in local Active Directory
In this scenario, a user account is created in Office 365 in a hybrid setup. It is worth mentioning that this scenario is correct and supported by Microsoft. However, it causes problems for an Office 365 user when he or she wants to access public folders being on the on-premises Exchange. This means that the user will not be able to access local public folders (legacy public folders) and any attempt of connection will throw an error:
Cannot expand the folder. The set of folders cannot be opened. Network problems are preventing connection to Microsoft Exchange
How to solve this problem
To solve the problem you need to run SMTP matching. This means that you need to create a local AD object with SMTP address that matches primary SMTP address of a user object in Office 365. Unfortunately, there are some limitations highlighted by Microsoft related to SMTP matching:
- A user account that you want to run SMTP matching on needs to have an Exchange Online email address (the Exchange Online license is not required).
- A user account that was originally authored in Office 365 can be SMTP-matched only once.
- During the SMTP matching process, the primary address of an Office 365 user can’t be updated.
- Every SMTP address needs to be unique, otherwise, the synchronization will fail and you may see this error:
Unable to update this object because the following attributes associated with this object have values that may already be associated with another object in your local directory services: [ProxyAddresses SMTP:[email protected];]. Correct or remove the duplicate values in your local directory.
To match users in Office 365 with AD users, follow the steps below:
- Log in to Office 365 and go to Exchange admin center.
- Write down the primary SMTP address for a selected user in Exchange Online (if you do not have an Exchange Online license, you can take this address from user’s Office 365 login – in most cases it’s the same).
- Create a user object in your local Active Directory with the same attributes (first name, last name, UPN, etc.) as they are in Office 365.
- Set up the primary SMTP address for a new AD object using the address from step 2. In Active Directory, look for the proxyAddresses attribute.
- Force the synchronization of AD objects with Office 365 on the server with Azure AD Connect. Use the following cmdlet:
Start-ADSyncSyncCycle -PolicyType Delta
- After a successful user synchronization, you should see that the Sync type section shows Synced with Active Directory instead of In cloud.
Once the synchronization is finished, an Office 365 user should have access to on-premises public folders.
A user has both Office 365 and local AD accounts
Sometimes a company uses both environments to have access to different services offered by these two platforms. For example, the company decides to use Office 365 to have access to SharePoint Online and Skype for Business services. At the same time, the company maintains the on-premises Exchange Server.
However, when you set up a hybrid environment and synchronize directories via Azure AD Connect, this may duplicate user accounts or cause other sync issues. A single user can end up having two accounts – one in Office 365 and one in local Active Directory. If the company uses Skype for Business (Lync) in an on-premises environment, the synchronization can be even more complicated.
If that is the case, you should carefully plan the synchronization before using Azure AD Connect for the first time. By verifying attributes, UPNs and SMTP address, make sure that all AD objects correspond to Office 365 objects. Additionally, when you have Skype/Lync on-premises you should think over what results you expect to achieve. For example, you may decide to migrate to Skype for Business Online and stop using the on-premises solution.
Generally speaking, if any problems appear in this scenario, you can run SMTP matching as well. If there are duplicates of user accounts, you need to remove them from Office 365 using the following cmdlet in Azure Active Directory Module for Windows PowerShell:
Remove-MsolUser -UserPrincipalName [email protected] Remove-MsolUser -UserPrincipalName [email protected] -RemoveFromRecycleBin
For a user who has a duplicated account, you should check and correct attributes either in Office 365 or in local AD. In Azure AD Connect, you can find more details on fixing synchronization problems.
To get more information on Skype/Lync migrations, visit this Microsoft website.
A user has one mailbox in Office 365 and one in an on-premises Exchange
It is one of those weird situations when a single user has one AD account but is connected to two mailboxes – one mailbox is in Office 365 and the second one is on on-premises Exchange (practically, it will be connected to on-premises via Autodiscover). This situation is very similar to the one described in the second scenario above, with the only difference that an Office 365 user has the Office 365 license assigned (including a license for Exchange Online). As you can imagine having two mailboxes in hybrid settings causes complications in email flow for that user. When the MX record points to Office 365, an email will get stuck in Office 365 mailbox and will not be delivered to an on-premises mailbox.
How to solve the problem
Unfortunately, in this case, SMTP matching will not help. The only result you would achieve after running the SMTP matching is having Office 365 and the on-premises accounts matched – this will not merge mailboxes though. Removing a license from an Office 365 user will not solve the problem either.
Note: Keep in mind that although no SharePoint or OneDrive data should be deleted during the process, the duplicate cloud mailbox will be purged. If there is any additional Exchange Online content in this mailbox, you should back it up before performing the clean up. If you need to repeat this procedure for a number of users, you may consider using a third party tool like CodeTwo Backup, which will also help you restore data to on-premises mailboxes.
The best solution is to clean up the problematic Exchange Online object. To do so, simply follow the steps below:
- Connect to Exchange Online:
Connect-ExchangeOnline (learn more about connecting to Exchange Online remotely)
- Then, clean up the object using the following cmdlet:
Set-User [email protected] -PermanentlyClearPreviousMailboxInfo
As soon as you confirm the action and PowerShell finishes this task, you are left with a clean object which can be re-licensed correctly. Once you assign the Office 365 license, you should see the following information:
If you backed up the data from this mailbox, as noted earlier, you can now restore it.
There is a second method you can use to solve the duplicate mailbox problem. Before the option to clean up the Exchange Online object was available, the only solution was to remove the Office 365 user and recreate it using Azure AD Connect. While this method can still be used, it will result in deleting the whole user object, together with their SharePoint and OneDrive data.
68 thoughts on “How to merge an Office 365 account with an on-premises AD account after hybrid configuration?”
@Michal Januszczyk THANK YOU! I was fighting with the exact same issue, following the steps for scenario #1 and kept getting a second O365 account created. Removed the role and ran the process again successfully!
I found something that may be useful for others – if you have scenario 1 (O365 user no AD) you will get duplicate O365 accounts when you try to sync if your O365 user has ANY admin roles assigned. Remove the admin roles first > create user in local AD > update proxy address to match O365 > run delta sync > O365 account should now change from CLOUD account to LOCAL SYNC account. I was fighting with this for days until i found an Azure sync error log which states the below (for once a useful error message). Once the account becomes a Local AD sync user you can add the O365 admin roles back. Figured this may help someone from having to delete the O365 account:
This user object cannot be synchronized with Azure AD because an object with the same UserPrincipalName or ProxyAddresses which has administrative permissions assigned, already exists. It is not allowed to soft match a user object from on premises AD with a user object in Azure AD that has an administrative role assigned to it.
To resolve this issue, either change the UserPrincipalName or ProxyAddresses to a value that does not match that of an Admin user in Azure AD – which will create a new user in Azure AD with the matching UserPrincipalName or ProxyAddresses – or remove the administrative role from the Admin user in Azure AD, which will enable the soft match between the on premises user object and the existing Azure AD user object.
Note that you can assign the administrative role to the existing user object again after the soft match between the on premises user object and the Azure AD user object has completed.
It always seems to come down to “delete the 365 account” and resync. But the problem I have is that the OnPrem account was only used to logon to the local domain and all documents and mail are created by and attached to the 365 account. If I delete the 365 account, I guess I will lose all Teams, OneDrive and Mailbox content for that user? Or a I mistaking?
It depends on your scenario. If you have an on-prem account (but not mailbox), you can run the SMTP matching (the second scenario), which shouldn’t influence Teams, OneDrive or Mailbox content.
If you have mailboxes in both Exchanges (on-prem and Online), you can use the method described in the third scenario (including the cmdlet: Set-User [email protected] -PermanentlyClearPreviousMailboxInfo). It doesn’t delete OneDrive or Teams data, but purges the mailbox. For more information, take a look at this Microsoft’s blog.
We have onsite AD to cloud Office 365 Azure. Our system is set up where users have to manually change passwords in AD for it to sync Office 365. Is there any way to set it up to allow users to change passwords using Office 365 to sync to AD??
You can set it up with the Azure AD password writeback feature. Learn more about prerequisites and how to set it up on this Microsoft’s page.
Our setup is OnPrem AD : Domain name : xyz.local
O365 Mailbox : Domain Name : abc.co.in
Currently users are able to to login to their machines using local credentials and access O365 mailbox using outlook.
Now we are planning for SSO for AD and O365 both and we want that OnPrem AD password will Sync to O365.
In both (OnPrem AD & O365 Mailbox) ID’s for the users are differnt, please suggest how we can SYNC and use same password.
Take a look at this Microsoft’s article, it describes in detail how to handle non-routable (.local) domains.
Using AAD Sync tool from on-prem to 365 (no onsite exchange)
Existing AD user “adminperson” with email address and 365 mailbox of [email protected]
Want to create New AD user and assign that same email to them instead of existing.
Will it “know” to keep all content but simply link new AD account?
As far as I know, you won’t be able to do this. You can’t link two AD users to one Microsoft 365 mailbox and SMTP matching will fail if two objects have the same SMTP address.
It would help if you specified what you want to achieve.
I need help with merging account from O365 to AD on Premises. I tried to create user account in AD with same SMTP but it ends up with an error “The pre-Window 2000 logon name you have chosen is already in use in this domain. Choose another pre-Window 2000 logon name, and then try again.”
It seems you already have the user account in AD. Check if it’s mailbox-enabled and follow the solution from the third scenario.
Hi Adam. I love to read your blogs. thanks for great work! I have the same situation: many users with duplicate mailboxes (one on Prem on in Cloud). We gave ExOnline Licenses in O365, then we installed ADConnect with Hybrid flag). I NOT yet have run the HCW. Is it true that I can run the HCW any time and it will nothing change about the duplicate situation? I ask because I need to merge the accounts later. Thanks.
I’m glad you enjoy the blog! HCW will not delete any mailboxes – mailboxes will still exist both on-prem and in the cloud. You can read more about what the HCW does exactly in this article.
Great article, I got my hopes up for a second but I don’t think it covers our situation. We have had a hybrid setup for a couple of years with most mailboxes in Exchange. AD and Exchange accounts are created by a third party tool and AAD connect syncs password hash to 365. A powershell script assigns the correct 365 license.
We have now started to create new users with exchange online accounts by not creating a local exchange account and letting the application of license in 365 generate a mail account. This works apart from us having no local visibility of the exchange online account and mail from not 365 accounts is not being routed to the new accounts.
I am guessing we need to sync back exchange details to on prem or can AAD connect tell on prem the email acount is in 365?
BTW it works fine if I create on prem and migrate to 365.
You probably should have used New-RemoteMailbox on your local Exchange to create an (on-prem) AD object and an associated Microsoft 365 mailbox. Have you tried fixing it with the SMTP matching (scenario 1)?
Trying to forecast a reaction of Office/ Outlook after AD-Sync . I’m in this scenario : We have 157 user in Office 365 using office licenses but emails are not being used. Our logon is [email protected] We also have a Exchange 2010 on-premise server with email [email protected] . I think I can utilize AD-sync and soft match the sync. My issue is the Microsoft license. After I AD- sync to the cloud, what happens to the license? Does it retain the assigned user email address [email protected]? What happens to the desktop user when they open Office Outlook ? do they get prompted for credentials? Has anyone goes thru these same scenarios?
And I did follow these steps :
As long as you match accounts correctly, licenses shouldn’t be an issue. Apart from the sync, you will also need to perform a mailbox migration, which includes changing MX records and recreating Outlook profiles. Read more about mailbox migration
I have same scenario, need some suggestion to resolve it.
OnPrem AD : Domain name : xyz.com
O365 Mailbox : Domain Name : ABC.com
Currently users are able to to login to their machines using local credentials and access )365 mailbox using outlook, but they are unable to connect with Skype for Business online.
Requirement : Change the Local AD Domain name in sync with O365 domain name i.e. abc.com and would like to setup the Skype for Business server OnPrem connecting with AD to use same O365 credentials login to local machine. This will allow user to use same o365 mailbox credentials in Skype for Business and also able to connect with other users.
Please suggest the solution. Thanks
Do you have a hybrid environment currently configured? You can change the on-premises AD domain name and sync it to AAD afterwards, but is it a good idea to do all this work when SfB is being retired next year?
Thanks for the wonderful info above. I am somewhat of an advanced PowerShell user. When I create a user on my scripts, I first create locally (locally for shares, folder, access) and make a new account on o365 and sync. They sync right up! The problem I have is there are two different passwords, one local and one O365. Is there something I can do to fix this? When you create a user on O365 it auto sets a random password.
Which cmdlet are you using to create a new user? Using New-RemoteMailbox should do the trick – it creates a user locally and also adds an associated mailbox in Exchange Online. There should be no password issue, then.
I work for a university in a department that have their Exchange email hosted by Intermedia (@dept.school.edu). We want to migrate back into the school’s O365 (@school.edu) instance and retain our current subdomain (@dept.school.edu) as the default login after migrating to the campus 0365 instance. How do I go about doing that?
Migrating from the hosted Exchange to Office 365 (@school.edu) can be simplified with Office 365 Migration. Later on, you would have to add the subdomain (@dept.school.edu) as a custom domain to Office 356, add the subdomain’s email addresses to users and configure an alternate login ID (here are instructions on Microsoft Docs).
Thx for create article!
I have a scenario
the customer changes service provider.
They are intertwined with O365 and local AD.
The new service provider is doing a new AD. How it should be synchronized with the existing O365. What else to look out for?
This topology is described in this Microsoft Docs article. Mind that it is possible to consolidate users with AAD Connect, but groups will be problematic.
Hi – I have a scenario and looking for help
I have users who have an AD account and who also have a contact account in the same AD domain – So both type of accounts using same email address, which is external to the AD domain because these users are kind of contractors who use their parent company mail address. Both are synced to AAD – for the AAD sync since the contact account is synced after the user account, it merges with the user account and no sync errors pop up. But the emails send to these mail address sourced from any on-prem mail boxes are getting dropped at exchange server showing duplicate accounts found with same email. We have a hybrid environment and this is causing a real messaging issue for all users. Any suggestions please?
– Thanks in Advance
Keeping a mailbox on-premises and in the cloud is a common cause for mail-flow issues. This Microsoft docs article seems to apply to your situation.
Hi – I have scenario 1:
Local Exchange Mailboxes ([email protected])
Office 365 with MS-Team and Sharepoint License and NO Mailbox([email protected]).
When i do the migration (Staged/cutover) will it create a Mailbox on the existing O365 Account? Or do I have to delete/rename the existing accounts?
Scenario 1? Just to be sure, you have local Exchange mailboxes without their AD accounts?
When it comes to the native migration methods, you will need to assign Exchange Online licences before the migration. If you are using third party migration tools, they can both create users and assign licences for you.
In Scenario 1, will merging the account from a Cloud only account to a AD Sync account wipe any existing data on the cloud account? Like Mailbox data etc.?
SMTP matching doesn’t wipe any mailbox data. Office 365 data loss is guaranteed in the Scenario 3 – “A user has one mailbox in Office 365 and one in an on-premises Exchange”. In either situation, having a fresh Office 365 backup doesn’t hurt.
Thank you for the above information. I have a much simpler issue, I have in some cases Local AD user and an O365 User they have different UPN’s, in our scenario we used O365 to provision Office and One Drive storage and created just an O365 account, now that we synced with AD Connect I have duplicate entries for those users that was provisioned with an O365 account.
Id like to merge those duplicate accounts without having to re-sync One Drive data.
Please can you advise
Unfortunately, I don’t see a simple way to resolve this issue without re-syncing OneDrive data.
Basically what you have described is the third scenario from the article. You will not resolve it with a simple SMTP matching and recreating the mailbox will get rid of the OneDrive for Bussiness data.
Great stuff, save me
Bookedmarked for the future.
Thank you for this information, it was very helpful. I have a question though, is there an “Easy Button” method for scenario 3? Like if you had multiple accounts that did not migrate properly and needing to have this done quickly, is there an application or tool that Microsoft has that would streamline this?
If you have multiple cases like this, the best way would be to get a list of those mailboxes, delete them in bulk using PowerShell and finally run the Start-ADSyncSyncCycle -PolicyType Delta cmdlet on-premises. The hardest part is backing up the Office 365 data. CodeTwo Backup for Office 365 could help you with task. If you want to use natively available solutions, you can export data with eDiscovery.
I’m in this scenario : A user has one mailbox in Office 365 and one in an on-premises Exchange.
And I did follow these steps :
Connect to an Office 365 tenant using Azure Active Directory Module for Windows PowerShell:
Then, remove the user by executing the following cmdlets:
Remove-MsolUser -UserPrincipalName [email protected]
Remove-MsolUser -UserPrincipalName [email protected] -RemoveFromRecycleBin
Finally, recreate a user via Azure AD Connect by forcing the synchronization process (run the cmdlet on the server with Azure AD Connect):
Start-ADSyncSyncCycle -PolicyType Delta
As soon as you activate the Office 365 license, you should see the following information:
But when I reactivate the license for the user I have an unexpected error from EOL with a log correlation ID number.
When I look for details for this error (with the following command : (Get-MsolUser -UserPrincipalName [email protected]).errors.ErrorDetail.objecterrors.errorrecord.ErrorDescription)
The error is saying that the user is trying to add an already exsting ArchiveGUID.
(Local archiving was enabled for this user).
It seems that you have deleted the user from Azure Active Directory, but some data remains in Exchange Online. You should be able to fix this issue by using Remove-Mailbox *The GUID you mentioned* -PermanentlyDelete. If the cmdlet runs with no issues, you should be able sync succesfully using AAD Connect.
I have correctly installed AD sync to our server and it syncs with office365.
All the users that only had 1 email @company.com moved over correctly and are syncing with on premises.
However all the users with aliases did not move over correctly and got a onmicrosoft.com account on office365.
After going through the forums i found that I need to add their aliases to the attributes tab, which I have now done correctly for all users. I manually removed all the incorrect onmicrosoft accounts and ran another sync.
For some crazy reason it is still not syncing the correct account and creates another default onmicrosoft account.
Is there something i am missing?
Will i need to completely remove and start AD sync from the beginning?
As far as I know, you need to temporarily remove those aliases, sync AD accounts to Office 365 and re-add aliases after the sync. Test on a single account and see if AAD Connect creates onmicrosoft.com object then.
We have over 100 users currently created in Office 365. Same users are created in local AD but not sync to office 365. Now due to some regulations we need to have SSO from local workstation all the way over office 365. My problem is how do I give the current mailboxes to from office 365 users only to new sync user from AD.
If I understand correctly, the second scenario – a user has an Office 365 mailbox and an AD account – fits your situation perfectly. You should be able to sync your AD accounts with Office 365 mailboxes without problems, as long as you make sure that on-premises users have correspondent AD attributes before running the AAD connect.
If I create an O365 user. Then create an AD account for that user. Then do the SMTP matching, how do I get the O365 user to show up in my onprem GAL?
When you run the SMTP matching and force directory synchronization with AAD Connect, you can force GAL update using the Update-GlobalAddressList cmdlet. Mind it might take some time to update the address list in Outlook clients if your users are running a cached mode.
There is another method which avoid deleting the user introduced by Microsoft :
Set-User cmdlet in Exchange Online PowerShell
Please check :https://blogs.technet.microsoft.com/exchange/2018/01/17/permanently-clear-previous-mailbox-info/
That is right, thanks for mentioning this method. It was not available at the time of writing this article. I will be sure to add a few words about the Set-User cmdlet and the -PermanentlyClearPreviousMailboxInfo attribute.
Hi Everyone I have two DCs and O365 user, I have also added AD Sync tool on both DCs. My problem is , I don’t see any of the user synchronized to DCs Active Directory from O365 account? what could be the problem? I have tried scenario 1 which is working for new user add, but i want to synchronize all o365 user to my AD on Domain controller.
Thanks in advance
Have you followed the instructions from this part of the article? Because it seems (correct me if I’m wrong) that you have not re-created users from Office 365 into the local DC. If you scroll to this comment, Alfred has recently posted the procedure he followed, you can check if it makes things easier for you.
as you said, the user details won’t be included in the sync O365 to local AD.
I opened a test tenant and did the following:
– Added few users in O365
– Exported them with Get-Msoluser into a CSV, with all details I need/want in local AD
– Imported them to local AD with New-ADUser
– I didn’t need proxyAdress, it seems it works as long as the local UPN equals the login name to Office365 (and you don’t have a hybrid exchange environment running)
I ran into one thing: When I change details like City in local AD they won’t be published to O365 as long as the user has not an exchange licence added in O365 (as described in https://docs.microsoft.com/en-us/azure/active-directory/hybrid/reference-connect-sync-attributes-synchronized)
First testing went well, thanks for all the information provided
Adam, thanks for the fast response!
For sure I’ll go for Powershell :) Even if it would be 5 users ;)
Sounds like a plan. I will test it and post here again as soon as I got some results! Thanks!
Hey, thanks for all the information!
I got a running O365 tenant with about 15 users with Exchange Online. No local AD.
Now there will be a new local server with a new domain controller in a new domani environment. I don’t want to manage users locally and in O365 separately, so I want to sync them. Since I’m starting with an empty local AD, what would you advise?
Sync O365 into the local AD (does it even work with AADConnect?) or create 15 users in local AD by hand, add their proxyAdresses corresponding their O365 mail adress/login and hope for the best? ;)
Thanks in Advance!
Glad you found the article useful!
The scenario you need to follow is the first option in the article, so yes, the proxyAddress matching. You can create the users by hand since there is only 15 of them; however, I’d automatize it with PowerShell.
But first things first: AAD Connect is primarily used to sync on-prem Exchange to Exchange Online. If I remember correctly, AD attributes will not be synced from the cloud to the on-site Directory. That’s why I would first create a test account in O365, define some attributes, sync using proxyAddress matching and see what happens. Which, I suspect, would be syncing the empty, attribute-less account to the cloud.
If it works the way I suspect it to, the least problematic way to go about it would be to pull your users from Office 365 with their attributes to CSV (using the Get-MsolUser | Select-Object | Export-CSV cmdlets) and using the CSV to create users on-premises. After that, the synchronization *should* go without any problems.
Thank you for the helpful and informative write-up. Google keeps recommending your site for a solution to our issue.
We have an Office 365 Resource that acts as conference room and has a busy calendar. We’d like to merge this Office 365 Resource with an existing AD account and preserve the Office 365 calendar.
Is this possible or do you have any suggestions? Thanks!
i have a question is it possible to use online funcitons like outlook/people/calendar but with on-premise mailbox and not exchange online? Because as is mentioned in article user would have 2 mailboxes and there could be problem with synchronization, so is there a way to direct these online apps to on-premise exchange? As we testing it out when i try to use online outlook i get error: Microsoft.Exchange.Data.Storage.UserHasNoMailboxException
Hope this make sense.
Our setup is AD, O365, on-prem(2016) using Azure AD.
When we create a user in AD it will sync to O365, creating a user and mailbox but doesn’t create the user on-prem. This causes issues with system and copiers that point to the on-prem system to deliver emails.
i have tried to create the account on O365 but that also will not flow to on-prem or even AD.
I should mention that I did try to set the proxy address which did create the user on-prem but emails still did not route to the users O365 mailbox. Copiers showed the mail was delivered but received undelivered emails from on-prem.
Could you specify how you create the new users? Please try creating a test on-prem user with the new-mailbox cmdlet and see if the user is present in AD afterwards.
Creating a user in O365 will not sync it back to the on-prem environment – that is the default configuration.
I that did but really do not like to do it this way. Much easier to copy an AD user account will all the groups and settings.
Thanks for your help.
Hi Adam, I was searching for a solution to a problem I have and I keep getting directed to your page. In short, my problem is the 3rd scenario. 2 of my users have a local exchange mailbox and O365 mailbox. However, these users are admins and removing them will disable or break things in O365. So using the provided solution isn’t possible.
What I would like to know is there a way to just disable or remove the local exchange mailbox and direct all mail traffic to O365? Keeping the local mailbox isn’t a big deal since we can export a pst file then import it into the O365 account.
Hello Adam! Could you guide me in a particular case? I currently have a local domain and a domain in 365 that are called different, there is no synchronization between the two, the users of 365 are created manual and local too, now I am being asked to unify a single domain … to be called the same 365. What options do I have? Is there any way I can export users and passwords from Azure AD to a new local server that I configure with the name I want? thanks!
That is tricky. Azure AD Connect does not allow a sync from the cloud to the on-premises environment. So if you want to export users from Azure AD into the local AD, you would have to do it with PowerShell cmdlets. Mind that there is no PowerShell script to export passwords, so you will have to create temporary passwords in your target AD environment.
I presume that you will also have to migrate mailboxes? To migrate them, I would use CodeTwo Exchange Migration. This software will create users in the target environment for you and migrate mailboxes from Office 365 to the on-premises Exchange in an easy way.
Hi Adam, great article, thanks a lot!
I work in a school as teacher and have an extra function there as admin of our local AD (windows Server 2012 R2) and our Office 365. Our setup is like this:
Until a few years ago we had a Windows Server 2003 in the school with AD and Exchange. While the server still worked as AD, we moved our mail to Office 365 and I created users with mailboxes in Office 365.
Later when got a new Windows 2012 R2 server for AD, it didn’t synch from the Office 365 to our local server, only the other way round, even with Azure (probably because I don’t know how to do it). So I had to create users in AD, and they are automatically synched with Office 365. I do that with new teachers and it works fine. But I would like to merge the “old” teachers in our system to avoid the synch-conflicts from Azure.
Since we also use onedrive and sharepoint, I’m a little reluctant to change anyhthing that I don’t know the consequenses of. But with your guide I hope to end up with only one account for both the old and new users. Is that possible?
Please do let me know when you are able to do so. I was just thinking of the same situation and its resolution
If I understand correctly, your situation is like the one I describe in the third scenario. The solution I propose (deleting the Office 365 user and recreating the mailbox with AAD Connect afterwards) is not perfect – you need to backup all Office 365 data (including Onedrive and SharePoint) for the user and re-assign permissions for their mailbox. It will be time-consuming and problematic, but will end with a fully merged user in both on-premises Exchange and Exchange Online.
I have a on-premise AD and office 365 email (as well as Azure AD)
on-premise ID: [email protected]
office 365 mail: [email protected]
how do I sync/match this user with different username…? Is it possible?
You need to add proxyAdresses [Office 365 account id] in the attribute of the user located in Local Active Directory.
Searched for this page two months! Finally found it and worked out great.
CodeTwo sp. z o.o. sp. k. is a controller of your personal data.