NinjaOne ha rilasciato la funzionalità del campo personalizzato nel 2021, aggiungendo un nuovo livello di flessibilità, personalizzazione e potenza di automazione alla nostra piattaforma. I campi personalizzati sono una funzione avanzata che richiede di essere impostata per essere utilizzata, ma quando inizierai a utilizzarla, scoprirai che la potenza e la flessibilità di questa funzione sono quasi illimitate.
Nella prima parte di questa guida, ti illustreremo due potenti situazioni di utilizzo dei campi personalizzati in NinjaOne, tra cui:
Una rapida panoramica dei campi personalizzati in NinjaOne
Ruoli dei campi personalizzati
I campi personalizzati di NinjaOne si dividono in due categorie: campi personalizzati globali, che si applicano a tutti i dispositivi indipendentemente dal loro tipo, e campi personalizzati role-based, che si applicano solo a tipi di dispositivi specifici. Un campo personalizzato globale può utilizzare una sorta di numero ID di risorsa universale, che potrai applicare a tutti i dispositivi. Per fare un esempio, potresti utilizzare campi personalizzati role-based per assegnare un proprietario di dispositivo alle workstation e ai portatili, ma non ai server.
Tipi di campi personalizzati
NinjaOne offre oltre venti tipi di campi personalizzati, da quelli testuali a quelli contenenti numeri interi, da quelli a tendina a quelli di mappatura dei dispositivi. Forniamo anche elementi di interfaccia utente per rendere i campi personalizzati più facili da usare.
Accesso
Ciascun campo personalizzato può essere adattato per l’accesso dei tecnici e degli script, consentendo in questo modo di controllare chi può accedere a quali dati.
Situazione d’uso numero 1: Monitorare praticamente tutto
Non appena si installa l’agente NinjaOne, vengono forniti centinaia di dati su ogni endpoint monitorato, dalle specifiche hardware al software installato, fino all’utilizzo della CPU. Tuttavia, i dati specifici e le esigenze di monitoraggio sono diversi per ogni azienda. I campi personalizzati di NinjaOne ti consentono di raccogliere, archiviare e monitorare quasi tutti i dati provenienti da un endpoint, permettendoti di avere le informazioni necessarie per prendere le tue decisioni. Alcuni esempi che abbiamo visto nei nostri partner:
- Identificare e memorizzare il piano energetico corrente
- Documentare gli account di amministratore locale esistenti
- Ottenere un elenco di attività pianificate su un dispositivo
- Monitoraggio della temperatura della CPU
- Monitoraggio dello stato della batteria
Come fare
Vediamo un esempio di impostazione di un campo personalizzato e di uno script per monitorare lo stato della batteria. Per creare un monitoraggio personalizzato utilizzando i campi personalizzati, è necessario:
- Un campo personalizzato
- Uno script per raccogliere e memorizzare i dati
- Una condizione personalizzata per creare un alert
Configurazione del campo personalizzato
Il campo personalizzato verrà utilizzato per memorizzare i dati restituiti da uno script. 1) Aggiungi un nuovo campo personalizzato. Poiché monitoreremo lo stato della batteria dei portatili, creeremo un campo personalizzato role-based. 
2) Il passo successivo è la configurazione del campo personalizzato. Poiché vogliamo che questo campo venga scritto tramite uno script, imposteremo l’accesso del tecnico su ‘Sola lettura’ e l’accesso dello script su ‘Lettura/scrittura’.
Nota: se l’accesso per gli script non è impostato su “Scrittura” o “Lettura/Scrittura”, non sarai in grado di scrivere in questo campo con uno script. 
3) Ora dobbiamo assegnare il campo personalizzato role-based a un Device Role. Quindi, spostati su “Ruoli” e seleziona il tipo o i tipi di ruolo a cui vuoi applicare questo campo. In questo caso, assegneremo questo campo personalizzato al ruolo Windows Laptop. 
Configurazione del monitoraggio
Le condizioni in NinjaOne sono utilizzate per monitorare i cambiamenti di stato di un endpoint. NinjaOne include la possibilità di monitorare i campi personalizzati. In questo caso configureremo un monitoraggio per controllare gli stati di allarme o di degrado della batteria.
- Nella politicy scelta, vai su condizioni e clicca su “Aggiungi una condizione”
- Seleziona il tipo di condizione “Campi personalizzati”
- Alla voce “Il valore del campo personalizzato deve soddisfare qualsiasi condizione” seleziona “Aggiungi” e cerca “Stato della batteria”
- Imposta il selettore su ‘Contiene’ e aggiungere ‘Degradato’
- Ripeti le azioni descritte nei punti 3 e 4, ma invece di “Degradato” scegli “Warning”
- Imposta gravità, priorità, canale di notifica e impostazioni di ticketing in base alle tue preferenze e clicca su “Aggiungi”.
Se la condizione viene attivata, il risultato sarà simile a questo: 
Creazione di uno script per estrarre i dati
Dobbiamo scrivere uno script che prelevi i dati dall’endpoint e li memorizzi nel nostro campo personalizzato. Modificheremo lo script che si trova qui (per vederlo è necessario aver effettuato l’accesso a Ninja).
$Battery = Get-CimInstance -ClassName win32_battery
Switch ($Battery.Availability) {
1 { $Availability = "Other" ;break}
2 { $Availability = "Not using battery" ;break}
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
Questo script estrae le informazioni sulla batteria e le formatta, quindi le scrive nel campo personalizzato ‘batteryStatus’. L’unica parte di questo script Powershell che riguarda in modo specifico Ninja è la riga finale:
Ninja-Property-Set batteryState $BatteryOutString
Ninja-Property-Set è il comando Powershell di NinjaOne per impostare un campo personalizzato su un valore specifico. La sintassi è:
Ninja-Property-Set fieldName Value
In questo caso, si imposta il campo batteryState sul valore memorizzato nella variabile $BatteryOutString. Aggiungere questo script a NinjaOne è facile.
- Vai su “Configurazione” -> “Scripting”
- clicca su “Aggiungi un nuovo script”
- Copia il codice qui sopra nell’IDE
- Se il campo personalizzato non è denominato ‘batteryState’, aggiorna il nome del campo accanto a Ninja-Property-Set
- Imposta i parametri dello script su
- Name: Set Battery Status
- Language: PowerShell
- Operating System: Windows
- Architecture: Tutte
- Salva lo script
Mettere tutto insieme
Ora che abbiamo il campo personalizzato, la condizione e lo script, dobbiamo mettere tutto insieme per automatizzare il monitoraggio. Apri la policy a cui prima hai aggiunto la condizione come descritto in questa guida e vai su “Script pianificati”. Clicca su “Aggiungi uno script pianificato”. Clicca su “Aggiungi script” Seleziona lo script “Imposta stato batteria” creato in precedenza. Potrai eseguire questo script con la frequenza che ritieni necessaria. Per eseguire lo script su base oraria, seleziona “Ogni” dal menu a tendina “Pianificazione” e imposta “Si verifica ogni” su un’ora. Quindi premi Salva. Lo script set battery status ora estrarrà ogni ora i dati da tutti gli endpoint gestiti da questa policy e li scriverà nel nostro campo personalizzato. Se il valore restituito da uno di questi endpoint contiene “warning” o “degradato”, riceveremo un avviso per poter porre rimedio alla situazione. Questo stesso processo può essere utilizzato per monitorare quasi tutti i tipi di dati che possono essere estratti da un endpoint.
Situazione d’uso numero 2: Script di automazione avanzata
NinjaOne offre diversi modi per automatizzare le attività su tutti gli endpoint gestiti, da quelli più semplici a quelli più complessi. I quattro metodi principali per avviare le automazioni in NinjaOne sono:
- Script programmati: Automazioni che vengono eseguite regolarmente su tutti gli endpoint in una policy
- Condizioni di attivazione: Automazioni attivate da eventi, cambiamenti di stato o comportamento delle prestazioni di un endpoint
- Attività programmate: Automazioni che vengono eseguite regolarmente su tutti gli endpoint selezionati
- Script ad hoc: Automazioni eseguite manualmente su uno o più endpoint
Tutti questi metodi consentono di configurare una serie di script in base a una condizione time-based o event-based. Già così, questi metodi di automazione possono essere davvero potenti e generare valore, ma non sono particolarmente dinamici. Per automazioni più dinamiche, dobbiamo parlare di altri due concetti:
- Condizioni sulla base del risultato di uno script
- Campi personalizzati
Entrambe le funzioni di NinjaOne consentono di creare automazioni dinamiche concatenate in base ai risultati dell’implementazione di uno script iniziale. La differenza fondamentale è che le condizioni basate sui risultati degli script non memorizzano i valori per un’analisi successiva e possono attivarsi solo per un singolo risultato dello script.
Conteggio e alert sulla frequenza dei login falliti
La condizione integrata di NinjaOne legata a un ID evento di Windows consente di attivare un avviso, creare un ticket o attivare l’esecuzione di uno script ogni volta che viene rilevato uno specifico ID evento. È incredibilmente utile per rilevare eventi come la creazione di un account amministratore, le modifiche apportate al firewall di Windows o l’identificazione di un errore di Windows Server Backup, tutte situazioni in cui è possibile utilizzare singoli eventi. Quando abbiamo bisogno di un gran numero di eventi per rendere attivabile un alert, invece, abbiamo bisogno di campi personalizzati. Per esempio, è improbabile che sia necessario attivare un alert sulla base di un singolo login fallito. Dieci tentativi di login falliti nell’ultima ora, invece, potrebbero indicare che qualcosa non va. Creiamo quindi un’automazione che conti i login non riusciti nell’intervallo di un’ora e invii un alert se il conteggio supera la soglia di 10 accessi non riusciti.
Impostazione del campo personalizzato
Inizieremo creando un campo personalizzato per memorizzare i tentativi di login falliti. Per questo esempio, creeremo un campo personalizzato globale, in quanto verranno rilevati i login non riusciti in tutti i tipi di dispositivi.
- Label di campo: Tentativi di login falliti
- Nome campo: failedLoginAttempts
- Tipo di campo: Numero intero
- Script: Lettura / Scrittura
Imposteremo un secondo campo personalizzato per ottenere l’ID di sicurezza dell’ultimo tentativo di login.
- Label di campo: Login all’account non riuscito Nome utente
- Nome del campo: failedAccountLoginUserName
- Tipo di campo: Testo
- Script: Lettura / Scrittura
Scrivere lo script di monitoraggio
Successivamente, scriveremo uno script per rilevare i login falliti. L’operazione è abbastanza semplice: basta interrogare il registro degli eventi e contare il numero di tentativi di login falliti. Scriveremo quindi il valore restituito nel campo failedLoginAttempts. Restituiremo anche il nome dell’utente nel 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
Aggiungere questo script a NinjaOne è semplice.
- Vai su “Configurazione” -> “Scripting”
- clicca su “Aggiungi un nuovo script”
- Copia il codice qui sopra nell’IDE
- Se il campo personalizzato non è denominato ‘failedLoginAttempts’, aggiorna il nome del campo accanto a Ninja-Property-Set
- Imposta i parametri dello script su
- Name: Conteggio dei tentativi di login falliti
- Language: PowerShell
- Operating System: Windows
- Architecture: Tutte
- Salva lo script
Successivamente, occorre impostare lo script in modo che venga eseguito periodicamente.
- Nella policy scelta, vai su Script pianificati e clicca su Aggiungi uno script pianificato
- Poi clicca su Aggiungi script e seleziona lo script Conteggio dei tentativi di login non falliti
- Assegna allo script un nome e una descrizione
- Imposta la pianificazione in modo che lo script venga eseguito ogni ora
Scrivi lo script di risoluzione
Se si rileva un volume elevato di tentativi di login falliti, è possibile porre rimedio al problema bloccando temporaneamente l’account. Estrarremo l’utente dal campo failedAccountLoginUserName e lo disabiliteremo con Powershell.
$User = Ninja-Property-Get failedAccountLoginUserName Disable-LocalUser -Name $User
Imposta la condizione
- Nella politicy scelta, vai su condizioni e clicca su “Aggiungi una condizione”
- Seleziona il tipo di condizione “Campi personalizzati”
- Alla voce ‘Il valore del campo personalizzato deve soddisfare qualsiasi condizione’ seleziona ‘Aggiungi’ e cerca ‘Tentativi di login falliti’, seleziona l’operatore ‘maggiore o uguale a’ e imposta il valore su 10.
- Clicca su “Applica”
- Daremo alla condizione il nome “Numerosi tentativi di login falliti”
- Imposta la gravità, la priorità e gli intervalli di ripristino
- Decidi se vuoi che vengano create notifiche e ticket
- Clicca su “Aggiungi”
- Se vuoi automatizzare la disabilitazione dell’account locale dell’utente, puoi aggiungere lo script Disabilita utente locale come automazione a questa condizione
Continua a leggere la seconda e la terza parte della serie qui sotto:
- https://www.ninjaone.com/it/rmm/self-service-it-per-utenti-finali/
- https://www.ninjaone.com/blog/asset-lifecycle-management-using-ninjaone/
Perché NinjaOne?
Sei stanco di passare da un RMM all’altro e di rimanerne deluso? Prova tu stesso i campi personalizzati in Ninja e scopri perché NinjaOne è diverso. Inizia la tua prova gratuita.
