NinjaOne lanzó la funcionalidad de campos personalizados en 2021, añadiendo un nuevo nivel de flexibilidad, personalización y poder de automatización a nuestra plataforma. Los campos personalizados son una función avanzada que requiere configuración para su uso, pero una vez que empiezas, el poder y la flexibilidad de esta función son casi ilimitados. En la primera parte de esta guía, te presentaremos dos casos de uso muy útiles de los campos personalizados en NinjaOne:
Una visión rápida de los campos personalizados en NinjaOne
Roles de los campos personalizados
Los campos personalizados de NinjaOne se dividen en dos categorías: los campos personalizados globales, que se aplican a todos los dispositivos, independientemente de su tipo, y los campos personalizados basados en roles, que se aplican únicamente a tipos específicos de dispositivos.
Un campo personalizado global puede utilizar algún tipo de número de identificación de activo universal que se aplica a todos los dispositivos. Por ejemplo, puedes utilizar campos personalizados basados en roles para asignar un propietario a estaciones de trabajo y a portátiles, pero no a servidores.
Tipos de campos personalizados
NinjaOne ofrece más de veinte tipos de campos personalizados, desde texto a números enteros, pasando por desplegables y campos de mapeo de dispositivos. También proporcionamos elementos de interfaz de usuario para que los campos personalizados sean más fáciles de usar.
Acceso
Cada campo personalizado puede personalizarse para el acceso de técnicos y scripts, lo que te permite controlar quién tiene acceso a qué datos.
Caso práctico n.º 1: supervisar prácticamente todo
Nada más instalas el agente NinjaOne, te proporcionamos cientos de puntos de datos sobre cada endpoint supervisado, desde especificaciones de hardware hasta software instalado y utilización de la CPU. Aun así, los puntos de datos específicos y las necesidades de supervisión de cada empresa son únicas.
Los campos personalizados de NinjaOne te permiten recopilar, almacenar y supervisar casi cualquier punto de datos de un endpoint, asegurándote de que tienes la información que necesitas para tomar decisiones. Estos son algunos ejemplos que hemos visto de nuestros socios:
- Identificar y almacenar el plan de energía actual
- Documentar las cuentas de administrador local existentes
- Obtener una lista de tareas programadas en un dispositivo
- Controlar la temperatura de la CPU
- Controlar el estado de la batería
Cómo hacerlo
Veamos un ejemplo de configuración de un campo personalizado y un script para controlar el estado de la batería.
Para crear una supervisión personalizada utilizando campos personalizados, necesitarás:
- Un campo personalizado
- Un script para recopilar y almacenar los datos
- Una condición personalizada para crear una alerta
Configurar el campo personalizado
El campo personalizado se utilizará para almacenar los datos devueltos por un script.
1) Añade un nuevo campo personalizado. Como vamos a monitorizar el estado de la batería de los portátiles, crearemos un campo personalizado de rol.
2) El siguiente paso consiste en configurar el campo personalizado. Como queremos que este campo se escriba a través de un script, configuraremos el acceso del técnico a «Sólo lectura» y el acceso del script a «Lectura / Escritura».
Nota: si el acceso al script no está configurado en «Escribir» o «Leer/Escribir», no podrás escribir en el campo a partir de un script.
3) Ahora tenemos que asignar el campo personalizado de rol a un rol de dispositivo. Seguidamente, ve a «Roles» y selecciona el o los tipo(s) de rol a los que deseas aplicar este campo. En este caso, asignaremos este campo personalizado de rol al rol Windows Laptop.
Configurar la supervisión
Las condiciones en NinjaOne se utilizan para supervisar los cambios de estado en un endpoint. NinjaOne incluye la posibilidad de supervisar campos personalizados. Vamos a configurar una supervisión para hacer un seguimiento de las advertencias o la degradación de la batería.
- En la política que elijas, ve a «Condiciones» y haz clic en «Añadir una condición»
- Selecciona el tipo de condición «Campos personalizados»
- En «El valor del campo personalizado debe cumplir alguna condición», selecciona «Añadir» y busca «Estado de la batería»
- Selecciona la opción «Contiene» y añade «Degradado»
- Repite los pasos 3 y 4, pero cambia «Degradado» por «Advertencia»
- Define los parámetros de gravedad, prioridad, canal de notificación y gestión de tickets según tus preferencias y haz clic en «Añadir».
Si se activa la condición, verás algo así:
Crear un script para extraer datos
Tenemos que escribir un script que extraiga los datos del endpoint y los almacene en nuestro campo personalizado. Vamos a modificar el script que se encuentra aquí (tendrás que estar conectado a NinjaOne para verlo).
$Battery = Get-CimInstance -ClassName win32_battery Switch ($Battery.Availability) { 1 { $Availability = "Other" ;break} 2 { $Availability = "Not using battery"} 3 { $Availability = "Running or Full Power";break} 4 {$Availability = "Warning" ;break} 5 { $Availability = "In Test";break} 6 { $Availability = "Not Applicable";break} 7 { $Availability = "Power Off";break} 8 { $Availability = "Off Line";break} 9 { $Availability = "Off Duty";break} 10 {$Availability = "Degraded";break} 11 {$Availability = "Not Installed";break} 12 {$Availability = "Install Error";break} 13 { $Availability = "Power Save - Unknown";break} 14 { $Availability = "Power Save - Low Power Mode" ;break} 15 { $Availability = "Power Save - Standby";break}} 16 { $Availability = "Power Cycle";break} 17 { $Availability = "Power Save - Warning";break} } $BatteryOutString = "Status: $($Battery.Status)", "Battery Name: $($Battery.name)", "Charge Remaining: $($Battery.EstimatedChargeRemaining)", "Estimated runtime: $($Battery.EstimatedRunTime)", "Availability: $Availability" | Format-Table | Out-String Ninja-Property-Set batteryState $BatteryOutString
Este script extrae la información de la batería, la formatea y luego la escribe en el campo personalizado «batteryStatus».
La única parte específica de NinjaOne de este script Powershell es la línea final:
Ninja-Property-Set batteryState $BatteryOutString
Ninja-Property-Set es el comando Powershell de NinjaOne para establecer un campo personalizado a un valor específico. La sintaxis es la siguiente:
Ninja-Property-Set fieldName Value
En este caso, establecemos el campo batteryState al valor almacenado en la variable $BatteryOutString.
Añadir este script a NinjaOne es fácil.
- Ve a «Configuración» > «Scripting»
- Haz clic en «Añadir un nuevo script»
- Copia el código anterior en el IDE
- Si tu campo personalizado no se llama «batteryState», actualiza el nombre del campo junto a Ninja-Property-Set
- Establece los parámetros del script de la siguiente forma:
- Nombre: establecer el estado de la batería
- Lengua: PowerShell
- Sistema operativo: Windows
- Arquitectura: todas
- Guarda el script
Es el momento de montar las piezas
Ahora que tienes tu campo personalizado, condición y script, es el momento de montar las piezas para poder automatizar esta supervisión.
Abre la política a la que has añadido tu condición anteriormente y dirígete a «Scripts programados».
Haz clic en «Añadir un script programado».
Haz clic en «Añadir script».
Selecciona el script «Establecer estado de la batería» que creamos anteriormente.
Puedes ejecutar este script con la frecuencia que consideres necesaria. Para que se ejecute cada hora, selecciona «Cada» en el menú desplegable «Programación» y establece «Ocurre cada» en 1 hora. A continuación, haz clic en «Guardar».
El script de definición de estado de la batería ahora extraerá datos de todos los endpoints gestionados por esta política cada hora y los escribirá en el campo personalizado. Si el valor de retorno en cualquiera de esos endpoints contiene «advertencia» o «degradado», recibiremos una alerta para que podamos remediarlo.
Este mismo proceso puede utilizarse para supervisar casi cualquier punto de datos que pueda extraerse de un endpoint.
Caso práctico n.º 2: automatización avanzada de scripts
NinjaOne te ofrece varias formas de automatizar tareas en todos sus endpoints gestionados, que van desde las más simples a las más complejas.
Los cuatro métodos principales para iniciar automatizaciones en NinjaOne son los siguientes:
- Scripts programados: automatizaciones que se ejecutan periódicamente en todos los endpoints de una política
- Condiciones de activación: automatizaciones que se activan por eventos, cambios de estado o comportamiento del rendimiento en un endpoint
- Tareas programadas: automatizaciones que se ejecutan regularmente en todos los terminales seleccionados
- Scripts ad hoc: automatizaciones que se ejecutan manualmente en uno o varios endpoints
Todos estos métodos te permiten desplegar un conjunto de scripts basados en un único desencadenante temporal o en eventos. Por sí solos, estos métodos de automatización pueden ser realmente potentes y aportar mucho valor, pero no son muy dinámicos.
Para automatizaciones más dinámicas, necesitamos añadir dos conceptos:
- Condiciones del resultado del script
- Campos personalizados
Estas características de NinjaOne permiten encadenar automatizaciones dinámicas basadas en los resultados de un despliegue inicial del script. La principal diferencia es que las condiciones de resultado de script no almacenan valores para su posterior análisis y sólo pueden responder a un único resultado de script.
Contar y alertar sobre la frecuencia de inicios de sesión fallidos
La condición de ID de eventos de Windows intregrada en NinjaOne te permite activar una alerta, crear un ticket o activar la ejecución de un script cada vez que se detecta el ID de un evento. Esto es extremadamente útil para detectar eventos como la creación de una cuenta de administrador, los cambios realizados en el firewall de Windows, o la identificación de un error de Windows Server Backup, donde los eventos singulares son procesables.
Cuando necesitamos un gran número de eventos para que un aviso sea procesable, necesitamos campos personalizados. Por ejemplo, es poco probable que un único inicio de sesión fallido sea procesable. En cambio, diez intentos de inicio de sesión fallidos en la última hora pueden ser una señal de que algo va mal. Entonces, vamos a crear una automatización que cuente los inicios de sesión fallidos en el último período de una hora y alerte si supera el umbral de 10 inicios de sesión fallidos.
Configurar el campo personalizado
Empezaremos creando un campo personalizado para almacenar nuestros intentos de inicio de sesión fallidos. Para este ejercicio, vamos a crear un campo personalizado global, ya que detectaremos los inicios de sesión fallidos en todos los tipos de dispositivos.
- Etiqueta de campo: intentos de inicio de sesión fallidos
- Nombre del campo: failedLoginAttempts
- Tipo de campo: número entero
- Scripts: lectura / escritura
Configuraremos un segundo campo personalizado para obtener el ID de seguridad del intento de inicio de sesión más reciente.
- Etiqueta de campo: Error de inicio de sesión Nombre de usuario
- Nombre del campo: failedAccountLoginUserName
- Tipo de campo: texto
- Scripts: lectura / escritura
Escribir el script de supervisión
A continuación, escribiremos un script para detectar inicios de sesión fallidos. Esto es bastante simple de hacer, simplemente tenemos que consultar el registro de eventos y contar el número de intentos de inicio de sesión fallidos. A continuación, escribiremos el valor devuelto en el campo failedLoginAttempts. También devolveremos el nombre de usuario al campo failedAccountLoginUserName.
$failedLogins = ((Get-EventLog -LogName Security -After (Get-Date).AddDays(-7) -InstanceID 4625) | Select @{Name="UserName";Expression={$_.ReplacementStrings[5]}} | Group-Object -Propert UserName).count $Login = ((Get-EventLog -LogName Security -After (Get-Date).AddDays(-7) -InstanceID 4625) | Select @{Name="UserName";Expression= {$_.ReplacementStrings[5]}} | Group-Object -Propert UserName).name Ninja-Property-Set failedLoginAttempts $failedLogins Ninja-Property-Set failedAccountLoginUserName $Login
Añadir este script a NinjaOne es simple y fácil.
- Ve a «Configuración» > «Scripting»
- Haz clic en «Añadir un nuevo script»
- Copia el código anterior en el IDE
- Si el campo personalizado no se llama «failedLoginAttempts», actualiza el nombre del campo junto a Ninja-Property-Set
- Establece los parámetros del script de la siguiente forma:
- Nombre: Contar los intentos de inicio de sesión fallidos
- Lengua: PowerShell
- Sistema operativo: Windows
- Arquitectura: todas
- Guarda el script
A continuación, tenemos que configurar este script para que se ejecute periódicamente.
- En la política que elijas, ve a «Scripts programados» y haz clic en «Añadir un script programado»
- Haz clic en «Añadir script» y selecciona el script «Contar los intentos de inicio de sesion fallidos»
- Dale un nombre y una descripción al script
- Prográmalo para que se ejecute cada hora
Escribir el script de corrección
Si podemos detectar un alto volumen de intentos fallidos de inicio de sesión, es posible que queramos remediar este problema bloqueando temporalmente esa cuenta. Sacaremos el nombre de usuario del campo failedAccountLoginUserName y deshabilitaremos ese usuario con Powershell.
$User = Ninja-Property-Get failedAccountLoginUserName Disable-LocalUser -Name $User
Establecer la condición
- En la política que elijas, ve a «Condiciones» y haz clic en «Añadir una condición»
- Selecciona el tipo de condición «Campos personalizados»
- En «El valor del campo personalizado debe cumplir alguna condición» selecciona «Añadir» y busca «Intentos de inicio de sesión fallidos». Para un operador, utiliza «superior o igual a» y establece el valor en «10».
- Haz clic en «Aplicar»
- Le daremos a la condición el nombre «Alto número de intentos de inicio de sesión fallidos»
- Establece la gravedad, la prioridad y los intervalos de reinicio
- Indica si quieres que se creen notificaciones y tickets
- Haz clic en «Añadir»
- Si queremos automatizar la desactivación del usuario de la cuenta local, podemos añadir el script «Desactivar el usuario local» como automatización a esta condición
Sigue leyendo la segunda y la tercera parte de la serie aquí:
- https://www.ninjaone.com/es/rmm/end-user-self-service-it-portal/
- https://www.ninjaone.com/blog/asset-lifecycle-management-using-ninjaone/
¿Por qué NinjaOne?
¿Estás harto de probar un RMM tras otro y que todos te decepcionen? Prueba los campos personalizados por ti mismo y descubre por qué NinjaOne es diferente. Pruébalo, ¡es gratis!