Наибольшим промахом своего предшественника я счел выбор GlusterFS. Для ядра linux существует модуль DRBD (Distributed Replicated Block Device), позволяющий создавать на машинах блочные устройства для репликации их по сети между распределенными узлами, который я и выбрал для решения поставленных целей. Для ОС Solaris, кстати, существует аналогичный DRBD проект Sun StorageTek Availability Suite. Для FreeBSD аналогов не существует, что не удивляет.

В качестве ОС было решено использовать SUSE Linux Enterprise Server 11 + дополнение High Availability Extention. SUSE поддерживается компанией Novell, включает в себя удобные утилиты конфигурирования и регулярно обновляется. А дополнение SLES-HA представляет собой набор ПО, организующего кластерные отношения между узлами, основанное на связке проектов Linux-HA и ClusterLabs. Другими словами – cluster membership service, графические утилиты настройки этих сервисов, утилиты для поддержки кластерных файловых систем и прочее. Хочу отметить что графические утилиты в ОС Linux по-прежнему остаются сыроваты, имеют очень ограниченный функционал и могут вызвать проблемы несовместимости. Пользоваться ими лучше аккуратно.

Итак, вышеописанное программное обеспечение было установлено на оба узла, поверх RAID-массивов. По значительному разделу было выделено под drbd-устройства, располагающиеся поверх логических томов LVM, позволяющих в будущем удобно менять размеры виртуальных машин. Загрузчик GRUB настроен на запуск по умолчанию ядра с поддержкой Xen. Все 4 сетевых интерфейса было решено агрегировать с помощью технологии linux bonding в 5 режиме адаптивной передачи нагрузки. В сети предприятия активно используются VLAN’ы, потому трафик на выходе кластера должен быть тэггированым по протоколу 802.1q, поддержка которого осуществляется модулем ядра Linux. Каждая виртуальная машина с помощью моста подключается к нужному VLAN’у. При выходе из строя 3 из 4 сетевых интерфейсов, вся система продолжает работать, но на скорости до 1 гигабита =)

С настройками DRBD все достаточно просто, единственное – рекомендовано не использовать внутренние meta-диски, особенно если в будущем понадобиться менять размеры устройств.

Теперь все готово для настройки самого кластера, которую можно разделить на 2 этапа: настройка основных компонент (OpenAIS + Pacemaker) и настройка ресурс-агентов кластера, непосредственно управляющих нашими сервисами.

При настройке OpenAIS и Pacemaker нужно учитывать что в 2х-узловой конфигурации не нужно использовать quorum.

Для нашего случая, в котором кластер следит за виртуальными машинами, для каждой из них необходимо настроить следующие ресурсы:

1. управляющие устройствами DRBD (один примитивный и один master/slave)
2. управляюший монтированием файловой системы
3. управляющий доменом Xen

После чего объединить их в группы и задать параметры order и colocation, объясняющие кластеру в какой последовательности запускать ресурсы.

На этом настройка кластера заканчивается. Используя продукты VMWare или Citrix осуществить эту задачу конечно легче и удобней, тк о многих вещах просто не приходится задумываться, но вместе с лицензией на ПО вам придется приобрести внешнюю СХД. Ни в ESX ни в XenServer нет поддержки репликации разделов между узлами, не смотря на то что построены они на базе того же ядра Linux с использованием утилит, разработанных в рамках проекта GNU.

PS. Недавно, на конференции «Russian Open Source Forum 2010», IT-директор АВТОВАЗа рассказывал про организацию инфраструктуры их головного офиса – все сервисы предоставлены почти таким же кластером, только с внешней СХД и другим дитстрибутивом GNU/Linux.

Например, если зайти в окно библиотеки документов, и выбрать пункт «Создать документ», а затем попытаться сохранить его, то откроется следующее окно:

