ScriptRunner 2020PS7 – Lanzamiento

Con la versión 2020, nuestros clientes recibirán una importante actualización de funciones centrada en las mejoras de PowerShell 7, PowerShell Remoting y ScriptRunner junto con la automatización de la infraestructura. Las siguientes secciones proporcionan una descripción general. Para temas individuales nos referimos a publicaciones de blog separadas, videos y nuestra documentación. Para obtener una lista detallada de todas las funciones nuevas, consulte las notas de la versión en la base de conocimientos de ScriptRunner.

PowerShell 7 en ScriptRunner

El nuevo PowerShell 7 es la versión independiente de la plataforma del popular lenguaje de automatización. Se basa en la plataforma independiente .NET Core Runtime.

Disponible para muchas plataformas, PowerShell 7 permite a los profesionales de TI utilizar un único lenguaje de secuencias de comandos para lograr una gestión unificada de una infraestructura heterogénea.

ScriptRunner, la solución todo en uno líder para la administración de Powershell, admite escenarios de automatización y delegación con PowerShell 7 en paralelo con Windows PowerShell 5.1.

Si desea probar o utilizar PowerShell 7, puede utilizar el paquete PowerShell7pwsh.zip de ScriptRunner Setup.

• Primero instale .NET Core 3.1 Runtime en el servidor ScriptRunner

• Descomprima el archivo zip por completo y copie los archivos en el directorio

  C:\ProgramFiles\ScriptRunner\Service\Pwsh

• ScriptRunner ejecuta los scripts para PowerShell 7 en el entorno de proceso SRXPSCoreHost.exe. Se seleccionan en la Configuración de acción en la aplicación web de administración en las Opciones de PowerShell (Figura 1).

Fig. 1: Seleccione el entorno de proceso “PowerShell 7 Host (experimental)” en la configuración de acción de la aplicación web de administración para ejecutar scripts de PowerShell 7 en ScriptRunner.

No se requieren más precauciones para la ejecución local de scripts en PowerShell 7. Si desea ejecutar scripts en PowerShell 7 en un sistema remoto, como Linux o MacOS, PowerShell 7 debe estar instalado y configurado allí. Puede encontrar los paquetes de instalación adecuados en el repositorio de PowerShell GitHub.

Configuración y uso de SSH con PowerShell 7

Con la introducción de PowerShell 7, la comunicación remota SSH ahora se está centrando en el foco de atención. PowerShell SSH Remoting utiliza el protocolo SSH entre un cliente SSH (en el servidor ScriptRunner) y un servidor SSH (en el sistema de destino).

Para trabajar con SSH y PowerShell 7 en ScriptRunner, se deben seguir los siguientes pasos:

• Instale el cliente SSH y el servidor SSH en el sistema respectivo. En Windows Server 2019, está disponible como característica opcional; para otras plataformas están disponibles las implementaciones respectivas.
• Instalación de PowerShell 7 en los sistemas (consulte la sección PowerShell 7 en ScriptRunner)
• Configurar SSH para usar PowerShell 7
• Configurar la autenticación SSH

Puede encontrar más información aquí:

Conexión remota de PowerShell a través de SSH - PowerShell | Documentos de Microsoft

Habilite la comunicación remota SSH de PowerShell en PowerShell 7 - Thomas Maurer

Para utilizar una conexión SSH con ScriptRunner, necesita la configuración del sistema de destino correspondiente (Figura 2).

Fig. 2: En la pestaña Configuración de destino, seleccione la opción "SSH" para establecer una conexión SSH con ScriptRunner.

Al seleccionar el tipo de sistema de destino apropiado, asignar las credenciales SSH almacenadas y seleccionar la opción PowerShell 7 en la Configuración de acción, podrá administrar sistemas de destino remotos a través de SSH con PowerShell 7.

Para configurar la autenticación SSH en un sistema de destino, cree una credencial para SSH e ingrese la cuenta del usuario SSH (Figura 3). Este usuario debe estar autorizado en el sistema de destino.

