HMC 4.5 and Exchange 2007 SP1 – Part #2 – Address Lists Segregation


In part #1, I spent a fair bit of time explaining how HMC was introduced into Exchange as part of the multi-tenant enablement process for service provider. I also spent some time discussing about how the Active Directory was partitioned and what the primary attributes that are essential to the Exchange 2007 SP1 multi-tenant enablement.

So far, there wasn't anything complicated about it. Now, I am going to move on to the 2nd part of the customizations, which is probably one of the more important ones, that is the Address List Segregation.

Let's look at what address lists we need to segregate and why. Address list is about contact information which is very important because it makes managing and finding your contacts (internal as well as external) easier and hence makes communication easier. There are a few places where you will use Outlook to locate the contact information,

  • Contacts folder - this folder is created within the mailbox itself if you have an Exchange account. Think of this folder like a normal Inbox or Calendar folder in your mailbox. This is a private folder. If you don't use a Microsoft Exchange Server e-mail account, Outlook stores your Contacts with the rest of your Outlook data in a Personal Folders file that has a PST file extension.


  • Personal Address Book (PAB) - Outlook also supports Personal Address Books (PAB). Like Contacts, a Personal Address Book can store a contact's name, address, e-mail address, phone, and other information. Outlook stores the Personal Address Book in a file with a PAB file extension. The PAB is completely separate from your other Outlook data stored in your PST file (or in an Exchange Server store). You can add more than one PAB to an Outlook profile.


  • Server-side Address Lists - in Exchange 2007 environment, you have 2 types of address lists,
    • Global Address List (GAL) - The GAL contains information for all email users, distribution groups, and Exchange resources. Outlook needs this to work and Outlook can only see one GAL at a time.


    • Other Address Lists - Sometimes, Exchange Server administrator might create other address lists to organize Exchange users by department, surname, or other criteria. These additional address lists show up under the All Address Lists group in the Show Names from the drop-down list in the Outlook Address Book.

From the above, I think it is pretty obvious that Contacts folder is a private folder, like the Inbox folder in a mailbox, is only accessible to the mailbox owner. PAB is really an offline file that store contact information. There is really nothing required to be done on these contact stores for a multi-tenant environment because those are 'not shared' and are private by default.

Server-side address lists however are slightly different. The address lists are shared and because of how we designed Exchange and Outlook, the address lists in Exchange, out of the box is accessible by everyone in the environment. That obviously is a problem for multi-tenancy because it means users in company A will be able to see the users in company B. So, let's take a closer look at what HMC will change in order to segregate the address lists so that every company will only see what they are supposed to see.

Before that, I think it is important to highlight that address list in Exchange is really nothing more than an Active Directory object containing query logic or filter that specify what mail enabled objects in Active Directory should be included in that list. It is not an actual list or a table or store that consists of all the contact information. It is a filter or I like to call it query logic. That's not all, what is more important to understand is that this query logic is only essential when creating the mailbox, but not so much for the actual Outlook query. As we walk through the blog, the statement above will become clearer to you and you will why HMC does what it does.

What is HMC trying to do?  

So, let's look at what HMC intends to achieve here,

  • Global Address List - By default when you install Exchange 2007, it assumes that it is only meant for one company; hence it comes with a Default Global Address List which lists of all email users, distribution groups, and Exchange resources in the whole environment. That is not something a multi-tenant environment would like to have. Therefore, the primary objective here is NOT to have one GAL that will display everyone in the environment but different GALs for different companies.


  • Other Address List - If there is any other address list being used by a company in the environment, those address lists have to be only accessible and visible to users in that company only.

So, with the above objectives in mind, let's take a closer look.

Global Address List Segregation

Outlook needs GAL to work and as we know, Outlook can only see one GAL at a time. In order to provide each company their own Global Address List, we need to create different GAL objects for different companies, having specific query logic that scope to just users, distribution groups and resources in the company.

Once we have different GALs for different companies, we need to address the following,

(1) What's the limitation of Global Address List?

The default configuration of the global address list (GAL) class object allows only 1000 address lists. This presents a clear problem because we do expect most hosters to have at least more than that. To make sure that the environment can support more than 1000, you need to use the MakeGalLinked tool to extend this limit.

