• 1. London, UK
  • 2. New York, NY
  • 3. Sydney, Australia
  • 4. Melbourne, Australia
  • 5. Moscow, Russia
  • 6. Singapore
  • 7. Paris, France
  • 8. Chicago, IL
  • 9. Hong Kong
  • 10. Houston, TX

Tuesday, February 20, 2007


OPATH: Filterable properties that can be used in Recipient Filters

Posted by Bharat Suneja at 7:52 AM
I posted about OPATH filters recently [read previous posts 1) Adventures with OPATH: some annoyances if you're used to LDAP and 2) memberOf Attribute can now be used in OPATH filters!].

One of the issues was my inability to get a list of filterable properties that can be used in OPATH filters - unlike LDAP filters (I hate to call them legacy filters :), you cannot use *all* the attributes of recipients in an OPATH filter. Commands referenced in the documentation to get this did not work for me the last last time I checked.

Last week Evan Dodds informed me the list of filterable properties should be up on his blog soon, and here it is, as promised - Filterable Properties in Exchange 2007 RTM. He warns "The rest of this blog post will be long. And boring". Not if you've been waiting for this info Evan... it's an interesting reference!

Updated list of filterable properties in SP1

There are differences in the filterable properties used by the -Filter parameter used in recipient commands like Get-Mailbox, and the properties used in OPATH filters for the -RecipientFilter parameter (for Address Lists, EmailAddressPolicies, Dynamic Distribution Groups). Both lists have been updated for SP1.

Filterable properties for the -Filter parameter: RTM SP1

Filterable properties for the -RecipientFilter parameter: RTM SP1

As you'll find out from the post - and this is one of the issues I've had with OPATH - a lot of ldap attributes are referenced in OPATH using a name that's different from their LDAP Display Name (ldapDisplayName). Here's a list of some of the common ones:

1. the ldap attribute for last name is sn (or surname, as it's known in many cultures). OPATH refers to it as LastName.
2. physicalDeliveryOfficeName is referred to as Office
3. st (the LDAP quivalent of State) is known as StateOrProvince
4. mailNickname - a commonly used attribute in LDAP filters - is known as Alias
5. cn becomes CommonName
6. targetAddress (used for mail-enabled Contacts/Users) becomes RawExternalEmailAddress
7. msExchHideFromAddressLists becomes HiddenFromAddressListsEnabled
8. memberOf, as noted in previous post, is MemberOfGroup
9. msExchRequireAuthToSendTo becomes RequireAllSendersAreAuthenticated
10. mail (the email attribute seen on General tab of a recipient in ADUC) becomes WindowsEmailAddress

Yes, many of the OPATH property names do make a lot more sense, and while these will make things easier to figure out for newbies - as Evan notes in his post, it does add some complexity for folks used to LDAP syntax, filters, and attribute names.

I'm beginning to equate the OPATH property names to what "users" see in their Address Books in Outlook - simplified property names. At times you struggle with the cross-references between those simplified property names, and the actual attribute names that they map to when you fire up a tool like ADSIEdit or edit a Display Template.

If you've been using OPATH for any length of time, I am certain you must have felt some of that discomfort. Evan's post and the list of filterable properties may help alleviate some of that.

Labels: , , , ,


June 3, 2007 6:00 AM
Anonymous Anonymous said...

Thanks for the post, and the link to Evan Dodd's reference material. Unfortunately, Evan disabled comments on his post after accepting a few. My comment/question is:

Why is there a limited set of properties which oPath can filter on?

In Microsoft's desire to "simplify", they have broken or reduced functionality by limiting what can be used.

I'm certain I'm in the minority on this issue, but ldap search filters are a fact of life for anyone worth their salt in Active Directory support, and I can't really see how oPath makes my life better.

June 3, 2007 8:16 AM
Blogger Bharat Suneja said...

I am yet to come across a really good explanation why (there a limited set of properties which oPath can filter on), though part of it may be related to optimization of ldap queries for address lists, recipient policies and dynamic distribution groups.

What attributes would you like to see included in the list of filterable properties??

>I'm certain I'm in the minority on this issue.
No, you're not.

I would love to see a way to continue using (now) 'legacy' LDAP filters as an alternative, or get the ability to enter LDAP filters and have the shell convert it to OPATH as required.

October 2, 2007 5:20 AM
Anonymous Anonymous said...


Been browsing this website a while now, alot of usefull knowledge to be picked up, thank you :-)

Your site doesn't seem to have a forum so I thought I could ask my question here, sorry in advance if this is frowned upon.

My question involves Exchange 2003 en query based distribution lists.

Since a week i've made query distribution lists for each department in my company.

At the user accounts the field deparment is filled in and the query distribution lists filter this field aswell.

Now every user who has "example" filled in at their department field will automatiscally join the query distribution group "example"

It seems the filtering options are AND and not OR based.

I actually have 3 distribution lists which I need 1 user to be a member off. This is not possible without adding a OR filter.

Any help is much appreciated.


June 20, 2008 11:16 AM
Blogger V. Edward Martin said...

I was and am very satisfied with the power and functionality of the LDAP query engine. Creating Address Lists, Query-Based DL, etc was and is straight forward in Exchange 2003. With Exchange 2007, Microsoft complicated and clouded the procedure to such an extend that I am seriously considering keeping an Exchange 2003 mailbox server on-line after the migration just to manage and create Address Lists, Query-Base DL, etc. Trying to accomplish the goal with Exch2007 is just too complicated and time consuming. Whomever at Microsoft thought the Exchange Command Shell would be more useful needs to have an MRI!


Post a Comment

Links to this post:

Create a Link

<< Home