Fig. 3: Para configurar la autenticación SSH para un usuario en un sistema de destino específico, primero debe crear una credencial correspondiente. El archivo de clave SSH requerido se recupera del directorio predeterminado como se muestra (opción "Usar el archivo de clave de usuario predeterminado de -/.ssh/. ")

ScriptRunner utiliza archivos de claves SSH existentes de perfiles de usuario existentes o los administra en el propio servidor ScriptRunner.

Los archivos de claves existentes de un usuario en el servidor ScriptRunner se encuentran en el directorio de usuarios de forma predeterminada. Simplemente puede habilitar el directorio predeterminado (-/.ssh/.) o, alternativamente, especificar un directorio diferente (Figura 4).

Fig. 4: Como alternativa al directorio predeterminado en -/.ssh/. También puede especificar un directorio personalizado para un archivo de claves SSH existente.

Si desea centralizar los archivos de claves SSH en ScriptRunner en lugar de los archivos de claves SSH en varios directorios de usuarios, utilice la opción "Contenido del archivo de claves SSH" (Figura 5).

Esta opción le permite copiar el contenido del archivo de clave SSH en la configuración de Credenciales de ScriptRunner. ScriptRunner crea y administra automáticamente un archivo de clave SSH a la vez.

Este procedimiento proporciona más control, seguridad y centralización que el estándar.

Fig. 5: La opción “Contenido del archivo de clave SSH” permite copiar el contenido de un archivo de clave SSH en la Configuración de credenciales de ScriptRunner

Flujos de trabajo con Office365 Power Automate

ScriptRunner es un componente importante de una TI totalmente automatizada. El requisito básico para ello es una cooperación sin errores con los demás componentes básicos de la solución global: flujos de trabajo, sistemas de monitorización, sistemas ITSM y otros autómatas especializados, p. para SAP o en otras aplicaciones especializadas.

La integración de ScriptRunner con sistemas de flujo de trabajo ha sido una característica fija del producto desde 2016. La popularidad de Office 365 ha llevado a muchas empresas a considerar el uso de Microsoft Power Automate en varios escenarios de aplicaciones.

Especialmente para los equipos de operaciones de TI, resulta atractivo el uso de Power Automate como sistema de flujo de trabajo en combinación con ScriptRunner como plataforma para PowerShell. Esto permite implementar procesos complejos con procedimientos de aprobación en Power Automate como un flujo de trabajo. ScriptRunner ejecuta los pasos individuales del flujo de trabajo, especialmente las tareas con PowerShell, como participantes del flujo de trabajo y los resultados se transfieren al flujo de trabajo.

Con la nueva versión, ScriptRunner admite la implementación directa de acciones de ScriptRunner, incluidos los parámetros en Power Automate. Esto permite utilizar cualquier acción de ScriptRunner como bloque de construcción en el flujo de trabajo sin la necesidad de programar llamadas WebAPI complejas ni transferencias de parámetros.

Se deben seguir los siguientes pasos:

• Configurar la puerta de enlace de datos local de Microsoft en ScriptRunner
• Configure un conector de servicio web ScriptRunner para O365 Power Automate y asigne las acciones de ScriptRunner disponibles en el flujo de trabajo
• Exportar un archivo OpenAPI desde ScriptRunner usando la aplicación web Admin
• Cree un "Conector personalizado" en Power Automate e importe el archivo OpenAPI.
• Volver a importar un archivo OpenAPI personalizado después de realizar cambios en una acción de ScriptRunner

Para exportar el archivo OpenAPI, seleccione el conector previamente configurado y ejecute la función de exportación en la barra de acciones (Figura 6).

Fig. 6: Para exportar el archivo OpenAPI, primero seleccione el conector de automatización correspondiente y luego haga clic en "Exportar OpenAPI" en la barra de herramientas.

Ahora cree un nuevo "Conector personalizado" en Power Automate e importe el archivo OpenAPI desde ScriptRunner.

