The question nobody dares to ask! How do you create a new user in a hybrid environment.

Iron Contributor

Hi, the last couple fo days the question how to create a new user in a hybrid exchange environment is floating around in my head.


Most of the time when i create a user i create a onpremise account in active directory sync this over to office 365. The next step i perform is the creation of a mailbox onprem in exchange for the user i have created. When i have done this i migrate the user mailbox to office 365, i assign a license and the user is good to go.


Is this the best way to do this? It seems more logical to create a user in AD sync this over to office365 and give them a Exchange online license. so he or she will get a mailbox directly in Office 365.


Can anyone give me an explanation what is best practice for creating a new User in a hybrid exchange environment when al the users will be synced to office365.


Thanks in advance!

44 Replies


I would have a follow up question. If I use the New-RemoteMailbox command instead of migrating the user, I see as a difference that the on-premise recipient gets no X500,x500 address, the exchange guid is  00000000-0000-0000-00000000  and the ExchangeVersion is lower (compared to a migrated user). Does that have any consequence if I move the online mailbox back to on-premise (say for insufficient license count)?

The Get-RemoteMailbox address information does also not list x500 addresses, but if I do get-mailbox on O365 online, then I get as said before an X500 entry (uppercase only and as said different OU).



A different topic yes, but a quick response for my two cents. You can run without the Exch on prem, but it is not supported by Microsoft and requires digging into AD Attributes manually if you need to change some objects like primary SMTP address etc. Do-able, but not supported. It is best to leave one Exch server on premise just for management purposes event if it doesn't have any mailboxes or databases. I have heard of some even standing up a current version (in the event your on prem servers are older) in a VM and just reducing resources to the min required and keeping it around as a management machine. You will still need to apply OS and Exchange updates to it so don't forget about it.

You can have also an Hybrid Server Key License for free, depends the conditions.


In the bellow site is the how to, and the conditions to qualify to Hybrid Server free license.

So let’s do a recap!


You can create users in two ways.


Create a user onprem sync the user and create a mailbox onprem then migrate it.
You create a new-remotemailbox that will create a mail user in the on-premises AD and also create an associated mailbox in O365.


The way to create a shared mailbox is create it onprem and move it to Online, or create a user mailbox online and convert it.


The best practice is whatever works for your user management. And in an Hybrid environment you always need the exchange server for maintenance purposes.


One last question when you use the new-remotemailbox option. You have to set the rights on the user manually? So you can’t use Copy from user John Doe?

I did some extensive testing and research on this topic.  I have elected to create new user, room, and equipment mailboxes in Exchange Online.  My process for user, room, or equipment mailboxes includes:

1.  Create AD account and add sync attribute.

2.  Run enable-remotemailbox command

3.  Wait for synchronization.

4.  License mailbox. 


I am creating shared mailboxes on-prem and migrating them. 


In the event you need to migrate a mailbox created in Exchange Online back to on-prem you will need to add the mailbox GUID as shown in this article:


I hope that helps. 






I would agree with others as well. Creating the user on-prem and migrate it to the cloud everytime we need to create a EXO user is a hassle. But as of now this is the accepted way. (I guess) And this is mainly for because of the AAD Sync is setup to sync from On-Prem to EXO.

The method I'm using to create a new user is

*Create the Remote mailbox (which creates the AD account as well)

*AAD Sync force sync and it will create the user in Office 365

*License the user

*And this will enable the EXO mailbox


Method of migrating an exsisting user is

*Make sure the user is synced accross

*License the user

*Execute the Online to On-Prem migration from the EXO portal

*Once the mailbox is migrated, the on-prem account is anyway will be a remote mailbox.


Hope this helps.


If you own Azure AD Premium (or EMS or SPE license) then you can simplify this process down to one step

Step 1: Create the Remote mailbox.


How is this possible?

Creating a remote mailbox automatically creates the AD account. Then, AAD Sync will sync every 30 minutes (by default) and that will create the account after the new remote mailbox command is issued from on-prem. So no real need to force a sync unless you are in a hurry.

Azure AD Premium will automatically License the user. Instructions on setting that up are here:

This is all now possible due to the new Azure AD Premium feature, which lets you assign licenses based on group membership, or even dynamic membership.



Yeah, only thing that is missing for replacing my script is the advanced auditing settings for the Exchange mailbox, but maybe there is something I am not aware of.



For me, the only way to make it that let you migrate the mailbox from EXO to On Prem and vice- versa without issue, still to create the AD account on prem, create the mailbox on prem and migrate it to EXO.

Since the AAD Sync still one way.

I'm with Paul, Vasil and Nuno :)

Just a hint: if you create the mailbox in EXO, the ExchangeGUID is not present on the object and if you want to offboard the mailbox, this value has to be set manually.

Environment: Exchange 2010 SP3 and Exchange Online hybrid. 


I have tried the create account in on-prem Exchange 2010 and migrate method and the Exchange Management Shell (EMS) method and found that EMS method is most efficient for me. Below is the command string I'm using.

New-RemoteMailbox -UserPrincipalName "[]" -Name "[First Last]" -Alias "[First.Last]" -RemoteRoutingAddress "[First.Last]" -FirstName "[First]" -LastName "[Last]" -DisplayName "[First Last]" -OnPremisesOrganizationalUnit "[OU Where I Want User's AD Account]"

