PowerShell 7.1 Preview7


Вышла последняя предварительная версия PowerShell 7.1 Preview7. Вскоре будет RC и сам релиз. Так что пробуйте, тестируйте и поторопитесь сообщить о проблемах, если они обнаружатся.

Что нового?

  1. Команда MSFT начала проект по реструктуризации SMA.dll на подсистемы. Это позволит создавать дистрибутивы с минимальным набором функций.
  2. Тип Utf7 более не поддерживается. Вы получите предупреждение, если скрипт использует этот тип. Причина простая — в .Net 5.0 этот тип объявлен как deprecated. В будущем он будет удален вообще. Собственно ничего страшного, так как Uft7 никогда не используется.
  3. В Web командлетах теперь можно указать использование Tls13. Так как командлеты используют возможности операционной системы, а поддержка TLS 1.3 во всех ОС сейчас ограниченная, то не стоит ожидать, что это будет работать прямой сейчас.

Стоит отметить, что Preview7 основано на .Net 5.0 Preview8, где удалена встроенная поддержка WinRT. Теперь существует отдельный проект поддержки WinRT API в C#. Это уже породило проблемы с некоторыми модулями. Кое-что уже исправлено в PowerShell, кое-что в .Net. Надеюсь, к моменту выхода .Net 5.0 обратная совместимость будет на высоте.

Странности в развитии PowerShell Remoting


Речь о PowerShell 6/7 в первую очередь. Традиционно для удаленного доступа Windows PowerShell использовал технологию WS-Management, или WSMan. Когда вышел PowerShell 6 там появилась возможность использовать SSH в качестве альтернативы, но при этом была добавлена ограниченная поддержка WSMan на Linux и MacOS. Внезапно эта поддержка прекратилась. При этом никаких ясных заявлений от MSFT не было. По всей видимости произошли внутренние разногласия между различными подразделениями огромной компании по поводу приоритетов и направлений развития. Скорее всего они сами надеялись как-то разрулить ситуацию со временем, но за несколько лет ситуация только ухудшилась, превратилась в абсурдную, когда новое ещё до конца не создано (переход экосистемы на SSH), а старое уже не только не развивается, но и не работает (WSMan на Unix).

Да, WSMan на Unix толком не работает. Причина в том, что реализация жестко привязана к SSL 1.0.0, которая в большинстве систем не устанавливается как устаревшая и небезопасная.

Цепочка зависимостей выглядит так WSMan -> PSRPClient -> libmi — OMI. Проблема в стыке libmi и OMI. В OMI есть проблемы с SSL. Команда MSFT OMI отказывается вносить изменения, так как это deprecated проект и это не соответствует их приоритетам. В свою очередь команда MSFT PowerShell не может исправить libmi. Эта библиотека также объявлена deprecated.

В репозитории PowerShell существует множество вопросов по этому поводу. Только в последнее время команда MSFT PowerShell стала говорить о том, что WSMan не поддерживается на Unix, и все должны использовать SSH транспорт.

При этом существуют обходные пути, как установить более новую версию SSH и создать линки так, чтобы WSMan заработал на Unix. Он еще долго будет нужен, т.к. существует огромная экосистема, где он используется. Включая Облачные сервисы. Даже новый модуль Exchange Online V2 использует WSMan. Пользователи PowerShell на Unix могли бы остаться в стороне, если бы не альтернативный проект поддержки.

Если у вас есть потребность в WSMan на Unix посмотрите эту статью и поддержите проект.

А что MSFT? Протокол SOAP объявлен deprecated. Почему я упомянул его? WSMan на Windows реализован поверх SOAP (MMI.dll).

Таким образом не только Unix, но и Windows системы идут по пути миграции PowerShell Remoting на SSH.

Команда MSFT PowerShell только что начала предпринимать реальные шаги по изживанию Management Instrumentation (libmi.dll/mmi.dll). Сейчас она ведет соответствующие работы над DSC. Конечно это будет постепенный процесс. Посмотрите — это интересно. Хотя похоже на проклятье — жить в эпоху перемен :-)

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


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

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