Наконец-то пришло время закончить цикл по миграции на Exchange 2016. В последней заметке мы удалили все серверы с ролью Mailbox с сопутствующими данными. У нас остались серверы с ролями Client Access Server и Hub Transport. До запуска процесса их удаления необходимо удалить CAS Array, который может быть связан с выводимыми из эксплуатации серверами. Exchange 2016 этот объект не использует, так что можно его удалять безболезненно:

Get-ClientAccessArray | Remove-CLientAccessArray

Далее штатным образом удаляем сами роли:

Setup.com /mode:Uninstall /role:CA,HT

На этом миграцию можно считать завершённой.

Задача: настроить управление конфигурацией серверов Exchange через DSC.

Для решения задачи энтузиастами был написан соответствующий модуль для DSC, который называется xExchange. Модуль требует для выполнения передачи в конфигурации пароля, который используется для запуска удалённой сессии WinRM для подключения к серверу Exchange. Чтобы не стать героем интернет-баек не стоит такие данные передавать в открытом виде, благо DSC даёт механизм шифрования паролей с использованием сертификата. Схема описана в официальной документации тут. Проблема в том, что в случае если Exchange устанавливается на Windows Server 2012 R2 (не важно какой версии – 2013 или 2016) эта схема не работает.

Давайте разбираться почему.

Шифрование пароля в модуле PSDesiredStateConfiguration реализовано через функцию Get-EncryptedPassword. Полный листинг функции можно посмотреть в файле PSDesiredStateConfiguration.psm1. В кратце, базовая версия DSC в составе WMF 4.0, который идёт в комплекте с Windows Server 2012 R2 (и единственное сочетание, которое поддерживается в связке Windows Server 2012 R2/Exchange 2013/16) реализуется так:

# Cast the public key correctly
$rsaProvider = [System.Security.Cryptography.RSACryptoServiceProvider]$cert.PublicKey.Key

# Convert to a byte array
$keybytes = [System.Text.Encoding]::UNICODE.GetBytes($value)

# Add a null terminator to the byte array
$keybytes += 0
$keybytes += 0

# Encrypt using the public key
$encbytes = $rsaProvider.Encrypt($keybytes, $false)

# Reverse bytes for unmanaged decryption
[Array]::Reverse($encbytes)

# Return a string
[Convert]::ToBase64String($encbytes)

А вот как это реализуется в обновлённой версии DSC, которая идёт в комплекте с WMF 5.0/5.1:

# Encrypt using the public key
$encMsg =Protect-CmsMessage -To $CmsMessageRecipient -Content $Value

# Reverse bytes for unmanaged decryption
#[Array]::Reverse($encbytes)

#$encMsg = $encMsg -replace '-----BEGIN CMS-----',''
#$encMsg = $encMsg -replace "`n",''
#$encMsg = $encMsg -replace '-----END CMS-----',''

return $encMsg

Найдите 10 отличий. Всё это приводит к тому, что mof-файл сгенерированный на сервере Windows Server 2016 (WMF 5.1) содержит пароль, который не может расшифровать DSC который идёт с WMF 4.0 на Windows Server 2012 R2.

Вывод: все mof-файлы для серверов Exchange установленных на Windows Server 2012 R2 необходимо генерировать на сервере Windows Server 2012 R2 с идущим в комплекте фрэймворком WMF 4.0.

Багофича: после обновления до Exchange 2016 CU8 перестаёт работать аутентификация в EWS для учёток, которые не имеют почтового ящика.

Сценарий: есть ящик, который собирает почтовый трафик, есть робот, который разбирает почту в этом ящике и работает в контексте сервисной учётки. Сервисная учётка не имеет почтового ящика (логично – зачем он ей, мы же почту не планируем получать?). После обновления до Exchange 2016 CU8 этот сценарий становится неработоспособным до того момента, пока мы не создадим почтовый ящик для сервисной учётки.

В логах IIS события подключения к почтовому ящику будут отображаться с 500 ошибками (Internal Server Error). Если копнуть глубже и посмотреть логи EWS, то в них будет более интересная запись:

ServiceDiagnostics_ReportException=System.ArgumentException: mailboxGuid
    at Microsoft.Exchange.Data.Directory.MailboxLocationInfo.ValidateMailboxInfo()

В общем будет явно намекать на то, что аутентифицирующийся имеет проблемы с аттрибутом mailboxGuid, что неудивительно, так как он этим аттрибутом не обладает.

Пока никаких официальных статей со стороны MS нет. Инсайдеры говорят, что внутри команды разработки сейчас идёт дискуссию по этому поводу. Рекомендаций по правильному процессу аутентификации при использовании сценария delegated mailbox так же пока добиться не удалось.