1

We have a hybrid environment with on-prem exchange (almost done migrating) and O365 Email.

I create a new user in our on-prem AD via powershell. It syncs properly via AADConnect to our Azure environment and creates the O365 user and email account. Using powershell I can change proxy addresses and the msExchRecipient/Remote attributes.

The expected result is that I have an email account on both sides, with the on-prem Exchange srerver showing the Mailbox Type as “Office 365”.

For one particular user, I ended up with a user who has email accounts in both on-prem and online exchange. The user receives messages in their O365 account. However, messages that are trapped by our Mimecast server are not getting through. The Mailbox Type listed in on-prem is “User”. This is messing up the mail routing.

Is there a way I can powershell my way out of this mess and somehow convert the mailbox type from “User” to “Office 365”? I can’t migrate because the account already exists in O365. If I delete the O365 I would lose the email, I think.

Should I have my powershell user creation script create the ad user, create the on-prem mailbox and also perform the migration? At least until we are fully migrated and out of our hybrid environment?

Any insight into this can of worms would be greatly appreciated.

One of the documents I referenced is this one about Recipient Type Values:

https://answers.microsoft.com/en-us/msoffice/forum/all/recipient-type-values/7c2620e5-9870-48ba-b5c2-7772c739c651

: Keith

2 Spice ups
2

The process we use for Exchange Hybrid is

  1. Create User in AD

  2. Create Mailbox on Exchange

  3. Check that account is synced and created automagically in AzureAD via AzureADConnect - it should be unlicenced

  4. Migrate Mailbox from On-Prem to Cloud

  5. Once completed only then activate appropriate O365/M365 licencing

One mailbox in one location, fully licenced and ready to rock

3

When we create user in AD, AADConnect syncs to O365 and creates the user and mailbox automatically.

Also - our licensing is automatically granted based on membership in AD groups via Azure.

I was really hoping to avoid having to create new accounts in on-prem during the “hybrid” time period.

I was also hoping to avoid the whole “migration” nonsense for a new account.

Technically, the “Migrated” mailboxes still exist in the on-prem exchange server. You can look them up and see the placeholder Mailbox Type of “Office 365”.

Normally, I can use “enable-mailbox” in exchange on-prem powershell with “remoteroutingaddress” pointing to user-at-tenant.mail.onmicrosoft.com to allow it to go from on-prem back to O365.

4

Hi,

If your user having mailboxes both on-premises and in the cloud, you could follow the method below to solve this issue:

Delete the account and email address in the cloud and synchronize it from the local computer AD account number.

  1. Delete the user on Azure AD

Remove-MsolUser -UserPrincipalName user@domain.com -RemoveFromRecycleBin

  1. Force AD synchronization

Start-ADSyncSyncCycle -PolicyType Delta

  1. After the account is synchronized, migrate the on-premises mailbox to the cloud.

If you worry about losing emails, you could export the emails from outlook before you perform the operation.

1 Spice up
5

This was actually what I was thnking of trying in the morning. Just wanted to hear somebody else say it :slight_smile:

  • backup to *.pst

  • delete MSO user

  • sync

  • migrate

6

Hi,

Any progress here? Is your issue resolved by using the method shared above?

7

By default, when users are added or assigned an Exchange Online license, the users are provided with a primary SMTP address that’s based on their user name. And, users are provided with an email address that’s based on the Microsoft Online Direct Routing Domain (MODRD) such as, for example, contoso.onmicrosoft.com. Additionally, when a user name is changed, the primary SMTP address may also be changed. However, alternate addresses aren’t updated or removed.

Check these articles for more insight - A user with this name already exists error in Microsoft 365 portal - Microsoft 365 | Microsoft Learn

8

I am waiting for the user to arrive so I can check their account.

The biggest headache with our hybrid environment has been the integration (or lack of) worn Mimecast. Mimecast was installed on our on-prem server and we thought about moving it to the hybrid server, but have not. So the routing still expects on-prem to be part of the path.