четверг, 31 июля 2014 г.

Time Synchronization and Domain Controller and NTP

Не надеясь на уникальность собственных действий, напишу еще одну статью про убежавшее время в домене.

В результате манипуляций с авторитетным сервером времени в организации N, сторонними лицами, время убежало на час вперед (по ошибке). Обнаружилось это день спустя, когда все контроллеры домена,  серверы и рабочие станции показывали уже неправильное время и поступали жалобы от пользователей.

Cхема синхронизации времени выглядела следующей:




Рабочие станции и серверы в составе домена –> контроллеры домена PDC –> сервер времени NTP.
В зависимости, используется ли виртуализация, то в некоторых случаях время синхронизируется с хостом виртуализации, на котором работают виртуальные машины. Проверить и выключить такую синхронизацию можно по этой инструкции. http://www.sole.dk/how-to-configure-your-virtual-domain-controllers-and-avoid-simple-mistakes-with-resulting-big-problems/

Необходимо настроить и проверить авторитетный источник сервер времени (NTP server) 

Восстановление:

1. Восстановление времени на NTP сервере
2. На PDC серверах 
3. На серверах в составе домена

w32tm /resync /rediscover /nowait

И далее по цепочке синхронизируются остальные DC + дочерние PDC (если имеются)и остальные члены домена. Для мониторинга и отслеживания ошибок используем дополнительные параметры:

w32tm /monitor 
w32tm /stripchart /computer:<targetPCname>



пятница, 30 мая 2014 г.

Moving Exchange 2003 mailboxes to new forest


Постановка проблемы:

Как известно, Exchange 2003 не поддерживает сосуществование двух организаций и процесс переезда ящиков между организациями Exchange.



В статье рассматриваются нюансы переподключения старых почтовых ящиков к новым учетным записям в новом лесу.

Немного теории:

Если появляется необходимость слияния двух лесов AD, то для решения можно использовать специальные утилиты миграции содержимого пользовательских ящиков, Как например Exmerge утилиту. Предлагаемые решения при слиянии организаций заключаются в сохранении и переносе учетных записей в новый лес, и разворачивании новой Exchange организации с нуля. Выглядит это так:
  •        Перенос учетных записей пользователей в новый с SID history в новый лес Active Directory
  •        Разворачивании новой Exchange 2003 организации с пустыми ящиками
  •        Экспортом старых ящиков с помощью ExMerge в PST файлы Outlook и перенос фалов в новый лес
  •        Импорт содержимого PST файлов с помощью ExMerge в новые почтовые ящики в новом лесу

Схема является стандартной, если новый лес действительно является новым, и ранее не содержал пользователей. Новые учетные записи образуются путем миграции из старого леса с SID history.

Но рассмотрим ситуацию, что существуют два леса AD в одной организации достаточно долго не связанные доверительными отношениями (они физически изолированы) развивались параллельно и обслуживают в реальности одних и тех же сотрудников.  При этом пользователи данной компании имеют персональные учетные записи в обоих лесах. Получается, что сотрудник Иванов Иван в лесу  Forest1 имеет учетку ivanov@forest1.local и в то же время имеет свою же учетную запись в лесу Forest00-iivanov@forest2.local Данные учетные записи не являются одинаковыми, поскольку атрибуты samscountname и SID будут принципиально разные. Но эти две учетки являются идентификацией одного и тоже человека в реальности.  И в этом следующая проблема. Exmerge в данном случае не сможет сделать автоматический импорт ящиков в новый лес.

В этом случае возникает вопрос об управлении учетными данными (IdM) и синхронизации объектов разных служб каталогов. Но это другие дебри и программные продукты, которые могут обеспечить такую функциональность на этапе слияния двух лесов внутри одной организации. Это Forefront Identity Manager. Вопрос о приобретении FIM для миграции устаревшей версии Exchange 2003, к тому же снятой с поддержки в апреле 2014, звучит как-то необоснованно.  И почему возникает необходимость поддержки Exchange 2003 с истекшим жизненным циклом для заказчика, я предлагаю опустить.

Решение:

Ввиду отсутствия денег на проект миграции решение следует максимально упростить. Метод заключается в переезде файлов почтовой базы Exchange 2003 в новую организацию Exchange. И далее монтирование этой базы на новом Exchange сервере в новом лесу.

Проверяем функциональность Exchange 2003 в исходном лесу. База содержит ящики и письма пользователей.



