For many Office 365 customers directory synchronization is the primary method of populating their Office 365 tenant with users, groups, and contacts.  The directory synchronization process allows for the centralized management of these objects.

 

In the service customers taking advantage of Exchange Online through Office 365 actually have two directory representations.  Objects managed with directory synchronization are replicated to the Azure Active Directory.  This directory serves as the centralized repository for Office 365 objects.  The directory synchronization process is responsible for mapping on premises Active Directory attributes to the Azure Active Directory.  Each object within the on premises active directory has a wide array of attributes that are configurable on the object.  The directory synchronization service is configured to map these attributes to attributes within the Azure Active Directory. 

 

Attributes of objects within the on premises Active Directory are generally managed by either Active Directory Users and Computers or the Exchange Management tools.  In some special circumstances tools like ADSIEdit can be utilized to process attribute changes.  When an object is changed within the directory administrators can view the synchronization of those changes through the MIISClient on the Directory Synchronization server. 

 

In this example I have changed an object on premises by adding City. 

 

 

In the MIISConsole we can see the object change detected and subsequently the attribute updated in the Azure Active Directory.  The original CITY attribute was NULL and has now been populated with the value “Charlotte”.

 

 

Using the Azure Active Directory module we can see the results of this change with get-MSOLUser.

 

PS C:> Get-MsolUser -UserPrincipalName DevUser@domain.com | fl userprincipalname,city

UserPrincipalName : DevUser@domain.com
City              : Charlotte

 

The list of attributes that are synchronized from On-Premises to the Azure Active Directory is documented at this location:

 

http://support.microsoft.com/kb/2256198

http://social.technet.microsoft.com/wiki/contents/articles/19901.list-of-attributes-that-are-synced-by-the-windows-azure-active-directory-sync-tool.aspx

 

The second directory representation for the object is present within the Exchange Online directory.  When an object has been assigned an Exchange license, a service provisioning process is responsible for extending this object into the Exchange Online directory and subsequently providing a mailbox.  This provisioning process is also responsible to monitor for changes and ensure those changes are reflected within the Exchange Online object.  For example, if you look at the mailbox associated with our test user you will now see that city has been populated with a value of “Charlotte” where previously it was NULL.

 

PS C:> Get-Recipient -Identity DevUser@domain.com | fl name,city

Name : Dev User
City : Charlotte

 

The attributes that are replicated from the Azure Active Directory to the Exchange Online directory are not necessarily the same as those replicated from the On-Premises Active Directory to the Azure Active Directory.  Currently there is no list of attributes that replicate between Azure Active Directory and Exchange Online.

 

In most instances no issues arise from this difference in directory synchronization.  There are though some circumstances where this can cause an issue.   Let us explore an example. 

 

An administrator has decided that on-premises an address list would exist that displays all recipient objects where the Company attribute is populated with a given value.  The address list allows for you to specify that any recipient that contains company=X will be included in the address list.  This effectively allows the administrator to set company on users, distribution groups, and contacts and have them appear in the same address list.

 

The directory synchronization metaverse, by default, does not sync the company attribute on objects of type group.  Notice in the below example that company is not included.

 

 

Using the add attribute button Company is added as an attribute that is synchronized for groups.

 

 

 

By default company is not an attribute of a group when edited via Active Directory Users and computers or through the Exchange Management Tools. 

 

 

 

To achieve this result the administrator uses the attribute editor of Active Directory Users and Computers (or ADSIEdit) to set the company attribute on the distribution group.

 

 

When reviewing the directory synchronization logs we can observe the object is replicated with the attribute company populated.

 

 

After waiting a period of time it was noted that the same address list in Exchange Online did not contain the group objects.  This would be considered by design – Company is not an expected attribute of a distribution group.  Although the Azure Active Directory did in this case allow for the attribute to be successfully synchronized from on premises the Exchange Online provisioning process is not configured to detect this attribute and replicate it to Exchange online.

 

In this case the administrator needed to switch to an attribute that is replicated, for example custom attribute 1.  There should be no expectation that attributes that are not default on an object on-premises will be replicated into Exchange Online although they may be replicated to the Azure Active Directory. 

Customers may implement CRM applications that track customer interactions.  In some instances the CRM applications are configured to archive and record email transactions that are sent to and from customer service representatives. 

 

