• Cloud, Guide, Microsoft 365, Sicurezza, Sistemi Operativi
• 11 Febbraio 2026

Nel lavoro quotidiano con Microsoft Intune, i gruppi a membership dinamica di Microsoft Entra ID sono uno strumento fondamentale per automatizzare l’assegnazione di applicazioni e criteri, riducendo attività manuali e rischi di inconsistenza. Tuttavia, la membership dinamica può valutare esclusivamente gli attributi disponibili sull’oggetto dispositivo in Entra ID. Questo significa che nativamente non è possibile creare regole basate direttamente su informazioni che risiedono sui client, come l’inventario software installato. Un caso tipico è la richiesta “includi nel gruppo tutti i pc che hanno Google Chrome installato“. Per quanto comune, non esiste una condizione nativa del tipo “installedApps contains Chrome“.

In questa guida vi mostrerò come adottare un approccio che consente di superare il vincolo in modo controllato e ripetibile, calcolando localmente un’informazione tramite PowerShell (ad esempio la presenza di un’applicazione) e la pubblichiamo sull’oggetto dispositivo in Entra ID aggiornando un attributo dedicato tramite Microsoft Graph. Una volta scritto l’attributo, diventa immediatamente utilizzabile nelle regole dei gruppi dinamici, abilitando scenari di targeting basati su criteri personalizzati.

In questa guida vedremo dunque nel dettaglio:

• Cos’è Microsoft Graph
  
• I limiti dei Dynamic Groups di Microsoft Entra
  
• Cosa sono gli extension attributes
  
• Come utilizzare PowerShell e Microsoft Graph per creare Dynamic Groups
  
• Troubleshooting
  
• Conclusioni
  

Cos’è Microsoft Graph

Microsoft Graph è l’interfaccia API ufficiale di Microsoft per accedere in modo programmabile ai dati e alle funzionalità dei servizi Microsoft 365 e della piattaforma Entra. In pratica è un punto di ingresso unico (endpoint HTTPS) che consente a un’applicazione, a uno script o a un servizio di leggere e modificare risorse come utenti, gruppi, dispositivi, directory, Teams, mail, SharePoint e molto altro, utilizzando richieste REST e payload JSON.

Nel contesto di questa guida, Graph è ciò che renderà possibile il passaggio chiave, ovvero aggiornare l’oggetto device in Microsoft Entra ID e valorizzare gli extensionAttributes. Intune di per sé esegue i nostri script sugli endpoint tramite Remediations, ma non scrive automaticamente attributi custom in Entra. Con Graph, invece, possiamo pubblicare in directory un’informazione calcolata sul client (ad esempio “App1 installata“) e renderla utilizzabile dalle regole dei gruppi dinamici. Dal punto di vista dell’autenticazione, Microsoft Graph è protetto da OAuth 2.0, quindi prima di chiamare le API serve ottenere un access token. È qui che entrerà in gioco l’App Registration, in modo da definire l’identità dell’app e i permessi concessi. In generale si possono avere due modalità:

• permessi delegated, dove l’app agisce a nome di un utente autenticato
• permessi application, dove l’app agisce in modalità app-only (senza utente)

In questa demo usiamo i permessi application perché lo script deve poter aggiornare l’oggetto device in modo automatico. Infine, è bene citare Graph Explorer; un client web che permette di inviare richieste a Microsoft Graph e visualizzare le risposte. È utilissimo per verificare rapidamente che un attributo sia stato scritto correttamente sull’oggetto device e, se necessario, per eseguire rollback con un PATCH manuale.

I limiti dei dynamic group di Intune ed Entra

Partiamo da un chiarimento utile: i dynamic groups non sono una funzionalità di Intune in senso stretto. Sono gruppi a membership dinamica di Microsoft Entra ID, che Intune poi utilizza come contenitore per il targeting di criteri o configurazioni. Questo dettaglio è importante perché i limiti che incontri dipendono dal modello dati e dal motore di valutazione di Entra, non dall’inventario o dalle capability di Intune.

Chiarito questo aspetto, passiamo ai limiti. Il primo limite è concettuale: la membership dinamica può basarsi solo su attributi disponibili sull’oggetto (utente o dispositivo) in Entra ID. In pratica, la regola può interrogare proprietà directory e non lo stato locale del client. Per questo motivo non esiste una condizione nativa del tipo “installedApps contains Chrome“, come citato nell’introduzione, o “se c’è quel file allora…“. Il software installato, le versioni applicative, la presenza di chiavi di registro specifiche o l’esito di un check custom sono tutte informazioni che Entra non possiede automaticamente come attributi interrogabili nelle regole di membership.