Si el conector personalizado se creó correctamente en Power Automate, debe configurar las opciones para conectarse a la puerta de enlace local y a la autenticación de Windows por motivos de seguridad.

Después de crear un nuevo flujo de Power Automate con activación manual, ahora se pueden crear los pasos del flujo de trabajo.

Se requiere el conector personalizado configurado para realizar más configuraciones. Esto lo podrás encontrar en la sección “Personalizado”.

El Conector personalizado se utiliza para seleccionar entre las diferentes acciones. La acción - SR INTERNAL - se utiliza para la comunicación interna entre Power Automate y ScriptRunner. NO se puede utilizar en un flujo.

Después de seleccionar la acción, se debe configurar la conexión correspondiente. El nombre de usuario y la contraseña para iniciar sesión en el servidor ScriptRunner se almacenan aquí. También se debe seleccionar la puerta de enlace previamente configurada.

Una vez que el conector ha sido completamente configurado, los parámetros ahora se pueden usar directamente dependiendo de la acción seleccionada y asignada en el flujo de trabajo.

Selección del sistema de destino en el momento de la ejecución del script.

El creciente número de escenarios de nuestros clientes y los comentarios que recibimos se incorporan a nuestro desarrollo. Una característica que proporciona mayor flexibilidad a la mesa de servicio es la nueva selección de objetivos en la aplicación web Delegate.

Esta función permite a los usuarios de la aplicación Delegate, p. en Service Desk, para seleccionar un sistema de destino de un conjunto previamente definido en el momento de la ejecución del script en el que se ejecutará una acción. Esto abre una multitud de casos de uso.

Gestión de servicios adicionales de Office 365

La nueva versión de ScriptRunner también ofrece nuevas posibilidades para administrar los servicios de Office 365 con PowerShell.

Se ha implementado una mejora para la conexión a Exchange Online. A partir de ahora se puede utilizar el nuevo módulo PowerShell Exchange Online V2 (EXOv2) (Figura 7).

Para hacer esto, primero se debe instalar el módulo PowerShell ExchangeOnline Management en el servidor ScriptRunner. Luego, ScriptRunner establece, autentica y cierra automáticamente la conexión utilizando el nuevo procedimiento implementado por Microsoft.

Con EXOv2, el módulo para Azure Active Directory ahora también se utiliza para Exchange Online. De este modo se sustituye por completo el antiguo módulo MS Online.

Fig. 7: El nuevo módulo PowerShell Exchange Online V2 (EXOv2) ahora se puede seleccionar como una opción en la Configuración de conexión a la nube de la aplicación de administración ScriptRunner.

El soporte de gestión directa para el ahora muy popular Microsoft Team se implementó de forma completamente nueva (Figura 8). ScriptRunner ahora realiza todo el manejo de la conexión y la autenticación. El módulo PowerShell Microsoft Teams debe estar instalado en el servidor ScriptRunner.

Para comenzar con la administración de PowerShell de Microsoft Teams, también proporcionamos el ActionPack gratuito para Microsoft Teams en nuestro repositorio de GitHub.

Figura 8: Microsoft Teams ahora se puede seleccionar como una opción en la Configuración de conexión a la nube de la aplicación de administración ScriptRunner.

El servicio O365 para Microsoft Teams permite el inicio de sesión basado en certificado en Azure AD para establecer la conexión. Para hacer esto, necesita un certificado válido en ScriptRunner Server. El certificado debe almacenarse en el almacén de certificados local en ScriptRunner Server.

Para obtener información sobre cómo configurar un inicio de sesión basado en certificado en Azure AD, consulte Microsoft Docs: Azure Active Directory: autenticación basada en certificados.

La huella digital del certificado y el ID de la aplicación deben ingresarse en la configuración del sistema de destino.

Azure y otros servicios en la nube