Размонтируем базу во время окна обслуживания сервера.


Проверяем целостность базы утилитой eseutil /mh. Проверяем состояние - Clean Shutdown



Копируем файлы базы STM и EBD на новый сервер EX03 в новом лесу. Продолжительность операции зависит от объема передаваемых данных скорости сетевых подключений и  других факторов.


В исходном лесу все работы завершены. 

В новом лесу, подключаем только что перенесенную  базу. Я использовал старые пути и буквы дисков. Получаем сообщение при попытке ее смонтировать:


В свойствах базы отмечаем галку, что бака восстановлена из бекапа. Так как в AD информация о базе отсутствует или устаревшая. 


После этого база успешно монтируется.



Давайте откроем список почтовых ящиков. Мы видим, что ящики переехали в новый лес. Но радоваться пока рано. Отображаются старые пользователи. 


Для обновления информации из AD запустим Mailbox Cleanup Agent. Агент обновляет информацию об отключенных ящиках. Входит в задачи обслуживания почтового сервера. Подробности можно узнать тут http://support.microsoft.com/kb/324358
Мы же в данном случае запустим его принудительно. 
Exchange System Manager - Servers - First Storage Group - Mailbox Store - Maiboxes - ПКМ - Reconnect


После указанной процедуры все перенесенные ящики окажутся отключенными. Дело в том, что в лесу forest2.local у пользователей Active Directory еще нет Exchange атрибутов, таких как msExchMailboxGuid. Так вот картина будет следующая, все перенесенные  почтовые ящики станут отключенными. 


Теперь нам надо просто подключить старый ящик к новому идентичному пользователю.
Тем самым сделать новые Exchange атрибуты на новый пользователей в AD. ПКМ по ящику - reconnect mailbox


Из AD выбираются идентичные пользователи. Но это не значит что нельзя подключить ящик совсем другому сотруднику. Просто наша цель подключить ящик идентифицированный с конкретным человеком исходя из его ФИО и атрибутов AD Displayname в новом леcу forest2.local. Ищем в AD соответствующего сотрудника:


Ящик подключен к новому пользователю AD. А в реальности - к прежнему сотруднику. Осталась маленькая деталь. Восстановить значение атрибута mail. Без него невозможно залогиниться на OWA.


Итак теперь нам предстоит проверить доступ к этому ящику через OWA. В лесу forest2.local обращаемся к Outlook Web Access через браузер по пути:

http://EX03.forest2.local/Exchange  где EX03 - имя нового сервера Exchange 2003



Как видим ящик успешно подключен.

Выводы:

В статье  рассмотрен недокументированный способ переезда ящиков разработанный лично мной. Осуществлен переезд постовой базы в новую Exchange организацию. Ящик подключен новому пользователю ручным способом. 

Утилиты ADMT и Exmerge в данном случае использовать было нельзя, так как ADMT не копирует Exchange атрибуты, а Exmerge необходимо сохранение SID history ADMT. К тому же миграции лесов AD не происходило и не планировалось. 

Остается открытым вопрос автоматизации с помощью Powershell подключения сразу множества ящиков к новым пользователям в новом лесу. Исследования показали, что для успешного подключения ящиков необходимо восстановить атрибуты пользователя в AD, конкретно:
  • DispayName
  • msExchMailboxGuid
  • mail
Экспортировать эти данные из старого леса не составит проблем с помощью PowerShell. Далее подкорректировав название почтового домена эти атрибуты добавить идентичным по Displayname пользователям нового домена с помощью скрипта.

Об автоматизированном переподключении ящиков - в следующей части статьи.





понедельник, 5 мая 2014 г.

How To Permanently Delete Disconnected Mailbox in Exchange 2013 Database with bypass Retention Policy

Поводом к поиску решения послужило обращение друга-коллеги. Вопрос был следующим:

"Есть ли возможность безвозвратного удаления не нужного почтового ящика из базы ручками? Я знаю,что оно после того как нажато в консольке\шеле - удалить, валится в первую корзину, где живет н-ное количество времени, потом оттуда во вторую, где живет стока же и потом ещё и в третью (если включена). Ситуация следующая. я создал две учетки с почтой, потом один юзер на работу не вышел, но я удалил не ту учетку. пришлось создать её заного (старый ящик в базе так и остался болтаться, как ты понимаешь, с тем же алиасом, но типа оно отключено и не юзается). по факту экчендж запутался, он часть писем (те, что идут рассылкой по группам)  валит куда надо. а те, что отправляются из адресной книги валятся в никуда (вернее на тот, отключенный ящик, который сообщает - адрес не найден)"