Место сохранения по умолчанию будет выбрано – папка «Мои документы». В списке папок слева не будут показаны билбиотеки SharePoint, и при попытке ручного ввода адреса http://шарепойнт/имя_библиотеки/ отображаться библиотека также не будет, а выведется следующее окно:

При этом, если открыть существующий документ из SharePoint и сохранить его, либо указать в имени файла полный путь с именем – например, http://шарепойнт/имя_библиотеки/файл.docx, то сохранение произойдет. То есть, имеется проблема с отображением web-папок.

Решение: нужно выполнить следующих два шага:

Скачать и установить обновление Microsoft для web-папок по адресу http://www.microsoft.com/downloads/details.aspx?displaylang=ru&FamilyID=17c36612-632e-4c04-9382-987622ed1d64 (ссылка дана для русского Office, в случае других языков необходимо выбрать нужный). Не обращайте внимания, что в списке предназначенных операционных систем указаны только Windows XP и Windows 2003 – именно это обновление и нужно устанавливать на Windows 7.

Затем, установить для ярлыка вызова Microsoft Word в меню «Пуск» настройку совместимости «Запускать в режиме совместимости – Windows XP с пакетом обновления 3″. Только в этом случае окно сохранения документов изменится в стиле Windows XP и будет отображать библиотеки SharePoint:

Exchange Server 2010 позволяет отправлять и принимать SMS через Outlook или OWA, используя обычный коммуникатор, подключенный по протоколу ActiveSync. Отправка SMS поддерживается с использованием коммуникаторов на базе Windows Mobile 6.1 и старше. При подключении к Exchange Server 2010 коммуникатора на базе Windows Mobile 6.5 по протоколу Active Sync, можно выбрать параметр синхронизации «Текстовые сообщения.» Но, когда вы используете коммуникатор на базе Windows Mobile 6.1 (коих сейчас больше всего), данный пункт меню поумолчанию отсутствует. Но при первом подключении к коммуникатора к Exchange Server 2010, в коммуникатор должно прийти специальное письмо-уведомление, в котором будет ссылка на загрузку обновления с сайта Microsoft для Outlook Mobile. Подробнее об этом можно прочитать тут, а инструкцию по настройке можно найти в следующем документе.

Но почему-то на практике не всё оказалось так гладко. Мой коммуникатор Samsung i900 (Omnia, WiTu), работающий под управлением Windows Mobile 6.1, подключился к Exchange 2010, применил политики, синхронизировал почту, календарь и контакты, но никаких уведомлений об обновлениях я так и не получил. И соответсвенно никаких функций по синхронизации SMS у меня так и не появилось. Поиски в Интернете никаких результатов тоже не дали.

Однако вернувшись к инструкции, я увидел скриншот со ссылкой на соответствующее обновление http://go.microsoft.com/fwlink/?LinkId=150061

Пройдя по этой ссылке, мы попадаем на загрузку файла обновления Outlook Mobile: https://outlook.vo.msecnd.net/OutlookMobileSetup.cab На самом деле это не файл обновления, а лишь инсталлятор и весит он всего 180 КБ. Далее этот инсталлятор загружает соответсвующее обновление через Интернет, в соответствие с текущей версией операционной системы коммуникатора и локализации.

Далее я вручную загрузил этот CAB-файл на мобильное устройство и запустил его. Но при установке получил сообщение об ошибке 0×80040700 «Не достаточно свободного места». На телефоне было свободно около 5 МБ системной памяти, но нигде не говорится о том сколько же требуется для установки. Эту информацию мне удалось найтив лог-файле Outlook Mobile, который расположен тут: Windows\OutlookLive\ClientLog0.txt. Там была строчка disk space Needed: 10709112. Как только я высвободил необходимое пространство на внутренней памяти, обновление успешно установилось, и в настройках синхронизации появился соответсвующий пункт меню: »Текстовые сообщения«.

