Microsoft lanza PowerShell 7.7 con .NET 11 y un cambio de fondo en los identificadores
Microsoft ha publicado PowerShell 7.7, la nueva versión de su intérprete de comandos y lenguaje de automatización multiplataforma, que alcanzó la disponibilidad general el 10 de noviembre de 2026. Se trata de una versión de soporte estándar, conocida por las siglas STS (Standard Term Support), y está construida sobre .NET 11, la plataforma que la compañía ha ido preparando a lo largo del año. El lanzamiento afecta a cualquier persona que use PowerShell en Windows, Linux o macOS, desde administradores de sistemas que gestionan flotas de servidores hasta desarrolladores que lo usan como herramienta de construcción, pruebas o despliegue.
La versión llega con un conjunto de novedades prácticas, entre ellas un cmdlet nuevo para crear directorios temporales, mejoras en la composición de rutas y en la inspección de firmas digitales, y una variable de sesión que permite controlar con precisión la codificación de salida de las aplicaciones nativas. Pero lo más relevante no está en las funciones añadidas, sino en dos decisiones de fondo: un endurecimiento notable de la seguridad, especialmente en Constrained Language Mode y en el remoting, y un cambio incompatible que puede pasar desapercibido hasta que rompe algo, ya que ‘New-Guid’ pasa a generar identificadores UUID de versión 7 en lugar de los de versión 4 que producía hasta ahora.
Junto a 7.7.0, el equipo de PowerShell ha publicado también la actualización de mantenimiento 7.6.10 para la rama de soporte a largo plazo, mientras que las ramas 7.4 y 7.5 quedan fuera de soporte. Es, por tanto, un momento de reordenación del catálogo de versiones que obliga a muchas organizaciones a decidir hacia dónde migran.
Contexto: dos ritmos de publicación que conviven
Para entender el alcance de PowerShell 7.7 conviene recordar cómo organiza Microsoft sus lanzamientos. Desde que PowerShell se convirtió en un proyecto de código abierto y multiplataforma, su ciclo de vida está ligado al de .NET. Las versiones que se apoyan en una edición de .NET con soporte a largo plazo reciben la etiqueta LTS y un periodo de mantenimiento más amplio; las que se construyen sobre una edición de .NET de soporte estándar se marcan como STS y su ventana de soporte es más corta.
En ese esquema, PowerShell 7.6 es la referencia estable del año. Alcanzó la disponibilidad general en marzo de 2026 como versión LTS construida sobre .NET 10, y el propio equipo la presentó entonces como la opción recomendada para la automatización en producción. PowerShell 7.7, en cambio, ocupa el papel de versión de soporte estándar: incorpora antes las novedades del lenguaje y del motor, se apoya en el .NET más reciente y está pensada para quienes quieren estar a la última, aceptando a cambio un horizonte de mantenimiento más corto.
Esta doble vía no es nueva. Ya ocurrió con la convivencia de versiones LTS y STS en ciclos anteriores, y responde a una lógica razonable: las organizaciones conservadoras pueden quedarse en la rama LTS y actualizar con calma, mientras que los equipos que necesitan las últimas capacidades de .NET o del propio PowerShell pueden adoptar la STS. Lo que cambia en esta ocasión es que la publicación de 7.7 coincide con la retirada simultánea de dos ramas, 7.4 y 7.5, lo que deja el panorama reducido a dos opciones con soporte: 7.6 y 7.7.
Antecedentes: de la consola de Windows a herramienta transversal
PowerShell nació como el shell de administración de Windows, con una propuesta diferente a la de los intérpretes tradicionales de Unix: en lugar de encadenar texto, encadena objetos. Esa decisión de diseño, que en su momento parecía una rareza para quienes venían del mundo Linux, se ha convertido con los años en uno de sus principales argumentos. Filtrar, ordenar o transformar resultados sin tener que analizar cadenas de texto simplifica mucho la escritura de scripts complejos.
El salto a .NET multiplataforma y al código abierto cambió su posición en el ecosistema. Hoy PowerShell se instala en distribuciones Linux, en macOS y en contenedores, y se ha convertido en una pieza habitual de las canalizaciones de integración y despliegue continuo. Muchos equipos lo usan como lenguaje común para automatizar tareas que antes se repartían entre scripts por lotes de Windows y guiones de shell en Linux. Ese uso transversal explica por qué cada versión nueva despierta interés más allá del público estrictamente vinculado a Windows: un cambio en el comportamiento de un cmdlet básico puede repercutir en procesos de construcción, en herramientas internas y en tareas programadas que llevan años funcionando sin que nadie las revise.
Las novedades funcionales de PowerShell 7.7
Las notas de versión enumeran un conjunto de mejoras que, sin ser espectaculares, atacan necesidades muy concretas del trabajo diario. Su valor está precisamente en eso: reducen código repetitivo y eliminan pequeñas fuentes de errores.
La primera novedad es ‘New-TemporaryDirectory’. PowerShell ya contaba desde hace tiempo con un cmdlet para crear archivos temporales, pero no tenía un equivalente para carpetas. Hasta ahora, quien necesitaba un directorio de trabajo efímero, por ejemplo para descomprimir un paquete, generar artefactos intermedios o ejecutar pruebas aisladas, tenía que componer a mano la ruta a partir de la carpeta temporal del sistema, inventar un nombre único y crear el directorio. Ese patrón, repetido en innumerables scripts, era propenso a errores: nombres que colisionaban, rutas mal construidas en sistemas que no eran Windows o carpetas creadas fuera de la ubicación temporal esperada.
Con el nuevo cmdlet, esa operación pasa a ser una sola instrucción con un comportamiento coherente en los tres sistemas operativos soportados. Es el tipo de mejora que no aparece en los titulares, pero que se agradece en cualquier repositorio de scripts de cierto tamaño.
La segunda mejora afecta a ‘Join-Path’, uno de los cmdlets más utilizados para construir rutas de forma portable. PowerShell 7.7 le añade el parámetro -Extension, que permite indicar la extensión del archivo resultante en el mismo paso en que se compone la ruta. Parece un detalle menor, pero resuelve un caso muy frecuente: generar nombres de archivos de salida, registros o informes a partir de un nombre base, sin recurrir a concatenaciones de cadenas que suelen terminar con puntos duplicados o extensiones olvidadas.
En el terreno de la verificación de código, ‘Get-AuthenticodeSignature’ devuelve ahora una nueva propiedad, SubjectAlternativeName, con el nombre alternativo del sujeto del certificado de firma. Esta información es útil para quienes auditan la procedencia de scripts, módulos o binarios, ya que permite comprobar con más detalle a quién pertenece realmente un certificado sin tener que bucear manualmente en sus extensiones. En entornos donde se exige que solo se ejecute código firmado por determinadas entidades, disponer de este dato directamente en el objeto devuelto simplifica la escritura de reglas de validación.
La cuarta novedad es una variable de sesión, $PSApplicationOutputEncoding, que permite controlar la codificación con la que PowerShell interpreta la salida de las aplicaciones nativas, es decir, de los ejecutables externos que se lanzan desde el shell. La gestión de codificaciones ha sido históricamente una fuente de quebraderos de cabeza: caracteres acentuados que aparecen corrompidos, salidas de herramientas de línea de comandos que no se pueden procesar correctamente o diferencias de comportamiento entre Windows y Linux.
Disponer de una variable específica, separada de otros ajustes de codificación, da a los autores de scripts un control más fino. Para usuarios hispanohablantes, que trabajan habitualmente con tildes, eñes y otros caracteres fuera del conjunto ASCII básico, esta mejora tiene un impacto práctico directo cuando se integran herramientas externas en flujos de PowerShell.
La seguridad, protagonista de esta versión
Si las novedades funcionales son discretas, el capítulo de seguridad tiene más peso. Según las notas de versión, PowerShell 7.7 endurece Constrained Language Mode y el remoting, con una validación más estricta de los argumentos y de los frames que circulan en las sesiones remotas, y restaura la validación de esquema en los cmdlets CIM.
Constrained Language Mode es el modo de lenguaje restringido que PowerShell aplica en entornos con políticas de control de aplicaciones. Su objetivo es limitar las capacidades del lenguaje que pueden aprovecharse para ejecutar código arbitrario, como el acceso libre a tipos de .NET o la invocación de ciertas API, cuando el script no procede de una fuente de confianza. Es una pieza importante en las estrategias de defensa de muchas organizaciones, porque PowerShell es una herramienta potente y, precisamente por eso, un objetivo atractivo para quien intenta moverse dentro de una red tras un acceso inicial.
El endurecimiento de este modo significa que algunas vías que antes quedaban abiertas se cierran. Para la mayoría de usuarios el cambio será transparente, pero quienes ejecutan scripts en entornos con políticas de control de aplicaciones deberían comprobar que su código sigue comportándose como esperan, ya que operaciones que antes se toleraban pueden ser rechazadas ahora.
El remoting es la capacidad de PowerShell para ejecutar comandos en equipos remotos, y es la base de buena parte de la administración a escala. La versión 7.7 introduce una validación más estricta de los argumentos y de los frames que se intercambian en estas sesiones. En la práctica, esto reduce la superficie expuesta a datos malformados o manipulados que podrían aprovechar debilidades en la forma en que se procesan los mensajes entre cliente y servidor.
Este tipo de endurecimiento tiene un coste potencial: herramientas de terceros o implementaciones personalizadas que generaban mensajes al límite de lo aceptado pueden encontrarse con rechazos. Por eso el endurecimiento del remoting en PowerShell merece una fase de pruebas propia antes de desplegar la nueva versión en servidores que reciben conexiones remotas desde múltiples orígenes.
Por último, se ha restaurado la validación de esquema en los cmdlets CIM, los que se emplean para consultar y gestionar información de sistema mediante el modelo común de información. La palabra clave es “restaurado”: no se trata de una función nueva, sino de recuperar una comprobación que garantiza que los datos manejados se ajustan al esquema esperado. Es una corrección que refuerza la robustez del sistema y que, de nuevo, puede hacer aflorar errores latentes en scripts que hasta ahora funcionaban por la tolerancia del motor.
New-Guid y el salto a UUID versión 7
El cambio que probablemente genere más conversaciones en los equipos técnicos es el de ‘New-Guid’. A partir de PowerShell 7.7, este cmdlet genera identificadores UUID de versión 7 en lugar de los de versión 4 que producía hasta ahora. Las notas de versión lo clasifican como cambio incompatible, y no es para menos.
Los UUID de versión 4 se construyen casi por completo a partir de bits aleatorios. Su gran ventaja es la simplicidad y la práctica imposibilidad de colisión, pero carecen de cualquier orden: dos identificadores generados uno detrás de otro no guardan relación alguna entre sí. Los UUID de versión 7, definidos en la especificación RFC 9562, incorporan en sus bits más significativos una marca de tiempo, seguida de una parte aleatoria. El resultado es un identificador igualmente único a efectos prácticos, pero que se puede ordenar cronológicamente.
Esta propiedad tiene ventajas claras. En bases de datos, los identificadores ordenados por tiempo provocan mucha menos fragmentación en los índices que los completamente aleatorios, porque las nuevas filas tienden a insertarse al final en lugar de dispersarse. En sistemas de registro y trazabilidad, permiten ordenar eventos sin necesidad de un campo de fecha adicional. Por eso la industria lleva tiempo desplazándose hacia este formato, y la propia plataforma .NET ya ofrecía la posibilidad de generarlos de forma nativa antes de este lanzamiento.
El problema surge cuando un script asume, de forma explícita o implícita, propiedades de los UUID versión 4. Hay varios escenarios posibles. Una validación que compruebe el dígito de versión del identificador fallará, porque ahora será un 7 y no un 4. Un proceso que trate los GUID como valores impredecibles, por ejemplo para generar tokens o nombres que no deberían poder adivinarse, debe tener en cuenta que parte del identificador codifica ahora el momento de su creación, lo que filtra información temporal y reduce la porción aleatoria. Y cualquier lógica que dependiera de que dos GUID consecutivos no compartieran prefijo verá que ahora sí lo comparten con frecuencia.
Ninguno de estos casos es especialmente común, pero en organizaciones con años de scripts acumulados basta uno para causar una incidencia. La recomendación del equipo de PowerShell es clara: revisar los scripts frente a la lista de cambios incompatibles antes de desplegar a gran escala. La adopción de UUID versión 7 en PowerShell es, en suma, una mejora técnica sensata que exige, eso sí, una revisión consciente.
Desaparece el aviso de actualizaciones
Otro cambio que llamará la atención de los usuarios habituales es la eliminación de la función de notificación de actualizaciones. Hasta ahora, PowerShell podía mostrar al iniciarse un aviso indicando que había disponible una versión más reciente. Con 7.7, esa notificación desaparece.
La decisión tiene una lectura práctica. En muchos entornos, especialmente en servidores, contenedores y canalizaciones automatizadas, el aviso resultaba irrelevante o incluso molesto, y numerosas organizaciones ya lo desactivaban mediante variables de entorno. Además, la actualización de PowerShell se gestiona cada vez más a través de los mecanismos del propio sistema, como los gestores de paquetes de Linux, la tienda o los canales de actualización de Windows, o las imágenes de contenedor. La contrapartida es que los usuarios que instalaron PowerShell de forma manual y dependían de ese aviso para enterarse de las nuevas versiones tendrán que vigilar por su cuenta el calendario de publicaciones, algo especialmente importante ahora que dos ramas acaban de perder soporte.
Impacto para desarrolladores
Para los desarrolladores, PowerShell 7.7 tiene dos lecturas. La primera es la del lenguaje y las herramientas: los nuevos cmdlets y parámetros reducen código auxiliar en scripts de construcción, pruebas y empaquetado. Un directorio temporal limpio para cada ejecución de pruebas, rutas compuestas con su extensión en un solo paso o una salida de herramientas externas correctamente decodificada son mejoras que se notan en el mantenimiento diario.
La segunda lectura tiene que ver con .NET 11. Al estar construido sobre la plataforma más reciente, PowerShell 7.7 permite cargar ensamblados y bibliotecas que apuntan a esa versión, algo relevante para quienes desarrollan módulos binarios o integran PowerShell en aplicaciones propias. Los equipos que construyen servicios con el ecosistema de Microsoft, por ejemplo quienes trabajan en una API REST con .NET, suelen usar PowerShell para automatizar compilaciones, migraciones de base de datos o despliegues, y alinear la versión del shell con la del runtime simplifica la compatibilidad de dependencias.
También conviene pensar en quienes desarrollan en Windows con herramientas de Linux. Muchos programadores combinan PowerShell en el lado de Windows con un entorno Linux integrado mediante WSL2 en Windows 11, y en ese escenario la nueva variable de codificación puede resultar especialmente útil cuando se invocan desde PowerShell herramientas que producen salida en UTF-8 y se quiere procesar sin caracteres corruptos.
El cambio en ‘New-Guid’ es, para los desarrolladores, el punto a vigilar. Quien genere identificadores en scripts de semillas de datos, en pruebas automatizadas o en herramientas internas debe comprobar que ninguna validación ni ninguna aserción de pruebas depende del formato anterior.
Impacto para administradores de sistemas
Para los administradores, la noticia tiene un componente de calendario tan importante como el técnico. La retirada de soporte de 7.4 y 7.5 significa que los equipos que sigan en esas ramas dejarán de recibir correcciones, incluidas las de seguridad. En un componente con tanto acceso al sistema como un shell de administración, quedarse en una versión sin soporte no es una opción recomendable.
La decisión que tienen ahora por delante es elegir entre 7.6 LTS y 7.7 STS. Para la mayoría de entornos de producción, especialmente servidores con ciclos de cambio controlados, la rama 7.6 seguirá siendo la elección natural: es LTS, acaba de recibir la actualización 7.6.10 y ofrece un horizonte de mantenimiento más largo. La rama 7.7 tiene sentido en estaciones de trabajo de administradores, en entornos de pruebas y en organizaciones que necesitan las mejoras de seguridad o las funciones nuevas cuanto antes y están dispuestas a actualizar con más frecuencia.
Las mejoras de seguridad merecen una mención aparte. Los administradores que aplican políticas de control de aplicaciones y dependen de Constrained Language Mode, o que gestionan servidores mediante remoting de forma masiva, son precisamente quienes más se benefician del endurecimiento, pero también quienes deben probar con más cuidado. Una validación más estricta puede rechazar comportamientos que antes funcionaban, y es preferible descubrirlo en un laboratorio que en una ventana de mantenimiento nocturna.
Comparativa con versiones anteriores y con otros shells
Comparada con 7.6, la versión 7.7 no supone una ruptura de paradigma. La base del lenguaje es la misma, los módulos existentes siguen funcionando en su inmensa mayoría y la experiencia de uso apenas cambia. Las diferencias se concentran en el runtime subyacente, que pasa de .NET 10 a .NET 11, en el puñado de funciones nuevas descritas y en el endurecimiento de seguridad. Frente a las ramas 7.4 y 7.5, que ahora pierden soporte, el salto es mayor y acumula los cambios de varias versiones, lo que refuerza la necesidad de revisar las listas de cambios incompatibles de cada paso intermedio y no solo las de la última.
En comparación con otros intérpretes de comandos, PowerShell mantiene su enfoque particular. Quien domina el scripting en Bash encontrará en PowerShell una filosofía distinta: Bash sobresale en la composición de pequeñas utilidades que intercambian texto, mientras que PowerShell trabaja con objetos estructurados y ofrece una integración profunda con .NET y con la administración de Windows. Ninguno sustituye al otro por completo, y en muchos equipos conviven: Bash para tareas ligadas al sistema en Linux y PowerShell para automatizaciones que cruzan plataformas o que necesitan manipular datos estructurados. Las mejoras de 7.7 en rutas, directorios temporales y codificación van precisamente en la línea de hacer que esa convivencia sea menos friccionada.
La situación al momento de escribir
A fecha de redacción de esta noticia, cinco días después de la disponibilidad general, PowerShell 7.7.0 es la versión STS más reciente y 7.6.10 la última actualización de la rama LTS. Las ramas 7.4 y 7.5 figuran ya como fuera de soporte. Esto deja a las organizaciones con dos caminos soportados y con la necesidad de planificar la migración de los equipos que aún ejecuten versiones retiradas.
En este momento, el mensaje que transmite el equipo de PowerShell a través de las notas de versión es de cautela razonable: la actualización aporta mejoras reales, pero incluye cambios incompatibles que conviene revisar antes de desplegar a gran escala. No hay indicios de problemas generalizados en los primeros días, aunque es habitual que los casos límite afloren a medida que la versión llega a más entornos, y es previsible que en las próximas semanas aparezcan actualizaciones de mantenimiento con correcciones, como ocurre tras cada lanzamiento.
Conviene recordar también que, con la eliminación del aviso de actualizaciones, la responsabilidad de seguir el ritmo de parches recae por completo en los mecanismos de gestión de cada organización. Los equipos que no tengan PowerShell integrado en sus procesos habituales de actualización harían bien en incorporarlo cuanto antes.
Análisis: una versión de consolidación con decisiones valientes
PowerShell 7.7 puede leerse como una versión de consolidación. No introduce grandes cambios en el lenguaje ni redefine la experiencia de uso, pero toma tres decisiones que dicen mucho sobre la dirección del proyecto.
La primera es la apuesta por la seguridad por defecto. Endurecer Constrained Language Mode y el remoting, y restaurar validaciones que se habían perdido, es coherente con un contexto en el que las herramientas de administración son vectores habituales de ataque. Microsoft parece dispuesta a asumir el coste de algunas incompatibilidades a cambio de cerrar puertas, una postura que los equipos de seguridad valorarán y que los responsables de operaciones deberán gestionar.
La segunda es la modernización de comportamientos heredados, con ‘New-Guid’ como ejemplo paradigmático. Cambiar el formato que genera un cmdlet tan básico es una decisión arriesgada, porque afecta a un comportamiento que muchos daban por inmutable. Sin embargo, alinea PowerShell con la tendencia general de la industria hacia identificadores ordenables y aprovecha capacidades que .NET ya ofrecía. El hecho de que se haya introducido en una versión STS, y no en una LTS, permite que la comunidad lo pruebe y detecte problemas antes de que llegue a la próxima rama de soporte largo.
La tercera es la simplificación. Eliminar la notificación de actualizaciones reduce ruido y elimina una función que, en la práctica, muchos desactivaban. Es una señal de que el proyecto confía en los canales de distribución estándar de cada sistema operativo para mantener las instalaciones al día.
En conjunto, el lanzamiento confirma la utilidad del modelo de doble vía. La rama STS actúa como banco de pruebas para cambios que, de demostrar su solidez, acabarán consolidándose en la siguiente LTS. Para la comunidad, esto significa que lo que hoy aparece en 7.7 es un buen indicador de lo que vendrá en la próxima versión de soporte largo, y conviene prestarle atención aunque no se vaya a desplegar de inmediato en producción.
Recomendaciones para la migración
Para quienes estén planificando el paso a la nueva versión, o simplemente la salida de las ramas retiradas, hay una serie de pautas que conviene seguir.
En primer lugar, hay que inventariar las versiones en uso. Antes de decidir nada, es imprescindible saber qué equipos ejecutan 7.4 o 7.5, porque son los que han quedado sin soporte y deben moverse con prioridad. En muchas organizaciones conviven varias versiones sin que nadie tenga una visión completa, sobre todo en servidores antiguos, imágenes de contenedor o agentes de integración continua.
En segundo lugar, conviene elegir la rama de destino según el perfil de cada entorno. Para servidores de producción con ciclos de cambio controlados, 7.6 LTS es la opción más prudente. Para estaciones de trabajo, entornos de desarrollo y equipos que necesiten las novedades de 7.7, la rama STS es adecuada, siempre que se asuma su ciclo de actualización más rápido.
En tercer lugar, es fundamental revisar la lista de cambios incompatibles. A la hora de migrar scripts a PowerShell 7.7 no basta con instalar y ejecutar: hay que leer los breaking changes publicados y buscar en el código usos que puedan verse afectados. El caso de ‘New-Guid’ es el más evidente, y una búsqueda en los repositorios de scripts de cualquier validación del formato de los GUID o de cualquier uso de estos como valores secretos es un buen punto de partida.
En cuarto lugar, hay que probar específicamente los escenarios de seguridad. Los scripts que se ejecutan en Constrained Language Mode, las sesiones de remoting hacia y desde servidores con configuraciones heterogéneas y las automatizaciones basadas en cmdlets CIM deben pasar por un entorno de pruebas antes de llegar a producción. Las validaciones más estrictas pueden destapar errores que llevaban tiempo ocultos.
En quinto lugar, conviene revisar el tratamiento de codificaciones. Si existen scripts que aplicaban soluciones improvisadas para corregir la salida de herramientas externas, la nueva variable $PSApplicationOutputEncoding puede permitir sustituirlas por una configuración explícita y más mantenible.
Por último, es recomendable integrar PowerShell en los procesos de actualización estándar. Sin el aviso integrado, la única forma fiable de mantenerse al día es gestionar PowerShell como cualquier otro componente del sistema, mediante gestores de paquetes, políticas de actualización o la reconstrucción periódica de imágenes. Planificar el ciclo de vida de PowerShell como parte de la gestión de parches evita que se repita la situación de equipos que siguen ejecutando ramas sin soporte sin que nadie lo advierta.
Recursos para ponerse al día con PowerShell
Un lanzamiento como este es buen momento para que quienes usan PowerShell de forma esporádica refuercen sus bases, y para que quienes vienen de otros shells den el paso con un método ordenado. La documentación oficial y las notas de versión son la referencia imprescindible para conocer los detalles concretos de 7.7, pero para aprender el lenguaje de forma estructurada un buen libro sigue siendo una opción muy recomendable.
Entre los títulos más conocidos destaca Learn PowerShell in a Month of Lunches, escrito por Travis Plunk, James Petty, Tyler Leonhardt y Jeff Hicks. Su cuarta edición, publicada por Manning en 2022, está organizada en lecciones breves pensadas para estudiarse en ratos cortos y cubre el uso de PowerShell en Windows, Linux y macOS. Conviene ser claros: el libro es anterior a PowerShell 7.7, por lo que no recoge novedades como ‘New-TemporaryDirectory’, el nuevo comportamiento de ‘New-Guid’ ni el endurecimiento de seguridad de esta versión. Sin embargo, los fundamentos que explica, como el trabajo con objetos en la canalización, el sistema de ayuda, el remoting, la escritura de scripts y la gestión de módulos, siguen plenamente vigentes y son exactamente los que permiten entender y aprovechar los cambios de cada nueva versión. Combinado con la lectura de las notas de versión de 7.7, es una base sólida para quien quiera dominar la herramienta.
Conclusiones
PowerShell 7.7 llega como la nueva versión de soporte estándar del proyecto, construida sobre .NET 11 y disponible desde el 10 de noviembre de 2026. Sus novedades funcionales, con ‘New-TemporaryDirectory’, el parámetro -Extension en ‘Join-Path’, la propiedad SubjectAlternativeName en ‘Get-AuthenticodeSignature’ y la variable $PSApplicationOutputEncoding, resuelven problemas cotidianos con soluciones sencillas y coherentes entre plataformas.
El peso real del lanzamiento está, sin embargo, en sus decisiones de fondo. El endurecimiento de Constrained Language Mode y del remoting, junto con la restauración de la validación de esquema en los cmdlets CIM, refuerza la seguridad de una herramienta con un enorme poder sobre los sistemas. El paso de ‘New-Guid’ a UUID versión 7 moderniza un comportamiento básico y lo alinea con la tendencia de la industria, pero obliga a revisar los scripts que dependían del formato anterior. Y la eliminación del aviso de actualizaciones traslada definitivamente la responsabilidad del mantenimiento a los procesos de cada organización.
La publicación simultánea de 7.6.10 y la retirada de las ramas 7.4 y 7.5 dejan un mensaje claro para administradores y desarrolladores: es momento de revisar qué versiones están en uso, elegir entre la estabilidad de la rama LTS y las novedades de la STS, y planificar una migración ordenada que pase por la lectura de los cambios incompatibles y por pruebas específicas de los escenarios de seguridad. Quien lo haga con método podrá aprovechar las mejoras de PowerShell 7.7 sin sobresaltos; quien lo aplace corre el riesgo de quedarse con un componente crítico sin soporte.