La administración de Azure con el módulo Az también permite el inicio de sesión basado en certificado para la configuración de la conexión (Figura 9). Para ello necesita un certificado válido en el servidor ScriptRunner. El certificado debe almacenarse en el almacén de certificados local en el servidor ScriptRunner.

La huella digital del certificado y el ID de la aplicación deben ingresarse en la configuración del sistema de destino con Az.

Para la gestión de otros servicios en la nube con PowerShell, se ha implementado un nuevo tipo de sistema de destino, el Generic Cloud Target (Figura 10). Esto le permite ingresar una secuencia de comandos de PowerShell para el establecimiento y desconexión de la conexión. Además, se puede cargar un módulo específico en el proceso de conexión.

En el código de PowerShell para el establecimiento de la conexión se puede utilizar la variable $Cred. A esta variable se le asigna la credencial de acceso configurada para el sistema de destino.

Fig. 10: El nuevo tipo de sistema de destino "Generic Cloud Target" permite administrar servicios de nube adicionales con PowerShell y ScriptRunner.

Conexión remota de PowerShell a través de hosts de administración/salto

El uso de los llamados hosts de gestión o de salto tiene una larga tradición en la gestión de infraestructuras. Por lo general, se instalaban numerosas herramientas de administración en dichos sistemas y solo los administradores seleccionados tenían acceso a la máquina y a las herramientas. La principal ventaja es que las herramientas solo necesitan actualizarse en una ubicación y se puede controlar el acceso a las herramientas desde el exterior.

En principio, este concepto también es adecuado para PowerShell en entornos distribuidos. Por ejemplo, es posible crear PowerShell Jump Hosts específicos del sitio en los que se instalen todos los módulos de PowerShell necesarios y se puedan ejecutar los scripts.

ScriptRunner amplía este concepto para utilizar Jump Hosts como "nodos de distribución" a otros sistemas de destino (Figura 11). Esto evita el clásico problema del doble salto de una manera impulsada por políticas.

Además del puro "nodo de distribución", ahora también se pueden construir escenarios simples con objetivos mixtos, p. para ejecutar un script en un sistema de destino remoto y acceder directamente a los recursos de un cliente O365 o Azure desde allí.

También es posible abordar un sistema de destino a través de una cadena de Jump Hosts.

Esta característica también se utiliza para que PowerShell Direct administre máquinas virtuales en hosts Hyper-V o contenedores en Windows Container Service Host.

Fig. 11: ScriptRunner hace posible utilizar Jump Hosts como "nodos de distribución" a otros sistemas de destino o para direccionar un sistema de destino a través de una cadena de Jump Hosts.

Para el uso práctico de esta característica se deben cumplir los siguientes requisitos:

• Los Jump Host están configurados como sistemas de destino con PowerShell Remoting estándar.
• Los sistemas de destino reales están configurados. Estos sistemas de destino también pueden ser servicios en la nube, máquinas virtuales y contenedores a través de PowerShell Direct.
• La configuración se realiza en el sistema de destino real utilizando la función "Acceso a este destino a través de la administración o salto de host indirectamente". Allí se debe seleccionar el host apropiado.
• Para controlar los derechos de acceso para conectarse y ejecutar los scripts y utilizar el "trampolín", se utiliza la credencial almacenada en el sistema de destino respectivo.

Consejo: El informe de PowerShell documenta la conexión a través de Jump Hosts. Si se van a registrar detalles durante la prueba, por ejemplo, se debe activar el interruptor Detallado en la acción ScriptRunner en Opciones de PowerShell.

Comunicación remota PowerShell para Hyper-V, Container y CIM

Los scripts de PowerShell se pueden ejecutar en un sistema de destino remoto. ScriptRunner admite esta posibilidad desde el principio, que ahora se ha ampliado con opciones adicionales. Las opciones adicionales se pueden configurar al crear un nuevo destino remoto de PowerShell.

PowerShell Direct es un método desarrollado por Microsoft para ampliar el uso de PowerShell en entornos virtualizados y reducir la sobrecarga de conexión a máquinas virtuales en contenedores Hyper-V o Docker en Windows Container Service. También ayuda a evitar el problema del doble salto.

