Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm upgrading a (working) query based group (Exchange 2003) to a new and 'improved' dynamic distribution group (2010).

For better or worse, our company decided to store everyone's employee ID in the pager field, so it's easy to manipulate via ADUC. That employee number has significance, as all employees are in a certain range, and all contractors are in a very different range.

Basically, the new opath syntax appears to be using string compare on my pager field, even though it's a number. Let's say my employee ID is 3004, well, it's "less than" 4 from a string check POV.

Set-DynamicDistributionGroup -Identity "my-funky-new-group" -RecipientFilter "(pager -lt 4) -and (pager -like '*') -and (RecipientType -eq 'UserMailbox')"

Shows up in EMC with this:

((((((Pager -lt '4') -and (Pager -ne $null))) -and (RecipientType -eq 'UserMailbox'))) -and (-not(Name -like 'SystemMailbox{*')) -and (-not(Name -like 'CAS_{*')) -and (-not(RecipientTypeDetailsValue -eq 'MailboxPlan')) -and (-not(RecipientTypeDetailsValue -eq 'DiscoveryMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'ArbitrationMailbox')))

This group should have max of 3 members right? Nope - I get a ton because of the string compare. I show up, and I'm in the 3000 range.

Question: Anyone know a clever way to force this to be an integer check?

The read-only LDAP filter on this group looks good, but of course it can't be edited.

The LDAP representation (look ma, no quotes on the 4!) - Also interesting it sort of 'fills the' bed with the (pager=4) thing...

(&(pager<=4)(!(pager=4))(pager=*)(objectClass=user)(objectCategory=person)(mailNickname=*)(msExchHomeServerName=*)(!(name=SystemMailbox{*))(!(name=CAS_{*))!(msExchRecipientTypeDetails=16777216))(!(msExchRecipientTypeDetails=536870912))(!(msExchRecipientTypeDetails=8388608)))

If there is no solution, I suppose my recourse is either finding an unused field that actually will be treated as an integer, or most likely building this list with powershell every morning with my own automation - lame.

I know of a few ways to fix this outside of the opath filter (designate "full-time" in another field, etc.), but would rather exchange do the lifting since this is the environment at the moment.

Any insight would be great - thanks!

Matt

share|improve this question
    
Currently getting some traction here: social.technet.microsoft.com/Forums/en-US/exchange2010/thread/… –  Matt Jan 25 '11 at 17:59
    
Will post the solution if I get one. –  Matt Jan 25 '11 at 18:20

1 Answer 1

up vote 0 down vote accepted

Spoke with Microsoft.

"You are correct on the reasons why its not working Pager just like telephone Number Is a Unicode string, for the filter we have created to work correctly it should be a Large integer, the sad part about the Large integer attributes available for users is they are mostly system attributes something like (uSNCreated changed etc). I have tried it hare in my lab environment as well at it doesn't seem to work as desired, I think we will need to look for other options."

So, at the moment, with Exchange 2010 SP1, it appears you can't do an integer comparison with anything other than a few key system attributes (IssueWarningQuota, MaxReceiveSize). Everything else will be treated as a string compare.

The other options the support suggested were things like hoping they were in the same Exchange Store, Particular OU's, or some other criteria. Since these won't work in our environment, I'm gonna have to build these DL's nightly via Powershell.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.