После завершения процесса синхронизации, перезапустив  Microsft Office Outlook или OWA, вы увидите, что в папке входящие помимо писем, появятся и ваши SMS сообщения.

Теперь SMS-сообщения можно и отправлять прямо из Outlook или OWA. Можно просто ответить на входящее сообщение, а можно и создать новое. В меню «Создать», появился новый пункт «Текстовое сообщение».

Причём, можно и не набирать телефон вручную, достаточно выбрать людей из адресной книги, написать SMS и нажать отправить. По протоколу ActiveSync сообщение попадёт в ваш коммуникатор, который сразу же отправит его получателю. И через несколько секунд ваша SMS-ка придёт на мобильный телефон соответствующего человека. Если он вам ответит, то через несколько секунд его ответ вы увидите у себя в Outlook. При этом на самом телефоне SMS-переписка также сохраняется.

Единственное, что я заметил, так это, что при отправке SMS-сообщений через Outlook, не запрашиваются подтверждения о доставке.

Теперь отправлять SMS сообщения стало намного легче и удобнее. Используя Outlook, вы отправляете сообщения со своего номера мобильного телефона, который уже известен вашим коллегам и не нужно искать какие-либо WEB-сервисы или приобретать дополнительные услуги мобильных операторов.

]]> http://blogs.lankey.ru/2010/04/19/send-sms-exchange-server-2010/feed/ 0 http://blogs.lankey.ru/2010/04/09/ocs-2007-r2-in-resource-forest/ http://blogs.lankey.ru/2010/04/09/ocs-2007-r2-in-resource-forest/#comments Fri, 09 Apr 2010 12:32:31 +0000 Ярослав Никифоров http://blogs.lankey.ru/?p=570 Как известно, Office Communications Server 2007 R2 всю свою информацию хранит в Active Directory, и при развертывании он изменяет лес AD – расширяет схему, создает новые атрибуты пользователей. Бывают случаи, когда изменение схемы Active Directory основного леса нежелательно – а тем не менее, развернуть и использовать OCS надо, и хочется использовать все прелести объединенных коммуникаций.

Для решения такой задачи существует специальное развертывание Office Communications Server, называемое развертыванием в ресурсном лесу (resource forest). Это значит, что параллельно с существующим у нас основным лесом и доменом мы можем развернуть совершенно отдельный лес, в котором и будет располагаться OCS. Это решение поддерживается Microsoft и описано в паре англоязычных документов, ну а чтобы не отсылать читателя к ним, мы расскажем по-русски, как это сделать.

Пусть у нас есть некий основной домен с пользователями, называющийся например mycompany.ru. Соответственно, пользователи имеют e-mail-адреса логин@mycompany.ru, пользуются Outlook’ом, Exchange (неважно каким, но лучше конечно 2007/2010 ).

Развертывание OCS в ресурсном лесу будет состоять из следующих шагов:

1. Развертывание отдельного леса, с именем например myocs.local
2. Установка доверия между доменами
3. Развертывание OCS в лесу myocs.local
4. Создание в этом лесу учетных записей-заглушек для пользователей основного домена
5. Наслаждение работой с объединенными коммуникациями Microsoft

Шаг 1 – развертывание отдельного леса

Для отдельного леса нам понадобится один компьютер, который будет служить контроллером домена этого леса. Конечно, в идеале их должно быть как минимум два, но поскольку мы рассматриваем тестовый вариант – можно ограничиться одним компьютером. И, конечно, для удобства это будет виртуальная машина, запущенная под управлением Hyper-V на Windows Server 2008 R2.

Структура лесов будет выглядеть следующим образом:

Итак, мы установим компьютер операционной системой Windows Server 2008 R2, назовем его dcrf, и промотируем его до домен-контроллера. При создании домена укажем, что это новый домен нового леса. А домен назовем myocs.local.

Уровень домена/леса должен быть не ниже 2003 – так требует OCS. Поскольку ресурсный лес будет обслуживаться только этим контроллером – смело ставим уровень леса в Windows Server 2008 R2.

