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


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

Первая неделя эксплуатации выявила некоторые странности в поведении терминальных серверов: иногда они аварийно перегружались, иногда были недоступны по 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 позволяет спать в это время :-) ). Помните, что сначала политика должна примениться, и только потом перезагружать сервер.

UsoClient — замена wuauclt


Windows 10 оказалась очень практичной системой. За несколько лет эксплуатации в корпоративной среде мы не имели с ней проблем. И расслабились :-) — как-то разом застряли кумулятивные обновления на всех системах.

По всей видимости через WSUS приехало некачественное обновление и попортило образы систем. В CBS.log на разных компьютерах ошибки на разные компоненты. Будто это не детерминированные компьютеры, а последствия взрыва гранаты — где как пришлось.

Попробовали вылечить несколько систем вручную с помощью sfc и dism. Несколько ошибок они исправили, но не все. Победить проблему удалось только утилитой SFCFix. Но это же не вариант лечить вручную сотни компьютеров, да ещё сторонней утилитой!

Открыли системам доступ в Интернет на сайты Windows Update. Dism сразу стал инициировать загрузку каких-то компонентов, но до конца всё так и не вылечил.

К счастью оказалось, что последние обновления всё-таки ставятся и проблема лечится автоматически: загрузка последних обновлений, пара установок с аварийным завершением (при этом в CBS.log видно исправление ошибок образа системы!) и перезагрузкой — и всё работает. (Иногда правда перезагрузка может зависать надолго на некоторых системах, но это терпимо.)

Попутно выяснилось, что привычная wuauclt утилита не работает. К тому же её можно было запускать только локально.

Если на Windows XP и Windows 7 приходилось из-за ограничений Windows Update клиента прибегать к некоторым ухищрениям, чтобы удаленно инициировать установку обновлений, то на Windows 10 было приятно открыть для себя утилиту UsoClient, которая работает через удаленное подключение PowerShell или PSExec.

С помощью неё можно не только иницировать поиск обновлений, но и их загрузку, установку и перезагрузку системы.

Список параметров от доброго человека:

  • StartScan Used To Start Scan
  • StartDownload Used to Start Download of Patches
  • StartInstall Used to Install Downloaded Patches
  • RefreshSettings Refresh Settings if any changes were made
  • StartInteractiveScan May ask for user input and/or open dialogues to show progress or report errors
  • RestartDevice Restart device to finish installation of updates
  • ScanInstallWait Combined Scan Download Install
  • ResumeUpdate Resume Update Installation On Boot

PowerShell 7 — список совместимых модулей


Обновленная документация содержит список модулей совместимых с PowerShell 7. Список обновляется.

Ссылка https://docs.microsoft.com/en-us/powershell/scripting/whats-new/module-compatibility?view=powershell-7

Ожидаем PowerShell 7.0 RC2


После выхода в декабре 2019 года PowerShell 7.0 RC1 в январе 2020 ожидался выход окончательной версии.

Планы изменились. Сейчас выйдет RC2, а релиз в начале февраля. Причина банальна: неожиданно было получено много отзывов на RC1 и было сделано много мелких исправлений. Всё это должно быть проверено перед выпуском окончательной версии.

Не откладывайте на потом и пишите отзывы сейчас https://github.com/PowerShell/PowerShell/

Кстати посмотрите как растет использование PowerShell Core. Число запусков в месяц перевалило за 80 миллионов. Не так давно это число не превышало 20 миллионов. Большая часть запусков по-прежнему на Linux — более 70 миллионов. Ситуация должна измениться с выходом 7-й версии: большое количество Windows модулей работает на 7.0, и всё больше пользователей будут использовать PowerShell Core на Windows.

Вышел PowerShell 7.0 Preview6


Вышла последняя предварительная версия PowerShell 7.0 перед RC, который ожидается через месяц.

Найти описание и дистрибудив можно по ссылке https://github.com/PowerShell/PowerShell/releases/tag/v7.0.0-preview.6

Как всегда множество исправлений и несколько новинок.