I did find that if I used the -PrimarySmtpAddress switch with New-RemoteMailbox, there was the unintended consequence of disabling the email address policy for the mailbox, creating Exchange Online to on-prem Exchange email delivery and calendar free/busy issues. This can be resolved by using the following command.


Set-RemoteMailbox -Identity [mailbox name] -EmailAddressPolicy $true


I hope this helps someone save some time.

Also, to give credit to the person that solved the issue caused by me using the -PrimarySmtpAddress switch.

Could you kindly share the script where you create the user in AD and force the dir-sync.

What i'm trying to achieve is to make the whole process automated
The user fields(properties) will be generated by a CSV file
1.Create the user in AD OU that is AD-Connected
2.force AD Sync
3.Assign License (by PS script) - we use only two types of license: Business Premium and E3
4.Send Notification to Admin that email account was activated.

@ShrenikSalguna wrote:
Could you kindly share the script where you create the user in AD and force the dir-sync.

What i'm trying to achieve is to make the whole process automated
The user fields(properties) will be generated by a CSV file
1.Create the user in AD OU that is AD-Connected
2.force AD Sync
3.Assign License (by PS script) - we use only two types of license: Business Premium and E3
4.Send Notification to Admin that email account was activated.

I posted my script in the following location because I used the OP's script as the starting point for my script. I have since added valuable functionality to my script and will be posting an update as soon as I take the time to remove all my company information from it.




I use the on-premise Exchange server to create the user if that helps you (note the below cannot simply be used, just for inspiration)

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://[yourExchangeServer] -Authentication Kerberos -Credential $adminCredential

Import-PSSession $Session -Prefix XXX
$remoteMailbox = New-XXXRemoteMailbox -Alias $initials -SamAccountName $initials -UserPrincipalName $userUPN `
-Name $fullName -FirstName $firstname -LastName $lastname -DisplayName $fullName `
-Password (ConvertTo-SecureString -AsPlainText $password -Force) -ResetPasswordOnNextLogon $false `
-OnPremisesOrganizationalUnit $ou.DistinguishedName `
-Confirm:$false `
-DomainController $domainController -PrimarySmtpAddress $userUPN # `
#-Archive #latest addition to have an archive mailbox active

Start-Sleep -Seconds 8 -Verbose

$remoteMailbox | Set-XXXRemoteMailbox -EmailAddressPolicyEnabled $True

Remove-PSSession $Session



and for sync I run the following:


$Session = New-PSSession -ComputerName [syncserver] -Authentication Kerberos -Credential $adminCredential


$JobSync1 = Invoke-Command -Session $Session -Scriptblock { Import-Module ADSync }
$JobSync2 = Invoke-Command -Session $Session -Scriptblock { Start-ADSyncSyncCycle -PolicyType Delta }

Remove-PSSession $Session

@Jerry Meyer 


The answer that you are looking for is not something that is easily defined any longer. Everyone who has provided a working answer here is in part correct about what is 'best practice.' 


The speed at which things change in relation to cloud-hosted services is causing us to change our perspective on concepts like "Best Practice" for administration tasks like this. What is "best practice" today is quickly changed as soon as that new feature is released. I'm inclined to reference the previous comment regarding the Exchange Admin Center update that provides the "Create New Mailbox In Exchange Online." You are spot on, that is a "Best Practice," but so is the method that the other commenter has about creating a script that does it all for him.


Conclusion.... there are 13 ways to slice the bread (administration tasks) and because things are changing faster than we can establish "Best Practice" the best way to do it is going to be the way that works best for you.


Not the answer you are looking for, and I know that... I am sorry.... : )


I would take a list of the possible ways and figure out which are most applicable to you. Try them each, and understand them each. Establish a process, and dub that YOUR BEST PRACTICE methodology.

And on the conversation that things change quickly, now with the latest CU's for Exchange Server you can create shared mailboxes in Exchange Online with "New-RemoteMailbox - Shared".

It though is still the case that with AD Sync in place attributes in Azure AD are mostly read only and need changing in the source directory of Active Directory. Changes to Exchange attributes in AD is only supported via Exchange management tools, so Best Practice would still need to include that. Creating objects or licensing stuff that results in attribute changes before Microsoft build a supported system for writing back the attribute on premises is likely to lead to more administrative issues and problems.

@Paul Bridges Incorrect, if no on-premise mailbox exists when the account is synced and licenced, it will create a mailbox. And this leads to major problems with the user not being able to receive mail (depending on your mail routing), not appearing in the GAL and a real pain to sort out.


In a Hybrid environment, if a new mailbox is created on EXO, on prem mailbox user will not see these EXO users in GAL - is this correct?

We have created 1000+ mailboxes straight on EXO, and we are in the middle of migration from Ex 2010 to EXO!

Please advise how can we solve this issue.


it's probably best to start a new thread/question, but to answer your question, no that is not the expected experience. If your on-premises users are not seeing the cloud users in the GAL then that means someone missed a step when provisioning those cloud users, because in a Hybrid configuration, those cloud users should be represented as RemoteMailbox recipient types on-premises. Fortunately, there is a fairly quick fix to resolve this which includes using the enable-remotemailbox command, which tells the on-premises AD account that it has a cloud mailbox in O365. That step will cause the remote mailboxes to appear in the on-premises Exchange Online address book. If you need further help email me us here: support AT

Hi  @Joe Stocker 

Thank you so much for this. We will try the suggested fix ;)