Figura 1: I limiti dei dynamic groups in Microsoft Entra ID

Il secondo limite è operativo: i gruppi dinamici non sono istantanei. Microsoft indica che le modifiche di membership sono in genere processate “entro alcune ore“, ma in condizioni specifiche possono volerci più di 24 ore, e la prima popolazione del gruppo dopo una regola nuova/modificata può richiedere tempo. Inoltre, la latenza cresce con la complessità della regola, la dimensione del tenant e anche con l’uso di operatori più costosi (ad esempio CONTAINS, MATCH o scenari in preview come memberOf). Questo impatta direttamente i rollout, e se vi aspettate che un device entri nel gruppo subito dopo un cambiamento, rischiate di costruire flussi fragili.

Il terzo limite è di governance e performance. Microsoft consiglia di usare in modo consapevole i meccanismi di targeting. Infatti, dove serve un’applicabilità rapida e a bassa latenza, spesso è più efficiente assegnare a un gruppo più ampio e poi restringere con i Filters di Intune, che vengono valutati in modo performante al check-in del device e senza necessità di pre-calcolo della membership. I filtri non sostituiscono i gruppi dinamici in ogni scenario (hanno proprietà filtrabili più limitate), ma sono un’alternativa importante quando il problema è la tempestività o la scalabilità.

C’è infine un vincolo di prodotto da tenere a mente. Microsoft Entra impone un tetto al numero di gruppi a membership dinamica per tenant (massimo 15.000). E sul fronte licensing, la funzionalità richiede Microsoft Entra ID P1 (o Intune for Education) in base alle regole di copertura indicate da Microsoft; quindi, se la soluzione viene adottata su larga scala, va considerata anche questa dimensione.

Questi limiti spiegano perché l’approccio PowerShell + Graph ha perfettamente senso. Sostanzialmente non bypassa i dynamic group, ma li alimenta con un attributo directory in linea con ciò che il device sa di possedere, rendendo la regola dinamica semplice, stabile e sostenibile anche nel tempo.

Alcuni approfondimenti utili sull’argomento li trovate alle pagine Microsoft Understand and manage dynamic group processing in Microsoft Entra ID e Manage rules for dynamic membership groups in Microsoft Entra ID.

Cosa sono gli extension attributes

Gli extension attributes sono un set di 15 proprietà predefinite disponibili in Microsoft Entra ID sia sugli utenti sia sui dispositivi, con nomenclature fisse che partono da extensionAttribute1 fino a extensionAttribute15. Nascono storicamente come custom attributes del mondo on-prem ed oggi sono utilizzabili direttamente anche in cloud tramite Microsoft Graph. Dal punto di vista pratico, puoi pensarli come campi jolly, ovvero stringhe che puoi valorizzare con etichette per rappresentare uno stato o una classificazione che Entra non calcola nativamente.

Il motivo per cui sono così utili è che, una volta valorizzati, diventano interrogabili nelle regole dei gruppi a membership dinamica. In una regola puoi usare espressioni come device.extensionAttribute1 -eq “App1” e quindi trasformare un fatto che hai calcolato altrove (ad esempio via PowerShell sul client) in un criterio di membership. Sul piano tecnico, in Microsoft Graph gli extension attributes del device sono esposti come una proprietà strutturata extensionAttributes dell’oggetto dispositivo e si aggiornano con una classica chiamata PATCH (è esattamente il meccanismo che useremo più avanti nel capitolo PowerShell + Graph).

Note pratiche: Gli extension attributes sono solo 15, dunque conviene trattarli come risorsa preziosa, con una piccola convenzione interna (quale slot usa quale progetto e quali valori sono ammessi). Usateli come tag controllati (pochi valori, ben definiti). Se ci mettete testo libero, dopo due mesi diventa ingestibile e il targeting perde affidabilità.

Come utilizzare PowerShell e Microsoft Graph per creare gruppi dinamici