Я использую для контроллера именно Windows Server 2008 R2, потому что в нем есть встроенные коммандлеты для управления Active Directory, что очень поможет нам на шаге 4, при создании пользователей-заглушек с информацией из основного домена.

Так как нам необходимо, чтобы между доменами было доверие – то контроллеры доменов dc.mycompany.ru и dcrf.myocs.local должны находить друг друга. Поэтому следующим шагом будет соответствующая настройка DNS – создадим на DNS-сервере dcrf.myocs.local форвардинг на IP-адрес контроллера dc.mycompany.ru, а на DNS-сервере dc.mycompany.ru – conditional forwarding для домена myocs.local на IP-адрес dcrf.myocs.local.

На этом же сервере развертывается Enterprise Root Certification Authority, который будет использован для выдачи сертификатов для серверов OCS.

Шаг 2 – настройка доверия между доменами

После того, как мы добьемся, что оба домена друг друга увидят – разрешат имена серверов, можно настраивать доверие.

Достаточно создать 1-way trust от ресурсного домена к основному – то есть, ресурсный домен доверяет логиниться к себе пользователям из основного. Открываем AD Domains and Trusts на dcrf.myocs.local, и создаем External Trust, 1-way outgoing, до домена mycompany.ru. И, соответственно, на контроллере dc.mycompany.ru создаем External Trust, 1-way incoming.

Итог – мы создали ресурсный лес, и установили доверие с основным рабочим доменом.

Шаг 3 – развертывание OCS в ресурсном лесу

Далее, совершенно обычным образом развертываем Office Communications Server 2007 R2 на серверах в ресурсном лесу. Я назвал такие сервера ocsse.myocs.local и ocsmed.myocs.local, на которых будут развернуты Standard Edition и Mediation Server соответственно. Edge-сервер нам не потребуется – все пользователи будут авторизоваться посредством доверия между доменами, с помощью обычных своих учетных данных.

Установим мы серверы на для удобства тоже на виртуальных машинах – но уже само виртуальные машины будут содержать Windows Server 2008. Поскольку Office Communications Server 2007 R2 не очень хорошо работает на Windows Server 2008 R2, придется использовать предыдущую версию операционной системы.

При установке OCS крайне важно указать следующее – в качестве домена для установки мы выбираем домен myocs.local. А в качестве SIP-домена мы указываем домен mycompany.ru. Это необходимо, поскольку мы хотим, чтобы SIP-адреса пользователей совпадали с их email-адресами, то есть, относились бы к домену mycompany.ru.

Я не буду расписывать подробно установку OCS, настройку и связь с VoIP-шлюзом - это можно найти в соответствующих статьях на этом же блоге.

Главное, что нужно изменить после инсталляции OCS – указать в параметрах Front-End сервера Standard Edition тип авторизации пользователя - только NTLM.

Это важно, поскольку стоящая по умолчанию настройка – Kerberos and NTLM – не позволит авторизоваться пользователям основного домена.

В результате мы получаем два сервера Office Communications Server 2007 R2 в ресурсном лесу, и следующим нашим шагом будет создание пользователей-заглушек.

Шаг 4 – создание и синхронизация информации о пользователях

Поскольку пользовательские учетные записи располагаются в основном домене, а OCS-у требуется, чтобы у него были свои учетные записи, со списком контактов и соответствующими параметрами – необходимо создать отключенные пользовательские аккаунты в домене myocs.local, для которых будут храниться настройки Office Communications Server. А для того, чтобы не приходилось дублировать и синхронизировать пароли – необходимо обеспечить взаимосвязь между действующим аккаунтом пользователя в основном домене, и отключенным аккаунтом пользователя в ресурсном лесу.