This is documented in the deployment walkthrough. I am not going to spend time to cover that as I am quite sure you can find other blogs cover this better.

(2) How to make sure that Outlook clients access the correct global address list if there is more than one global address list?

If you refer to the following article,, you will realize that Outlook displays the global address list that meets the following criteria:

  • The user has permissions to access this global address list.
  • The user is a member of this global address list.
  • This global address list is the largest of all of the other global address lists.

The above Outlook logic means that the Default Global Address List will always be used because all the users created will always be a member of this GAL and it is obviously the largest GAL of all because it consists of everyone in the environment.

Because of the above Outlook logic, we need to either make sure the user is not a member of the Default GAL or we make sure that the user has no permission to it. HMC has selected the latter. We deny almost everyone except Exchange Servers and Domain Admins permission to Open Address List for Default GAL. You may notice that this isn't very different as compared to the steps documented in White Paper: Configuring Virtual Organizations and Address List Segregation in Exchange 2007.

With the default GAL not accessible to all the users, we need to now create different GAL for different companies so that Outlook will actually work.

What HMC did is this, when you create a company and the user with Outlook plan, it will automatically create a company GAL. HMC also ensures that only users (AllUsers@<company>) in that company/tenant will have the Open Address Lists permission their GAL. I am not going to list down all the permissions that we set in there but it shouldn't stop you from finding out yourself, right? If you want to know the exact permissions being granted, just run Get-ADPermission cmdlet, for example,

Get-ADPermission "AlpineSkiHouse GAL" | FL

(3) What query logic or filter should we use for the company GAL?

In White Paper: Configuring Virtual Organizations and Address List Segregation in Exchange 2007 , the article uses customattribute1 and they make sure that mailboxes or resources created must have that attribute, if not, it will not be included in that GAL.

This is where HMC 4.5 does things slightly differently. If you perform a Get-GlobalAddressList on one of the GALs created by HMC, you will find the query logic/filter, which is the RecipientFilter and LdapRecipientFilter attributes are empty.

These attributes are essential if you want to make sure a newly created mailbox will be included as a member of this GAL. Only if the user is a member of the GAL, it can access the GAL and that it can show up in the GAL. These attributes are being read during the creation of the mailboxes and if the mailbox falls under the query logic, the appropriate membership will be stamped.

So, why does HMC not have any value on those attributes then? The answers are,

    • HMC mechanism - HMC has its own mechanism to retrieve the company GAL and perform the membership stamping. How? Remember the otherWellKnownObjects attribute I talked about in part #1?  
    • It is faster. Just imagine if the environment hosts 20,000 domains in the environment, how long do you think it will take to walk through those query each time I create a mailbox? Having HMC to accurately retrieve the correct GAL will be more effective.

You may ask, what about when I query this from Outlook? Does it use those query logic? The answer is no. When you query from Outlook, it retrieves the objects based on Address List Membership (showInAddressBook) attribute in each objects. In short, the query logic in the GAL itself is only used for stamping the membership during mailbox creation.  

There you go, Global Address List segregation, not really a difficult concept but can be confusing sometimes.

Address List Segregation

Address List Segregation isn't very different as compared to the GAL Segregation. However, there are a few things worth mentioning here.

Firstly, out of the box, Exchange 2007 installation comes with a few default address lists, All Contacts, All Groups, All Rooms, All Users, and Public Folders. Those will be removed during HMC 4.5 deployment. So, a clean HMC deployment will have an empty All Address Lists container.

Next, like the GAL segregation, the permission of the All Address Lists container has been properly locked down. Now, in theory, we don't really need to be part of any Address Lists for Outlook to work. Being part of the GAL is more essential because if you are not, you can't even create an Outlook profile for that user.

However, some processes in Exchange, such as the Offline Address Book generation prefers using Address List than Global Address List when generating the OAB (I will cover the OAB generation process in my next part). For those reasons, we need to make sure each company will also have company Address List where every mail enabled objects in the company will be part of that address list (yes, there is no difference compared to GAL).