È ora di passare dalle parole ai fatti. In questo capitolo vedremo, passo dopo passo, come usare PowerShell e Microsoft Graph per valorizzare gli extensionAttributes dei devices in Microsoft Entra ID. Una volta pubblicata questa informazione in directory, potremo sfruttarla nelle regole dei gruppi a membership dinamica e costruire criteri di raggruppamento basati su parametri personalizzati, anche quando non sono disponibili come attributi nativi. È un approccio particolarmente potente perché consente di trasformare qualunque informazione verificabile sul client in un attributo “directory-based” e quindi utilizzabile per il targeting: software installato, versione di un’app, readiness per una migrazione, stato di un servizio, presenza di chiavi di registro o file, esito di controlli personalizzati e molto altro.

In questo scenario dimostrativo creeremo una App Registration nel Microsoft Entra admin center e assegneremo i permessi necessari per invocare Microsoft Graph. Successivamente configureremo un Dynamic Device Group denominato “Google Chrome Devices” basato sulla regola di membership device.extensionAttribute1 -eq “HasChrome”, così da identificare i dispositivi che riportano il tag relativo alla presenza del software. Infine, creeremo e distribuiremo una Intune Remediation composta da un detection script che verifica localmente la presenza di Google Chrome, e da un remediation script che aggiorna extensionAttribute1 impostandolo a HasChrome tramite Microsoft Graph.

Il risultato atteso è che il gruppo “Google Chrome Devices” si popolerà automaticamente con i dispositivi che, a seguito dell’esecuzione della remediation, risulteranno effettivamente conformi al criterio (Chrome installato). Completeremo la demo mostrando come verificare via Microsoft Graph gli attributi presenti sull’oggetto dispositivo e come eseguire il rollback, svuotando l’extensionAttribute quando necessario.

Figura 2: Workflow per l’assegnazione di extensionAttributes per la creazione di dynamic groups in Entra ID

Creazione App registration

Un App Registration serve per stabilire una relazione di trust tra un’applicazione e Microsoft Entra ID, in modo che l’app possa autenticarsi e ottenere token OAuth2 per chiamare API protette come Microsoft Graph. In questo scenario ci serve perché lo script di remediation deve poter invocare Graph ed eseguire l’aggiornamento dell’oggetto dispositivo in Entra ID (valorizzando extensionAttributes). In pratica, l’App Registration definisce l’identità dell’app (Client ID), il tenant di riferimento (Tenant ID) e il metodo con cui l’app dimostra la propria identità (client secret o certificato), oltre ai permessi necessari per operare sugli oggetti della directory.

Per creare la nostra applicazione, come prima cosa, colleghiamoci al Microsoft Entra admin center e navighiamo in Entra ID > App registrations

Figura 3: Creazione App Registration – Parte 1

Una volta aperta la tab App Registrations, facciamo click su + New registration

Figura 4: Creazione App Registration – Parte 2

Nella pagina che segue, inseriamo un nome per la nostra application. Una volta finito, procediamo cliccando il button Register in fondo alla pagina

Figura 5: Creazione App Registration – Parte 3

Dopo qualche secondo, l’Entra admin center farà redirect sulla pagina della nostra nuova app registration appena creata

Figura 6: Creazione App Registration – Parte 4

Spostiamoci adesso nella sezione API permissions, facciamo click su Add a permission e sul pannello che si aprirà alla vostra destra, selezioniamo Microsoft Graph

Figura 7: Creazione App Registration – Parte 5

Proseguiamo selezionando Application permissions, nella barra di ricerca “Select permissions” digitiamo Device.ReadWrite.All. Sotto apparirà la sezione Device; espandiamola e selezioniamo la checkbox della permission Device.ReadWrite.All. Infine, facciamo click su Add permissions in fondo alla pagina. Questa permission consente all’applicazione di leggere e modificare tutti gli oggetti device presenti nella directory, operando in modalità app-only (quindi senza un utente interattivo). Nel contesto della demo è il requisito che abilita la chiamata a Microsoft Graph per eseguire la PATCH dell’oggetto e valorizzare extensionAttributes e rendendo l’informazione disponibile per le regole dei gruppi dinamici.

Figura 8: Creazione App Registration – Parte 6

Una volta aggiunta la permission, la vedremo elencata nella sezione API permissions. Noterete che, accanto, potrebbe comparire un’icona di avviso con la dicitura “Not granted for …”: significa che i permessi sono stati configurati sull’App Registration, ma non sono ancora stati consentiti a livello tenant. Questo comportamento è normale, perché le Application permissions richiedono l’admin consent. Per completare la configurazione, facciamo quindi clic su Grant admin consent for <NomeTenant> e confermiamo con Yes nel prompt che appare

