MIM 2016: Things to consider before you go live with your MIM Galsync

You are ready to synchronize the Exchange GAL with another Exchange Gal in another organization or within the same organization. You have done code development and prepared the Galsync.dll. Now you are thinking about going live, what would you need to consider? Here are some items from my experience after doing several Galsync deployments.

Existing contacts:

This is probably the most likely area with the biggest issue you would face. It can lead to email duplications. No matter what you are told about the directory where MIM will be creating contacts, I would advise that you still do your own verification. Duplications can occur because

  1. Users already have contacts that were manually created and placed in different locations in the directory. So you might be told all existing contacts are in an OU called contacts but in reality there may be some that are not there.
  2. Users have mailboxes in the remote directory. Users with 2 mailboxes in the organization.
  3. Users have their email address added as a proxy to another object in the remote directory

So the best thing is to

  1. Get all the user email addresses that MIM is going to create. You can get this from the Metaverse. You can also do a PS export here of all SMTP addresses in the proxy address field of the mailboxes to be synced
  1. Scan the remote directory mail and proxyaddress field to see if the email address already exists. See script sample below.
  2. Make a decision on what to do about these duplicates.
    1. You could move the contacts within MIM scope so MIM can join the contacts to the mailboxes from the other directory.
    2. If there are users with 2 mailboxes, same email address then you may have to delete one mailbox or exclude from the Galsync.
    3. If email is added to a proxyaddress, you may have to remove that address from the proxy.

Make sure there is no business impact to all these actions.

Here is a PowerShell script sample to do AD scan for Duplicate SMTP.

#set it to Remote2 DC

$PSDefaultParameterValues = @{“*-AD*:Server”=’tlkdc.tlkenterprise.net’}

$file = Get-Content d:\temp\tlk1contactsintlk2.txt

for($i=0;$i -lt $file.count;$i++){

#foreach ($address in $EmailAddress)



$foundAddress=Get-ADObject -Properties displayname,mailnickname,mail,proxyAddresses -Filter “mail -like ‘*$mail*’ -or proxyAddresses -like ‘*$mail*'”

If (($foundaddress -ne $null) -and ($foundaddress.mailnickname -ne $null)){

write-host $mail



Displayname difference, Lync impact:

You may have a case where users displayname does not match their firstname or lastname. If you have MIM building the displayname for the contacts it creates via FN and LN, this may be due to the fact that the other directory has a different displayname format (e.g LN, FN not FN LN) this may result in a different displayname from what the other directory has. This can become an bigger issue if there are already existing contacts for these users, then people may have difficulty trying to find them in the GAL. It is not really a big deal with Exchange because of the Outlook Cache which operates on the X500 address but it is a big deal with Lync or Skype for business. People are used to seeing the Common name in the Lync directory and so may raise questions because they can no longer find say “Reggie Law” who now appears as “Reginald Law”. Two cases to look out for

  1. Environment where they have Legal names for FN LN, common name for displayname. If MIM is building the displayname in the remote directory with FN and LN then you will see the legal names in the displayname. While it is not a big deal in some cultures because their common name is usually the same as their legal name, it is not the same for other cultures and can be a sensitive topic.
  2. People with non English names working in an English speaking company may want to use names that are easier to pronounce in English for Lync. They may have non-Exchange accounts for Lync in the remote directory with these English friendly names but once contacts are created in the remote directory, Lync will take the displayname from the contact and discard the name in the non-Exchange account so its best to make sure the displayname matches up.

Run sync twice:

The way MIM operates is that mailboxes are read in to the CS and then projected into the MV. But if there are existing contacts you want these contacts to be joined to the mailboxes that are projected. If the mailboxes have not been projected into the MV, there is nothing to join. So if you have existing contacts make your management agent profile runs like this

A/ AD1Galsync – Full Import

B/ AD2Galsync – Full Import

C/ AD1GalSync – Full Sync[Mailboxes projected]

D/AD2GalSync – Full Sync[Mailboxes projected, contacts joined to AD1 mailboxes projected]

E/ AD1GalSync – Full Sync[Contacts joined to AD2 mailboxes projected]

Exclude some from galsync:

Provide a means for users to be excluded from the Galsync, use like an Extension Attribute with a phrase “NoGalSync” which will trigger deprovision and remove the user from the MV, also add a connector filter so that the user is not processed again.

There is a possible impact from this exclusion.

  1. The user JDoe1 has an existing contact or mailbox in the remote directory so you decide to exclude the user from the Galsync.
  2. The contact or mailbox in the remote directory may have a different email address from the email address of the primary mailbox of the user e.g. Jdoe1@tlk1.com in the primary mailbox and jdoe1@tlk2.com in the Jdoe1 contact in TLK2. The proxy address of the contact or mailbox in the remote directory does not have all these other addresses, more importantly, it does not have the X500 of the primary mailbox.
  3. When other users in the JDoe1’s Exchange are moved to the remote directory, they have the X500 of the Jdoe1’s primary mailbox in their Outlook Cache, they also have JDoe1’s email from the primary mailbox.
  4. The result is NDRs for these users now moved to the remote directory when they try to send to JDoe1 they will find that JDoe1’s x500 from the primary mailbox is in their Outlook cache, even worse they may have JDoe1’s primary mailbox email address stored as a personal contact. They have to clear their Outlook Cache, delete their personal contact and manually select JDoe1 from the GAL to resolve this. Can be a major issue if you are doing a lot of moves due to say business consolidation.

With Galsync, MIM would have copied all the email addresses and X500 addresses to the contacts preventing these NDRs.

Contact hidden from the gal?

There may be existing contacts in the remote directory which are hidden for a variety of business reasons. If the contact is hidden it will not be picked up by MIM Galsync, so it will not be joined to the mailbox (if the mailbox is not hidden) and so a duplicate contact will be created. If you want the contact to be remain hidden without hiding the mailbox then you may have to exclude the mailbox from the Galsync.

Email Address does not match PrimarySMTP

This is where Admins make email address changes in Active Directory instead of via the Exchange console. Its a rule in Exchange that the email address or mail attribute should match the primarySMTP of the user (that is the address in the proxy address field with the “SMTP” tag). In Exchange immediately you update the email, the primarySMTP is updated, the two attributes are locked together. In AD they are not, so you could have this disconnect. MIM is creating mail-enabled contacts which are subject to Exchange rules, so if Exchange detects this mis-match it will deny/prevent the creation of the object.

Do a scan in the directory from where MIM will be exporting (before the Galsync starts) for any such mismatches. Fix them by finding out what is the most current email address and make sure the mail and PrimarySMTP are the same.

AD Attribute character length limitations

There are two key attributes in AD with size limitations that could affect your Galsync export to the remote AD.

  1. Canonical Name (CN) – 64 characters
  2. Mailnickname – 64 characters

If you are syncing distribution lists or users have really long names then these size limits could impact you depending on what rule you are using to build the CN or mailnickname. If you are using the email address or the names (FN, LN) then in the Galsync.dll you should check for these limits and adjust the rule you are using to build the fields for the contacts

MIM Contacts are changed after export

Are there any processes in the remote directory that will make changes to the MIM contacts? This will lead to a loop since MIM will remove these changes. There are 3 instances to look out for

  1. There is a script in AD that makes changes to all contacts
  2. There is an Exchange policy that stamps all contacts. Take a look at this blogpost
  3. AD Connect is exporting the contacts to O365 and O365 is stamping the contacts with O365 X500 address.