AddressListMembership goes missing again?

Article
05/26/2009

Have you ever wonder why sometimes in your HMC environment, some of your users just lose the address list membership?

Well, let me briefly talk about that here. In HMC, when you create the Global Address List (GAL) and Address List (AL) through the MPS, all the purported search for those created ALs and GALs are empty. In another word, all the GALs and ALs in the HMC environment (with the exception of the Global Address List) have no RecipientFilter.

By default, each mail enable object in HMC should have in their showInAddressBook attribute (or AddressListMembership field if you use the GET-MAILBOX cmdlet to retrieve the object) the Default Global Address List (the permission of this global address list is hardened but it is necessary to still have it there for some of the 3rd party application to work such as BlackBerry), the Organization AL and the Organization GAL.

When you create a mailbox, HMC calls NEW-MAILBOX cmdlet and in that process the Default GAL is stamped. As part of the HMC mailbox creation procedure, it will also stamp the Org AL and Org GAL in the showInAddressBook attribute. Now, this is all good.

We all know that Exchange Server 2007 no longer embraces the concept of Recipient Update Service (RUS) as in Exchange Server 2003. The responsibility of the triggering the RUS has been shifted to be part of many of the cmdlets instead. This is where things get complicated in a HMC environment. In HMC environment, we don't want the RUS to run (for those who can remember, we always disable it in HMC 3.5) but when you embed the RUS call into the cmdlets, there is no way to stop it from running and when it run, this is where you experience the problem. It will find out what AL and GAL should this object belongs to and because all the address lists have their purported search set to null, nothing will match except for the Default Global Address List. As a result, running certain cmdlets will result in resetting the address lists set on the object. Everyone gets the picture now?

There are in fact quite a few cmdlets that you should NOT execute in the HMC environment unless you know exactly what you are doing. If you need to perform certain actions, my recommendation would be to first see if any of the procedures in the HMC can do the job for you and use them instead. If you are not sure, then contact Microsoft to clarify.

Now, the HMC procedures will also use those cmdlets, however it will perform a re-stamp each time right after it executes the cmdlets to ensure that your Organization AL and Organization GAL will be put back. You should know that missing the Organization AL and Organization GAL can adversely affect your service to your users such as your users may not be able to recreate profile and your users may not be able to access the GAL if they are running on online mode and etc.

So, the story is simple, as much as possible, do not use the Exchange native cmdlets to set any setting unless you know exactly what you are doing. You can use most of the GET cmdlets as those are only retrieving information and will not change anything. Some of the cmdlets, though may seem like the right thing to do from the Exchange’s standpoint, it will cause you grief in the HMC environment.

Here are some cmdlets that I know will surely cause you some issues,

Update-AddressList
Update-GlobalAddressList
Move-Mailbox
Set-Contact
Set-Mailbox
Set-CASMailbox
Set-DistributionGroup

The following should be done through MPS too, if not recovery tasks may be required to set the object back approripately.

Enable-Mailbox
Disable-Mailbox
Enable-MailContact
Disable-MailContact
Enable-DistributionGroup
Disable-DistributionGroup
Move-OfflineAddressBook

The above are not the full list but I listed the above common cmdlets so that all of you are aware of it.

How do we fix it?

The good news is that it isn't the end of the world. You can fix it. This is how you can do it but this is provided "AS IS" with no warranties, and confers no rights. Use of the included samples are subject to the terms specified in the Terms of Use. And, you should know that you are using at your own risk. If you are not sure, please contact Microsoft.

1. Firstly, verify that the mailbox has indeed been missing the appropriate GAL and AL.

You can do that by either looking at the showInAddressBook attribute using ADSIEdit or LDP or you can look at the AddressListMembership field when calling a the specific cmdlet, such as

GET-MAILBOX johnc@alpineskihouse.com | FL

2. To repair a specific mailbox, you can run the following (change the bold value)

Provided all the otherWellKnownObjects are in place for the OU, the following will repair the object accordingly.

<data>

<preferredDomainController>AD01.Fabrikam.Com</preferredDomainController>

<path>LDAP://CN=johnc@alpineskihouse.com,OU=AlpineSkiHouse,OU=ConsolidatedMessenger,OU=Hosting,DC=Fabrikam,DC=Com</path>

<owningOrganization>LDAP://OU=AlpineSkiHouse,OU=ConsolidatedMessenger,OU=Hosting,DC=Fabrikam,DC=Com</owningOrganization>

</data>

</execute>

</procedure>

</request>

If you have a lot of user objects to deal with, say all the 200 user objects in the organization has been reset, you can call something like the following (change the bold value),

<?xml version="1.0" encoding="utf-8"?>