Figura 9: Creazione App Registration – Parte 7

Al termine dell’operazione, verrà mostrato un messaggio di conferma e lo stato della permission risulterà Granted (l’avviso scomparirà), indicando che l’app è ora autorizzata a utilizzare Device.ReadWrite.All per chiamare Microsoft Graph nel tenant

Figura 10: Creazione App Registration – Parte 8

Adesso spostiamoci nella sezione Certificates & secrets. Un client secret è una credenziale associata all’App Registration che l’applicazione utilizza per autenticarsi verso Microsoft Entra ID nel flusso client credentials (app-only), insieme al Client ID e al Tenant ID. In pratica funziona come una “password” dell’app. Serve per ottenere un access token da presentare a Microsoft Graph. Per la demo possiamo crearne uno selezionando New client secret, assegnando una descrizione e una scadenza. Infine, facciamo click su Add

Figura 11: Creazione App Registration – Parte 9

Terminata la creazione del client secret, lo vedremo elencato nella sezione Certificates & secrets. Copiate e salvate il valore che vedrete nella colonna Value e conservatelo con attenzione, ci servirà più avanti.

Figura 12: Creazione App Registration – Parte 10

È importante ricordare che il valore del secret viene mostrato una sola volta. Se non viene salvato subito, non sarà più recuperabile e sarà necessario generarne uno nuovo; va quindi copiato e conservato in modo sicuro. In scenari reali è preferibile utilizzare un certificato o un meccanismo che eviti credenziali statiche sugli endpoint, ma per un POC il client secret è sufficiente.

Figura 13: Creazione App Registration – Parte 11

Creazione dynamic group

Adesso possiamo creare il gruppo dinamico. Spostiamoci nella sezione Groups del Microsoft Entra admin center e selezioniamo New group

Figura 14: Creazione Dynamic device group – Parte 1

Nella pagina che si apre impostiamo Group type su Security, assegniamo un valore a Group name (ad esempio Google Chrome Devices) e, se necessario, aggiungiamo una descrizione. In Membership type selezioniamo Dynamic device, quindi facciamo clic su Add dynamic query per definire la regola di membership.

Figura 15: Creazione Dynamic device group – Parte 2

Nel capitolo successivo creeremo uno script che verifica la presenza di Google Chrome sui dispositivi e, in caso positivo, valorizza extensionAttribute1 con il valore HasChrome. Ricordate che sono disponibili 15 extensionAttribute (extensionAttribute1…extensionAttribute15). In questa demo utilizzeremo extensionAttribute1, ma potete scegliere uno slot diverso in base alle vostre esigenze e alle convenzioni adottate.

Nella schermata della regola dinamica impostiamo quindi come proprietà
extensionAttribute1, come operatore
Equals e come valore
HasChrome. La regola risultante sarà:

(device.extensionAttribute1 -eq “HasChrome”)

Una volta completata la configurazione, facciamo clic su Save per salvare la query

Figura 16: Creazione Dynamic device group – Parte 3

A questo punto, tornati nella pagina di creazione del gruppo, facciamo click su Create per finalizzare la creazione del nostro gruppo.

Figura 17: Creazione Dynamic device group – Parte 4

Come possiamo notare nella pagina Overview del gruppo appena creato, al momento non sono presenti membri. È un comportamento atteso, poiché in questa fase nessun dispositivo risulta ancora valorizzato con HasChrome in extensionAttribute1; quindi, la regola di membership non può includere alcun device. Nel prossimo capitolo vedremo come scrivere la logica in PowerShell per calcolare il parametro sul client e pubblicarlo in Entra ID tramite Microsoft Graph.

Figura 18: Creazione Dynamic device group – Parte 5

PowerShell e logica

Eccoci al cuore di questa guida. In questa sezione costruiremo una logica semplice ma efficace per determinare se su un dispositivo è installato Google Chrome e, in caso positivo, pubblicare questa informazione in Microsoft Entra ID valorizzando un extensionAttribute tramite Microsoft Graph. Questo passaggio è ciò che abilita il targeting tramite gruppo dinamico. Una volta che l’attributo è presente sull’oggetto device, la membership del gruppo può essere calcolata automaticamente in base alla regola configurata nel capitolo precedente.

Per cominciare creiamo due script:

• detect.ps1
• remediation.ps1

