Sachin's Blog

Exchange 2013 ROCKS

Dealing with hidden DL members in Exchange 2010

Dealing with hidden DL members in Exchange 2010

  • Comments 7
  • Likes

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 http://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: http://technet.microsoft.com/en-us/library/aa996976(v=EXCHG.65).aspx

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

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

http://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!

Comments
  • Good stuff Sachin, thanks for sharing this nifty trick ;)

  • I am not come across this scenario :( But it's very nice article to learn.

  • Just because the users or contacts are hidden does NOT mean that emails sent to the DL are not received by those hidden from the DL.

  • Hmm in my setup when a 2010 users logs into OWA, they are able to see the hidden contact when they search for or expand the DL. Okay they can not directly search for the hidden contact, but as a member of a DL it is visible :-(

    Do you have any idea how to avoid this? I don't want users to see hidden contacts anywhere in OWA.

    Can it be the problem that these users were migrated from exchange 2007 to 2010?

    Thanks!

  • Hello Sachin,

    I have a similar issue, however its as below, please advise, I have Exchange 2010 SP2 Hosting.

    "All other tenant user's are visible while adding the distribution group members"

    Created a test DG "test" in the org test01.local. We then made test@test01.local as the owner. When we logged in to OWA with this user, we are able to see all the addresses when we click on the Add button to add members to the DG.

  • All contacts have been unchecked "hidden" after step 1

    and the contacts did not hide again?

    if so, "We need to be able to see external contacts who are members in a DL” should be already reached at step 1?

  • Hi Sachin, Thanks for this post it was of great help and I was able to get the desired functionality in a lab environment. I have a customer keen to get this implement as they liked the '2007' functionality of expanding membership on DL's. Would the change of using ADSI edit to force remove the Default address book I take it would mean they are no longer running a "supported" environment? I'm hesitant to do anything drastic. You mentioned at the start of your article using Address Book Policies to achieve the same results? Are you able to provide any insight on how you would do this? Cheers

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment