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 
Steve
Exchange 2010 SP2 Hybrid Wizard resets OWA Redirect URL to Tenant Domain
Background
When you run the Hybrid Configuration wizard even in a tenant that uses Federated login, you might find that even if you’ve chosen only one of your federated domains, the redirect URL to Office 365 is set to your tenant domain (onmicrosoft.com) rather than the federated domain you chose in the wizard or would prefer to use:
If you’ve not this before, this results in the end use having to enter their User Principal Name at the Microsoft Online Services login page, before being redirected back to the ADFS services:
So the first thing you might do is the following to set your TargetOWAURL to the correct value:
Set-OrganizationRelationship "On Premises to Exchange Online Organization Relationship" -TargetOwaURL:https://outlook.com/owa/federateddomain
This results in the smoother (or even super-smooth if you check out my previous article) experience where the end use is redirect straight to AD FS login.
The Problem
If you need to update the Hybrid Configuration – for example to add or change IP addresses of External Transport Server IP addresses, update the certificate or add/remove Hub Transport or Client Access Servers, then you’ll re-run the Hybrid Configuration Wizard.
A seemingly innocuous change to an IP address for outbound SMTP servers that doesn’t affect the organization relationship itself will result in the Redirect URL for OWA being set back to the tenant domain resulting in the scenario outlined above.
So, just bear that in mind when you need to re-run the Hybrid Configuration wizard.. It’s simple to deal with by ensuring your reconfigure your TargetOWAURL, just make sure you don’t forget 
Steve
Updated–Getting info about ActiveSync, EWS and WebDAV clients from Exchange 2007 and 2010
Last year, I wrote a script for pulling out information from Exchange 2007 log files on Windows Server 2003 to detail information about EWS, ActiveSync and WebDAV clients. The purpose of this script was primarily to make it easy to find out about client you need to test before moving to Exchange 2010.
I’ve been meaning for a while to make an update to the script, as one issue with original version is that is was aimed only at Windows 2003 servers – and naturally there are a fair few Windows 2008 and 2008 R2 servers running Exchange Server 2007. The script is also useful when checking out what’s in the current environment before migrating to Office 365, so it’s applicable to Exchange 2010 as well.
So, I’m pleased to say that I’ve finally updated the script to support Windows 2008, 2008 R2, and also tested the script against Exchange 2007 and 2010 logfiles.
As with the previous version, it’s a little slow on larger log files, taking an hour or so for a 500MB log file and for log files of around 3GB each it can take around 6 hours.. So a future Log Parser Studio version might be in order.
Visit the original article for the updated script
DiscoverySearchMailbox in an Exchange 2007/Office 365 Hybrid environment causes DirSync errors
Whilst working on an Office 365-Exchange 2007 hybrid environment, you may experience errors similar to those shown below from the Directory Synchronization Error Report email and in Forefront Identity Manager:
|
Identity |
Error Description |
|
DiscoverySearchMailbox {D919BA05-46A6-415f-80AD-7E09334BB852}@exchangelabs.co.uk |
Unable to update this object in Microsoft Online Services, because the attribute Username is not valid. Update the value in your local Active Directory. |
Why does this happen?
This is because as part of building your Hybrid environment, you’ll introduce Exchange 2010 servers into your environment as your Hybrid co-existence servers, running both the Client Access, Hub Transport but not the Mailbox role. When running the pre-requisite Active Directory Preparation a Discovery Search Mailbox, used in Exchange 2010 for storing the results of multi-mailbox searches.
In an full Exchange 2010 – Office 365 hybrid environment you won’t see this issue, because DirSync filters out any Discovery Mailboxes within the organization by checking (amongst other things) the mxExchMailboxTypeDetails attribute and if it’s set to the hexadecimal value 0x20000000, it will not exclude it from synchronization:
However the reason why it isn’t included within an Exchange 2007 hybrid environment is because the mailbox is never enabled – Discovery Search mailboxes do not exist in Exchange 2007. So as a “standard” user object, DirSync attempts to export it.
Correcting the issue in your Exchange 2007 Hybrid environment
Unfortunately, it’s not possible to enable the Discovery Search mailbox with the correct type from either the Exchange 2007 management console (you’ll just enable it as a normal mailbox) or the Exchange 2010 Hybrid Servers (you don’t have Exchange 2010 mailbox servers).
What you can do though is simply delete the Discovery Search Mailbox from the Users container of Active Directory.
Once deleted, synchronization will complete without an error about the Discovery Search Mailbox.. And that’s all there is to it until you decide to migrate your Exchange 2007 environment to Exchange 2010…
Re-creating the Discovery Search Mailbox if you install Exchange 2010 Mailbox Servers into your Hybrid environment.
If you need to re-create the Discovery Search Mailbox at a later date, it’s fairly straightforward – all you need to do is re-run the AD preparation for Exchange 2010. Let’s just walk through that process:
Locate the Exchange 2010 Service Pack 2 media and run the following command:
setup.com /PrepareAD
If at this point you have Exchange 2010 mailbox servers and wish to enable this as a proper Discovery Search Mailbox, first, check you can find the Discovery Search user from an Exchange 2010 Management Shell:
Get-User DiscoverySearchMailbox*
Assuming a single user is returned, simply enable it using the Enable-Mailbox cmdlet with the –Discovery parameter:
Get-User DiscoverySearchMailbox* | Enable-Mailbox –Discovery
And at this point, because you’ve got Exchange 2010 mailbox servers and enabled the Discovery Search Mailbox correctly (which will set the msExchRecipientTypeDetails attribute in Active Directory) you won’t see any DirSync errors either.
Steve
More from StevieG.org
- About Me
- Car PC
- Exchange 2010 Virtual Load Balancer
- Exchange Environment Report
- Recommended Exchange Reference Material
Find Me On…
Important Notice
Categories
Recent Posts
- Checking out GFI MailEssentials Online
- Enabling a Remote Mailbox on Office 365 fails
- Using the KEMP LoadMaster with Exchange Server 2010
- Outlook 2003 is unresponsive when managing Delegates with Exchange 2010
- Exchange 2010 SP2 Hybrid Wizard resets OWA Redirect URL to Tenant Domain
- Updated–Getting info about ActiveSync, EWS and WebDAV clients from Exchange 2007 and 2010
Top posts
- Enabling a Remote Mailbox on Office 365 fails
- Using the Exchange 2010 SP1 Mailbox Export features for Mass Exports to PST files
- Auto-mapping shared mailboxes in Exchange 2010 SP1 with Outlook 2010 and Outlook 2007
- Generate Exchange Environment Reports using Powershell
Blogroll
- Aaron Tiensivu's Blog
- Clint Boessen's Blog
- Devin on Earth
- Dougs Blog…
- Elan Shudnow's Blog
- Exchange Server Pro
- Exchange Team Blog
- Exchange2010.com
- Exchangepedia Blog
- Henrik Walther Blog
- Microsoft Messaging and Mobility User Group UK
- Mike Crowley's Whiteboard
- Mike Pfeiffer's Blog
- Nuttin but Exchange
- VMlover by Daniel Eason