Известно, что основным идентификатором пользователя в домене является его SID – Security Identifier. После установки OCS (и соответствующего расширения схемы AD) в ресурсном лесу у объекта пользователя присутствует специальное поле msRTCSIP-OriginatorSID – нам необходимо записать в него SID пользователя из основного домена. Таким образом, в ресурсном лесу у пользователя будет два SID-а – один обычный, относящийся к ресурсному лесу, и второй, который мы занесем вручную – SID пользователя из основного рабочего домена.

Ну и конечно, для того, чтобы в контакт-листе Communicator отображалась полноценная информация о пользователе – необходимо указать имя и фамилию пользователя, его телефон, должность, и e-mail.

Общая таблица атрибутов , которые нам необходимо перенести из основного домена для пользователя, выглядит следующим образом:

Создавать объекты и переносить атрибуты, конечно, можно и вручную – но это неинтересно и долго. Как я уже упомянул, в Windows Server 2008 R2 есть коммандлеты PowerShell, которыми я и воспользуюсь.

Вот простейший скрипт, от которого можно отталкиваться в собственных случаях:

$srcdc = "dc.mycompany.ru" # исходный домен
$srcbase = "OU=Domain users,DC=mycompany,DC=ru" # OU, который сканируем на предмет пользователей
$dstdc = "dcrf.myocs.local" # ресурсный домен
$dstbase = "OU=OCS Users,DC=myocs,DC=local" # OU, в котором будут созданы объекты-заглушки.
New-PSDrive -Name DstAD -Root "" -Server $dstdc -PSProvider ActiveDirectory -Cred MYOCS\Administrator # подключаемся к ресурсному домену с правами администратора, который может создавать объекты.
New-PSDrive -Name srcAD -Root "" -Server $srcdc -Cred MYCOMPANY\user -PSProvider ActiveDirectory # подключаемся к исходному домену с правами просто пользователя, который может хотя бы читать данные из исходного AD.
cd srcAD:
$usrs = get-ADUser -SearchBase $srcbase -Filter * -Properties mail # выбираем всех пользователей в указанном OU.
cd dstAD:
foreach ($u in $usrs) {
   echo $u.name
   New-ADUser -Path $dstbase -DisplayName $u.Name -Name $u.name -GivenName $u.GivenName -Surname $u.Surname -SamAccountName $u.samAccountName -OtherAttributes @{'mail'=$u.mail;'msRTCSIP-OriginatorSid'=$u.SID} # создаем пользователя, указывая для него необходимые аттрибуты. Пользователь создается отключенным - Disabled.
}
cd c:
remove-psdrive srcad
remove-psdrive dstad

Этот скрипт не совсем полный – он не переносит должности, название компании, город и офис. Мне это было не нужно - но это всегда можно дописать самостоятельно

Можно заметить, что в ресурсном домене мы создаем пользователей, не указывая для них пароли. Это действительно неважно – так как пользователи будут авторизоваться по своим собственным учетным данным в основном домене, а затем уже просто сопоставляться с отключенными аккаунтами в ресурсном лесу.

После создания пользователей-заглушек мы обычным образом включаем их – Enable for Office Communications Server, и настраиваем – Configure for Office Communications Server.

В основном домене необходимо будет сделать лишь одно изменение – добавить в атрибут proxyAddresses пользователей адрес вида sip:логин@mycompany.ru. Это необходимо для того, чтобы при запуске Communicator пользователю не приходилось бы вручную указывать свой SIP-адрес для входа. Сделать это можно с помощью ADSI Edit, с помощью Email Address Policy в Microsoft Exchange, или написать свой скрипт – как угодно.

Шаг 5 – запускаем и работаем

Все! теперь можно смело ставить на клиентские компьютеры Office Communicator. Также необходимо импортировать на клиентские компьютеры сертификат того корневого центра сертификации, который использовался при создании сертификатов для серверов OCS. В нашем случае это сертификат с центра сертификации dcrf.myocs.local. Импортировать этот сертификат нужно в раздел «Доверенные корневые центры сертификации».