In questa demo utilizzerò Visual Studio Code per scrivere il codice PowerShell, ma siete liberi di utilizzare l’editor che preferite. Trovate tutti gli script di riferimento al mio GitHub alla pagina Create Dyamic Group with Graph – Microsoft Intune.

Figura 19: Creazione detection e remediation script – Parte 1

Detect

Nel file detect.ps1 implementeremo una logica volutamente semplice. L’obiettivo è verificare se Google Chrome risulta installato sul dispositivo. Se la verifica ha esito positivo, lo script terminerà con exit 1 così da segnalare a Intune che è necessaria la remediation e attivare l’esecuzione di remediation.ps1. In caso contrario, terminerà con exit 0 e non verrà avviata alcuna azione correttiva.

Figura 20: Creazione detection e remediation script – Parte 2

Remediation

Passiamo ora allo script remediation.ps1. Se il detection ha restituito exit 1, Intune eseguirà questo script con l’obiettivo di pubblicare il risultato in Microsoft Entra ID, valorizzando un extensionAttribute del dispositivo tramite Microsoft Graph. Il flusso è composto da tre passaggi:

• autenticazione a Graph
• identificazione dell’oggetto device in Entra
• aggiornamento dell’attributo con una richiesta PATCH

Nella prima parte definiamo i parametri dell’App Registration (Tenant ID, Client ID e Client Secret) e richiediamo un access token con il flusso OAuth2 client credentials. In pratica l’applicazione ottiene un token valido per Microsoft Graph utilizzando lo scope https://graph.microsoft.com/.default, che corrisponde ai permessi applicativi assegnati e approvati al capitolo “Creazione App registration” (vedi Figure 9 e 10 per admin consent). Una volta ottenuto il token, lo includiamo nell’header Authorization come bearer token, insieme al Content-Type JSON.

A questo punto dobbiamo individuare il dispositivo in Entra ID. Lo script ricava il Device ID locale (GUID) e lo usa per interrogare Microsoft Graph e ottenere l’id dell’oggetto device in directory. Questo passaggio è necessario perché l’operazione di aggiornamento tramite PATCH viene eseguita sull’oggetto device in Entra. Una volta ottenuto l’identificativo, costruiamo il body JSON impostando extensionAttributes.extensionAttribute1 al valore atteso dalla regola del gruppo dinamico (nel nostro esempio HasChrome) e inviamo la richiesta PATCH a Microsoft Graph. Al termine della chiamata, l’attributo risulta valorizzato sull’oggetto device e la regola di membership del gruppo dinamico potrà includere il dispositivo in base alla condizione configurata.

Figura 21: Creazione detection e remediation script – Parte 3

Per ricavare i dettagli di <ClientID> e <TenantID> possiamo recarci nella pagina di Overview della nostra App registration. Per quanto riguarda <Secret>, utilizziamo il campo Value che abbiamo salvato, come visto al capitolo “Creazione App registration” (Figura 12).

Figura 22: Creazione detection e remediation script – Parte 4

Bonus: come mettere in sicurezza client secret

Come avrete notato, per questa demo abbiamo utilizzato un client secret direttamente nello script, perché è il modo più rapido per mostrare il flusso end-to-end. In produzione, però, un secret inserito in uno script distribuito sugli endpoint non può essere considerato realmente protetto. Anche se lo offuschi o lo nascondi, lo script viene comunque scaricato in cache tramite l’Intune Management Extension, eseguito in chiaro e potenzialmente leggibile da chi ha privilegi elevati sulla macchina.

Per rendere l’architettura solida e difendibile, le alternative consigliate sono principalmente due:

• introdurre un servizio intermedio
• sostituire il secret con un certificato sull’App Registration

Tra la velocità e la sicurezza, scegliete SEMPRE la sicurezza!

Microsoft Intune Remediation

Siamo ormai quasi arrivati al termine di questa guida, passiamo ora al Microsoft Intune admin center per creare e distribuire la remediation che eseguirà i nostri script sui dispositivi. In questa fase caricheremo il detection script e il remediation script, configureremo la pianificazione di esecuzione e assegneremo il pacchetto a un gruppo di test, così da iniziare a valorizzare extensionAttribute1 in Microsoft Entra ID e, di conseguenza, popolare automaticamente il gruppo dinamico creato nei capitoli precedenti.

Navighiamo in Devices > Scripts and remediations

Figura 23: Creazione Intune Remediation – Parte 1

