Forum Discussion
Solved
The question nobody dares to ask! How do you create a new user in a hybrid environment.
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!
The best practice is whatever works for your user management workflows. You can create it either way. In a hybrid you can move mailboxes back and forth whether they were created on-prem or in the cloud.
One caveat with New-RemoteMailbox is that it can't do Shared mailboxes. Those you need to create on-prem and then move, or, create in EXO as a user mailbox and then convert to Shared. Either way, same result.
We just started doing it this way: (Hybrid Exchange and Skype)
1. We run set-aduser, and set the minimal Exchange and Lync attributes that portray that a user has already been migrated. (You can look at an already migrated user to see what is set at migration)
2. Sync.
3. Assign license.
The mailbox and Skype/teams accounts are created online and believe they were migrated. The on-prem servers are fully aware of the accounts and believes they were migrated.
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 "[flast@MyCompanyDomain.com]" -Name "[First Last]" -Alias "[First.Last]" -RemoteRoutingAddress "[First.Last]@MyCompanyTenant.mail.onmicrosoft.com" -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.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.
Hello,
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.
Cheeers!
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.
Best
Martin
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.
It gets easier to understand once you've done the hybrid setup ;) Exchange 2013 CU15 hybrid in my case:
Once you've done the hybrid setup, you simply get a new UI option in the exchange admin center (onPrem) under recipients > mailboxes > New Office 365 Mailbox.
Thats it.
So there is no need to go through that many steps as you've described
- create new Office 365 Mailbox
- this of course creates the onPrem AD User with the linked Office 365 mailbox
- wait for Azure AD Connect to sync your your AD Users (not sure if this is necessary)
- enable Exchange Online License for synced user
- done
Ivan54 wrote:It gets easier to understand once you've done the hybrid setup ;) Exchange 2013 CU15 hybrid in my case:
Once you've done the hybrid setup, you simply get a new UI option in the exchange admin center (onPrem) under recipients > mailboxes > New Office 365 Mailbox.
Thats it.
Thanks a lot! (edit) apparently I was not aware of that option at the time I wrote the script.
Its good to see that this question isn't really that stupid :).
What i do is the following, i use create user in onprem and mailbox onprem migrate it to office365 and assign license when the customer is gonna use the hybrid server for Maintanance and administration.
When a customer is planning to go all the way to the cloud i use create user sync user assign license. With the assumption the Exchange on-prem environment will be cleaned up.
This assumes the user doesn't have an IAM process/team that uses some other user management process. In most cases, creating the user through Exchange is not an option at the larger clients and we have to powershell it somewhat through the IAM tool in place.
Paul Bridges wrote:This assumes the user doesn't have an IAM process/team that uses some other user management process. In most cases, creating the user through Exchange is not an option at the larger clients and we have to powershell it somewhat through the IAM tool in place.
True, though no powershell was mentioned as a requirement in this case. In any case, (almost) everything the Exchange or AD Consoles can do via GUI is of course sriptable via powershell.
You can even auto apply licenses via Azure AD group memberships, therefore saving you one scripting step and just add a group membership.
- create new Office 365 Mailbox
Also not an answer to your question, but a comment. We were advised by our consultants too, to do exactly what you describe. And indeed it is a back and forth between the systems, especially if you do it manually (note I talk here still of experience with dirsync).
We also had cases where admins would create e.g. distribution groups only on EXO. That gave some issues with adding members of only on-premise users (obviously). So from my experience the procedure makes sense, as the hyrbrid setup does not enforce the online setup to sync back entirely (note, still just talking about dirsync).
Additionally I noted that there is a difference attribute wise on the user AD object if you create the user in the AD and then mail enable it, or directly let create the AD user object in Exchange (all on-premise).
So I ended up making a script that
- creates the AD user object and the mailbox on our Exchange server (Exchange managment shell)
- forces a dirsync run
- assigns a license once the user is visible in O365
- create a move request, once the mail user is visible in EXO (that is different than the msol user object)
If there is a shorter or recommended way, I am also very interested (AD sync experience differences included).
- 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 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].dca.dk/PowerShell/ -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 $Sessionand for sync I run the following:
$Session = New-PSSession -ComputerName [syncserver].dca.dk -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
Martin Meraner wrote:So I ended up making a script that
- creates the AD user object and the mailbox on our Exchange server (Exchange managment shell)
- forces a dirsync run
- assigns a license once the user is visible in O365
- create a move request, once the mail user is visible in EXO (that is different than the msol user object)
If there is a shorter or recommended way, I am also very interested (AD sync experience differences included).
I'm not sure your path is correct, but I believe you have to enable the license AFTER the mailbox move. Because when you enable it before, you're pratically provisioning a cloud mailbox additionally to the existing onPrem Mailbox. It could be though that the remote move request to Exchange Online understands this, deprovisions the existing cloud mailbox, moves the onPrem, and enables is it afterwards.
Might not be an issue if the users doesn't technically exist yet, but there might be a small time window where the user could access the cloud mailbox, before his onPrem is properly moved.
If the environment is Hybrid, licensing the user prior to the mailbox move is fine, it will not create a duplicate mailbox.
Have you looked at using New-RemoteMailbox or Enable-RemoteMailbox?
I would go with Paul here as having used New-RemoteMailbox myself and with the addition of the coming use of Security Groups in Azure to assign licensing you don't have to worry as much about that anymore either.
Yes i know that will work and it will create only a remote mailbox for a user. But the question is what is the best practice for creating a user with mailbox in a hybrid environment so the mailbox will be in O365 exchange online.
