Dealing with hidden DL members in Exchange 2010

  • Article

Recently, I had to figure out an interesting scenario for a customer. The business uses thousands of external contacts that are created in active directory. These are all set to “Hide from Address List”, so none of these objects are visible in the Global Address List. The organization uses Exchange 2007. There are multiple DLs in the environment that include these hidden objects as members. When a user looks up the membership of the DL in the GAL, it clearly shows the external contacts as members of the DL, similarly when they expand the DL in an e-mail, it expands to include the otherwise hidden recipients in the GAL. Life is good!

Now, Welcome Exchange 2010!! This is where we made a conscious change and made a decision to treat “hidden as really hidden”. In Exchange 2010, if you have hidden recipients as members in a DL, they are not shown in the membership of the DL. You are not able to mine the GAL and “find out” hidden recipients. The whole idea was to use the new Address Book Policy feature offered with the product!

But, in my case the customer did not want to use ABPs and requested that this feature be allowed as a “toggle”. I worked with some senior Escalation Engineers and PMs to figure out a “supported” method to achieve this. Remember, this is NOT what we want our customers to do, the Address Book Policy feature provides most of this functionality. Anyway, here is how we figured it out

As an example, I have 2 external contacts created in the GAL, one if hidden; the other is not.

 

I have a DL that includes both of these objects as a member

 

 

When the user logs in to OWA, as you see below; they are able to see both the objects when they mine the object

 

 

On the other hand, when a 2010 user logs in to OWA, this is what they see

 

 

External Contact 1 is hidden; we treat it as such in Exchange 2010.

The business requirement was stated as “We need to be able to see external contacts who are members in a DL”

There are 2 ways that this can be done really. One, unhide the object from the GAL, add a custom attribute to the object and modify your address list and the global address list filters to display only objects with the custom attribute set, we have a problem with that and I will talk a little more about it below. Two, we simply remove the address list and modify the default global address list to not include contacts in the filter that it uses.

Let’s talk about the problem with these approaches. The Default Global Address List in Exchange 2010 CANNOT be modified (through a supported method), but a new one can be created with a recipient filter that matches objects to the requirement.

Here is what we did. We first decided to unhide all the objects from the GAL, we then set CustomAttribute10 to a value of “Test”. Then, we created a New GAL using https://technet.microsoft.com/en-us/library/bb232063(v=exchg.141), we also updated the filter for the All Contacts Address List to only include objects that have CustomAttribute10 set to “Test”

Below are the example recipient filters that were used to set up the GAL and the AL respectively.

  • ·         ((Alias -ne $null) -and (((((((((((ObjectClass -eq 'user') -or (((ObjectClass -eq 'contact') -and (CustomAttribute10 -eq 'Test'))))) -or (ObjectClass -eq 'msExchSystemMailbox'))) -or (ObjectClass -eq 'msExchDynamicDistributionList'))) -or (ObjectClass -eq 'group'))) -or (ObjectClass -eq 'publicFolder'))))
  • ·         ((CustomAttribute10 -eq 'Test') -and (RecipientType -eq 'MailContact'))

Below are the high level steps to achieve this.

1. Remove the Hide from Address list option from All Contacts and any other users that you want to have seen in the DL membership.

2. Create a new Global Address list using the Commandlet New-GlobalAddresslist

3. Now we need to set the new GAL as the default GAL. Open Adsiedit locate the New GAL and set the MSExchRecipientFilterFlag to 3 for the New GAL, and 0 for the Original Default Global Address List.

                Location is in: Configuration – Services – Microsoft Exchange – Org Name – Address list container – All Global Address lists.

4. Run Remove-GlobalAddresslist “Default Global Address list” (You cannot execute this while the MSExchRecipientFilterFlag is set to 3, as it would not allow it to be run. Once the Default Global Address list MSExchRecipientFilterFlag is set to 0 it will allow the execution of this command.)

6. Run the Update-GlobalAddresslist command to force the GAL to be re-populate, restart the Address book service, and recycle the App pools on your CAS servers (if you want to test it all immediately), if you just want to wait the ~2 hours for all things to Reset their cached data and the like just run Update-GlobalAddresslist. Restarting these services will have limited impact on users.

7. Update the OAB, You will have to reset the OAB to pull from the New Default Global Address list (right click on the Default OAB in EMC open Properties then Address list Tab, then Ensure that the Include the Default Global Address list is Checked, the New GAL which we set as the Default in step 3) Then right click and Update the OAB. 

8. Run the command Update-FileDistributionService -Id <CasServer> (so that the OAB is pushed out to all Web distribution points)

From here the Outlook clients will download the new OAB; this can be a bandwidth consumer depending on the new size of the OAB. You might want to look at Staging this or throttling it by site, or placing CAS servers in the remote locations to avoid WAN link saturation.

Options for dealing with the OAB download.

Staging the OAB files: https://technet.microsoft.com/en-us/library/aa996976(v=EXCHG.65).aspx

OAB throttling: https://blogs.msdn.com/b/dgoldman/archive/2009/10/21/how-can-we-try-to-control-the-network-consumption-by-using-oab-throttling.aspx

https://technet.microsoft.com/en-us/library/ee791758(v=WS.10).aspx

https://technet.microsoft.com/en-us/library/bb232155.aspx

Caveats: Please test these changes thoroughly when applying service packs or Update Rollups, or even Interim Updates, as if any of them make a manipulation to the "Default Global address list" you may need to re-run through these steps to ensure that the contacts are not part of the GAL, so ensure that this is tested in a non-production environment before implementation.

Hope the above helps!