about_Windows_Powershell_5.1
Descripción breve
Describe las nuevas características que se incluyen en Windows PowerShell 5.1.
Descripción larga
Windows PowerShell 5.1 incluye nuevas características importantes que amplían su uso, mejoran su facilidad de uso y permiten controlar y administrar entornos basados en Windows de forma más sencilla y completa.
Windows PowerShell 5.1 es compatible con versiones anteriores. Los cmdlets, proveedores, módulos, complementos, scripts, funciones y perfiles diseñados para Windows PowerShell 4.0, Windows PowerShell 3.0 y Windows PowerShell 2.0 suelen funcionar en Windows PowerShell 5.1 sin cambios.
- Nuevos cmdlets: usuarios locales y grupos; Get-ComputerInfo
- En las mejoras de PowerShellGet se incluyen la aplicación de módulos firmados y la instalación de módulos JEA
- PackageManagement ha agregado compatibilidad con contenedores, configuración de CBS, configuración basada en EXE y paquetes de CAB
- Mejoras de depuración para las clases DSC y PowerShell
- Mejoras de seguridad, incluido el cumplimiento de módulos firmados por catálogos procedentes del servidor de extracción y al usar cmdlets de PowerShellGet
- Respuestas a varios problemas y varias solicitudes de usuarios
Windows PowerShell 5.1 se instala de forma predeterminada en Windows Server versión 2016 y posteriores y en la versión 10 y posteriores del cliente de Windows.
Para instalar Windows PowerShell 5.1 en versiones anteriores de Windows, consulte Instalación y configuración de WMF 5.1. Asegúrate de leer los detalles de descarga y cumplir todos los requisitos del sistema antes de instalar Windows Management Framework 5.1.
También puede leer sobre los cambios en Windows PowerShell 5.1 en Novedades de Windows PowerShell.
Ediciones de PowerShell
A partir de la versión 5.1, PowerShell está disponible en diferentes ediciones que denotan distintos conjuntos de características y compatibilidad de la plataforma.
- Desktop Edition: basado en .NET Framework y proporciona compatibilidad con scripts y módulos destinados a las versiones de PowerShell que se ejecutan en las ediciones de superficie completa de Windows como Server Core y Windows Desktop.
- Core Edition: basado en .NET Core y proporciona compatibilidad con scripts y módulos destinados a las versiones de PowerShell que se ejecutan en las ediciones de superficie completa de Windows como Nano Server y Windows IoT.
Más información sobre el uso de las ediciones de PowerShell
- Determinación de la edición de ejecución de PowerShell con $PSVersionTable
- Filtrado de los resultados de Get-Module mediante CompatiblePSEditions con el parámetro PSEdition
- Impedir la ejecución de scripts, a menos que se ejecuten en una edición compatible de PowerShell
- Declarar la compatibilidad de un módulo con versiones específicas de PowerShell
Cmdlets del catálogo
Se han agregado dos nuevos cmdlets en el módulo Microsoft.PowerShell.Security . Estos cmdlets generan y validan los archivos de catálogo de Windows.
New-FileCatalog
New-FileCatalog
crea un archivo de catálogo de Windows para el conjunto de carpetas y archivos.
Este archivo de catálogo contiene hashes para todos los archivos de las rutas de acceso especificadas. Los usuarios pueden distribuir el conjunto de carpetas junto con el correspondiente archivo de catálogo que representa a esas carpetas. Esta información es útil para validar si se han realizado cambios en las carpetas desde que se creó el catálogo.
New-FileCatalog [-CatalogFilePath] <string> [[-Path] <string[]>]
[-CatalogVersion <int>] [-WhatIf] [-Confirm] [<CommonParameters>]
Se admiten las versiones 1 y 2 del catálogo. La versión 1, utiliza el algoritmo hash SHA1 para crear los hashes de archivo y la versión 2 utiliza SHA256. Debe usar la versión 2 del catálogo.
Para comprobar la integridad del archivo de catálogo (Pester.cat en el ejemplo anterior), fírmelo mediante el cmdlet Set-AuthenticodeSignature.
Test-FileCatalog
Test-FileCatalog
valida el catálogo que representa un conjunto de carpetas.
Test-FileCatalog [-Detailed] [-FilesToSkip <String[]>]
[-CatalogFilePath] <String> [[-Path] <String[]>]
[-WhatIf] [-Confirm] [<CommonParameters>]
Este cmdlet compara todos los hashes de archivo y sus rutas de acceso relativas que se encuentran en un catálogo con archivos en disco. Si detecta algún error de coincidencia entre los hashes de archivo y las rutas de acceso, devuelve el estado como ValidationFailed
. Los usuarios pueden recuperar toda esta información mediante el parámetro Detailed . También muestra el estado de firma del catálogo en la propiedad Signature , que equivale a llamar al cmdlet Get-AuthenticodeSignature en el archivo de catálogo. Los usuarios también pueden omitir cualquier archivo durante la validación mediante el parámetro FilesToSkip .
Caché de análisis de módulo
A partir de WMF 5.1, PowerShell proporciona control sobre el archivo que se usa para almacenar en caché los datos sobre un módulo, como los comandos que exporta.
De manera predeterminada, esta caché se almacena en el archivo ${env:LOCALAPPDATA}\Microsoft\Windows\PowerShell\ModuleAnalysisCache
. La caché normalmente se lee en el inicio al buscar un comando y se escribe en un subproceso en segundo plano después de que se importa un módulo.
Para cambiar la ubicación predeterminada de la memoria caché, establezca la variable de entorno $env:PSModuleAnalysisCachePath
antes de iniciar PowerShell. Los cambios en esta variable de entorno solo afectan a los procesos secundarios.
El valor debe asignar un nombre a una ruta de acceso completa (nombre de archivo incluido) en la que PowerShell tiene permiso para crear y escribir archivos. Para deshabilitar la caché del archivo, establezca este valor en una ubicación no válida, como por ejemplo:
$env:PSModuleAnalysisCachePath = 'nul'
Esto establece la ruta de acceso en un dispositivo no válido. Si PowerShell no puede escribir en la ruta de acceso, no se devuelve ningún error, pero puede ver informes de errores mediante un seguimiento:
Trace-Command -PSHost -Name Modules -Expression {
Import-Module Microsoft.PowerShell.Management -Force
}
Al escribir la memoria caché, PowerShell comprueba si hay módulos que ya no existen para evitar una caché innecesariamente grande. Puede deshabilitar las comprobaciones mediante la siguiente configuración:
$env:PSDisableModuleAnalysisCacheCleanup = 1
Establecer esta variable de entorno surte efecto inmediatamente en el proceso actual.
Especificación de la versión del módulo
En WMF 5.1, using module
se comporta de la misma forma que las restantes construcciones relacionadas con módulos de PowerShell. Anteriormente, no tenía forma de especificar una versión de módulo determinada. Si hay varias versiones presentes, se produjo un error.
En WMF 5.1:
Puede usar el constructor ModuleSpecification (tabla hash). Esta tabla hash tiene el mismo formato que
Get-Module -FullyQualifiedName
.Ejemplo:
using module @{ModuleName = 'PSReadLine'; RequiredVersion = '1.1'}
Si hay varias versiones del módulo, PowerShell usa la misma lógica de resolución que
Import-Module
y no devuelve un error.
Mejoras en Pester
En WMF 5.1, la versión de Pester que se incluye con PowerShell se actualizó de 3.3.5 a 3.4.0. Puede revisar los cambios en las versiones 3.3.5 a 3.4.0 inspeccionando el CHANGELOG en el repositorio de GitHub.
PALABRAS CLAVE
Novedades de Windows PowerShell 5.1