Script personalizado: Despliegue del agente NinjaOne por una tarea programada inmediata de AD en un objeto de política de grupo (GPO)

Tema

En este artículo se explica cómo y en qué situaciones se debe utilizar el script de automatización «NinjaOne Agent Deployment by AD Immediate Scheduled Task GPO» de la biblioteca de plantillas de automatización de NinjaOne.

Entorno

• NinjaOne Endpoint Management
• Microsoft Windows

Descripción

NinjaOne ofrece una función de detección e implementación de Active Directory (AD) que simplifica la implementación de agentes en entornos controlados por dominios de AD. Consulte NinjaOne Endpoint Management: Detección e implementación de Active Directory para obtener más información sobre esta opción.

Como alternativa, puede utilizar un modelo de implementación de agentes basado en dominio que utiliza un objeto de directiva de grupo (GPO) de tarea programada inmediata. Puede ser más adecuado utilizar este modelo si se da al menos una de las siguientes situaciones:

• Necesita implementar el agente en portátiles remotos y dispositivos similares que se conectan a la red a través de una red privada virtual (VPN).
• Tiene un dominio más grande con un gran número de unidades organizativas (OU) que contienen sus objetos de equipo, o necesita realizar la implementación en varias OU simultáneamente.
• Desea implementar el agente en sus objetos de equipo en función de la pertenencia a grupos de seguridad en lugar de por unidad organizativa.
• Desea registrar objetos de equipo de diferentes UO o grupos de seguridad en distintas ubicaciones dentro de NinjaOne.
• Necesita enviar el agente a los objetos de equipo con una frecuencia superior a una vez al día, a la semana o al mes.
• Sus objetos de equipo se conectan a Internet a través de un proxy.
• No puede conectar NinjaOne a su controlador de dominio (DC) por motivos de seguridad.
• No tienes acceso directo al DC y, en su lugar, administras el dominio mediante las Herramientas de administración remota de servidores (RSAT).
• Necesita realizar la implementación tanto en servidores como en estaciones de trabajo simultáneamente.
• Necesita realizar la implementación en objetos de equipo de diferentes segmentos de red, independientemente del segmento en el que resida el DC.

Para utilizar un modelo de implementación de agentes basado en dominio con GPO, acceda al script de automatización disponible en la biblioteca de plantillas de NinjaOne, denominado «NinjaOne Agent Deployment by AD Immediate Scheduled Task GPO». Consulte la Biblioteca de automatización: Scripts de plantillas para conocer los pasos de navegación.

Índice

Seleccione una categoría para obtener más información:

• Características y ventajas adicionales
• Requisitos previos, campos personalizados y valores de variables de script
  • Campos personalizados utilizados para la automatización
  • Variables de script utilizadas para la automatización
• Procesos de scripts de automatización
• Cómo editar el campo personalizado de la lista de destinos de GPO de NinjaOne
• Recursos adicionales

Características y ventajas adicionales

Además de los casos de uso descritos en la sección «Descripción» de este artículo, este script ofrece las siguientes características y ventajas:

• El GPO generado por la automatización es una tarea programada inmediata. La tarea se aplicará inmediatamente en la siguiente actualización automática o manual de la política de grupo, por lo que no es necesario reiniciar los puntos finales para implementar el agente de NinjaOne. La tarea se volverá a aplicar de forma continua en cada actualización automática o manual de la política de grupo a partir de entonces hasta que el agente se haya implementado correctamente. La tarea también se aplicará a dispositivos remotos, como ordenadores portátiles, cada vez que se conecten a la red, ya sea a través de una VPN o de otro modo, y posteriormente al DC, sin necesidad de una VPN «siempre activa».
• El proceso descargará automáticamente el archivo de instalación genérico del agente desde la plataforma NinjaOne en la que está registrado el dispositivo que lo ejecuta, y verificará la firma digital.
• Esta automatización es totalmente compatible con entornos de Microsoft Entra Domain Services, y no es necesario mantener un servidor de gestión conectado permanentemente. Guardará todos los archivos requeridos por el GPO en el almacén de directivas de grupo.
• Tenga en cuenta que este script no es compatible con Microsoft Entra ID ni con Microsoft Intune. Para obtener instrucciones sobre cómo realizar la implementación a través de Intune, consulte Instalación del agente NinjaOne: Implementación a través de Microsoft Intune.
• Cuando sea aplicable, NinjaOne pasará la contraseña del proxy a la automatización a través de un campo personalizado seguro y solo la almacenará en un estado cifrado, y únicamente dentro de la tarea programada inmediata en el DC. El GPO pasará la contraseña cifrada al punto final como un argumento de script de PowerShell, por lo que nunca se almacenará en el punto final ni en ningún otro lugar en texto sin cifrar.
• El script ejecutado por el GPO tiene las siguientes características:
  • Detectará si el servicio del agente de NinjaOne está instalado en el punto final y solo intentará instalar el agente si no se encuentra el servicio. El script detectará y eliminará cualquier resto de instalaciones fallidas o desinstalaciones anteriores para maximizar la probabilidad de una implementación exitosa.
  • Comprobará el encabezado del archivo de instalación actual del agente de NinjaOne (solo descargará el encabezado, no el archivo completo) para determinar si hay una actualización disponible y, en caso afirmativo, la descargará y verificará. Esto garantiza que sus terminales no instalen un agente obsoleto solo para actualizarse inmediatamente después.
  • Opcionalmente, puede escribir eventos en el Registro de eventos de Windows para facilitar la resolución de problemas y el diagnóstico de implementaciones fallidas.
