I'm already familiar with creating QBDLs in Exchange 2003, but I'm not really pleased with the change from LDAP to Opath in 2007. I started out with a simple enough LDAP query: (& (physicalDeliveryOfficeName=officename) (company=companyname*) (!employeeType=Consultant) ) which returns all the users in a specific office who work for a specific company or its divisions, whose accounts are not set to expire. Unfortunately, it seems the employeeType attribute (and many other LDAP attributes) are not available in Opath, so now my Exchange 2003 -> 2007 transition can't be completed. What's the logic behind the switch to Opath? While the syntax is easier to read, it's more difficult to build a query (for me, at least) and it seems very limited in capability. What's my solution? Sure, I could copy the employeeType into an extensionAttribute, but that's an ugly hack, especially when I'm using the AD schema as-designed.

What's the logic behind the switch to Opath? While the syntax is easier to read, it's more difficult to build a query (for me, at least) and it seems very limited in capability. What's my solution? Sure, I could copy the employeeType into an extensionAttribute, but that's an ugly hack, especially when I'm using the AD schema as-designed. Tony Redmond (Exchange MVP) has some interesting reflections on this topic in his Exchange 2007 book. To sum up: * The move to PowerShellOPATH is the filtering syntax used by PowerShell, so it is a natural progression for Exchange 2007 to embrace OPATH as its preferred syntax, especially as it also removes the need for administrators to learn and master the somewhat obscure and opaque queries that LDAP often generates. * Performance issuesThe Active Directory query builder allows you to construct very sophisticated and precise searches against the Active Directory but on the other hand, an unsuspecting or careless administrator is able to build queries that take hours to execute.* Troubleshooting issuesReal-life experience showed that it was all too easy for Exchange administrators to fall into the trap of creating queries that stressed servers as the Active Directory attempted to build lists of thousands of matching objects ... The problem was compounded by the fact that the processing that ensued after a user sent a message to a dynamic group was a black hole and administrators could not get any insight into what was happening on their servers * Not widely deployedQuery-based distribution groups never made much of an impact in many organizations that deployed Exchange 2003, so now is as good a time as any to change the filter syntax. Microsoft Exchange Server 2007: Tony Redmond's Guide to Successful Implementationhttp://www.amazon.com/Microsoft-Exchange-Server-2007-Implementation/dp/1555583474As to your solution. I think you should copy the employeeType into an extensionAttribute. Every database application has some sort of de-normalization. The reasons are mainly optimization of code and ease of maintenance. Guess what is possible to achieve, should also count in, as in your case.MCTS: Messaging | MCSE: S+M | Small Business Specialist