Forum Discussion
The question nobody dares to ask! How do you create a new user in a hybrid environment.
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.
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).
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.
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.
Hi,
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.
THANK YOU
