Don’t forget to update your LDAP filters to OPATH filters when transitioning from Exchange 2003 to Exchange 2010

A lot of posts have been done by the Microsoft Exchange Team to document why and how one should remember to convert any LDAP filter used in your Exchange 2003 environment to OPATH filtering.

For more info have a look here:

• OPATH recipient filtering for Exchange Server 2007
• Need help converting your LDAP filters to OPATH?
• Address List and EAP filter upgrades with Exchange Server 2007

Last month I was in Luxembourg, talking about Exchange 2010, and one of the attendees wanted to know if the script provided by Bill Long to convert LDAP to OPATH, was still valid to convert any LDAP filter to OPATH in an Exchange 2003-Exchange 2010 environment. I promised to blog the answer, which is, lucky enough: YES :-)

Environment

In my demo environment, I have an Exchange 2003 SP2 server, and I have just finished installing an Exchange 2010 RTM (Mailbox, CAS, HUB) server in that organization. As can be seen in the picture below:

I have the following address lists defined in my Exchange organization:

All Rooms, is a new address list, included within Exchange 2010, which includes all resources that have been designated as a a room in your organization. It is in this setup the only address list that can be managed using Exchange 2010 management tools.

Why do we need to convert from LDAP to OPATH?

As taken from the MsExchangeTeam blog, here it is:

OPATH is basis for the filtering syntax used by PowerShell, and is therefore the filtering syntax used by Exchange 2007. It replaces the complicated syntax of LDAP used in Exchange 2003, and will allow for filters which are easier to create and interpret.

When using the Exchange Management Console 2010 to edit any of the existing address lists (besides All Rooms), the following error message will pop-up:

Using the Exchange System Manager, no error pops up…except for the newly built-in address list All Rooms, which generates the following error when trying to edit it using the Exchange System Manager:

 

 

 

Convert from LDAP to OPATH

The conversion can be done using the Exchange Management Shell, and its cmdlet Set-AddressList, which will enable you to populate a value for the parameter RecipientFilter:

Converting the default Address Lists is not that complicated, for example converting the default address lists, you just need to run the following lines:

Set-AddressList “All Users” –IncludedRecipients MailboxUsers

Set-AddressList "All Groups" -IncludedRecipients MailGroups

Set-AddressList "All Contacts" -IncludedRecipients MailContacts

Set-AddressList "Public Folders" -RecipientFilter { RecipientType -eq 'PublicFolder' }

The Default Global Address List is a bit more complicated…

Set-GlobalAddressList "Default Global Address List" -RecipientFilter {(Alias -ne $null -and (ObjectClass -eq 'user' -or ObjectClass -eq 'contact' -or ObjectClass -eq 'msExchSystemMailbox' -or ObjectClass -eq 'msExchDynamicDistributionList' -or ObjectClass -eq 'group' -or ObjectClass -eq 'publicFolder'))}

Converting any custom built LDAP filter, is less easy, and that’s where the script can be a tremendous help!

Using the script

To download the script, click here!

Rename the file to .ps1, and you are ready to go.

In this example I will use the script to convert the LDAP filter used for my custom address list that includes all users that have customattribute1 set to a value of “mechelen”, by populating the attribute RecipientFilter.

To convert I enter:

Set-AddressList “All users in Mechelen” –RecipientFilter ( .\ConvertFrom-LdapFilter (Get-AddressList “All users in Mechelen”).LdapRecipientFilter

After running the script, I can manage the Address List, using the Exchange 2010 Management Console:

 

Ilse

Comments

• Anonymous
  October 17, 2013
  So, how is your customer feedback regarding this "feature"? We have many legacy filters relying on things like custom attributes, and even simple attributes like "St" (State) and these simply CANNOT be converted to OPATH because they don't work. While it's annoying enough to be forced to populate our custom attributes into the Exchange-provided custom attributes, it is absolutely mind-boggling that "st" is not supported. Does no-one create geographically-based distribution lists? Luckily we still have an Exchange 2003 server in the org.

• Anonymous
  September 16, 2014
  Awesome Post! Thank you!

• Anonymous
  October 20, 2014
  Do we need to warn the end users about this update? Meaning is there a change to the Outlook client that we should warn them about?

• Anonymous
  January 08, 2015
  Thank you

• Anonymous
  December 03, 2015
  The comment has been removed