Загрузка / выгрузка списка фильтруемых отправителей в Exchange 2003
В посте “Sender whitelist (белый список) отправителей для Exchange 2003” описывал, как можно использовать возможности MS Exchange 2003 по фильтрации отправителей по адресу (чёрный список) в качестве списка надёжных отправителей (в качестве белого списка). Обещал привести скрипт по закгрузке / выгрузке этого списка средствами powershell. Исполняю обещание.
Слева видим интересующие нас параметры в AD. Сам список сохранён в параметре msExchTurfListNames, опции (галки, которые мы видим в окне Message Delivery Properties) – msExchTurfListOptions. Соответственно, можно и установить “галки” через это параметр.
Итак, нам необходимо прочитать msExchTurfListNames для объекта CN=Default Message Filter,CN=Message Delivery,CN=Global Settings,CN=NovGARO,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=novgaro,DC=ru (в моём случае). Решение на vbs можно подглядеть здесь:
Для ldifde:
Для Exchange 2007 существуют командлеты типа Set-SenderFilterConfig.
А для Exchange 2003 приведу решение на powershell:
$exchSenderFilterConfig = [ADSI]"LDAP://CN=Default Message Filter,CN=Message Delivery,CN=Global Settings,CN=NovGARO,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=novgaro,DC=ru" $exchSenderFilterConfig.msExchTurfListNames | %{ ";адрес:<$($_)>;"} $exchSenderFilterConfig.msExchTurfListOptions
Вот так вот всё просто. Теперь загрузим этот список из текстового файла. В моём случае в исходном файле имеют место быть и адреса, и домены. Домены начинаются с @. Преобразуем загруженный список в формат, подразумеваемый msExchTurfListNames:
switch -wildcard ($controlDomains) { "@*" { "*$($_)" } default { "$_" } }
Итого, сценарий загрузки:
$exchSenderFilterConfig = [ADSI]"LDAP://CN=Default Message Filter,CN=Message Delivery,CN=Global Settings,CN=NovGARO,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=novgaro,DC=ru" $exchSenderFilterConfig.msExchTurfListNames = get-content -path $controlDomainsFilePath | ? {$_} | %{ switch -wildcard ($_) { ` "@*" { "*$($_)" } ` default { "$_&" } ` } $exchSenderFilterConfig.SetInfo()
Ранее я публиковал сценарий, в том числе проверяющий по журналам входящие сессии от “контрольных” контрагентов. Теперь загрузку контрольных контрагентов изменим – загрузим из AD:
# загрузим контрольный список шаблонов адресов # $controlDomains = get-content -path $controlDomainsFilePath $controlDomains = ([ADSI]"LDAP://CN=Default Message Filter,CN=Message Delivery,CN=Global Settings,CN=NovGARO,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=novgaro,DC=ru").msExchTurfListNames ` | ? {$_} | %{ switch -regex ($_) { ` "^\*(@.*)" { "$($matches[1])" } ` default { "$_" } ` } }
На этом – всё.
Отзывы » (10)
RSS комментарии
Обратная ссылка
Сергей, рассказали мне про ваш блог. Сейчас почитаю
Только начал, по сути. Постараюсь писать о том, что может пригодиться или показаться интересным. Буду благодарен комментариям и замечаниям.
На мой взгляд, публикация 1с 7.7 уже давно не актуально. А так всё отлично, буду ждать новых постов
Чистая правда. Беда только в том, что мы ещё длительное время будем использовать эту платформу. Как минимум — для существующих баз. А посему и о публикации необходимо думать.
Я думаю, многие вынуждены предоставлять возможность своим бухгалтерам хотя «на просмотр» использовать старые (на базе 7.7) базы. Возможно — в этом и пригодится предложенный рецепт.
Да и 21 веке распространение приложений посредством GP на мой взгляд моветон. Все эти загрузки /перезагрузки, сборка msi пакетов своими руками — далеко не для слабонервных.
Отчасти согласен, но лишь — отчасти. Поясню:
- действительно, есть более гибкие средства (SMS …). Однако — они далеко не бесплатны. Для использования же GPO + MSI достаточно лицензии на Windows Server, на WIndows и CAL к Windows Server.
- даже более мощные средства никоим образом не решат проблему создания / восстановления профиля приложения в профиле пользователя, если мы говорим о многопользовательской рабочей станции. Другими словами, использование более мощных средств развёртывания всё-равно подразумевает msi (другой подобной технологии для windows я не знаю просто).
Итого — мы можем говорить о замене GPO для публикации приложений, но не MSI. А самое сложное, как раз, подготовить MSI.
Посему позиционирую GPO + MSI как бюджетное и БАЗОВОЕ решение для публикации приложений. И реальная альтернатива одна — виртуализация (технологии аля MS SoftGrid). Но это решение не повсеместно применимо (а мобильные пользователи или графические приложения?), да и по стоимости оно не сравнится с GPO+MSI (один CAL на терминал чего будет стоить…)
P.S. Дмитрий, у нас почему-то комментарии к посту о публикации 1С размещены в записи о белом списке для Exchange Server
Замены msi безусловно нет. Радует одно, что почти весь вменяемый софт уже давно отвечает требованиям windows logo и идет с нормальным инсталятором.
Если говорить про платные решения такие как system center, то скорее всего они себя окупят. Хотя далеко не всем нужен.
Еще как вариант: использовать сервер терминалов. Да нужны терминальные CAL’ы. зато гораздо проще и дешевле поддерживать такое решение. + можно вообще отказаться от windows рабочих станций и тем самым существенно съэкономить.
Абсолютно согласен, виртуализация — это и прошлое, и будущее. Однако, есть продукты, для которых виртуализация неприменима (средства 3D разработки, дизайна и так далее). Безусловно, 90% «офисных» станций можно убить (и цель такая стоит, если честно). Но 10% всё равно останутся, и их так или иначе следует обслуживать. А ради них System Center — это из пушки по ворьям стрелять. Посему у GPO+MSI есть своя небольшая такая ниша.
>>средства 3D разработки, дизайна и так далее
RemoteFX будет с sp1 и должен решить эту проблему.
Почитаю… Но в этом случае тонкий клиент уже будет не таким «тонким»…, хотя с точки зрения администрирования всё-равно будет проще. Остаётся один скользкий момент: указанные виды приложений и процессор грузят неплохо…