• Como medida de seguridad, el script de automatización almacenará las referencias a las unidades organizativas (OU) o grupos de seguridad utilizadas para determinar el ID del token de ubicación como identificadores únicos globales (GUID), en lugar de nombres en texto sin formato.

Requisitos previos, campos personalizados y valores de variables de script

La automatización de NinjaOne Agent Deployment mediante la tarea programada inmediata de GPO de AD asumirá que ha activado la tokenización de agentes, ya que utilizará los ID de token para determinar la ubicación en la que se registrarán los endpoints. Consulte NinjaOne Platform: Agent Tokenization para obtener más información sobre la tokenización de agentes.

Dependiendo de sus privilegios de acceso dentro del dominio, puede ejecutar este script de automatización en cualquier DC o en cualquier equipo unido al dominio que tenga instaladas y activas las características opcionales de Windows RSAT Active Directory y RSAT Group Policy .

Si la configuración de su dominio impide que la cuenta del sistema del DC local realice cambios a nivel de dominio, ejecute la automatización utilizando credenciales con los privilegios adecuados. Estos cambios incluyen la creación e importación de GPO, la lectura de objetos de AD y la lectura y escritura en el recurso compartido del volumen del sistema (SYSVOL). Para obtener más información sobre el uso de credenciales en NinjaOne, consulte NinjaOne Endpoint Management: Intercambio de credenciales.

Del mismo modo, si va a leer o escribir en campos personalizados, debe ejecutar la automatización con credenciales que puedan elevarse para hacerlo.

El script de automatización escribirá los archivos que necesita en la carpeta {[Su GUID de GPO]} dentro de la carpeta «Policies» del recurso compartido SYSVOL. Este recurso compartido se replicará automáticamente en todos los demás controladores de dominio sin necesidad de características adicionales de Windows, como la replicación del Sistema de Archivos Distribuido (DFS), por lo que el controlador de dominio en el que lo ejecute es arbitrario para dominios con varios controladores de dominio.

Campos personalizados utilizados para la automatización

El script de automatización puede utilizar cualquiera o todos los siguientes campos personalizados. Estos campos personalizados son opcionales, dependiendo de sus necesidades.

Para implementaciones a gran escala, puede resultar útil rellenar el campo personalizado «NinjaOne Location Token ID» a gran escala mediante un archivo de importación CSV. Puede encontrar instrucciones para hacerlo en nuestro Script Share: Importar datos de una hoja de cálculo a campos personalizados (API) (página de la comunidad Dojo).

Variables de script utilizadas para la automatización

El script de automatización utiliza las siguientes variables de script:

Procesos del script de automatización

En esta sección se describen las etapas del flujo de trabajo del proceso del script de automatización.

Etapa uno: Preliminares

El script comienza validando todos los requisitos previos y fallará inmediatamente si alguno de ellos no se cumple.

Algunos ejemplos son, entre otros:

• Validación de las variables del script
• Asegurarse de que el punto final esté unido al dominio y sea un DC u otro equipo con RSAT para AD y GPO instalado y activo
• Asegurarse de que la cuenta que ejecuta el script está activa y puede escribir en SYSVOL

A continuación, el script obtendrá la lista de todos los objetos de equipo y recuperará todas las unidades organizativas (OU) y grupos de seguridad que los contengan, lo que filtrará aquellos que solo contengan objetos de usuario. A continuación, el script recuperará el ID del token de ubicación, ya sea de la variable del script o del campo personalizado.