I recently worked with a customer that has their CRM application configured to monitor a centralized mailbox.  When a new organization was added to the CRM system, a proxy address would be added to this centralized mailbox for that customer.  For example, I might have a  centralized mailbox shared@company.com.  When a new customer is added to the CRM system, this mailbox would have an additional secondary proxy added of customer1@company.com.  When the customer service representatives communicate with this customer by email, the customer1@company.com alias is added to the message CC line.  This ensures that all messages to that customer and subsequent replies are retained in the centralized mailbox.  This also allows the CRM application, which monitors this centralized mailbox, to ingest the information into the CRM application.

 

The issue arises with how Outlook, Outlook Web Access, and transport handle secondary proxies.  When a secondary proxy is addresses in any of these products the proxy is immediately resolved to the user object where the proxy is applied.  Instead of retaining customer1@company.com on the CC line the address is changed to shared@company.com.  This results in exposing this mailbox / address in all correspondence to external recipients rather then the individual customer proxy address added to the object.

 

Let’s take a look. 

 

For this example I have created a mailbox CentralMailbox@domain.com.  This will serve as the mailbox that I would have subscribed for monitoring by my CRM application. 

 

PS C:> Get-Mailbox CentralMailbox

Name                      Alias                ServerName       ProhibitSendQuota
—-                      —–                ———-       —————–
CentralMailbox            CentralMailbox       by2pr06mb028     49.5 GB (53,150,220,288 bytes)

 

On this mailbox I have added a secondary proxy address of Customer1@domain.com. 

 

PS C:> $a=Get-Mailbox centralmailbox
PS C:> $a.emailAddresses
smtp:customer1@domain.com
SIP:CentralMailbox@tenant.onmicrosoft.com
SMTP:CentralMailbox@tenant.onmicrosoft.com

 

When addressing a message in OWA I manually utilize the customer1@domain.com email address. 

 

 

When the email is sent to the external recipient the reply to address is not the secondary address but rather the primary address of the mailbox where the secondary proxy is assigned. 

 

 

 

You can also see in the sent items that the address was resolved to the mailbox where it was assigned and not retained as an SMTP address.

 

 

How can this be resolved? 

 

One potential solution is to utilize customer mailboxes rather than secondary proxy addresses for customer communications.  To prevent having to configure the CRM application to monitor multiple mailboxes we would utilize the forwarding and delivery features in Exchange and Office 365.  Let’s take a look at an example.

 

In this instance a mailbox was created Customer2@domain.com

 

PS C:> Get-Mailbox Customer2

Name                      Alias                ServerName       ProhibitSendQuota
—-                      —–                ———-       —————–
Customer2                 Customer2            dm2pr0601mb0921  49.5 GB (53,150,220,288 bytes)

 

There are two properties of the mailbox that allow us to utilize this as a solution – ForwardingAddress and DeliverToMailboxAndForward. 

 

PS C:> Get-Mailbox Customer2 | fl ForwardingAddress,DelivertoMailboxandForward

ForwardingAddress          :
DeliverToMailboxAndForward : False

 

Using powershell I will set the ForwardingAddress to the centralized mailbox and DeliverToMailboxAndForward to FALSE.  By keeping DeliverToMailboxandForward false the message will not be delivered to the customer mailbox but only the central mailbox.  Should you desire to have it delivered to both location this would be set to TRUE.

 

PS C:> Set-Mailbox Customer2 -ForwardingAddress CentralMailbox -DeliverToMailboxAndForward:$FALSE

PS C:> Get-Mailbox Customer2 | fl ForwardingAddress,DelivertoMailboxandForward

ForwardingAddress          : CentralMailbox
DeliverToMailboxAndForward : False

 

When an email is addressed in OWA and the customer email address utilized it resolves to the mailbox that was created for the customer.

 

 

When the external customer receives the email the customer specific mailbox is retained – the centralized mailbox is not exposed.

 

 

 

When the external user performs a reply all the email continues to be addressed to the customer mailbox rather than the centralized mailbox.

 

 

When logging into the centralized mailbox both the original message and the reply are present.  The message retained the Customer2 email address even through they were forwarded to the centralized mailbox.

 

 

Utilizing a mailbox and mailbox forwarding allows us to address emails without exposing the central mailbox but still capture all correspondence in the central mailbox.  Not allowing delivery to the customer mailbox ensures that the message is stored in one location and the mailbox itself will not utilize any storage (although it will be assigned an Exchange database).

 

Another potential option utilizes distribution groups.  Let’s take a look.

 

Instead of creating a mailbox for each customer a distribution group is created. 

 

PS C:> Get-DistributionGroup Customer3

Name                          DisplayName                   GroupType                     PrimarySmtpAddress
—-                          ———–                   ———                     ——————
Customer3                     Customer3                     Universal                     Customer3@fortmillrescue.com

 