А решение подсказано технетом тут http://technet.microsoft.com/en-us/library/jj863440(v=exchg.150).aspx

Допустим, что у Нас есть Default MRM Policy по умолчанию для баз почтовых ящиков.

Get-MailboxDatabase | fl name, *retention*



И допустим, что у нас есть два пользователя user1 и user2. Удостоверимся с помощью вывода Get-Mailbox






В оснастке ECP (Exchange Control Panel) удаляем ящик пользователя User1 несколько раз, дабы собрать набор отключенных ящиков в почтовой базе за некоторое время.





Ищем в базе удаленные ящики со статусом DisconnectReason -eq "Disabled". 




Точнее нам нужно вынуть GUID отключенных или удаленных ящиков пользователя User1 в базе. Делаем это так:

Get-MailboxDatabase | Get-MailboxStatistics | where {$_.disconnectreason -ne $null} | fl displayname, mailboxguid, database, disconnectreason



Затем по нужному GUID удаляем ящик командой Remove-StoreMailbox

Remove-StoreMailbox -Database "Mailbox Database 0373441201" -Identity "a4832eb0-d1e5-4f34-ae86-8e397f61a421" -MailboxState disabled



На этом выбранные ящики вычищены из базы. 
Проверка:

Get-MailboxDatabase | Get-MailboxStatistics | where {$_.disconnectreason -ne $null} | fl displa
yname, mailboxguid, database, disconnectreason

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



Вот так обходится политика Default MRM Policy :)

вторник, 8 апреля 2014 г.

Значимый день - окончание технической поддержки Windows XP и Exchange Server 2003



8 апреля 2014 года. 

Этот значимый день уже вошел в историю. И сегодня именно этой ночью, компанией Microsoft завершится техническая поддержка Windows XP и выпуск обновлений безопасности, которые повышают защиту компьютера. Операционная система просуществовала более 13-ти лет и оказалась самой рентабельной и востребованной ОС среди корпоративных пользователей. 

На фото - моя виртуальная машина с последним экземпляром этой ОС, которая еще помнит  мой дипломный проект в программе FuzzyLogic.

Моя ИТ карьера, которая началась 10 лет назад, связана с использованием Windows XP и первым опытом сертификации MCP именно по этой ОС. В 2009 году я получил статус  MCP, что в итоге явилось отправной точкой для дальнейшего обучения и становления своей карьеры.  

Кстати говоря,  не менее значимый продукт, срок поддержки которого заканчивается сегодня это Exchange Server 2003 SP2.

Проверить жизненный цикл остальных продуктов Microsoft можно по ссылке:

Провожаю Windows XP c пафосом: Прощай Windows XP! Прощай IE 6!

И я, по данному случаю, выпью стаканчик особой вишневой медовухи, который я специально подготовил заранее J



   

среда, 5 марта 2014 г.

Get-Eventlog Get-LogonHistory.ps1 script

Качественно сделанная сложная задача приносит удовлетворение, вызывает чувство гордости. Это один из мощнейших мотиваторов. Если вы, конечно, внесли в нее значительный вклад.

Скрипт делает удаленную выборку событий журналов Eventlog security на предмет  последних интерактивных входов  пользователей в ОС Windows.
Скрипт решает несколько задач:
  • Автоматическое определение версии  и локализации ОС, Get-Wmi-Object  вследствие выполняются четыре различные функции
  • Ввод компьютеров с консоли пользователя либо опрос файла со списком компьютеров с которых нужно собрать информацию
  • Сбор информации из Eventlog Security за несколько последних дней. История входа пользователей.
  • Сбор данных о пользователях из Active Directory Get-Aduser mail, telephonenumber
  • Вывод требуемой информации в файл формата CSV  для последующей обработке в Excel со столбцами
Скачать мой скрипт можно отсюда:

Спасибо человеку с Github -  Craig Meinschein https://github.com/pfaffle за предоставленную наработку. Его скрипт был взят за основу и дописан мною под требования заказчика.

А задача была следующая:
Определение  для виртуальных Windows-машин неизвестного назначения 5-ти последних профилей пользователей AD, которые регистрировались  в операционной системе. Далее, опираясь на эту информацию, подготовить таблицу следующего содержания:

