Попрощались со старым Exchange Server 2013

На днях разбирал старый Exchange Server 2013 после переезда на версию 2019. Всё прошло гладно, но с парой приколов. Выяснилось, что часть клиентов упрямо подключается к старым CAS серверам. После недолгих изысканий оказалось, что недостаточно обнулить URL-ы в SCP с помощью командлетов. Пришлось запустить ADSIEDIT.msc и удалить старые SCP вручную:

CN=<server>,CN=Autodiscover,CN=Protocols,CN=<server>,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=OrganizationName,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=ru

Это значительно улучшило ситуацию, но некоторые клиенты продолжали подключаться к старым CAS серверам. Оказалось, что есть записи в Host файлах на клиентах: когда-то что-то отлаживали и забыли убрать :-)

Еще один прикол вылез со старыми клиентами — несколько Unix систем и масса МФУ, которые анонимно отправляли сообщения в локальные почтовые ящики. Оказалось, что не работает TLS — на новых Windows Server 2019 все старые протоколы отключены, кроме TLS 1.2. МФУ пришлось перепрошивать (у некоторых и это не помогло — сделали под них анонимный коннектор без TLS). На Unix-ах исправляли конфиги.

Exchange Server 2013 безотказно проработал около 7 лет за что ему большое спасибо! Хочется верить, что Exchange Server 2019 проработает не меньше, несмотря на политические замещения :-)

Реклама

Не запускается Server Manager

Уже втрой раз за несколько месяцев после установки ежемесячных обновлений Service Manager не может запуститься и подает в дамп.

Ситуация описана в https://social.technet.microsoft.com/Forums/en-US/d7e48460-bc23-4288-b976-98e7952d1517/server-manager-crashes-on-opening-on-windows-server-2016?forum=winservermanager

Код ошибки 1026. Смое важное в сообщении об ошибке:

Microsoft.Windows.ServerManager.Common.Data.RoleFeatureRoot..ctor(System.Collections.Generic.ICollection`1<Microsoft.Windows.ServerManager.Common.Data.IFeature>)
   at Microsoft.Windows.ServerManager.Common.Data.Server.UpdateFeatures(System.Collections.Generic.ICollection`1<Microsoft.Windows.ServerManager.Common.Data.IFeature>,

Статья на форуме Technet полезная, но не раскрывает всех секретов.

«UpdateFeatures» в сообщении об ошибке навивает на мысли. Фактически Server Manager не может получить список установленных компонентов.

Основная хитрость в том, что Server Manager использует PowerShell Remoting для подключения к серверам. Иначе говоря, если вы будете делать проверки локально, то не увидите проблему. Нужно проверять именно удаленное подключение.

Service Manager фактически использует для получения списка установленных компонент командлет Get-WindowsFeatures. Чтобы выполнить проверку правильно даже на локальном сервере, необходимо использовать параметер ComputerName:

Get-WindowsFeatures -ComputerName "server"

Если этот командлет вернет ошибку «Данный ключ отсутствует в словаре.» / «The given key was not present in the dictionary.», значит вы нашли поврежденный сервер.

Для лечения выполняем на нём команду:

dism /online /enable-feature /featurename:IIS-ASPNET45 /all

Остаётся только один вопрос: что если в Service Manager добавлено много серверов? Перебирать их вручную не очень интересное занятие. К тому же поврежденными могут оказаться серверы не подключенные в данный момент к Service Manager, но проблема может всплыть позднее в самое неподходящее время. Следовательно надо проверить все серверы и вылечить их.

# Получить список имен серверов, которые пингуются.
# Это значительно ускоряет процесс.
$servers = Get-ADComputer -SearchBase "OU=Servers,DC=firm,DC=ru" -Filter * | Select-Object -ExpandProperty Name | Where-Object { Test-Connection -ComputerName $_ -Count 1 -ErrorAction SilentlyContinue }

# Проверяем каждый сервер на конкретную этой ситуации ошибку.
$brokenServers = $servers | Where-Object { (Get-WindowsFeature -ComputerName $_ -ErrorVariable err -ErrorAction SilentlyContinue) -and ($err.Exception -is "System.Collections.Generic.KeyNotFoundException") }

$brokenServers

# Если найден поврежденный сервер, то выполняем на нем команду:
dism /online /enable-feature /featurename:IIS-ASPNET45 /all

Медленное подключение MMC Computer Management к удаленным компьютерам

В SCCM консоле мы активно используем Recast RCT (Right Click Tools). В частности запускаем оснастку MMC Computer Management. В один прекрасный момент эта оснастка стала подвисать при запуске на окне с ползунком прогресса, да ещё иной раз аварийно завершаться, если не дождаться завершения подключения.

Команда netstat показала SYN_SENT. Иначе говоря на целевых компьютерах фаервол что-то блокировал. Аудит правил фаервола ничего не дал: все правила удаленного управления были на месте.

С коллегой провели некоторые изыскания. Просто запустили mmc.exe и перебирали все оснастки, которые подгружаются в Computer Management. Обнаружили, что проблема есть с двумя из них: Performance и Windows Backup. Удивительно, что в фаерволе нет стандартных правил для них.

Существует групповая политика, которая позволяет управлять (включать и запрещать) оснастками MMC. Мы попытались выключить эти две оснастки, которыми не пользовались. Оказалось, что в политике нет варианта для Windows Backup.

Решением стало добавление разрешающих правил в фаервол для двух процессов plasrv.exe и wbadmin.exe. (Найти их помогла всё та же утилита netstat -ano)

Как только политика с правилами фаервола применилась к компьютерам, оснастка Computer Management стала снова быстро подключаться.