about_Windows_Powershell_5.1

Краткое описание

Описывает новые функции, включенные в Windows PowerShell 5.1.

Подробное описание

Windows PowerShell 5.1 включает значительные новые функции, расширяющие его использование, повышающие удобство использования и позволяющие управлять средами на основе Windows и управлять ими более легко и комплексно.

Windows PowerShell 5.1 является обратно совместимым. Командлеты, поставщики, модули, оснастки, сценарии, функции и профили, предназначенные для Windows PowerShell 4.0, Windows PowerShell 3.0 и Windows PowerShell 2.0, обычно работают в Windows PowerShell 5.1 без изменений.

• Новые командлеты: локальные пользователи и группы; Get-ComputerInfo.
• Улучшения PowerShellGet включают принудительное подписание модулей и установку модулей JEA.
• Дополнительная поддержка PackageManagement для контейнеров, установка CBS, установка на основе EXE, пакеты CAB.
• Улучшения отладки для классов DSC и PowerShell.
• Улучшения для системы безопасности, включая принудительное использование модулей, подписанных каталогом и полученных от опрашивающего сервера, а также при использовании командлетов PowerShellGet.
• Ответы на разные запросы пользователей и решение проблем.

Windows PowerShell 5.1 устанавливается по умолчанию в Windows Server версии 2016 и выше, а клиент Windows версии 10 и выше.

Чтобы установить Windows PowerShell 5.1 в более ранних версиях Windows, см. статью "Установка и настройка WMF 5.1". Перед установкой Windows Management Framework 5.1 обязательно считывайте сведения о скачивании и соблюдайте все требования к системе.

Вы также можете ознакомиться с изменениями в Windows PowerShell 5.1 в статье "Новые возможности" в Windows PowerShell.

Выпуски PowerShell

Начиная с версии 5.1 доступны различные выпуски среды PowerShell, что означает различные наборы возможностей и совместимость с разными платформами.

• Выпуск Desktop: создан на базе платформы .NET Framework и обеспечивает совместимость со сценариями и модулями, предназначенными для версий PowerShell в полноценных выпусках Windows, таких как Server Core и Windows Desktop.
• Выпуск Core Edition: построен на основе .NET Core и обеспечивает совместимость со скриптами и модулями, которые предназначены для версий PowerShell, выполняющихся в выпусках Windows с ограниченными возможностями, таких как Nano Server и Windows IoT.

Дополнительные сведения об использовании выпусков PowerShell

• Определение запущенного выпуска PowerShell с использованием $PSVersionTable
• Фильтрация результатов командлета Get-Module по CompatiblePSEditions с помощью параметра PSEdition
• Запрет на выполнение сценариев в несовместимых выпусках PowerShell
• Объявление совместимости модуля с определенными версиями PowerShell

Командлеты для работы с каталогами

В модуле Microsoft.PowerShell.Security добавлены два новых командлета. Эти командлеты создают и проверяют файлы каталога Windows.

New-FileCatalog

New-FileCatalog создает файл каталога Windows для набора папок и файлов. Файл каталога содержит хэши для всех файлов, находящихся по указанным путям. Пользователь может распространять набор папок вместе с соответствующим файлом каталога, представляющим этих папки. С помощью файла каталога получатель может проверить, были ли изменены папки с момента создания каталога.

New-FileCatalog [-CatalogFilePath] <string> [[-Path] <string[]>]
 [-CatalogVersion <int>] [-WhatIf] [-Confirm] [<CommonParameters>]

Поддерживаются каталоги версий 1 и 2. В версии 1 для создания хэшей файлов используется алгоритм хэширования SHA1, в версии 2 — SHA256. Следует использовать каталог версии 2.

Для проверки целостности файла каталога (Pester.cat в приведенном выше примере) его нужно подписать с помощью командлета Set-AuthenticodeSignature.

Test-FileCatalog

Test-FileCatalog проверяет каталог, представляющий набор папок.

Test-FileCatalog [-Detailed] [-FilesToSkip <String[]>]
 [-CatalogFilePath] <String> [[-Path] <String[]>]
 [-WhatIf] [-Confirm] [<CommonParameters>]

Этот командлет сравнивает все хэши файлов и их относительные пути, найденные в каталоге с файлами на диске. Если он обнаруживает несоответствие между хэшами файлов и путями, он возвращает состояние как ValidationFailed. Пользователи могут получить все эти сведения с помощью подробного параметра. Он также отображает состояние подписи каталога в свойстве Signature , что эквивалентно вызову командлета Get-AuthenticodeSignature в файле каталога. Пользователи также могут пропускать любой файл во время проверки с помощью параметра FilesToSkip .

Кэш анализа модуля

Начиная с WMF 5.1 PowerShell обеспечивает контроль над файлом, который используется для кэширования данных о модуле, например команд, экспортируемых им.

По умолчанию этот кэш хранится в файле ${env:LOCALAPPDATA}\Microsoft\Windows\PowerShell\ModuleAnalysisCache. Кэш обычно считывается при запуске в процессе поиска команды и записывается в фоновом потоке через некоторое время после импорта модуля.

Чтобы изменить расположение кэша по умолчанию, присвойте значение переменной среды $env:PSModuleAnalysisCachePath перед запуском PowerShell. Изменения в этой переменной среды влияют только на дочерние процессы. Значение должно быть полным путем (включая имя файла), на создание и запись файлов по которому у среды PowerShell есть разрешение. Чтобы отключить файловый кэш, укажите в качестве этого значения недопустимое расположение, например:

$env:PSModuleAnalysisCachePath = 'nul'

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

Trace-Command -PSHost -Name Modules -Expression {
  Import-Module Microsoft.PowerShell.Management -Force
}

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

$env:PSDisableModuleAnalysisCacheCleanup = 1

Установка этой переменной среды вступает в силу немедленно в текущем процессе.

Указание версии модуля

В WMF 5.1 using module работает так же, как другие связанные с модулями конструкции в PowerShell. Ранее у вас не было способа указать определенную версию модуля. Если существует несколько версий, это привело к ошибке.

В WMF 5.1:

• Вы можете использовать конструктор ModuleSpecification (Hashtable). Она имеет тот же формат, что и Get-Module -FullyQualifiedName.

  Пример: using module @{ModuleName = 'PSReadLine'; RequiredVersion = '1.1'}

• Если существует несколько версий модуля, PowerShell использует ту же логику разрешения, что Import-Module и не возвращает ошибку.

Усовершенствования Pester

В WMF 5.1 обновлена версия Pester, распространяемая с PowerShell, с 3.3.5 до 3.4.0. Изменения в версиях 3.3.5 до 3.4.0 можно просмотреть, проверив CHANGELOG в репозитории GitHub.

КЛЮЧЕВЫЕ СЛОВА

Новые возможности Windows PowerShell 5.1