Конечно, необходимо добавить в DNS-зону mycompany.ru записи sip.mycompany.ru и _sipinternaltls._tcp.mycompany.ru – подробнее смотрите в статье по установке и настройке Office Communications Server 2007 R2.

После этого можно смело запускать Office Communicator, и работать!

Для обеспечения более сильной защиты применяется так называемая многофакторная аутентификация – то есть, аутентификация из нескольких шагов. Отличным примером средства многофакторной аутентификации являются смарт-карты, или другие устройства, схожие со смарт-картами, например, USB-ключи eToken.

Несомненное достоинство ключа eToken перед смарт-картой – он не требует специального считывателя, а просто вставляется в свободный порт USB.

Аутентификация по смарт-карте или ключу может использоваться при входе в Windows, при подключении к VPN или RDP, при подключении к Outlook Web App.

Требуется только, чтобы на компьютере пользователя находился драйвер для смарт-карт или USB-ключей.

Например, при входе в Outlook Web App – вместо окна ввода логина и пароля выводится запрос на выбор сертификата:

В смарт-карту или ключ может быть загружено несколько сертификатов, при этом один из них помечается как используемый по умолчанию. Некоторые программы – например Internet Explorer – позволяют выбрать нужный из всех найденных в смарт-карте сертификатов. Другие программы – например, клиент удаленного рабочего стола – не позволяют выбрать сертификат – выбирается только указанный по умолчанию.

Выбрав сертификат, пользователю необходимо ввести лишь пин-код для доступа к смарт-карте или USB-ключу. И – все, авторизация пройдена! Таким образом, смарт-карта является полной заменой логину и паролю, используемому при обычной аутентификации.

Использование смарт-карты при аутентификации на рабочую станцию в Windows регулируется групповой политикой, и так же политикой регулируется поведение системы при убирании смарт-карты из считывателя (или USB-ключа из порта). Система может никак не реагировать на вытаскивание смарт-карты, может автоматически блокировать (Lock) сеанс пользователя до установки смарт-карты обратно, и может завершать (Logoff) сеанс пользователя.

Несомненная польза смарт-карты в том, что аутентификация с ее помощью является многофакторной – требуется предоставить «что-то, что мы имеем», то есть саму смарт-карту, и «что-то, что мы знаем», то есть пин-код к ней. И к тому же, в отличие от просто пароля, утрату смарт-карты или ключа обнаружить гораздо легче, чем  факт разглашения пароля. По факту утраты можно вовремя принять меры по отзыву сертификатов и запрета их использования для аутентификации.

ActiveSync – это широкоиспользуемый протокол для синхронизации мобильных устройств и смартфонов с сервером Exchange. По данному протоколу мобильный телефон получает почту, контакты, календари и задачи из корпоративного почтового ящика пользователя на сервере Microsoft Exchange. Более подробно о мобильном доступе можете прочитать здесь

Утилита позволяет перехватывать сигнал, расшифровывать трафик и смотреть всю почтовую переписку пользователя.

Как это работает:

Все вы слышали, когда телефон лежит рядом с компьютером и, например, приходит SMS, то в колонках происходит характерное потрескивание/гудение, которому никто не придаёт особого значения. Тоже самое происходит и при получении письма посредством ActiveSync через GPRS/EDGE/3G. Утилита компании Pastware перехватывает возмущения, возникающие в аналоговых цепях звуковых карт, снимает дамп этих шумов и, используя преобразования фурье и выделение гармоник, получает двоичный код сетевых пакетов TCP/IP. Затем специальными парсерами из общего потока выделяется содержимое HTTPS-пакетов протокола ActiveSync. Затем SSL пакеты расшифровываются другим модулем из пакета Pastware Kit и на выходе получаем всю почтовую переписку за определёный момент времени.