Fase dos: Configuración de la selección del ámbito de destino

La siguiente etapa depende del ámbito de destino. Para las unidades organizativas (OU) y los grupos de seguridad, si es la primera vez que ejecuta el script, o si selecciona «Recrear lista de destinos», el script rellenará el campo personalizado «Lista de destinos de GPO de NinjaOne» con la lista de nombres de OU o grupos de seguridad junto con el ID de token de ubicación proporcionado, y luego se detendrá. El script devolverá los nombres canónicos de las OU en lugar de sus nombres distinguidos, para que sean más fáciles de entender.

En este punto, puede editar el ámbito de implementación y, opcionalmente, controlar en qué ubicaciones registrará los objetos de equipo en cada unidad organizativa o grupo de seguridad. Para obtener instrucciones, consulte la sección de este artículo titulada Cómo editar el campo personalizado «Lista de destinos de GPO de NinjaOne».

Tercera etapa: cifrado de la contraseña del proxy

Si ha configurado detalles de proxy que incluyen una contraseña, el script leerá el campo personalizado seguro y cifrará la cadena de la misma manera que cuando se cifra localmente.

Fase cuatro: Creación del GPO principal y los archivos de apoyo

El script de automatización realiza las siguientes acciones durante la etapa cuatro:

1. El script de automatización eliminará cualquier GPO de implementación preexistente que se encuentre con el mismo nombre para eliminar todos los enlaces preexistentes.
2. El script creará un nuevo GPO y personalizará la plantilla incluida en el script de automatización para el dominio y el DC en el que se está ejecutando.
3. El script importará el contenido del GPO personalizado al GPO recién creado. El script dirigirá y vinculará el GPO según corresponda, ya sea en la raíz del dominio, a nivel de unidad organizativa (OU), en la raíz del dominio con filtrado de grupo de seguridad de la tarea programada inmediata, o no lo hará en absoluto.

4. Una vez que el GPO finalizado esté en su lugar y vinculado y filtrado según corresponda, el script de automatización generará el script que el GPO activará al actualizar la política, el cual se personaliza según el dominio y el DC. El script se personaliza automáticamente según sea necesario, incluyendo el registro de eventos de Windows, la orientación a la UO o al grupo de seguridad, las comprobaciones de actualización del agente y otras especificaciones.

El script se guardará automáticamente en la carpeta del GPO.

5. Para la selección de unidades organizativas y grupos de seguridad, el script de automatización escribirá un archivo CSV de consulta con los GUID de destino y los GUID de ubicación de NinjaOne correspondientes en la carpeta del GPO. Si ha seleccionado «Lista de equipos de salida», el script también escribirá la lista de unidades organizativas y grupos de seguridad de destino incluidos en el ámbito, así como sus respectivos objetos de equipo, en el campo personalizado «Lista de nombres de host del GPO de NinjaOne ».

6. El script de automatización descargará el archivo de instalación del agente en la carpeta GPO y verificará la firma digital antes de mostrar un mensaje con el resultado final.

Fase cinco: Proceso del script GPO

Cuando la actualización automática o manual de la política de grupo active el script, este comprobará primero si existe el servicio del agente de NinjaOne y, en caso afirmativo, se cerrará inmediatamente.

Si el servicio del agente de NinjaOne no existe, el script eliminará todos los posibles restos de cualquier instalación fallida o intento de desinstalación anterior para maximizar las posibilidades de que la instalación se realice con éxito.

El siguiente paso depende de la configuración del ámbito de destino:

• Para la selección de unidades organizativas (OU), el script recuperará el GUID de la OU del punto final y lo comparará con los de la búsqueda en el CSV. Esta comparación determinará el ID del token de ubicación de NinjaOne.
• Para la selección de grupos de seguridad, el script recuperará los GUID de los grupos de seguridad a los que pertenece el punto final y los comparará con los de la búsqueda en el CSV. Esta comparación determinará el ID del token de ubicación de NinjaOne.
• Para la raíz del dominio o sin selección de objetivos, el ID del token de ubicación proporcionado por la variable de script o el campo personalizado ya está codificado de forma fija.