En PowerShell Remoting clásico, se debe establecer una conexión directa y una sesión de PowerShell para cada máquina virtual o contenedor. Cuando se utiliza PowerShell Direct, se puede establecer una sesión remota con el host Hyper-V o el host contenedor. Luego las máquinas virtuales o contenedores se pueden direccionar directamente con su ID o nombre.

La opción Sesiones CIM le permite configurar y utilizar conexiones a puntos finales CIM estandarizados. El Instrumental de administración de Windows es compatible con CIM.

Para configurar PowerShell Direct, como en el ejemplo, se debe configurar un sistema de destino con PowerShell Remoting estándar en Hyper-V o host contenedor (Figura 12). Las máquinas virtuales o contenedores se configuran como sistemas de destino adicionales con la opción PowerShell Direct con Hyper-V (para VM) o Container Service (para contenedores Docker).

Como en el ejemplo, se puede utilizar el nombre de la VM o el ID de la VM para este propósito. La credencial de acceso requiere los derechos de ejecución correspondientes de PowerShell en la VM.

Fig. 12: Configuración de una VM o un Contenedor como sistema de destino en ScriptRunner.

Para poder controlar la máquina virtual a través del host con PowerShell Direct, el host Hyper-V debe asignarse como "a través de administración o host de salto indirectamente" en la configuración de la máquina virtual de destino en ScriptRunner (Figura 13). De manera similar, los sistemas de destino del contenedor se configuran con el host del contenedor.

Para obtener el ID del contenedor para la configuración, puede ejecutar el comando Get-Container en el host del contenedor una vez que haya cargado el contenedor del módulo PowerShell.

Fig. 13: Para poder controlar una VM a través del host con PowerShell Direct, se debe seleccionar la opción "Acceder a este destino a través de la administración o saltar al host indirectamente..." en la configuración del sistema de destino.

Escenarios de múltiples objetivos con PowerShell PSSession

En el uso práctico de PowerShell, especialmente en la automatización, se requiere acceso a diferentes sistemas para procesar los scripts, p. al AD interno y Azure AD, a Exchange local y Exchange Online, a Windows Server y diferentes recursos compartidos o bases de datos.

Lo que estos escenarios tienen en común es que se debe acceder a diferentes sistemas, cada uno con sus propios derechos de sistema, en tiempo de ejecución del script.

PowerShell proporciona de forma nativa el concepto de sesiones para este propósito. Por ejemplo, puede utilizar el cmdlet New-PSSession para crear y cambiar entre diferentes sesiones en la línea de comandos. Además, la función de prefijo le permite detectar automáticamente en qué sesión se debe ejecutar un comando en particular.

Ahora puede utilizar esta funcionalidad de PowerShell directamente en ScriptRunner para escenarios de múltiples objetivos. Necesita las definiciones de los parámetros para las sesiones requeridas en el bloque de parámetros del script de PowerShell.

Param
(
…
# PowerShell Remoting Session Type
[System.Management.Automation.Runspaces.PSSession]
$Session1,
[System.Management.Automation.Runspaces.PSSession]
$Session2,
# PowerShell CIM Session Type
[Microsoft.Management.Infrastructure.CimSession]
$cimsession,
…
)

En la configuración de parámetros de una acción de ScriptRunner, los parámetros de la sesión se pueden asignar a un sistema de destino mediante la selección desplegable (Figura 14).

Fig. 14: En la configuración de parámetros de una acción de ScriptRunner, puede asignar parámetros de sesión a un sistema de destino mediante el menú desplegable.

ScriptRunner establece la conexión con el sistema de destino almacenado en tiempo de ejecución cada vez antes de que se inicie el script. El objeto PSSession asociado se pasa al script como parámetro. Después de la ejecución del script, ScriptRunner finaliza automáticamente la sesión.

La sesión se utiliza en el propio script. Ya sea con una línea de programa