- Пользователь AD (по профилю);
- Список ОС виртуальных машин, на которых он регистрировался;
- Контакты пользователя из AD (email, телефон)
*** одна строка: 1 пользователь, 1 ВМ на которой он логинился, контакты пользователя в каждой строке. (для последующей сортировки в Excel)

Мне много пришлось потрудиться. Я потратил на скрипт неприличное количество часов и даже купил книжку по powershell. 

Мне очень понравилась задумка с функциями, которые предназначены для разных ОС учитывая разные номера EventID.  Функции выполняются на основе выбора оператором ветвления If() .. else if ().. и определению типа операционной системы Windows Server 2003 или Windows Server  2008.

Коды event ID с выходом Windows Server 2008 изменились. Коды событий взяты из замечательных справочников :

Давайте разберем понятия интерактивных входов в систему консоль entrytype=2 entrytype=10
Следует понимать, где следует собирать информацию о входах. Существует ошибочное мнение тех, кто готовился к экзаменам по сертификации МС, что информацию о входах пользователей надо искать на контроллерах домена. Но там будут только события сетевых входов entrytype=3. Это данные аутентификации пользователя в домене. 
Что мы понимаем под логином пользователя? сетевой вход, обращение к сетевой папке, вход компьютера, запрос билета керберос. Я провел тесты и обнаруживаю, что интересующие нас интерактивные входы контроллер не регистрирует. А значит их следует искать в локальных файлах журналов Eventlog Security куда непосредсвенно входил пользовтель по RDP  entrytype=10 и в консоль entrytype=2 (по нажатию ctrl + alt + delete).

Еntry type=2 — Interactive. Успешный вход пользователя на компьютер.
Entry type=10 — RemoteInteractive. Пользователь выполнил удаленный вход на этот компьютер, используя Terminal Services или Remote Desktop.

Информация по типам входа есть тут:

Более того, события в журнал пишутся на языке локализации ОС. Это значит, что будут разные записи в журнале смысл которых одинаков, а парсинг надо написать для каждого языка свой.
Пример:
"Entry type" = "Тип входа"
Для русской локазизации ОС пришлось написать еще две функции.

вторник, 21 января 2014 г.

How to monitor Text and CSV log files in SCOM

Имеется задача. Выявить, состоит ли белый ип адрес почтового сервера в DNS BL?

DNS Block List - DNS blacklist или DNS blocklist — списки хостов, хранимые с использованием системы архитектуры DNS. Обычно используются для борьбы со спамом. Почтовый сервер обращается к DNSBL, и проверяет в нём наличие IP-адреса клиента, с которого он принимает сообщение. При положительном ответе считается, что происходит попытка приёма спам-сообщения. Серверу отправителя сообщается ошибка 5xx (неустранимая ошибка) и сообщение не принимается. Почтовый сервер отправителя создаёт «отказную квитанцию» (NDR) отправителю о недоставке почты.

Попробуем с помощью System Center Operations Manager заполучить эту  «отказную квитанцию» и вывести на консоль оператора в виде алерта.

Нам потребуются:

SMTPDIAG консольная утилита с параметрами, которая позволяет получать коды ответы SMTP сервера по принципу как если бы мы подключались через telnet <host> 25, но с некоторыми возможностями автоматизации. Вывод этой утилиты мы запишем в текстовый файл. С файлом будет как раз работать SCOM, обрабатывать его новые строки и вынимать интересующую нас информацию. 
  1.  Создание лог-файла
  2. Создание правила в SCOM
  3. Вывод Алерта

вторник, 14 января 2014 г.

How to Integrate Operations Manager with VMM 2008 R2

Самое простое, что я мог бы предпринять, чтобы изменить мир к лучшему  -  это написать еще одну статью про интеграцию SCOM c VMM. А что если инфраструктура AD не совсем типична? И если у заказчика  имеется несколько лесов Active Directory. Какие сложности нас могут ожидать?

Рассматриваем схему, где используются два леса AD уже соединенные двусторонними доверительными отношениями.


Forest1.local - лес с пользователями, компьютерами, объектами мониторинга
Forest2.local - лес ресурсов, лес виртуализации
SCOM-1 - domain controller, SCOM Root Managenent Server
VMM-1 - domain controller, VMM Server

Все это собиралось на тестовом стенде, с целью исследовать интеграцию продуктов SCOM и VMM в разных лесах Active Directory.