Вышел PowerShell 7.2 Preview3


Скачать можно тут PowerShell/PowerShell: PowerShell for every system! (github.com). Список измнений Release v7.2.0-preview.3 Release of PowerShell · PowerShell/PowerShell (github.com).

Самое важное, что теперь PowerShell базируется не на .Net 5.0, а уже на .Net 6.0 (6.0.0-preview.1). Как известно эти версии будут LTS (поддержка после выхода 3 года минимум).

Насколько колосальный объем работ запланирован для .Net 6.0 вы можете посмотреть на сайте Themes of .NET (там есть фильтры для убодной навигации). К сожалению планы каманды MSFT PowerShell остаются туманными. Они всё ещё думают о создании рабочих групп, которые бы более активно развивали PowerShell — смотрите PowerShell Working Groups и присоединяйтесь.

Если вы планируете новые проекты на .Net или PowerShell, то самое время заняться тестированием, пока есть несколько месяцев на оперативное устранение багов и добавление новых фич.

PowerShell 7.1 и другие новинки


Давно ничего не писал про PowerShell 7, и за это время вышла версия 7.1. Краткое описание в блоге MSFT. Эта версия основана на .Net 5.0. Таким образом, если вы заинтересованы в использовании новых возможностей этой версии .Net, вы можете установить PowerShell 7.1 и использовать их прямо из PowerShell.

Что нового в PowerShell 7.1? Не более того, что было в предварительных версиях — так что смотрите мои предыдущие посты и посты в блоге MSFT.

Это не LTS версия — время поддержки год-полтора, пока поддерживается .Net 5.0. Следующая версия 7.2 будет на основе .Net 6.0, и обе будут LTS — с поддержкой не менее 3 лет.

Не так давно вышла предварительная версия PowerShell 7.2 Preview2. Она все ещё на основе .Net 5.0, так как пока нет доступной предварительной версии .Net 6.0 (ожидаем в январе). Очень большие надежды на эту версию в смысле увеличения производительности. Команда .Net настроена решительно улучшить сценарий запуска .Net приложений. Сейчас инициализация .Net занимает слишком много времени. Так PowerShell 7 запускается почти в двое медленнее Windows PowerShell. Мы мало что можем сделать в самам PowerShell, чтобы улучшить эту ситуацию. Эти работы ослеживаются тут. Можете принять участие. Если команда .Net реализует их планы, то у нас есть шанс получить запуск PowerShell 7 даже быстрее, чем Windows PowerShell.

В PowerShell 7.2 Preview2 появилась новая возможность раскрашивания вывода на экран с помощью ANSI escape кодов. Посмотрите $PSStyle. Это экспериментальная фича. Отзывы приветствуются в GitHub репозитории PowerShell. Лично мне не нравится способ, которым это реализовано — слишком дорого (в смысле ресурсов) и слишком ограничено. Я бы ожидал увидеть поддержку цветовых схем и цветовых шаблонов (themes), что позволило бы иметь предопределенные схемы, переключать их без необходимости тратить время на создание собственных раскрасок.

Другие проекты команды MSFT, находящиеся в активной разработке.

Crescendo. Это инструмент для создания оберток обычных утилит командной строки. PowerShell, как любой шелл, всегда позволял запускать утилиты и приложения. При этом всегда было желание сделать это более удобным. В частности преобразовать вывод утилиты и объекты PowerShell. В кратце как это работает. Создаётся файл описания в формате JSON. Crescendo преобразует этот файл в модуль PowerShell, который может быть отредактирован и распространяться как законченное решение.

Хотя команда PowerShell MSFT намерена развивать этот проект, мне он кажется тупиковым путем. Можно найти немало проектов генерации PowerShell кода и даже модулей. Все они работают (если работают вообще) только в узкой сфере. Например, CDXML модули распространяемые MSFT c Windows активно используются, но пригодны только для создания оберток WMI. Идея и реализация тут просты: опираясь на стандартное представление WMI, создается CDXML файл с мета информацией, PowerShell используя эту информацию динамически генерирует модуль и создает командлеты доступные в текущей сессии.

Почему это стало возможным и работает? Потому что есть стандарт WMI. В случае утилит никаких стандартов несуществует, и тогда говорят «проблема фундаментально неразрешима». Что в свою очередь говорит о том, что любые генераторы изначально будут ограничены в возможностях. И чем больше возможностей будет в них закладываться, тем сложнее будет с ними работать. Проще говоря, Crescendo JSON файлы будет очень сложно создавать и поддерживать. Я бы выбрал другой путь…

Надеюсь, что мои рассуждения вас заинтриговали, и вы попробуете Crescendo и напишите отзывы в его репозитории. (Можете и со мной подискутировать, если есть желание развивать это направление в PowerShell.)

SecretManagement и SecretStore. Очень интересные проекты. Рекомендую посмотреть, попробовать и написать отзывы. Поторопитесь, так как выпуск первой версии намечен на январь 2021 года. История появления этих проектов проста — то как мы привыкли работать с паролями, а частности их хранение в Credetial Manager, не работает в других ОС. Поэтому нужна поддержка альтернативных хранилищей секретов (в том числе Azure) и общие командлеты для работы с этими секретами.

PSReadline. Очень рекомендую установить самую последнюю версию. И включите экспериментальные фичи. Вы уже видели Predictive IntelliSense? Там ещё много чего есть и появилось для любителей сделать рабочую среду PowerShell удобной.

PowerShellGet 3.0 Основной источник модулей PowerShell. Новая версия движется к своему релизу. Пробуйте заранее и пишите отзывы.

PSScriptAnalyzer 1.19.1 Если не использовали раньше, то попробуйте. Проект тоже открытый, так что пишите отзывы и запросы на новые фичи.

PowerShell Working Groups Это не проект, а намерение команды MSFT сделать проект ещё более открытым и более активным, вовлечь больше разработчиков. Команда PowerShell MSFT маленькая, но за ней закреплено много проектов. Как результат, команде просто не хватает ресурсов, чтобы активно работать по всем направлениям. Идея в том, чтобы объединить заинтересованных людей в рабочие группы, которые бы работали автономно и разгрузили команду MSFT. Таких рабочих групп может быть много. Так если вы активно работаете с Web-командлетами и недовлетварены их качеством и возможностями, вы можете получить возможность улучшать их будучи членом рабочей группы. Рабочие группы будут формировать уже начиная с января 20221 года. Включайтесь в работу! Это не обязательно написание кода. Прежде чем писать код, нужно понять проблему, спроектировать решение. Требуется аналитика, квалифицированное обсуждение, разработка новых возможностей, тестирование в реальной среде.

Не запускается 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