Не которые побочные эффекты установки Windows Management Framework 3.0

Проблема: после установки WMF 3 на сервер Windows Server 2008 R2, где работает Forefront Identity Manager 2010 R2, в один прекрасный момент выяснилось, что не работает скрипт на VBScript, который выполняется по шедулеру, обращается к FIM и запускает агенты синхронизации.

(Такой скрипт можно сгенерировать средствами оснастки управления FIM и доработать ручками под конкретные условия.)

Проверка показала, что задания запускаются исправно и… зависают, при этом синхронизация не выполняется.

После ручного запуска скрипта из командной строки, он выдал ошибку с кодом  0x8004100E, которая говорит о том, что происходит ошибка обращения к WMI. Ручные проверки с помощью wbemtest и Powershell показали, что пространство имен root\MicrosoftIdentityIntegrationServer не существует. Собственно эти факты и заставили задуматься, что же такое делали на сервере, что изменились настройки WMI – и ответ был: установка WMF 3, который, как известно, добавляет в WMI новые возможности и, как следствие, вызывает перестроение базы MOF.

Небольшие изыскания помогли найти решение:

1.       Запускаем командную строку с повышенными правами

2.      Переходим в директорию C:\Program Files\Microsoft Forefront Identity Manager\2010\Synchronization Service\Bin

3.      Выполняем команду:

mofcomp mmswmi.mof

При этом на экран было выдано сообщение:

WARNING: File mmswmi.mof does not contain #PRAGMA AUTORECOVER.

If the WMI repository is rebuilt in the future, the contents of this MOF file wi

ll not be included in the new WMI repository.

To include this MOF file when the WMI Repository is automatically reconstructed,

 place the #PRAGMA AUTORECOVER statement on the first line of the MOF file.

Это собственно и объясняет, почему перестроение WMI, вызванное установкой WMF 3, привело к удалению пространства имен FIM.

После компиляции mmswmi.mof все скрипты запустились успешно и синхронизация заработала.

Вполне возможно, что установка WMF 3 может оказать такой же эффект на другие продукты использующие/предоставляющие WMI. Теперь вы знаете, как найти решение.

Дополнение (10/31/2012)

Оказывается теперь периодически запускается процесс перекомпиляции репозитория WMI, что приводит к потере пространства имен FIM. Нужно добавить mof файл в список файлов, которые перекомпилируются автоматически. Делается это командой:

mofcomp  -Autorecover mmswmi.mof

Либо можно добавить в файл #PRAGMA AUTORECOVER

 

Немного статистики о Sender Id

 Update: Немного статистики о Sender Id спустя три года

В настройках Exchange Server можно включить фильтр по Sender Id и указать, что делать с письмом, которое не прошло проверку: удалить молча,  удалить с отправкой NDR, принять письмо с пометкой.

Сразу хочется спросить: насколько Sender Id эффективно работает? Но такая постановка вопроса не конструктивна: анализ всего почтового трафика слишком трудоемкий, а практическая ценность результата фактически нулевая.

Можно спросить по-другому: если включить фильтр Sender Id, то сколько полезных писем мы можем потерять? Может показаться странным, но точный ответ не так просто найти.

Поэтому я сформулирую вопрос более хитро: насколько Sender Id широко используется среди тех, кто нам отправляет почту?

Вот это уже конструктивно и в смысле поиска ответа, и в смысле использования результата.

Суть заключается в том, что мы берем всю (или часть) полученной полезной почты после фильтрации спама и проверяем у отправителей Sender Id.

1.       Идем на пограничный сервер

2.       Берем для анализа журналы MessageTrackingLog

3.       Берем только записи о получении сообщения (в них информация об IP адресе отправителя), только на коннекторе приема почты из Интернета и только те, которые реально отправлены на внутренние серверы:

 $a1=Get-MessageTrackingLog -EventId «RECEIVE» -ResultSize Unlimited | ? { $_.ConnectorId -like «*From Inet*»} | ? { Get-MessageTrackingLog -MessageId $_.MessageId -EventId «SEND»}

 

 

