Exchange Server 2013 – первая установка


 

Нет, это не пошаговое руководство. Это заметки для тех, кто готовится к первой установке Exchange Server 2013.

Читать далее

Реклама

Перенос очередей печати и фильтрация журнала событий


На днях занимался переносом очередей печати на новый сервер печати. Удобная все же штука Group Policy Preferences – создавать и удалять подключения к очередям печати можно легко и просто для десятков пользователей.

Кроме настроек политик, надо еще убедиться, что пользователи успешно переключились на новый сервер. Лазить по всем компьютерам бессмысленно. Для контроля у нас есть журналы событий на сервере. И тут есть нюансы.

Читать далее

Добавление прав администраторам на перемещаемые профили


 

Проблема: На ферме терминальных серверов с помощью политик GPO настроили перемещаемые профили, но не активировали политику «Add the Administrators security group to roaming user profiles». Когда профилей было создано уже немало, и потребовалось кое-что в них почистить, оказалось, что администраторы не могут этого сделать – нет прав.

Как же исправить ситуацию?

Сначала, конечно же, надо активировать вышеупомянутую  политику, чтобы все новые профили создавались с нужными правами.

Теперь исправляем права на уже созданных папках профилей.

По умолчанию на папку профиля пользователя полные права имеет учетная запись самого пользователя и учетная запись системы. Таким образом, если выполнить скрипт с правами системы, то можно одним махом выставить нужные права. Сделать это можно, создав задачу Scheduled Task:

  1. Идем на файловый сервер, где хранятся папки с профилями
  2. Создаем задачу Scheduled Task
  3. Триггер любой, т.к. мы все равно выполняем задачу один раз, запуская ее вручную
  4. Действие задаем – выполнить программу icacls с параметрами «E:\ProfilePath\*» /grant «Administrators:(F)» /T
  5. В качестве пользователя от имени которого будет выполняться задача указываем SYSTEM
  6. Запускаем задачу на выполнение и ждем ее окончания

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

Не которые побочные эффекты установки 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.