Blog Post

Exchange Team Blog
2 MIN READ

Need help converting your LDAP filters to OPATH?

The_Exchange_Team's avatar
The_Exchange_Team
Icon for Microsoft rankMicrosoft
Mar 13, 2007

 

After installing Exchange 2007 into your existing Exchange organization, the address lists and recipient policies must have OPATH filters specified in order to administer them from the Exchange 2007 tools. As discussed in the earlier blog post, OPATH is the basis for the filtering syntax used by PowerShell, and is therefore the filtering syntax used by Exchange Server 2007.

Reading up on OPATH syntax can be a considerable time sink for an administrator who just wants to get his policies upgraded. I've written a PowerShell script that will perform these conversions for you, allowing you to save the OPATH documentation for the next time you're having trouble getting to sleep.

To use the script, just drop it somewhere on the Exchange 2007 server, change the extension to ps1, and change to that folder at the PowerShell prompt. The top of the script shows some various syntax examples, ranging from the simple conversion of a manually entered filter to the automatic upgrading of every existing legacy filter. Of course, before you just automatically upgrade every filter and call it a day, you should consider testing the script in your lab and saving your existing filters, just in case. One of the syntax examples shows how to write out the name, legacy LDAP filter, and suggested OPATH filter for each legacy object to a tab-delimited file, which you could then open in Excel for viewing. This is one of several ways you could save out your old filters before upgrading.

Some notes about the script:

  • All syntax examples assume you've changed into the folder where the script is, and that it's not in the path. If you drop the script in Exchange Server\bin you can eliminate the .\ that precedes the script name in the examples.
  • Some LDAP attributes are not available in OPATH. If the script encounters such an attribute in one of your filters it will report, "Could not convert LDAP attribute 'blah' to OPATH", and will fail out.
  • The script does very direct conversions from LDAP to OPATH. For instance, it typically will not use the 'RecipientType' property in OPATH since there is no LDAP equivalent. There is one exception where it looks for a specific string and produces 'RecipientType -eq UserMailbox' in response.
  • The script looks for filters matching the default address list filters and, if it finds one, it skips the normal conversion routine and produces the filter suggested in Evan's earlier post (http://msexchangeteam.com/archive/2007/01/11/432158.aspx).

Hopefully this will save you some time during your Exchange 2007 upgrade!

The link to the script is below (ConvertFrom-LdapFilter.txt - download and rename to .ps1 to run):

LDAP to OPATH filter conversion script - attached to this blog post.

- Bill Long 

Updated Apr 27, 2020
Version 3.0
administration
Exchange 2007
tools
  • Deleted's avatar
    Deleted
    Mar 14, 2007
    I try to work with ConvertFrom-LdapFilter.ps1 but I got some error below:
    The term '.ConvertFrom-LdapFilter' is not recognized as a cmdlet, function, operable program, or script file. Verify the term and try again.
    At line:1 char:143
     
  • Deleted's avatar
    Deleted
    Mar 14, 2007
    Hi Tman,

    Make sure you've changed into the folder where the script is. Also make sure it's a folder you have permissions to, such as your Desktop folder. I've seen that error when trying to run a script from the root of C:. For troubleshooting purposes you may want to specify the full path to the script instead of using ., such as "C:UsersbilldesktopConvertFrom-LdapFilter" instead of ".ConvertFrom-LdapFilter".
  • Deleted's avatar
    Deleted
    Mar 16, 2007
    I work on your recommend but I got new error message below:
    [PS] U:> Get-AddressList | WHERE { $_.RecipientFilterType -eq 'Legacy' } | fore
    ach { Set-AddressList $_.Name -RecipientFilter (D:ConvertFrom-LdapFilter $_.Lda
    pRecipientFilter) -ForceUpgrade }
    Unable to validate the filter: 'An Exchange 2007 server on which an address list service is active cannot be found.'
    At line:1 char:78
  • Deleted's avatar
    Deleted
    Mar 16, 2007
    Tman, try running just Get-AddressList by itself. Sounds like it's going to fail with the same error. You'll only be able to use Get-AddressList and Set-AddressList if you actually have Exchange 2007 installed in the forest where you're running the command. If you do have Exchange 2007 installed and you're still getting this error, I'd recommend opening a case with CSS.
  • Deleted's avatar
    Deleted
    Mar 26, 2007
    Hi, Bill.
    I have a cutomer who needs to know the corresponding OPATH name for LDAP attribute "comment".
    I couldn't find one in "ConvertFrom-LdapFilter.txt "
    Can you give me the answer ?
  • Deleted's avatar
    Deleted
    Apr 11, 2007
    The script won't execute because of the following error.

    ConvertFrom-LdapFilter.ps1 is not digitally signed. The script will not execute on the system.
  • Deleted's avatar
    Deleted
    May 10, 2007
    I am trying to implement a fairly simple Email Address Policy (simple at least in terms of my ability to explain it... but I can't seem to create an OPATH filter to implement it).

    I have a multi-domain forest environment. User/Group/Contact objects in the companya.com AD domain should get an email address of the form SMTP:%1g%s@companya.com. Similarly, User/Group/Contact objects in the companyb.com AD domain should get an email addresses of the form SMTP:%1g%s@companyb.com.

    OK, easy to explain, but I cannot get an OPATH recipient filter to filter by domain. I have tried to use the RecipientFilter {userPrincipalName -like '*@companya.com'} and this works fine for users, but not for Groups/Contacts. I have tried to do similar matching with other OPATH attributes like canonicalName and distinguishedname but they do not allow wildcard matching. I am really stumped to find an OPATH attribute that contains the domain name and still allows me to perform matching!

    I can only believe that I am doing something really stupid, because this seems like a fairly standard EAP requirement and I cannot for the life of me figure out how to implement it.