4.       Убираем тех «хорошо известных» нам отправителей, которые скорее всего у нас в белых списках: «соседи», партнеры и т.п. – нас интересуют только отправители, которые пришли из недр Интернета:

 $b1= $a1 | ? {$_.ClientHostname  -notlike «mail2.ufamts.ru»}

 

5.       Для каждого отправителя берем его адрес и имя почтового домена:

  $Senders=@{}

 

$b1 | % { $Senders[$_.ClientIp]=($_.Sender -split ‘@’)[1] }

 

6.       Выполняем проверку каждого у отправителя Sender Id:

$c1= $Senders.GetEnumerator()  | % {

 

$res = Test-SenderId -IPAddress $_.Key -PurportedResponsibleDomain $_.Value

$obj = new-object psobject -Property @{ClientIp=$_.Key; ResponsibleDomain=$_.Value; Res=$res.Status }

$obj

 

}

 

 

7.       Подсчитываем результаты:

 $c2=$c1 | Group-Object Res

 

8.       Переводим в проценты:

 $c2 | % {  «{0,-10} — {1:p}» -f $_.Name, $($_.Count/$c1.Count) }

 

None       — 49.54 %

Pass       — 41.65 %

Neutral    — 1.97 %

SoftFail   — 3.02 %

Fail       — 2.78 %

PermError  — 0.70 %

TempError  — 0.35 %

 

Как видите, среди моих корреспондентов около 42% настроили для своих почтовых серверов записи SPF (результат — Pass), около 50% не имеют SPF записей вообще (результат — None), а остальные 8% имеют проблемы с настройками SPF записей.

Выводы можете сделать сами.

Мне же лично, как оптимисту, нравится, что 50% легитимных отправителей заботятся обо мне или хотя бы пытаются настроить SPF записи. Что касается остальных, то рано или поздно жизнь их тоже заставит следовать правилам хорошего тона.

PS: Если вы собрали свою статистику, то можете опубликовать ее в комментариях к этой статье или в своем блоге, а здесь разместить ссылку.

 

Совместимость скриптов Powershell V3 и Powershell V2

 

После появления Windows Management Framework 3.0, который включает в себя Powershell V3, многие скорее всего уже поставили его на свои компьютеры и начали использовать новые возможности. А с выходом Windows Server 2012 RTM установка WMF 3.0 на более ранние версии ОС стала еще более актуальной, т.к. новый Server Manager позволяет управлять удаленными системами только при наличии на них WMF 3.0.

На днях столкнулся с проблемой: после установки WMF 3.0 на сервер с Sharepoint Server 2010 перестал работать скрипт, который я описывал с статье  Sharepoint – пусть бегут неуклюжи. Причину рассказал сам скрипт:

Get-SPWeb : Microsoft SharePoint is not supported with version 4.0.30319.269 of the Microsoft .Net Runtime.

 

Действительно Sharepoint Server 2010 работает исключительно на .Net Framework 2.0 и Powershell 2.0.

С счастью удалять WMF 3.0 не пришлось. Решение простое: в Диспетчере задач открываем параметры задачи, которая запускает наш скрипт, и в параметрах запуска Powershell.exe указываем параметр –Version 2.

>Powershell.exe   –Version 2

После этого скрипт работает!

К сведению.

Установка .Net Framework 4.0, WMF 3.0 и Powershell V3 не удаляет Powershell V2: прежний движок сохраняется для обратной совместимости скриптов. (Как сказано где-то в блоге разработчиков: совместимость почти полная).

Дело в том, что скрипты Powershell V2 откомпилированы на CLR 2.0, скрипты Powershell V3 на CLR 3.0, и, таким образом, они абсолютно не совместимы на бинарном уровне. Указание параметра –Version 2 позволяет нам запустить выполнение скрипта в правильной версии Powershell.