100% достоверность, пока не гарантируется, качество перехвата напрямую зависит от частоты дискретизации звуковой карты и разрядности АЦП. Рекомендуется использовать звуковые карты разрядностью 24 бит и более и частотой дискретизации 96 КГц и выше, без систем активного шумоподавления.

Для переноса OEM лицензий с одного компьютера на другой Microsoft выпустила специальный OEM Transporter Kit.

В комплект поставки входит дремель и несколько насадок. Смысл набора очень прост: В том месте старого системного блока, где у вас наклеена лицензионная наклейка, вы с помощью дремеля выпиливаете стенку корпуса и приклеиваете её к новому корпусу.  Далее вы переустанавливаете и переактивруете Windows на новом оборудовании и всё!

По предварительным данным стоимость КИТ-а будет составлять примерно 50$. В прайсах продукт можно будет найти под именем: WinPro 7 RUS OEM NL Transportering DrillGenuine

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

Гейтофобия – чаще всего проявляется у сетевых администраторов, имеющих сертификаты CCNA и CCNP, т.к. именно они в основном в компаниях отвечают за сетевую инфраструктуру, за работу интернет-а и соответственно за доступность основного шлюза. На них лежит большая ответственность и именно в них летят все «палки», в случае неработоспособности сети.

Основными симптомами заболевания являются параноидальный мониторинг доступности шлюза  при помощи ICMP пакетов, который в особо острой фазе и приводит к самой недоступности шлюза, ввиду невозможности последнего обработать такой большой поток Ping-ов. Далее, когда системный администратор видит надпись Default Gateway is Unavailable, происходит нервный срыв, который может сопровождаться нецензурной бранью, повышением температуры, а также почечной недостаточностью, вызванной высоким потреблением пива.

Пока способов лечения Гейтофобии не найдено, но врачи рекомендуют использовать резервные шлюзы с разными метриками, применять технологии балансировки сетевой нагрузки такие, как NLB или CARP.

Задачу автоматического выключения компьютеров наши инженеры решили довольно быстро, слава богу на всех компьютерах был установлен Windows 7 с продвинутым шедулером на основе триггеров. На всех компьютерах в Планировщике была создана задача, которая запускала скрипт с командой shutdown – s -t 0, а срабатывала задача при появлении события Windows Update Client, код события 21, ключевое слово Перезагрузка.

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

Но вот задача автоматического включения компьютеров оказалась немного сложнее. Первое, что конечно пришло в голову – это использование Wake on-Lan, но к сожалению данная функция работает далеко не на всех компьютерах, поэтому требовалось иное решение.  Данная задача была передана инженерам ОНВ (Отдел Нетрадиционного Внедрения). И решение было найдено! У данного заказчика весь офис запитан от одного большого централизованного ИБП APC Smart-UPS VT 30 kVA. Инженеры отдела ОНВ предложили на каждом компьютере в BIOS выставить режим Питания Always On. В данном режиме компьютер автоматически включается, если произошло выключение и затем повторное включение питания. Ну а дальше дело оставалось за малым, точнее за большим UPS-ом. Через консоль управления APC Power Chute было задано запланированное выключение и затем повторное включение питания всего офиса в 2 часа ночи каждую среду.

В Итоге: При пропадении питания, и его повторном появлении все компьютеры включаются, затем происходит установка обновлений, после установки обновлений компьютеры выключаются командой shutdown, запускаемой планировщиком по триггеру.

Данное решение работает уже около полугода в продакшене и не имеет почти никаких побочных эффектов, кроме того, что секретарша не может понять, какие сверхестетсвенные силы каждую среду сбрасывают время на кофемашине

Source: MSExchange Unified Messaging
Event ID: 1185
Task Category: UMCore
The Unified Messaging server failed to submit a message to Hub Transport server 'EXCHANGE' due to the following error: Unexpected server response. Expected: 220, actual: 500, whole response: 500 5.3.3 Unrecognized command