Successivamente facciamo click su + Create

Figura 24: Creazione Intune Remediation – Parte 2

Si aprirà il wizard Create custom script. Nella sezione Basics inseriamo il nome della nostra Intune Remediation, una descrizione e facciamo click su Next.

Figura 25: Creazione Intune Remediation – Parte 3

Nella sezione Settings carichiamo i due script creati nel capitolo “PowerShell e logica“. Per Detection script file e Remediation script file facciamo clic su Select a file e selezioniamo i file corrispondenti.

Figura 26: Creazione Intune Remediation – Parte 4

Figura 27: Creazione Intune Remediation – Parte 5

Per questa demo lasciamo Run this script using the logged-on credentials su No ed Enforce script signature check su No, quindi impostiamo Run script in 64-bit PowerShell su Yes. A questo punto proseguiamo con Next.

Figura 28: Creazione Intune Remediation – Parte 6

Nella sezione Scope tags (opzionale) lasciare Default, oppure selezionare uno scope tags già creato in precedenza nel vostro ambiente Intune. Nel nostro caso lasceremo quello di default. Successivamente cliccate su Next.

Figura 29: Creazione Intune Remediation – Parte 7

Nella sezione Assignments assegnamo la remediation al target desiderato. Facciamo clic su Select groups to include, cerchiamo il gruppo su cui vogliamo eseguire la remediation, selezioniamolo tramite la checkbox e confermiamo con Select.

Figura 30: Creazione Intune Remediation – Parte 8

Sempre nella pagina Assignments verifichiamo che il gruppo sia presente nell’elenco Selected groups. Se necessario, questo è il momento corretto per aggiungere ulteriori gruppi, modificare la schedulazione o applicare eventuali filtri; in caso contrario proseguiamo con Next.

Figura 31: Creazione Intune Remediation – Parte 9

Arrivati alla sezione Review + create, verificate che tutti i dettagli della configurazione siano corretti, inclusi i gruppi di assegnazione. Se è tutto ok, proseguire cliccando su Create.

Figura 32: Creazione Intune Remediation – Parte 10

Concludendo il wizard e tornando nella sezione Scripts and remediations, potremo verificare che la Intune Remediation è stata creata correttamente ed è ora pronta per essere eseguita sui dispositivi assegnati.

Figura 33: Creazione Intune Remediation – Parte 11

Troubleshooting

In questa sezione verificheremo end-to-end che il workflow stia funzionando correttamente e dove intervenire in caso di anomalie. Partiremo dal Device status della Intune Remediation per confermare l’esecuzione di detection e remediation sui dispositivi assegnati; passeremo poi al Dynamic Device Group per validare la rivalutazione della membership in base a extensionAttribute1; infine utilizzeremo Graph Explorer per ispezionare direttamente l’oggetto device e verificare che l’attributo sia stato scritto.

Verifica Device status

Una volta distribuita la Intune Remediation, verifichiamo che i dispositivi abbiano recepito la configurazione e che il gruppo dinamico Google Chrome Devices inizi a popolarsi correttamente. Dal Microsoft Intune admin center apriamo Scripts and remediations, selezioniamo la remediation Google Chrome dynamic group e accediamo alla sezione Monitor > Device status.

Figura 34: Troubleshooting – Monitoring device status – Parte 1

È normale non vedere immediatamente i record. La remediation viene eseguita secondo la schedulazione definita in fase di creazione e i dati di monitoraggio richiedono tempo per essere elaborati e visualizzati nel portale. In generale possono trascorrere alcuni minuti prima che lo stato compaia nella sezione di monitoring.

Figura 35: Troubleshooting – Monitoring device status – Parte 2

Quando l’esecuzione sarà avvenuta sui dispositivi inclusi nell’assegnazione, in Device status vedremo i record con l’esito del detection/remediation. A valle dell’aggiornamento di extensionAttribute1 in Entra ID, anche la membership del gruppo dinamico verrà rivalutata e il gruppo Google Chrome Devices inizierà a includere i dispositivi in linea con la regola configurata.