Появились новые операторы — null-conditional operators.

Обновился портированный Test-Connection. Теперь он более пригодный для использования, хотя проблемы ещё остались.

Запуск Windows PowerShell из PowerShell Core происходит более корректно (в смысле поиска и загрузки модулей).

Появился более удобный механизм использования несовместимых с PowerShell Core модулей — https://github.com/PowerShell/PowerShell/pull/10973 По сути создается «удаленная» сессия, в которой запущен Windows PowerShell. Это не решает всех проблем из-за сериализации, но это работает!

Как всегда улучшена производительность в некоторыз сценариях.

Командлет Select-String получил новый параметр Culture, который позволяет не только использовать правила конретного языка для поиска, но и выполнять самый быстрый бинарный поиск (Ordinal). Рекомендую попробовать.

Целый ряд непортированных командлетов добавлены обратно для лучшей совместимости скриптов с Windows PowerShell — Get-Counter, Get-ClipboardSet-Clipboard, Out-Printer, Clear-RecycleBin, Out-GridViewShow-Command и Get-Help -ShowWindow.

Не забываем про новый Get-Error, который постоянно улучшается.

И ещё много чего найдёте по ссылке.

AppLocker и CRL


Проверка списков отзыва сертификатов (CRL) полезная вещь позволяющая нам избежать взаимодействия с системами, у которых скомпрометирован сертификат.

Со временем политика использования сертификатов на Windows системах ужесточается. Мы все ощутили это в то время, когда RDP клиент на Windows 7 начал делать жесткие проверки сертификатов. Многие инфраструктуры пришлось тогда подчистить и подправить, чтобы пользователи не испытывали проблем с подключениями к удаленным рабочим столам.

Проверки CRL также могут вызывать проблемы — в виде задержек. Это уже было в нашем опыте с Sharepoint и Exchange серверами. Собственно это все тот же CAPI.

На днях выяснилось, что этой проблеме подвержен AppLocker. Оказывается, даже если он выключен, он всё равно работает где-то в недрах системы, пытается что-то проверять и даже провоцирует проверки сертификатов и CRL. А уж если он включен, и настроены правила Publisher, то и подавно.

Это имеет один неожиданный побочный эффект. Собственно так это и было обнаружено. Суть в том, что PowerShell имеет встроенную поддержку AppLocker, т.е. делает специальные вызовы API, чтобы проверить можно ли запускать тот или иной скрипт. Побочный эффект в том, что из-за проверок CRL в AppLocker PowerShell может работать медленнее: задержка запуска, задержки при загрузке модулей, задержки при выполнении скриптов.

Надо отметить, что эта проблема чаще всего возникает в изолированных сетях. Но иной раз и в сетях, которые просто неправильно сконфигурированы (фаервол и, особенно, DNS).

Неправильно сконфигурированные сети надо лечить.

Рекомендация для изолированных сетей простая: групповыми политиками уменьшить тайм-аут проверки CRL.

Ссылки:

Рекомендация отсюда

Обсуждение PowerShell

Обновлённый Select-String


После долгой эпопеи (это тема для отдельного поста, но история ещё не закончилась) командлет Select-String получил новый параметр Culture.

По умолчанию Select-String использует значение CurrentCulture. Это подразумевает преобразования текста в соответствии с правилами текущего языка сессии. Что если нужно выполнить поиск в файле с другим языком? Ранее у нас не было выбора. Теперь можно указать конкретный язык.

Но не только. Языковые преобразования замедляют поиск. Многие утилиты предлагают самый быстрый вариант поиска — двоичный. Теперь это возможно в Select-String! Укажите параметр Culture со значением Ordinal. Попробуйте выполнить поиск в большом лог файле, и вы убедитесь, что это быстрее.

Помимо это теперь Select-String умеет выделять цветом найденные элементы в отображаемой строке. Это включено по умолчанию. Отключить можно параметром NoEmphasis.

Наступают последние дни когда можно внести изменения в PowerShell Core перед выходом релиза 7.0. Пробуйте последние предварительные сборки и пишите замечания.