Like the GAL membership stamping process, the Address List membership stamping process is the same, it is done by HMC mechanism. Hence you will see the query logic/filter for all the Address Lists created by HMC are also empty.

Wait the minute, what about Outlook Web Access?

So far, we have been discussing about the Outlook experience of the Global Address List and Address Lists. I think it is important to highlight that things work a little bit differently in Outlook Web Access.

There is some permission that applies only to specific clients. For example, Outlook Web Access does not incorporate user permission sets when doing searches. The permissions set on OUs do not prevent search results from including other segregated group's recipients, due to how OWA works. This is where attribute msExchQueryBaseDN comes in.

In order for us to control or restrict the search results to include only the members of the appropriate address list in Outlook Web Access, we must set the attribute msExchQueryBaseDN on each user object to the distinguishedname (DN) of the OU or an address list containing the correct group of users. In the case of HMC, when a mailbox user is created, HMC will also populate this attribute with the OU of the company/tenant.

What about LDAP? I have clients needing this access.

If I have a group of users using other clients and needs LDAP access so that they can query the users of in their company/tenant, what happen then? Well, the way I look at it is this, as much as possible, don't.

However if you have to do it, make sure that the client has to at least go through some form of VPN or something because you really don't want to put your Active Directory server out and exposed them to the Internet just like that.

