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

Ещё один опыт эксплуатации терминальной фермы

Популярность удаленного доступа растет как и нашей локальной терминальной фермы.

Первая неделя эксплуатации выявила некоторые странности в поведении терминальных серверов: иногда они аварийно перегружались, иногда были недоступны по RDP, несмотря на присутствие пинга.

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

Неприятность ситуации заключалась в том, что вроде всё работает, но как-то слегка не так: то утром обнаруживаешь, что сервер ночью перезагрузился, то пользователь пожалуется, что его сессия прерывается, и непонятно то ли у него проблема с каналом или с оборудованим, то ли всё же с фермой. Это самая неприятная ситуация при эксплуатации систем. Гораздо проще, когда если уж не работает, то конкретно не работает, и чинить надо явно видимую проблему или проблемы.

После недели наблюдений пришло понимание, что проблема всё-таки где-то с фермой. Как раз повод установить очередное ежемесячное кумулятивное обновление. Два часа от ночного сна и готово!

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

Однако многолетный опыт сказался, и довольно быстро ниточка привела на вот это обсуждение. Стоило открыть оснастку фаервола, как стало понятно, что у нас эта проблема присутствует, хотя у нас версия 2019, а статья о версии 2016. Неужели до сих пор нет решения?! Оказалось, что надо следовать старому правилу и читать с конца :-) — последний пост в обсуждении содержал ссылку на исправление, а именно на последнее кумулятивное обновление для Windows Server 2019, которое мы только что установили. Можно сказать, что нам повезло.

KB4549949

Addresses an issue that slows server performance or causes the server to stop responding because of numerous Windows firewall rules. To enable this solution, use regedit to modify the following and set it to 1:
Type: “DeleteUserAppContainersOnLogoff” (DWORD)
Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy

Почистили системы от дубликатов правил в фаерволе, сделали политику для распространения ключа реестра. Системы стали работать веселее. (Мы поняли, что в нашем случае проблема маскировалась из-за того, что у нас слишком мощные серверы с 72 ядрами.)

Обратите внимание, что скрипты из упомянутого обсуждения работают, но содержат проблему: два раза вычисляется Compare-Object. Поэтому перед запуском исправьте это (запишите результат первой команды в переменную и используйте её вместо второй команды).

Тем не менее на следующий день мы снова увидили дубликаты правил фаервола. Пришлось производить ночную перезагрузку серверов (одноразовый Task позволяет спать в это время :-) ). Помните, что сначала политика должна примениться, и только потом перезагружать сервер.