The central mailbox is added as a member to the distribution group.

 

PS C:> Add-DistributionGroupMember -Identity Customer3 -Member CentralMailbox

PS C:> Get-DistributionGroupMember Customer3

Name                                                        RecipientType
—-                                                        ————-
CentralMailbox                                              UserMailbox

 

In this example the only member of the distribution list is the central mailbox.

 

The distribution list must also be set to accept mail from all senders, specifically senders that are non-authenticated.  This is required with the assumption that email will be received from external senders that are not authenticated to the hosting message solution.

 

PS C:> Set-DistributionGroup Customer3 -RequireSenderAuthenticationEnabled:$FALSE

 

When addressing an email in OWA the customer email is added to the CC line.  The SMTP address resolves automatically to the distribution list we created.

 

 

When the message is received by the external recipient this email address is retained.  The centralized mailbox is not exposed to the external recipient.

 

 

 

As in the mailbox example subsequent replies are addressed to the distribution list which results in both the original message and the replies residing in the centralized mailbox for processing.

 

 

 

Internally those users utilizing a distribution group may be able to expand distribution list membership in the message exposing the central mailbox to both internal and external users.  Additional internal users can pull the properties of the distribution list in the Global Address List and view membership.  Utilizing a distribution list is another viable option to ensure emails are delivered to the central mailbox for processing while preserving the customer specific email address.

 

Customer may additionally want to hide the customer mailboxes or distribution lists from the global address list.  This does not alter the functionality documented here but would prevent the selection of these objects from the global address list.  Knowledge of the specific customer email addresses would be necessary in order to address emails as no automatic name resolution would occur.

 

*Special thanks to Mark Terry for the additional suggestion of utilizing distribution groups in this scenario.*

In Exchange 2010 and Exchange 2013 the process of mounting a database has changed since Exchange 2007.  In versions prior to Exchange 2010 the Information Store process on a server was solely responsible for tracking the creation of mailbox databases and performing mount and dismount operations.

 

In Exchange 2010 and newer the Active Manager process is now responsible for tracking the creation of mailbox databases and performing mount / dismount operations.  The Active Manager process works with the Information Store process to complete these requests.  Every server, both standalone and members of Database Availability Groups, have an Active Manager process.  This process runs within the Exchange Replication Service.

 

When administrators create a new mailbox database an entry is created in the database configuration container within Active Directory.  This will subsequently replicate to all other domain controllers.  Some administrators have noted that if you attempt to create a new database and immediately mount it – it fails with the following error:

 

[PS] C:>Mount-Database test
Failed to mount database "test". Error: An Active Manager operation failed. Error: Couldn't find the specified mailbox
database with GUID '1a5e5284-a2d3-4241-a31a-fa0023fdc0e4'. [Database: Test, Server: MBX-3.domain.com]
    + CategoryInfo          : InvalidOperation: (Test:ADObjectId) [Mount-Database], InvalidOperationException
    + FullyQualifiedErrorId : [Server=MBX-1,RequestId=8bcb44ca-f7cf-4594-81b9-1adb70b5cb95,TimeStamp=2/1/2015 3:47:30
   PM] [FailureCategory=Cmdlet-InvalidOperationException] 19FDD999,Microsoft.Exchange.Management.SystemConfigurationT
  asks.MountDatabase
    + PSComputerName        : mbx-1.domain.com

 

This error may occur more often when creating a database and checking the mount this database option (checked by default).

 

 

 

When a mount command is issued the command is referred to the Active Manager process on the server.  In the case of a Database Availability Group the command is referred to the Primary Active Manager and then passed to the Replication Service of the node owning the active mailbox database copy.  The Replication Service then send a notification to the Information Store process to perform the mount.  In this instance the Replication Service is aware of the presence of the database, but the Information Store process is not.  This ultimately returns an error to the Replication Service which is subsequently returned to the administrative endpoint where the mount was issued (PowerShell / ECP).

 

After waiting a few minutes the database can be successfully mounted.  The wait time may be longer depending on the amount of time it takes domain controllers to successfully replicate the database object.

 

[PS] C:>Mount-Database Test

[PS] C:>Get-MailboxDatabase Test -Status | fl name,*mounted*

Name            : Test
MountedOnServer : MBX-1.domain.com
Mounted         : True

 

The same results may be observed when using the ECP.

 

*New database created but dismounted:

 

 

*Issue mount command on new database:

 

 

*Database verified as mounted.

 

 

In this time the Information Store process was made aware of the newly created database allowing for the mount request from the Replication Service to be processed successfully.