Also, if you are having HMC 4.0, you should look at this article, Hosted users can see other hosted users if they can access the HMC Active Directory by using LDAP tools in Microsoft Solution for Hosted Messaging and Collaboration version 4.0 (, to properly lock it down before allow your users to use it.

What are some of the usual problems that you may face with Address Lists?

(1) Incorrect Address List membership 

The most common issue that I have seen with address lists issues are membership problem. Based on the above, you kind of understand how some of the things could have gone wrong. The fact that HMC does not use the RecipientFilter and LdapRecipientFilter means that you can't run Update-GlobalAddressList or Update-AddressList because, That two cmdlets will rebuild (there is no update process in Exchange 2007, only rebuild) the address list, which means when it finds that it is empty, it may reset those accounts that currently are supposed to be in the address list.

When an account lost the GAL or AL membership, you may notice that you may not be able to create an Outlook profile for that user, and the user may have other problems too.

To resolve that, you can either use ADSIEdit to manually slot those membership back or you can use the hosted Email 2007::ModifyMailbox to reset this attribute to its correct values without having to know the address list DNs. This procedure resets the showInAddressBook attribute on each call.

Here is a sample, assuming that you supply the original values for <emailAddresses>  and <alias> the procedure will only reset the showInAddressBook value without modifying any other attributes.

    <user>LDAP://CN=User1,OU=AlpineSkiHouse,OU=ConsolidatedMessenger,OU=Hosting,DC=fabrikam,DC=com </user>
        <value> </value>
      <execute namespace="Hosted Email 2007" procedure="ModifyMailbox" impersonate="1" >
           <before source="data" destination="executeData" mode="merge" /> 
           <after source="executeData" destination="data" mode="merge" />

This functionality was added to account for the fact that the Exchange Cmdlets like to reset showInAddressBook value during most mailbox operations.

Comments (22)
  1. Anonymous says:

    Introduction One of the frequently asked questions about Hosted Messaging & Collaboration (HMC) is this, "What do you do to Exchange to make HMC work?" So, here I will attempt to demystify this. HMC started long way back but the concept has not deviated

  2. Anonymous says:

    Hi C. Jershauge,

    You are probably right. OWA uses a msExchQueryBaseDN and Outlook looks at the company GAL, specifically. Now, assuming that this user has been subscribed to a user plan with MAPI enabled. Take a look at this post that I blogged a while ago and see if it helps,…/addresslistmembership-goes-missing-again.aspx

    Let me know if you need more help.

  3. Anonymous says:

    It is being investigated. That's all I can say right now.

  4. Anonymous says:

    @ P Zain, I took a quick look at this. I am able to reproduce the issue. While this is not a conclusive answer, I believe the issue has to be that Outlook detects (either by some headers or message class) that the message is an internal delivery and hence attempts to resolve the address. I do not think this has to do with SP2 or HMC Update Rollup 6. I do not think there is a lot you can do to change this behaviour at the moment. I will a note to our internal team to investigate into this. Thanks for the feedback.

  5. Anonymous says:

    Hmm.. if everthing is right, then this could be either a version difference here. Alright, try replacing the line,

    <execute namespace="Managed Email 2007" procedure="RepairExchangeObject" impersonate="1">


    <execute namespace="Exchange 2007 Provider" procedure="RepairExchangeObject" impersonate="1">

    If the above doesn't work, run the 2nd option in my post, which is to do the EnsureAddressListStamp_.

  6. Anonymous says:

    Thanks alot for you quick response 🙂

    I looked at your earlyer Post, and i looked like that was what i needed, but then again maybe not.

    Í assume that the file you made an example of in that post, is to be run with provtest.exe, right ?

    Here is what i didt:

    I used the command get-mailbox "User" | fl and here is the result(a little modifyed:))

    OfflineAddressBook                   : USERDOM OAL

    SamAccountName                       :

    UserPrincipalName                    :

    AddressListMembership                : {USERDOM AL, All Users, Default Global Address List}

    Alias                                :

    OrganizationalUnit                   : saass.local/Hosting/Customers/USERDOM

    CustomAttribute1                     :

    CustomAttribute10                    :

    CustomAttribute11                    :

    CustomAttribute12                    :

    CustomAttribute13                    :

    CustomAttribute14                    :

    CustomAttribute15                    :

    CustomAttribute2                     :

    CustomAttribute3                     :

    CustomAttribute4                     :

    CustomAttribute5                     :

    CustomAttribute6                     :

    CustomAttribute7                     :

    CustomAttribute8                     :

    CustomAttribute9                     :

    HiddenFromAddressListsEnabled        : False

    LegacyExchangeDN                     : /o=saass/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/

    EmailAddressPolicyEnabled            : False

    PrimarySmtpAddress                   :

    IsValid                              : True

    OriginatingServer                    : SAASSDC02.SAASS.local

    ExchangeVersion                      : 0.1 (8.0.535.0)

    Name                                 :

    DistinguishedName                    :,OU=USERDOM,OU=Customers,OU=Hosting,DC=SAASS,DC=LOCAL

    Identity                             : SAASS.LOCAL/Hosting/Customers/USERDOM/

    Guid                                 : 1fb29985-73a6-497d-8bd1-35b8f3eed07b

    ObjectCategory                       : SAASS.LOCAL/Configuration/Schema/Person

    ObjectClass                          : {top, person, organizationalPerson, user}

    To me that looked fine, but i can not get that user on to the system using Outlook 2007, so i used the xml file modifyed to me use of cause, it is listed below.

    XML file to be run with provtest.exe, on the MPS server



       <!–The domain controller to use for Active Directory actions.–>


       <!–Specifies the LDAP path of the user, group, or contact.–>




       <!–Specifies the path of the hosted organization that contains the AL, GAL, and OAB as well-known-objects.  By default it is the LDAP parent container of the object.–>    






       <execute namespace="Managed Email 2007" procedure="RepairExchangeObject" impersonate="1">

         <before source="data" sourcePath="preferredDomainController" destination="executeData" mode="move" />

         <before source="data" sourcePath="path" destination="executeData" mode="move" />

         <before source="data" sourcePath="owningOrganization" destination="executeData" mode="move" />

         <after source="executeData" destination="data" mode="merge" />




    That gives me the following result:

    E:XML File>provtest Update_Mailbox_Attrib.xml /x2


     <errorContext description="Unknown error (0x80005000)Failed trying to create a DirectoryEntry for LDAP path: fullPath='LDAP://



    input preferredDomainController='SAASSDC01.SAASS.LOCAL'

    input ADObject path='





       <errorSource namespace="Exchange 2007 Provider"


       <errorSource namespace="Managed Email 2007"




    I porpperly have around 20 user with that same problem, therefore I rearly need your help.

  7. Anonymous says:

    I am facing a issue GAL in  HMC 4.5 ,

    Issue : Default GAL listing to all user / companies . We are facing this issue only in outlook client. In OWA we are able to see only the companies GLA, but in Outlook client we are getting all companies GAL.

    We tested by removing "CN: Default Global Address List " for one user using adsiedit and this solve the issue temporarily. But it not possible to remove  "CN: Default Global Address List " for all user in HMC environment manually .There is any way to overcome this issue by setting permission to default GAL.

  8. Anonymous says:

    @ YS. Thanks for your suggestion. I haven't done thorough testing but I do not believe it is nk2 Outlook name cache issue. It maybe the case if we are trying to resolve to a mailbox that has already been deleted but it isn't the case here.

  9. Anonymous says:

    Just make sure your BB service account has access to the Default Global Address List and make sure the rest of the mailboxes is also part of that but has no access to it.

  10. Anonymous says:

    Hi, I am looking at the request file. Your user path is set to,


    And owning Org is set to


    One is DC=LOCAL, and one is DC=DK.

  11. Anonymous says:

    I have been seeing installation issues with Blackberry Enterprise server because of the way HMC changes the GAL.  I’m unable how to figure a way around this.  Can you provide some direction?

  12. Anonymous says:

    "To resolve that, you can either use ADSIEdit to manually slot those membership back or you can use the hosted Email 2007::ModifyMailbox to reset this attribute to its correct values without having to know the address list DNs. This procedure resets the showInAddressBook attribute on each call. "

    Please help me, how do I correct the problem, in details.

    Let say that i have a user named "Bill Board" with the alias "" and a other user from a different company named "My Game" alias ", how do i make sure that they are updated.

    The exac problem that i have right now, is that I am running a HMC enviroment, and the OWA i working perfectly, but when the users try to setup the Outlook (2007) the run as Outlook AnyWhere, it returns the error, that "the user was not found in the addresslist" and so on. To me it look like it is at problem with the GAL.


  13. Anonymous says:

    Here is the result of the test


    E:XML File>provtest Update_Mailbox.xml /x2


     <errorContext description="Unknown error (0x80005000)Failed trying to create a

    DirectoryEntry for LDAP path: fullPath='LDAP://



    input preferredDomainController='SAASSDC01.SAASS.DK'

    input ADObject path='





       <errorSource namespace="Exchange 2007 Provider"


       <errorSource namespace="Hosted Email 2007"




    Using this file below

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




       <!–Specifies the path of the hosted organization that contains the AL, GAL, and OAB as well-known-objects.  By default it is the LDAP parent container of the object.–>    






     <execute namespace="Hosted Email 2007" procedure="EnsureAddressListStamp_" impersonate="1">

       <before source="data" destination="executeData" mode="merge" />

         <after source="executeData" destination="data" mode="merge" />        




  14. Anonymous says:

    @ P Zain, I will if I have the updates.

  15. Anonymous says:


    Sorry my mistake, in the real file they are both with DC=DK but i changed it for this purpose.

  16. P Zain says:

    I have a strange issue with our HMC4.5 environment. When a tenant from organization emails a tenant at another organization, the sender email address shows the LegacyExchangeDN attribute value in recipients email FROM Field when you double click on it to view the contact or reply. It only happens in all versions of outlook (2003, 2007 and 2010). It does not happen in OWA. Exchange server is running SP2 and HMC update rollup 6. I am not sure if this is by design or if there is a workaround? Can you please advice on what could be wrong?

  17. P Zain says:

    Thanks for the response. Please can you let us know how the investigation progresses and update this Blog?

  18. YS says:

    @P Zain

    The issue may come from Outlook client cache.

    just delete outlook autocomplete cache, that issue will be resolved,


  19. P Zain says:

    Hi I have tried deleting the cache .NK2 file in outlook but it does not fix the problem. Like Kip says it looks like it is another issue.

  20. P Zain says:

    Hi Have you got any updates from the internal Team.? Thanks

  21. aw says:

    hai, I just want to tell you that I am just very new to blogs and seriously loved this website. More than likely I’m planning to bookmark your blog post .
    You amazingly come with really good posts. Thanks a lot for sharing your blog Microsoft.

Comments are closed.

Skip to main content