La siguiente acción que realizará el script de GPO depende de la plataforma desde la que se haya ejecutado la automatización. Según corresponda, el script de GPO copiará el archivo de instalación del agente desde el controlador de dominio, o bien comprobará la fecha del archivo de instalación del agente actualmente disponible en NinjaOne a partir de su encabezado. Si la fecha del archivo de instalación disponible en NinjaOne es la misma que la del archivo en el controlador de dominio, el script copiará el archivo de instalación del agente desde el controlador de dominio. Sin embargo, si la fecha del archivo de instalación disponible en NinjaOne es posterior a la del controlador de dominio, el script descargará el archivo de instalación del agente más reciente y verificará su firma digital. Si la descarga o la verificación de la firma digital fallan, el script recurrirá a copiar el archivo de instalación desde el controlador de dominio; si tiene éxito, el script utilizará el archivo más reciente.

A continuación, el script instalará el agente, configurará el dispositivo para que se registre en la ubicación correcta según lo determinado por el ID del token de ubicación y eliminará la copia local.

Si ha proporcionado una configuración de proxy, el script la configurará una vez instalado el agente. Si la configuración de proxy incluye una contraseña, esta se pasará como una cadena cifrada en forma de argumento del script, por lo que nunca se almacenará en el punto final.

Por último, el script esperará a confirmar el registro correcto en la aplicación web de NinjaOne, lo cual puede fallar si el ID del token de ubicación no es válido. Tras confirmar el estado del registro, el script se cerrará.

Si ha seleccionado Habilitar registro de eventos, el script escribirá eventos en el registro de eventos de la aplicación con el origen NinjaOneGPODeployment durante todo el proceso. En la siguiente Figura 6, observe el origen NinjaOneGPODeployment en el registro de la aplicación :

Cómo editar el campo personalizado «Lista de destinos de GPO de NinjaOne»

Puede editar el campo personalizado «Lista de destinos de GPO de NinjaOne » después de la primera ejecución del script, tras recrear la lista de destinos o en cualquier otro momento posterior.

Para eliminar una unidad organizativa (OU) o un grupo de seguridad del ámbito, elimine la fila con la opción Eliminar fila del menú de acciones. Consulte la Figura 8 para ver un ejemplo ilustrado.

Debe realizar al menos un cambio en la lista de destinos inicial al seleccionar las OU, ya sea eliminando una o más filas del ámbito o cambiando uno o más ID de token de ubicación.

Ejecutar la automatización mientras se seleccionan todas las unidades organizativas con el mismo ID de token de ubicación tendrá el mismo resultado que seleccionar la raíz del dominio, por lo que, en este escenario, la automatización fallará.

Tenga en cuenta que este es un escenario diferente al de seleccionar todos los grupos de seguridad sin cambiar ningún ID de token de ubicación, ya que puede haber casos en los que no todos los objetos de equipo sean miembros de un grupo.

Para cada unidad organizativa o grupo de seguridad en la que desee cambiar la ubicación de destino, necesitará el ID de token de ubicación correspondiente.

Cómo obtener el ID del token de ubicación

Para encontrar su ID de token de ubicación en NinjaOne, siga estos pasos:

1. Vaya al panel de control del sistema de NinjaOne y abra la pestaña Dispositivos . Seleccione Instaladores de agentes.
2. Copie el ID de token de la ubicación que necesite de la columna «Token» y péguelo en la columna «ID de token» de la fila correspondiente en la lista de destino. El ID de token que elija debe ser compatible con una función de dispositivo basada en Windows; de lo contrario, esos puntos finales no podrán registrarse en la plataforma.

3. Cuando haya terminado, guarde los cambios.
4. Vuelva a ejecutar el script de automatización. El script validará los cambios y fallará si se cumple una o más de las siguientes condiciones:
   • Ha eliminado la fila de encabezado, la fila final o todas las filas de destino.
   • Está seleccionando unidades organizativas (OU), pero no ha realizado ningún cambio en el campo personalizado.
   • Ha establecido el «Ámbito de destino» en «Grupos de seguridad», pero el campo personalizado contiene unidades organizativas (OU), o viceversa.
   • Ha editado los nombres de las unidades organizativas o de los grupos de seguridad, por lo que ya no coinciden con el DC.
   • Existen uno o más objetos de equipo en varios grupos de seguridad con ID de token de ubicación conflictivos.
   • Algún ID de token se ha registrado en un formato GUID no válido.

Una vez que el script de automatización valide el campo personalizado, pasará a la tercera fase.

Recursos adicionales

Para obtener más información sobre cómo automatizar tus flujos de trabajo de NinjaOne y personalizar tu instancia, consulta los siguientes artículos:

• Scripting, automatización, CLI: Catálogo de recursos
• Campos personalizados de NinjaOne: Guía de inicio rápido