Enabling a Remote Mailbox on Office 365 fails

I came across this issue last week, and to be honest was a little surprised. I’m sure I’d used it before, probably before Exchange 2010 SP2, so just expected it to work.

Let’s say you’ve built a Hybrid Exchange 2010 SP2 / Office 365 environment. You create a user, using your provisioning tool of choice – for this example we’ll say Active Directory Users and Computers:

So generally, running Enable-RemoteMailbox should work, in the same way running Enable-Mailbox should work too – all the components in Exchange are configured correctly, and if you create a mailbox using New-RemoteMailbox or the Exchange Management Console everything works.

However, the following happens:

The error – for the purposes of people searching for it is The Address @tenant.mail.onmicrosoft.com is invalid: “@tenant.mail.onmicrosoft.com” isn’t a valid SMTP address. The domain name can’t contain spaces and it has to have a prefix and a suffix, such as example.com. FullyQualifiedErrorID : F0109C5E,Microsoft.Exchange.Management.Recipient.Tasks.EnableRemoteMailbox.

I did a quick search on the net, and didn’t find any answers however I did find someone having the same problem. Sadly they hadn’t had much luck with forum support or Office 365 support.. So I had a little bit more of a look into the issue and found that the solution in most cases should be fairly simple.

When enabling the remote mailbox, use the –RemoteRoutingAddress parameter, specifying your alias and service domain/Office 365 tenant, for example:

Enable-RemoteMailbox <username> -RemoteRoutingAddress <alias>@<tenantName>.mail.onmicrosoft.com

After using the command as shown above, the remote mailbox should be created and thus provisioned correctly by DirSync:

A few points of note in addition – if you’ve configured your Hybrid organization the “old” way – i.e. you’ve got a service domain, replace the above <tenantName>.mail.onmicrosoft.com with your chosen Service Domain (i.e. service.contoso.com). And the original poster to the question I answered on TechNet found in his environment, he needed to use the –Alias parameter also to get things moving.

Hope this helps Smile

Steve

13 thoughts on “Enabling a Remote Mailbox on Office 365 fails”

Enabling a Remote Mailbox on Office 365 fails https://t.co/1TKwuITD92 @stevegoodman #UrbanNerdConsult https://t.co/w81MHhZ6fz

Many thanks..

A bit late to the party… but I have this issue when trying to pipe results of this filter:

“Get-User -RecipientTypeDetails User -Filter { Company -Eq ‘Contoso’ } | Enable-RemoteMailbox”

It finds the users where Company=Contoso but still fails to prepend the users alias to the remoteroutingaddress. Any ideas how I can achieve this?

Thanks

Steve, I been battling this issue for awhile. Your solution seems to solve the issue. Thanks.

Jim

Can you elaborate? Under Sp1, the enable-remotemailbox command would auto-create the RemoteRoutingAddress using an “Exchange Guid@services.contoso.com” format. How do we now specify the -RemoteRoutingAddress value using the same Exchange Guid format, if the mailbox hasn’t been created yet? Can we just begin using “UPN@services.contoso.com” format and expect it to still work the same?

When I try your solution I need to provide the Exchange Guid …

Thanks a lot Steave, your post was very helpful !

side note: since the new cmdlet doesn’t accept pipiline input, a little workaround is required:
Get-user | foreach {Enable-RemoteMailbox -identity $_.userprincipalname
-RemoteRoutingAddress ($_.samaccountname+’@tenantdomain.mail.onmicrosoft.com’)}

Steve,
Once again your blog is delivering! Great solution (though strange). You were giving me the clou too when configuring my hybrid deployment, published behind a ForeFront TMG (needed the disable authentication on the ADFS server, using the powershell ADFS snapin).