Created in the Cloud
First off, an administrator can simply create a contact directly in the Exchange Online environment using the Microsoft Online Services Administration Center (commonly referred to as MOAC). The primary purpose of a contact object in Exchange is to include a single managed object which appears in the global address book to all users for sending email to an external SMTP address. A contact can not use an internal SMTP address in any domain, meaning that any domain which is currently verified in BPOS as Authoritative and configured for Inbound Messaging should not exist in a contact. Otherwise a Non-Delivery Report (NDR) would be created if any internal users attempt to send a message to it. Any foreign domains and any BPOS-verified domains still configured for External Relay would still be allowed.
Assuming we have a BPOS-Shared site of schertz1.microsoftonline.com let us create a new contact for my PointBridge email address. Using MOAC, the following contact was created directly in the cloud; no Directory Synchronization was used in this process (more on that later).
Once the contact is created it appears in the Contacts list with the SMTP address I added above:
But here where things get a little different. With a standard On-Premise Exchange deployment that exact address would appear in the address book in Exchange, but due to the fact that BPOS-Shared uses a single multitenant directory for separate clients there needs to be a way to store the address in a globally unique format. Otherwise if another BPOS-S client had already created a contact for the same SMTP address in their directory then we would have received an error when attempting to add this contact.
A quick peak at the Address Book in Outlook shows the actual format that the SMTP alias is stored in the directory:
By using this shadowed format the same SMTP alias can be stored in multiple tenant directories without conflict as the site’s specific (and unique) default domain name is used as the suffix. Regardless of how the SMTP alias appears in the address book to users the functionality is still the same and all messages sent to the contact are delivered to the correct address.
Directory Synchronization
The main difference here is when a contact object is created in BPOS by Directory Synchronization instead then the displayed E-mail alias will not look the same as what was shown above. When viewing the proxy address from either the administrative console or an Outlook client a different format appears, which upon first glance appears to be completely incorrect.
In this example there is a contact stored in an on-premise AD domain for Matt McGillen which contains his PointBridge SMTP address:
But when this object is created in BPOS via Directory Synchronization it appears to be stamped with a different address of mmcgillen@schertz1.microsoftonline.com which uses the default mail routing domain name in this BPOS site. This address appears the same anywhere it can be viewing in Exchange.
From the Contacts list in the Microsoft Online Service Administration Center:
From the E-Mail Address tab of a user in the Outlook Address Book:
From the online Address Book view in Outlook Web Access:
Obviously if this was the real address stamped on the contact it would no longer work as a mail forwarder as that domain is (by default) configured as an internal relay domain in BPOS and clearly wouldn’t send messages to the proper mailbox. But the contact will, and does work as expected. What happens is although the same shadowed proxy address format as described earlier in this article is used on the contact object itself to allow for unique address across the multi-tenant domain, the actually displayed format of that address does not reflect that.
The functionality is the same whether the contact was created manually in MOAC or automatically via Directory Synchronization, but the addresses are displayed to the administrators and end-users differently. I was told by Microsoft this caveat was necessary in order to get the proper functionality, but unfortunately the shadowed proxy address is not displayed for the synchronized contacts.
So, in a smaller environment it can sometimes be a better solution to leave the contacts out of AD (if possible) and simply create and manage them in MOAC. This will allow end-users to see the proper SMTP aliases and be less-confusing to them. Otherwise simply make sure that at least your administrators are aware of the display issue in the case any migrated end-users start to notice it and question the validity of the contacts. It is still undetermined if this behavior will be changed in the future to display the correct address for synchronized object.
