La gestione centralizzata e cloud-based è al centro dei pensieri di Microsoft, perchè ormai il mondo è sempre più mobile ed è sempre meno legato ai vecchi canoni, come il fatto che si lavora sempre, e solo in azienda, e che il dispositivo è di proprietà dell’azienda stessa.
Da quando Intune è stato migrato all’interno del portale Azure, abbiamo visto diverse novità introdotte ma anche dei tagli che hanno limitato le funzionalità del prodotto stesso ma questo perché anche la politica di gestione è cambiata, passando da un modello Agent a quello Native, dove l’integrazione con le piattaforme MDM è insita dentro il sistema operativo stesso (Windows 10).
Uno dei punti più critici in Intune è sicuramente la mancanza di gestione del sistema operativo client in modo più spinto, cosa invece possibile tramite le GPO. Ed è proprio questo parallelismo che ha portato molte aziende a non affidarsi totalmente ad una soluzione di gestione cloud, rispetto al classico modello on-premises. Via GPO possiamo distribuire script, installare stampanti, cambiare impostazioni e molto altro ancora; via MDM possiamo installare software, gestire (poco) gli update, fare alcune regole di compliance e niente più.
Proprio per colmare questo grande gap tra i due mondi, durante Ignite è stata presentata la teoria soluzione al problema.
Introduzione a PowerShell Script
I PowerShell Script sono un modo per andare ad eseguire comandi avanzati ed eseguire task che prima non erano possibili. La funzione si trova all’interno della sezione Device Compliance – figura 1.
Figura 1 – PowerShell Script
La struttura di ogni oggetto è molto semplice e prevede due valori:
- Esecuzione dello script solo a logon effettuato
- Controllo della firma script (utile se volete eseguire codice firmato digitalmente)
Figura 2 – Configurazione Oggetto
Esempio di Script
Questo è un esempio di uno script per installare Adobe Acrobat Reader:
$ResultADR = Get-ItemProperty HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* | where {$_.DisplayName -like “Adobe Reader DC*”} $TempPath = “Z:\” $appFile = “AcroRdrDC1500720033_MUI.exe” If ($ResultADR -eq $null) { (Start-Process -FilePath $TempPath$appFile -ArgumentList “/sAll /rs /rps /msi /norestart /quiet ALLUSERS=1 EULA_ACCEPT=YES” -Wait -Passthru).ExitCode }
Lo script verifica la presenza del software e nel caso non ci sia niente, viene eseguito il setup.
La condizione è quella di avere una share di rete già mappata che possa essere raggiunta dai client e che contenga i bit per l’installazione. In caso l’utente sia sempre in mobilità, si può modificare lo script per fare un wget esterno e salvare l’exe localmente.
Lo script viene eseguito come SYSTEM e quindi non ci sono rischi anche se l’end-user lavora con permessi non amministrativi.
Gestione Lato Client
Per amministrare la parte PowerShell, all’interno del client viene installato automaticamente un pacchetto (Microsoft Intune Management Extension) che va a configurare un nuovo servizio ed un task scheduler che consentono l’esecuzione degli script PowerShell. Di default il controllo viene fatto ad ogni riavvio del computer, ma la modifica sul TS può consentire di fare le verifiche più frequenti durante il giorno.
Gli amministratori possono analizzare i log, che si trovano all’interno della cartella C:\ProgramData\Microsoft\IntuneManagementExtension\Logs, per capire se le regole applicate funzionano correttamente o se ci sono degli errori nello script – figura 3.
Figura 3 – Analisi Log
Un valido alleato è sicuramente il CMTrace, che offre il parsing dei log in modo dettagliato e ci aiuta a capire subito gli errori, con una riga rossa.
Conclusione
L’introduzione degli script in PowerShell è sicuramente una delle chiavi per colmare il grande divario con le GPO, anche se rimane un problema di fondo dato dal fatto che ogni singola modifica deve essere riportata sotto forma di chiave di registro da modificare. È probabile che in futuro il team di Intune vada ad ampliare la gestione dei settings, avvicinando il Mobile Device Management alle GPO locali.