Freigeben über

Exchange 2007 objects are not stamped with ShowInAddressBook and never end up in the GAL after a gal sync

  • Artikel

When mailbox enabled objects are created they go through a stamping process to mail enable them. In Exchange 2003 the RUS (Recipient Update Service) is responsible for doing this. One of the main tasks of the Recipient Update Service is to populate the ShowInAddressBook attribute for objects in Active Directory. All mail-enabled objects have this attribute, including users, contacts, groups, public-folders and any other object in Active Directory that supports showInAddressBook attribute and has a mailNickname attribute.

Every time that a user, a group, or any object is added or modified in Active Directory, the Recipient Update Service picks up that object, determines which of the available address lists it belongs to, and adds that address list to the showInAddressBook attribute of the object. One exception for this is if the mailbox is hidden. In that case, the msExchHideFromAddressLists attribute is set to TRUE, so the Recipient Update Service will not stamp any address lists, and will remove any that are already present on the attribute.

The showInAddressBook attribute has two purposes.

1. To let people see the entry listed in the address list by means of Messaging Application Programming Interface (MAPI) client, such as Microsoft Outlook.
2. It allows users to "resolve a name" on a MAPI client.

Address Lists

By default, there are several address lists configured in Microsoft Exchange 2003 Server and Exchange Server 2007. The most important is the Default Global Address. Exchange 2003 and Exchange 2007 allow you to have several global address lists, and several other address lists with a much richer definition than earlier versions of Exchange Server. For example, you can create an address list called "Top Executives" that searches for entries that have "VP," "President," "CEO," or "Director" in the title.

By default, Exchange 2003 and Exchange 2007 provide the following address lists, plus the default global address list:

  • All Contacts
  • All Groups
  • All Rooms (Added in Exchange 2007)
  • All Users
  • Public Folders

How Exchange Uses the ShowInAddressBook Attribute to Resolve Names

To set up Microsoft Outlook to access an Exchange mailbox, you must create a profile for that mailbox. When you configure the Microsoft Exchange Server service in the profile, one of the steps is to enter your Exchange server name, and your mailbox alias.

When you click the Check Name button, Outlook attempts to resolve the alias to a mailbox on the Exchange server. Outlook uses MAPI to contact the Exchange server that you specify and queries to see if there is an entry that matches the alias that you entered. The server then searches for any mail-enabled objects that belong to at least one address list and that also match the alias. After the name has been resolved, the client is ready to log on. If a user does not have any address lists in the showInAddressBook attribute, it does not belong to any address list. Therefore, that user will not be able to resolve their alias to a mailbox.

This behavior occurs if the mailbox is hidden, which causes the msExchHideFromAddressLists attribute to be set to TRUE. In this case, you cannot resolve the name, and therefore, cannot create a profile in Outlook. To be able to access this mailbox, you need to unhide this object, create the profile, and then hide it again.

How To Fix (If you are running Exchange 2003)

1. Save out and clear your Windows Application Log.
2. Turn up diagnostic logging for MSExchangeSA\Proxy Generation.
3. In the ESM (Exchange System Manager) navigate to Organization | Recipients | Recipient Update Service container.
4. Right click the Recipient Update Service (Domain).
5. Select ‘Update Now’.

NOTE: If you select rebuild it will force a full rebuild and it can take a long time, in some cases hours.

6. Check the Application Log for errors. At this point if the RUS ran, the users should be stamped. Other things to look when troubleshooting this on Exchange 2003 are as follows:

  • The schedule of the RUS and what it is set to
  • Is the Update Interval set to never run?
  • Is the RUS pointing to a domain controller in another site (which then replication has to take affect)?
  • Is the RUS pointing to a domain controller that is offline or no long in existence?

Changes in Exchange 2007 (The RUS (Recipient Update Service) has been removed!)

One change in Exchange 2007 is that we removed RUS and it no longer exists in the Exchange 2007 product. If you are using a different process to create the objects (Quest, MIIS, etc) we do *NOT* stamp these attributes There are three new commands that you can run via the Microsoft Exchange Management Shell to achieve this:

  • Get-EmailAddressPolicy – This cmdlet is used to return all of the attributes on a policy or a set of policies.
  • Update-EmailAddressPolicy – This cmdlet is used to apply an e-mail address policy to all recipients.
  • Set-Mailbox–ApplyMandatoryProperties – This cmdlet is used to modify the settings of an existing mailbox. You can use this cmdlet for one mailbox at a time!

Once you run the cmdlets to stamp the objects you should then see them in the GAL and you can rebuild your Offline Address List.

How to Fix (If you are running Exchange 2007)

1. Open the EMS (Exchange Management Shell)
2. Run the following cmdlet: Get-EmailAddressPolicy

Note: You will see the following output:

[PS] c:\Get-EmailAddressPolicy

Name                       Priority                           RecipientFilter
Default Policy            Lowest

3. Run the following cmdlet: Update-EmailAddressPolicy –Identity “Your Policy Name Here”
4. Run the following cmdlet: Set-Mailbox–ApplyMandatoryProperties –Identity YourUserName

Once you run the following command in verbose mode you will see the following output for verification:

[PS] C:\>Set-Mailbox -ApplyMandatoryProperties -Identity ShowInAddressBookUser -V
VERBOSE: Set-Mailbox : Beginning processing.
VERBOSE: Set-Mailbox : Administrator Active Directory session settings are: View Entire Forest:
'False', Default Scope: 'OABWorld.local', Configuration Domain Controller: 'GC01.OABWorld.local',
VERBOSE: Set-Mailbox : Searching objects "ShowInAddressBookUser" of type "ADUser" under the root "$null".
VERBOSE: Set-Mailbox : Previous operation run on domain controller 'GC01.OABWorld.local'.
VERBOSE: Set-Mailbox : Processing object "OABWorld.local/Users/showInAddressBook".
VERBOSE: Setting mailbox "ShowInAddressBookUser".
VERBOSE: Set-Mailbox : Applying RUS policy to the given recipient"OABWorld.local/Users/showInAddressBook" with the home domain controller "$null".
VERBOSE: Set-Mailbox : The RUS server that will apply policies on the specified recipient is "e2k7.OABWorld.local".
VERBOSE: Set-Mailbox : The properties changed are: "{ AddressListMembership={ '\All Users','\Default Global Address List', '\My Custom Global Address List' }, EmailAddresses={ 'X400:C=US;A=;P=OABWorld;O=Exchange;S=showInAddressBook;', 'SMTP:showInAddressBook@OABWorld.local' },WindowsEmailAddress='showInAddressBook@OABWorld.local',
<OriginalWindowsEmailAddress='showInAddressBook@OABWorld.local'> }".
VERBOSE: Set-Mailbox : Saving object "OABWorld.local/Users/showInAddressBook" of type "ADUser" and state "Changed".
VERBOSE: Set-Mailbox : Previous operation run on domain controller 'GC01.OABWorld.local'.
VERBOSE: Set-Mailbox : Ending processing.

NOTE: You can run the following command to run this against all of your users:Get-User | Set-Mailbox -ApplyMandatoryProperties

This is a must read!!! For more information on the -ApplyMandatoryProperties switch and why this even exists, please read Evan Dodds blog post: https://blogs.technet.com/evand/archive/2007/02/28/applymandatoryproperties.aspx 

Dave

Comments

  • Anonymous
    May 27, 2007
    For more info on the ApplyMandatoryProperties switch (what it actually does and why the switch exists - ie, why does it fix this problem), see my earlier blog post: http://blogs.technet.com/evand/archive/2007/02/28/applymandatoryproperties.aspx

  • Anonymous
    June 04, 2007
    hi, i have migrated from exchange 2000 to 2007 and exch2000 has been decomissioned.in my case a user has got a old smtp e-mail address still showing in default GAL. actually this e-mail address has been removed from the user object.a new e-mail address has been assigned to him, and i can see the new e-mail address under 'All Users' category, but the default GAL and therefore the Default OAL(offline address list) is still getting the old e-mail address.when anyone on  the network tries to send an e-mail to this 'problamatic user' it's getting resolved to the old non existing e-mail address , which it is picking it from default GAL, whcih is ultimately an OAL. i don't know how i can get an uptodate default GAL with old data being flushed out. i appreciate your help regards REDDY

  • Anonymous
    June 04, 2007
    You will need to remove this users proxy address and then run this command as listed in the blog. This will stamp all of the mandatory attributes. If the user does not have a vaild proxy address and mail attribute that match you will get a 9325 in the application log stating that this user has been skipped from the generation process. They must be there and be correct for the user to be added to the gal.

  • Anonymous
    July 18, 2007
    I tried this and I am getting error "user has no mailbox" (I am trying to fix users with external addresses, without mailboxes). Any suggestions?

  • Anonymous
    July 30, 2007
    Just wondering i f anyone has seen this error.  It happened after I installed SP1 beta. WARNING: Object Default Policy has been corrupted and it is in an inconsistent state. The following validation errors have been encountered: WARNING: ConditionalCustomAttribute1 is too short: minimum length is 1, actual length is 0. WARNING: ConditionalCustomAttribute2 is too short: minimum length is 1, actual length is 0. WARNING: ConditionalCustomAttribute3 is too short: minimum length is 1, actual length is 0. WARNING: ConditionalCustomAttribute4 is too short: minimum length is 1, actual length is 0. WARNING: ConditionalCustomAttribute5 is too short: minimum length is 1, actual length is 0. WARNING: ConditionalCustomAttribute6 is too short: minimum length is 1, actual length is 0. WARNING: ConditionalCustomAttribute7 is too short: minimum length is 1, actual length is 0. WARNING: ConditionalCustomAttribute8 is too short: minimum length is 1, actual length is 0. WARNING: ConditionalCustomAttribute9 is too short: minimum length is 1, actual length is 0. WARNING: ConditionalCustomAttribute10 is too short: minimum length is 1, actual length is 0. WARNING: ConditionalCustomAttribute11 is too short: minimum length is 1, actual length is 0. WARNING: ConditionalCustomAttribute12 is too short: minimum length is 1, actual length is 0. WARNING: ConditionalCustomAttribute13 is too short: minimum length is 1, actual length is 0. WARNING: ConditionalCustomAttribute14 is too short: minimum length is 1, actual length is 0. WARNING: ConditionalCustomAttribute15 is too short: minimum length is 1, actual length is 0. shlgroup.com                            1                                       Alias -ne $null

  • Anonymous
    July 30, 2007
    The comment has been removed

  • Anonymous
    August 16, 2007
    I have not seen that but I would open a case with PSS to get that resolved.

  • Anonymous
    August 16, 2007
    Yes Bhavesh that is an attribute, however quest does not stamp that. You need to run Set-Mailbox–ApplyMandatoryProperties to fix that.