Importante: Nell’esempio mostrato in Figura 36, Detection status = With issues e Remediation status = Recurred indicano che, al momento dell’ultima esecuzione, lo script di detection ha segnalato una condizione non conforme (quindi ha restituito exit 1) e Intune ha avviato la remediation. Il fatto che la remediation risulti Recurred non significa necessariamente che non funzioni, significa che la stessa condizione si è ripresentata in esecuzioni successive e che la remediation è stata rieseguita più volte. Nel nostro scenario questo può accadere per motivi perfettamente in linea con la demo. Ad esempio, il detection è volutamente semplice e continua a restituire exit 1 ogni volta che trova Chrome installato, perché non verifica se l’attributo extensionAttribute1 sia già stato valorizzato correttamente in Entra ID. Di conseguenza, a ogni run pianificato Intune considera la condizione da correggere e rilancia la remediation, che riscrive lo stesso valore. Per evitare questo comportamento in un’implementazione reale è sufficiente cambiare la logica del detection, ovvero farlo terminare con exit 0 quando lo stato è già allineato. In pratica, oltre a verificare “Chrome è installato?”, il detection dovrebbe verificare anche che l’attributo sia già impostato al valore atteso (ad esempio leggendo lo stato da una cache locale, oppure interrogando Graph se si accetta la chiamata aggiuntiva). In questo modo la remediation verrà eseguita solo quando c’è effettivamente un cambiamento di stato (installazione o rimozione dell’applicazione), riducendo rumore nel monitoring e chiamate inutili a Microsoft Graph.

Il risultato è perfettamente in linea con le aspettative della demo.

Figura 36: Troubleshooting – Monitoring device status – Parte 3

Verifica Dynamic group

A questo punto verifichiamo che il gruppo dinamico sia stato popolato correttamente con il dispositivo PC-01, sul quale è stata eseguita la remediation. Dal Microsoft Intune admin center (oppure direttamente dal Microsoft Entra admin center), spostiamoci nella sezione Groups, utilizziamo la barra di ricerca per individuare il gruppo creato in precedenza (Google Chrome Devices) e selezioniamolo.

Figura 37: Troubleshooting – Verifica Dynamic group – Parte 1

Nella pagina di overview del gruppo possiamo osservare che Total direct members riporta ora 1 dispositivo. Per visualizzare nel dettaglio i membri inclusi tramite la regola di membership dinamica, apriamo la sezione Members: in elenco dovremmo trovare PC-01, come previsto.

Figura 38: Troubleshooting – Verifica Dynamic group – Parte 2

Figura 39: Troubleshooting – Verifica Dynamic group – Parte 3

Se selezioniamo il dispositivo PC-01 e apriamo i dettagli dell’oggetto, nella sezione Extension attributes risulterà presente extensionAttribute1 : HasChrome, perfettamente in linea con quanto impostato dallo script di remediation. Questo conferma che il valore è stato scritto sull’oggetto device in Entra ID e che la regola del gruppo dinamico sta funzionando correttamente.

Figura 40: Troubleshooting – Verifica Dynamic group – Parte 4

Verifica Graph Explorer

Per completare la validazione end-to-end, è utile verificare direttamente su Microsoft Graph che l’attributo sia stato scritto sull’oggetto dispositivo in Microsoft Entra ID. Graph Explorer ci consente di interrogare l’oggetto device e visualizzare i valori di extensionAttributes senza affidarci esclusivamente alla UI del portale, risultando particolarmente utile sia per confermare la corretta esecuzione della remediation sia per attività di troubleshooting e rollback.

Colleghiamoci al portale di Graph Explorer e autentichiamoci selezionando l’icona del profilo in alto a destra.

Figura 41: Troubleshooting – Verifica tramite Graph Explorer – Parte 1

Continuiamo completando il sign-in

Figura 42: Troubleshooting – Verifica tramite Graph Explorer – Parte 2

Una volta autenticati, verifichiamo di operare nel tenant corretto: Graph Explorer mostra chiaramente l’organizzazione in uso, così da evitare richieste eseguite sul tenant sbagliato.

Figura 43: Troubleshooting – Verifica tramite Graph Explorer – Parte 3

A questo punto possiamo interrogare direttamente l’oggetto dispositivo con una chiamata GET verso Microsoft Graph, utilizzando l’Object ID del device. Nel campo dell’URL inseriamo https://graph.microsoft.com/v1.0/devices/<OBJECT_ID>?$select=id,displayName,deviceId,extensionAttributes e procediamo facendo click sul button Run query.

Nota: <OBJECT ID> potete recuperarlo dalle proprietà del device in Microsoft Entra o Microsoft Intune (vedi Figura 40). Vi servirà il campo Object ID e non Device ID.