Source: MSExchange Unified Messaging
Event ID: 1423
Task Category: UMCore
A pipeline stage encountered the following error. Details : 'Microsoft.Exchange.UM.UMCore.SmtpSubmissionException: Submission to the Hub Transport server failed. The operation will be retried. ---> Microsoft.Exchange.Net.ExSmtpClient.UnexpectedSmtpServerResponseException: Unexpected SMTP server response. Expected: 220, actual: 500, whole response: 500 5.3.3 Unrecognized command

   at Microsoft.Exchange.Net.ExSmtpClient.SmtpTalk.CheckResponse(ServerResponseInfo response, Int32 expectedCode)
   at Microsoft.Exchange.Net.ExSmtpClient.SmtpTalk.Command(SmtpChunk[] chunks, SmtpCommandType command, Int32 expectedCode)
   at Microsoft.Exchange.Net.ExSmtpClient.SmtpTalk.StartTls()
   at Microsoft.Exchange.Net.ExSmtpClient.SmtpClient.Submit()
   at Microsoft.Exchange.UM.UMCore.SmtpSubmitStage.SubmitMessage()
   at Microsoft.Exchange.UM.UMCore.SmtpSubmitStage.InternalDoSynchronousWork()
   --- End of inner exception stack trace ---

Server stack trace:
   at Microsoft.Exchange.UM.UMCore.SmtpSubmitStage.HandleTransientSmtpFailure(Exception e, InternalExchangeServer smtpServerToUse)
   at Microsoft.Exchange.UM.UMCore.SmtpSubmitStage.InternalDoSynchronousWork()
   at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.AsyncProcessMessage(IMessage msg, IMessageSink replySink)

Exception rethrown at [0]:
   at System.Runtime.Remoting.Proxies.RealProxy.EndInvokeHelper(Message reqMsg, Boolean bProxyCase)
   at System.Runtime.Remoting.Proxies.RemotingProxy.Invoke(Object NotUsed, MessageData& msgData)
   at Microsoft.Exchange.UM.UMCore.SynchronousPipelineStageBase.SynchronousWorkDelegate.EndInvoke(IAsyncResult result)
   at Microsoft.Exchange.UM.UMCore.SynchronousPipelineStageBase.EndSynchronousWork(IAsyncResult r)'

Роли Hub Transport и Unified Messaging находятся на одном и том же сервере, но тем не менее, голосовое сообщение, оставленное пользователем, в ящик получателя не попадает.

Из приведенных ошибок видно, что при попытке установления SMTP-соединения служба Hub Transport выдает ответ, что команда не распознана. По подробной информации видно, что ошибка возникает в процессе работы процедуры StartTls, то есть имеет место быть неудачная попытка установки шифрованного соединения.

Ошибка возникла из-за следующей тонкости:

Сам сервер внутри сети называется EXCHANGE.имя-домена. А опубликован в Интернет он под именем MAIL.имя-домена. Соответственно, в процессе настройки в Receive Connector захотелось внести изменения, чтобы при подключении сервер отвечал не своим внутренним именем, а внешним, отличающимся от внутреннего. Но – при несовпадении FQDN, предоставляемого в ответ на HELO или EHLO, и системного имени сервера, отказывается работать включенная по умолчанию аутентификация Exchange Server authentification. Соответственно, эта галочка и была выключена.

А если выключена Exchange Server authentication – то в ответ на команду EHLO сервер в списке допустимых команд НЕ ВЫВОДИТ команду X-ANONYMOUSTLS, и не отвечает на нее. А службы Unified Messaging пытаются установить соединение с Hub Transport именно этим способом.

Решение: в нашем случае помогло включение обратно пункта Exchange Server authentication, смена выдаваемого FQDN в окне Receive Connector обратно на внутреннее имя сервера, и перезапуск служб MSExchange Hub Transport и MSExchange Unified Messaging.

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