Welcome to Exchange Team Blog Sign in | Join | Help

Syndication

This Blog

Need help converting your LDAP filters to OPATH?

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

- Bill Long

Published Monday, March 12, 2007 3:04 PM by Exchange
Filed Under: , ,

Comments

 

Tman said:

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
 
March 13, 2007 11:06 AM
 

Bill Long said:

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:\Users\bill\desktop\ConvertFrom-LdapFilter" instead of ".\ConvertFrom-LdapFilter".
March 13, 2007 2:37 PM
 

Tman said:

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
March 15, 2007 10:45 AM
 

Bill Long said:

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.
March 15, 2007 1:49 PM
 

S. Johnsen said:

Start the assistant service.
March 15, 2007 7:01 PM
 

Akihide Komoto said:

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 ?
March 26, 2007 7:40 AM
 

Oguz Mazlum said:

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.
April 10, 2007 5:53 PM
 

Exchange said:

April 10, 2007 6:30 PM
 

Helo @ mpriem.com » Blog archief » Exchange 2007 recipient policies… uhhh Email Address Policies said:

April 27, 2007 4:19 AM
 

jmulvey said:

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.
May 9, 2007 11:23 AM
New Comments to this post are disabled

News


This blog and its contents are provided "AS IS" with no warranties, and they confer no rights. Use of any included script samples are subject to the terms specified in the Terms of Use.
New! Would you like to suggest a topic for the Exchange team to blog about? Send suggestions to us.

Exchange Server 2010 - Get the Release Candidate



Poll:

Other Exchange Blogs from MSFT