Попрощались со старым 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 проработает не меньше, несмотря на политические замещения :-)

RRAS не работает с DHCP на Windows Server 2019


Давно не имел дела с RRAS (Routing and Remote Access Service) и недавно пришлось вспомнить о нём. Ранее я писал об опыте перехода на удаленную работу, в частности о настройке фермы RDP. И вот тот же повод заставил обратиться к RRAS.

Появилась категория сотрудников, которым для использования некоторого приложения (привет Cisco :-) ) обязательно нужен VPN. И опять, как в случае с WSUS, возникла нетривиальная проблема на Windows Server 2019. Только теперь проблема была в том, что RRAS никак не хотел работать с внутренним DHCP сервером для раздачи адресов VPN клиентам. Решение в правке реестра и перезапуске RRAS:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\Dhcp" /v RequiredPrivileges /d "SeChangeNotifyPrivilege"\0"SeCreateGlobalPrivilege"\0"SeImpersonatePrivilege"\0 /t REG_MULTI_SZ /f

Собственно две первые привилегии присутствуют по умолчанию и нужно добавить только SeImpersonatePrivilege.

Лечим импорт обновлений на WSUS


Давно не добавлял обновления на WSUS вручную. И тут надо было обновить драйвер на многих серверах. На Windows Update он есть, но вручную обновлять кучу серверов это не вариант. Запустил консоль WSUS, выбрал в меню соответствующую опцию, запустился Internet Explorer с сайтом Catalog Update, нашёл нужные драйверы, добавил в корзину, запустил импорт и … Fail в статусе.

Начал искать причину проблемы. WSUS работает на Windows Server 2019, все обновления установлены. На прокси сервере коннекты проходят нормально. Конфигурация Internet Explorer в норме. В общем время вышло и пришлось переключиться на более важную работу.

К вечеру занимаясь абсолютно другой проблемой совершенно случайно наткнулся на статью в блоге, где мимоходом упоминалась проблема с WSUS, очень похожая на мою. Оказалось, что это решение.

Достаточно добавить в ветку реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\v4.0.30319 ключ SchUseStrongCrypto со значением DWORD:00000001 и перегрузить WSUS сервер.

Полезная ссылка Enable Transport Layer Security (TLS) 1.2 on the site servers and remote site systems — Configuration Manager | Microsoft Docs