Una volta eseguita la query, otterremo in output la rappresentazione JSON dell’oggetto dispositivo. All’interno della risposta, nella sezione extensionAttributes, possiamo verificare che extensionAttribute1 risulti valorizzato con HasChrome, confermando che lo script di remediation ha aggiornato correttamente l’oggetto device in Microsoft Entra ID tramite Microsoft Graph.

Figura 44: Troubleshooting – Verifica tramite Graph Explorer – Parte 4

Rollback

Una volta validato il funzionamento della demo, può essere utile ripristinare lo stato iniziale, ad esempio per ripetere i test o per rimuovere tag non più necessari. In questa sezione vedremo come eseguire il rollback svuotando extensionAttribute1 sull’oggetto dispositivo in Microsoft Entra ID tramite Microsoft Graph, così da rimuovere il device dal gruppo dinamico e riportare la configurazione a uno stato neutro. Per farlo, questa volta dovremo utilizzare una richiesta PATCH verso Microsoft Graph, aggiornando l’oggetto dispositivo e impostando extensionAttribute1 a null. In questo modo l’attributo verrà svuotato e, alla successiva rivalutazione della membership dinamica, il dispositivo non soddisferà più la regola del gruppo e verrà rimosso automaticamente.

Nota: È importante ricordare che, se la Intune Remediation continua a essere assegnata al dispositivo, lo script di remediation potrebbe valorizzare nuovamente l’attributo alla successiva esecuzione pianificata. Per evitare che il valore venga reimpostato, è necessario escludere il device dall’assegnazione della remediation prima di eseguire il rollback.

Per eseguire il rollback e quindi reimpostare extensionAttribute1, inviamo una richiesta PATCH verso l’oggetto dispositivo in Microsoft Graph. Nel campo URL utilizziamo l’Object ID del device https://graph.microsoft.com/v1.0/devices/<OBJECT_ID>, mentre nel Request body inseriamo il seguente JSON:

Eseguiamo la richiesta tramite il button Run query. Se l’operazione va a buon fine, Graph restituisce tipicamente 204 No Content. A questo punto, alla successiva rivalutazione della membership dinamica, il dispositivo non soddisferà più la regola HasChrome e verrà rimosso dal gruppo (assicurandosi che la remediation non sia più assegnata al device, altrimenti l’attributo potrebbe essere valorizzato nuovamente).

Figura 45: Troubleshooting – Rollback tramite Graph Explorer – Parte 1

Dopo aver eseguito la richiesta, tornando nelle proprietà del dispositivo in Microsoft Entra (o nell’Intune admin center), noteremo che nella sezione Extension attributes il valore di extensionAttribute1 non sarà più presente, poiché risulterà vuoto e non più valorizzato.

Figura 46: Troubleshooting – Rollback tramite Graph Explorer – Parte 2

Di conseguenza, alla successiva rivalutazione della membership dinamica, anche il gruppo Google Chrome Devices verrà aggiornato e il dispositivo non comparirà più tra i membri, perché non soddisfa più la condizione prevista dalla regola.

Figura 47: Troubleshooting – Rollback tramite Graph Explorer – Parte 3

Conclusioni

In questa guida abbiamo visto come superare uno dei limiti più frequenti dei gruppi a membership dinamica: poter ragionare solo sugli attributi disponibili sull’oggetto dispositivo in Microsoft Entra ID. L’approccio PowerShell + Microsoft Graph non sostituisce i dynamic group, ma li potenzia. Possiamo calcolare un’informazione direttamente sul client tramite Intune Remediations, la pubblichiamo in Entra valorizzando un extensionAttribute e poi la utilizziamo in modo nativo nella regola di membership. Il risultato è un targeting automatico, ripetibile e governabile, applicabile non solo alla presenza di un software, ma anche a readiness, compliance custom, stato di componenti, versioni e qualunque altro parametro verificabile in modo affidabile sugli endpoint. Come sempre, ciò che fa la differenza tra demo e produzione è la governance. Scegliete con criterio gli slot extensionAttribute1…15, definite un vocabolario controllato di valori e adottare un modello sicuro per l’autenticazione a Graph, evitando credenziali statiche sugli endpoint quando si passa a scenari enterprise.

I gruppi dinamici non sono limitati ma sono semplicemente fedeli a ciò che la directory conosce. Con PowerShell e Graph, sei tu a decidere cosa la directory deve sapere.