Я обновляю (рабочую) группу на основе запросов (Exchange 2003) до новой и «улучшенной» динамической группы рассылки (2010).
Хорошо это или плохо, но наша компания решила хранить идентификаторы каждого сотрудника в поле пейджера, чтобы им было легко управлять через ADUC. Это количество сотрудников имеет значение, поскольку все сотрудники находятся в определенном диапазоне, а все подрядчики находятся в совершенно другом диапазоне.
По сути, новый синтаксис opath, похоже, использует сравнение строк в моем поле пейджера, даже если это число. Допустим, у меня идентификатор сотрудника 3004, ну, это "меньше" 4 из точки обзора строки.
Set-DynamicDistributionGroup -Identity "my-funky-new-group" -RecipientFilter "(pager -lt 4) -and (pager -like '*') -and (RecipientType -eq 'UserMailbox')"
Появляется в EMC со следующим:
((((((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')))
В этой группе должно быть максимум 3 участника, верно? Нет - я получаю тонну из-за сравнения строк. Я прихожу, и я нахожусь в диапазоне 3000.
Вопрос: Кто-нибудь знает умный способ заставить это быть целочисленной проверкой?
Фильтр LDAP только для чтения в этой группе выглядит неплохо, но, конечно, его нельзя редактировать.
Представление LDAP (смотрите ма, без кавычек на 4!) - Также интересно, что это как бы `` заполняет '' кровать предметом (pager = 4) ...
(&(pager<=4)(!(pager=4))(pager=*)(objectClass=user)(objectCategory=person)(mailNickname=*)(msExchHomeServerName=*)(!(name=SystemMailbox{*))(!(name=CAS_{*))!(msExchRecipientTypeDetails=16777216))(!(msExchRecipientTypeDetails=536870912))(!(msExchRecipientTypeDetails=8388608)))
Если решения нет, я полагаю, что я либо ищу неиспользуемое поле, которое фактически будет рассматриваться как целое число, либо, скорее всего, строю этот список с помощью PowerShell каждое утро с моей собственной автоматизацией - хромой.
Я знаю несколько способов исправить это вне фильтра opath (обозначьте "полный рабочий день" в другом поле и т. д.), но предпочел бы обменять на подъем, поскольку это среда в данный момент.
Любое понимание было бы здорово - спасибо!
Мэтт
Говорил с Microsoft.
"Вы правы в причинах, по которым не работает пейджер, как и номер телефона. Это строка в Юникоде. Чтобы созданный нами фильтр работал правильно, он должен быть большим целым числом, печальная часть атрибутов больших целых чисел, доступных для пользователей, заключается в том, что они в основном это системные атрибуты, например (uSNCreated изменен и т. д.). Я пробовал это заяц в своей лабораторной среде, но похоже, что он не работает должным образом, я думаю, нам нужно будет искать другие варианты ».
Итак, на данный момент с Exchange 2010 SP1, похоже, вы не можете проводить целочисленное сравнение с чем-либо, кроме нескольких ключевых системных атрибутов (IssueWarningQuota, MaxReceiveSize). Все остальное будет рассматриваться как сравнение строк.
Другие варианты, предложенные службой поддержки, заключались в том, чтобы надеяться, что они находятся в одном магазине Exchange, в конкретном подразделении или в каких-то других критериях. Поскольку они не будут работать в нашей среде, мне придется создавать эти DL через Powershell.