Invoke-Command -Session $Session1 -ScriptBlock { ... }
# or
Import-PSSession -Session $Session1 -Modules ...

Esto facilita el desarrollo del guión. Por un lado, ya no es necesario codificar la configuración y finalización de la sesión y, por otro lado, los escenarios de múltiples objetivos se pueden implementar muy fácilmente en un script. Además, se mejora la seguridad al utilizar diferentes credenciales administrativas, ya que en el script solo se puede utilizar la sesión, pero no el nombre de usuario/contraseña ni la credencial.

Usar objetos de PowerShell en consultas

Las consultas son una característica crucial en ScriptRunner desde la versión 2018R1. Además del uso versátil de las consultas de Active Directory, las consultas secuenciadas se han consolidado como una herramienta muy flexible para la implementación de casos de uso.

La idea básica de ofrecer un menú desplegable en la interfaz de usuario para la selección de parámetros ahora se ha ampliado para consultas programadas. Además de los valores de cadena individuales, ahora también se pueden pasar objetos de PowerShell.

Dado que una consulta con script y el script principal se ejecutan cada uno en su propio proceso de PowerShell, los valores de los objetos deben pasarse entre dos procesos de PowerShell separados. Para este propósito se pueden utilizar tanto Hashtable como PowerShell Custom Object. Para usarlos, la tabla hash u objeto personalizado debe estar definido tanto en el script de consulta como en el script principal. Los valores individuales se pasan de la consulta al script principal como una cadena codificada en base64.

En lugar de una sola cadena, el script de consulta completa los valores codificados de una tabla hash en la variable del sistema $SRXEnv.ResultList.

La variable del sistema $SRXEnv.ResultList2 almacena el nombre del objeto que se pasará. Por tanto, el procedimiento es similar al ya conocido para las consultas programadas. El procedimiento es similar si se utiliza un objeto personalizado en lugar de una tabla hash.

# Declaration Hashtable in param block
$hasht = @{ Name = ''; Age = 0 }
# Function code of query with foreach loop
…
$hasht.Name = 'Paul'
$hasht.Age = 31
# Filling the hashtable 
	if ($SRXEnv) {
	$null = $SRXEnv.ResultList.Add($hasht)
	$null = $SRXEnv.ResultList2.Add($hasht.Name)
}

Al probar la consulta, los valores codificados con las cadenas se muestran en la columna de la tabla "Valor de parámetro".

En el script principal, la tabla hash u objeto personalizado también se declara en el bloque de parámetros. La declaración debe corresponder al formulario utilizado en el script de consulta. Este parámetro está vinculado a la consulta en la acción para que los valores de la tabla hash codificada o del objeto personalizado se puedan pasar al script principal en tiempo de ejecución.

Cuando un usuario inicia la acción, la consulta devuelve una lista de objetos con nombre en el menú desplegable de selección. El usuario selecciona un objeto con nombre y los valores codificados se pasan al script principal. ScriptRunner utiliza el tipo de parámetro declarado en el script principal para decodificar la cadena transferida y asigna los valores individuales a las propiedades respectivas en la tabla hash u objeto personalizado.

Se puede acceder a las propiedades directamente.

….
# from declaration of the hashtable as above
$Age = $hasht.Age

Notas sobre el módulo de administración de secretos de PowerShell

El nuevo módulo PowerShell Secrets Management admite el uso de credenciales almacenadas en el almacén de credenciales de Windows y solicitudes de credenciales de servidores de contraseñas. El módulo funciona sólo localmente, es decir, debe instalarse en ScriptRunner Server.

Debido a su arquitectura, su uso se limita únicamente a la ejecución de scripts locales.

No existe ningún valor añadido del módulo en entornos ScriptRunner, al contrario. La capacidad de ejecutar scripts de forma remota, incluso a través de Jump Hosts, mientras se mantiene la administración de credenciales centralizada en ScriptRunner y Password Servers solo es posible con ScriptRunner.