Registry Inventory in Microsoft Intune

Simone Termine

Introduzione

Registry Inventory in Microsoft Intune consente di raccogliere chiavi e valori selezionati del Registro di Windows direttamente dai dispositivi gestiti, senza dover predisporre ogni volta uno script PowerShell dedicato. La funzionalità arriva con la service release Intune 2607 di luglio 2026 e introduce nel Properties catalog una nuova categoria dedicata al Registro, mentre i dati raccolti vengono mostrati nel Device Inventory del singolo dispositivo.

La configurazione parte dai percorsi e dai valori che l’amministratore ritiene utili per l’inventory. Intune interroga il dispositivo e restituisce il percorso della chiave, il nome del valore, il tipo e il contenuto rilevato durante l’ultima raccolta. Questo permette di controllare in modo centralizzato informazioni che, fino a oggi, richiedevano spesso script di discovery o verifiche manuali eseguite direttamente sul client, soprattutto quando l’obiettivo era leggere un dato senza applicare modifiche.

L’utilità emerge soprattutto durante le attività di verifica e troubleshooting, infatti una policy può risultare applicata nel portale, mentre il dispositivo continua a mostrare un comportamento diverso da quello previsto; allo stesso modo, un’applicazione può registrare nel Registro uno stato, una versione o una configurazione che non coincide con quella attesa. Registry Inventory permette dunque di mettere a confronto questi dati, individuare differenze tra dispositivi gestiti in modo simile e raccogliere un’evidenza aggiuntiva prima di passare all’analisi dei log o a controlli più approfonditi. Il valore restituito descrive però ciò che Intune ha rilevato durante l’ultima raccolta e, da solo, non consente di stabilire quale componente abbia scritto o modificato la chiave.

Cosa cambia con Registry Inventory in Microsoft Intune

Il cambiamento più tangibile riguarda il modo in cui gli amministratori possono raccogliere informazioni personalizzate dal Registro di Windows. Prima dell’arrivo di Registry Inventory, anche una verifica relativamente semplice, come controllare la presenza di un valore o confrontarne il contenuto su più dispositivi, richiedeva in genere uno script di rilevamento, una remediation o uno strumento di inventory distinto. Oltre alla logica necessaria per leggere la chiave, bisognava gestire i dispositivi sui quali il percorso non esisteva, formattare l’output e trovare un sistema pratico per consultare i risultati.

Con Registry Inventory la raccolta viene definita direttamente nel Properties catalog. È sufficiente indicare il percorso e i valori di interesse, assegnare il profilo ai dispositivi e consultare le informazioni restituite attraverso Device Inventory. La gestione diventa quindi dichiarativa: la policy descrive ciò che deve essere raccolto, mentre Intune si occupa di interrogare il client e presentare il dato nel portale. Lo stesso Properties catalog può includere proprietà hardware, informazioni di configurazione e dati applicativi; quest’ultimo scenario è approfondito nell’articolo dedicato a Microsoft Intune App Inventory pubblicato su Endpoint Ninja.

Questa modalità si presta soprattutto ai controlli nei quali il percorso da analizzare è già conosciuto. Può essere utilizzata per verificare impostazioni applicate a livello di dispositivo, versioni e stati registrati dalle applicazioni oppure differenze locali che aiutano a spiegare perché endpoint gestiti in modo simile presentino comportamenti diversi. Tra gli esempi pubblicati da Microsoft rientrano, ad esempio, i valori relativi al servicing dei certificati Secure Boot e la verifica dello stato DHCP nelle sottochiavi delle interfacce di rete.

Il dato raccolto deve comunque essere interpretato nel suo contesto perché Registry Inventory mostra ciò che era presente nel Registro durante l’ultima acquisizione, ma non ricostruisce l’origine della configurazione e non permette di attribuirla automaticamente a una specifica policy. Lo stesso valore potrebbe essere stato scritto da Intune, da Group Policy, da Microsoft Configuration Manager, da uno script, dal programma di installazione o dall’applicazione stessa. Per questo motivo il risultato costituisce un’evidenza utile da confrontare con lo stato delle policy, i log del dispositivo e la documentazione del componente interessato.

Prerequisiti, ruoli e licensing

Registry Inventory è disponibile attraverso il Properties catalog per i dispositivi Windows gestiti da Microsoft Intune. La raccolta può essere utilizzata sia sugli endpoint gestiti esclusivamente dal servizio cloud sia sui dispositivi in co-management con Microsoft Configuration Manager; in entrambi i casi, il dispositivo deve essere Microsoft Entra joined oppure Microsoft Entra hybrid joined. I dispositivi soltanto Microsoft Entra registered non sono indicati tra le configurazioni supportate dalla documentazione Microsoft.

La policy viene creata utilizzando la piattaforma Windows 10 and later e il tipo di profilo Properties catalog. Prima di procedere è quindi opportuno verificare che il dispositivo rientri nel perimetro supportato e che l’account amministrativo disponga delle autorizzazioni necessarie per visualizzare gli endpoint, creare il profilo e assegnarlo ai gruppi previsti.

Per creare e assegnare il profilo è possibile utilizzare il ruolo predefinito Policy and Profile Manager. Quando il modello di delega richiede un ruolo personalizzato, è possibile utilizzare i permessi Organization/Read e Managed Devices/Read per rendere visibili i dispositivi, insieme a Device configurations/Create, Device configurations/Read e Device configurations/Assign per gestire la policy di raccolta. Chi deve soltanto consultare le informazioni presenti in Device Inventory necessita invece del permesso Managed Devices/Read.

Registry Inventory è compreso nelle funzionalità di base di Microsoft Intune Plan 1 e non richiede Microsoft Intune Plan 2 o Microsoft Intune Suite. Restano però validi i requisiti generali del servizio: gli utenti o i dispositivi che beneficiano della gestione tramite Intune devono essere coperti da una licenza appropriata. Questo requisito non va confuso con la licenza dell’amministratore che accede al portale, perché Intune supporta anche l’accesso amministrativo senza licenza, abilitato automaticamente nei tenant creati dopo luglio 2021 e configurabile nei tenant precedenti.

I tre pattern di raccolta

Registry Inventory non esegue una scansione generica del Registro di Windows. La raccolta parte sempre da un percorso definito nella policy e, nella versione iniziale della funzionalità, può riguardare soltanto chiavi presenti sotto HKEY_LOCAL_MACHINE (HKLM). L’amministratore può scegliere fra tre collection pattern, pensati rispettivamente per leggere un singolo valore, tutti i valori contenuti direttamente in una chiave oppure lo stesso valore presente in più sottochiavi immediate.

La scelta dipende dalla struttura della chiave e dalla domanda alla quale deve rispondere l’inventory. Quando il percorso e il value name sono già conosciuti, Single Value offre il risultato più circoscritto: Intune legge soltanto l’elemento richiesto, rendendo più semplice confrontare il dato tra dispositivi e interpretare eventuali risultati vuoti o Not found.

All Values Under Key (Non-Recursive) è adatto alle chiavi che contengono un gruppo ristretto di proprietà direttamente correlate. Intune raccoglie tutti i valori presenti a quel livello, senza entrare nelle sottochiavi. Prima di utilizzare questo pattern è quindi opportuno esaminare il percorso su un dispositivo di test, così da verificare quali informazioni verranno acquisite ed evitare una raccolta più ampia del necessario.

Same Value Across Subkeys risponde invece agli scenari nei quali la stessa proprietà viene ripetuta per più istanze. Un esempio è rappresentato dalle interfacce di rete, archiviate in sottochiavi distinte ma caratterizzate da value name comuni. Intune esamina soltanto le sottochiavi immediatamente successive al percorso base; eventuali livelli più profondi non vengono attraversati.

Creare una policy Registry Inventory

Per creare la policy, accedete al Microsoft Intune admin center, aprite Devices > Windows e, nella sezione Manage devices, selezionate Configuration > Create > New Policy. Nel pannello Create a profile, impostate Platform su Windows 10 and later e Profile type su Properties catalog, quindi selezionate Create.

Nella pagina Basics assegnate alla policy un nome che permetta di riconoscerne immediatamente lo scopo. Per la raccolta utilizzata in questa guida può essere adottato, per esempio, Windows – Registry Inventory – OS Version. Il campo Description è facoltativo, ma vale la pena utilizzarlo per indicare quale informazione viene raccolta, a quale gruppo pilota è destinata la policy e chi dovrà interpretarne i risultati. In un tenant nel quale sono presenti più profili Properties catalog, una descrizione completa evita di dover aprire ogni policy per comprenderne la finalità. Dopo aver compilato i campi, selezionate Next.

Nella pagina Configuration properties, selezionate Add properties per aprire il Properties picker. Espandete la categoria Registry, selezionate la proprietà Registry key e confermate la scelta con Select. L’aggiunta della proprietà rende disponibili nella policy i campi necessari per definire il pattern di raccolta, il percorso della chiave e, quando previsto, il nome del valore.

Esempio con un singolo valore

Dopo aver aggiunto la proprietà Registry key, la pagina Configuration properties mostra la frequenza di aggiornamento prevista e il comando Add, che consente di inserire una o più righe di raccolta. Per il primo test utilizzeremo il pattern Single value e leggeremo DisplayVersion dalla chiave che contiene le informazioni sulla release di Windows installata.

Selezionate Add, quindi compilate i tre campi con i valori riportati nella tabella. In questo caso il percorso individua una chiave machine-wide, mentre DisplayVersion è un valore di tipo stringa che può essere facilmente confrontato con quanto presente sul dispositivo. L’esempio è quindi adatto a una prima verifica della funzionalità, perché utilizza un dato non riservato e restituisce un risultato immediatamente riconoscibile.

La schermata indica una frequenza di aggiornamento di 24 ore. Questa periodicità deve essere tenuta presente durante i test: Registry Inventory non fornisce una lettura in tempo reale e una modifica eseguita localmente potrebbe comparire nel portale soltanto dopo il ciclo di raccolta successivo. Dopo aver controllato il percorso, il collection pattern e il nome del valore, selezionate Next. La documentazione Microsoft indica inoltre che la prima acquisizione dei dati di inventory può richiedere fino a 24 ore.

Completata la configurazione, nel passaggio Scope tags potete associare alla policy gli eventuali tag previsti dal modello di delega amministrativa del tenant. Se non utilizzate Scope Tags personalizzati, è possibile proseguire mantenendo il tag Default, che Intune assegna automaticamente agli oggetti supportati privi di una classificazione specifica. Gli Scope Tags regolano la visibilità e la gestione amministrativa della policy attraverso Intune RBAC; non stabiliscono quali dispositivi riceveranno il profilo. Per approfondire questa distinzione, rimando al mio articolo Scope Tags in Microsoft Intune: configurazione e best practices pubblicato su ICT Power.

Nella pagina Assignments selezionate il gruppo Microsoft Entra che riceverà la policy. Poiché la raccolta riguarda informazioni memorizzate a livello di dispositivo, per il pilota è preferibile utilizzare un gruppo composto da endpoint Windows, mantenendo il perimetro abbastanza ristretto da consentire il confronto tra i risultati restituiti da Intune e quelli rilevati localmente.

Il gruppo pilota dovrebbe includere alcuni dispositivi rappresentativi delle configurazioni presenti nell’ambiente, senza estendere subito la raccolta all’intera popolazione gestita. Qualora il gruppo selezionato comprendesse endpoint con caratteristiche diverse, un assignment filter potrebbe restringere ulteriormente il target in base alle proprietà del dispositivo.

Nella pagina Review + create verificate che il riepilogo riporti il percorso completo della chiave, il pattern Single value, il value name DisplayVersion, gli Scope Tags previsti e il gruppo scelto per l’assegnazione. Se le informazioni sono corrette, selezionate Create per completare la configurazione.

La policy viene creata e associata al gruppo indicato; i dispositivi la ricevono durante uno dei successivi check-in con Intune. La comparsa del profilo tra le configuration policy conferma quindi la creazione dell’oggetto, mentre per valutare la raccolta sarà necessario attendere che il Device Inventory Agent elabori la richiesta e invii i dati al servizio.

Consultare i valori raccolti in Device Inventory

Dopo che il dispositivo ha ricevuto la policy e ha completato il primo ciclo di raccolta, i valori del Registro possono essere consultati direttamente dalla relativa pagina di inventory. Nel Microsoft Intune admin center, aprite Devices > Windows, selezionate il dispositivo da controllare e, nella sezione Tools, scegliete Device inventory. Nell’elenco delle categorie disponibili, selezionate quindi Registry. Questo è il percorso indicato anche dalla documentazione Microsoft per visualizzare le informazioni raccolte tramite il Properties catalog.

La tabella mostra una riga per ogni elemento configurato nella policy. Per il valore utilizzato nell’esempio sono disponibili il percorso completo della chiave, il nome DisplayVersion, il contenuto rilevato, il tipo di dato, lo stato della raccolta e la data dell’ultima acquisizione. Nello screenshot, Intune restituisce il valore 25H2 con tipo REG_SZ e stato Success, confermando che il Device Inventory Agent è riuscito a leggere e inviare l’informazione richiesta.

Lo stato Success riguarda esclusivamente l’esito della raccolta: indica che Intune ha acquisito il valore, senza esprimere una valutazione sulla correttezza della configurazione. Per stabilire se il dato corrisponde a quello previsto occorre confrontarlo con il valore atteso per il dispositivo, con la policy assegnata e, quando necessario, con le evidenze disponibili nei log.

Nella release iniziale, la procedura ufficiale documenta la consultazione dei valori del Registro dal Device Inventory del singolo endpoint. Microsoft Learn include Device Query e Device Query for multiple devices tra i contenuti correlati al Properties catalog, ma nella sezione dedicata a Registry Inventory indica ancora Device Inventory come esperienza prevista per visualizzare i dati raccolti. Prima di progettare report tenant-wide o query centralizzate è quindi necessario verificare che il relativo supporto sia stato esplicitamente documentato.

Interpretare i risultati

Quando si consultano i dati raccolti, un campo vuoto non indica necessariamente che la policy abbia fallito. Registry Inventory distingue infatti tra un valore esistente ma privo di contenuto e una chiave, o un value name, che non è presente sul dispositivo. La differenza è importante durante il troubleshooting, perché nei due casi il Device Inventory Agent ha incontrato condizioni diverse.

Se la chiave e il valore esistono, ma il relativo contenuto è vuoto, la raccolta viene comunque completata con successo e la colonna Value data non mostra alcun dato. Quando invece Intune non trova il percorso configurato oppure il value name richiesto, il risultato viene riportato come Not found. Questa condizione riguarda soltanto il dispositivo interessato e non interrompe la raccolta sugli altri endpoint assegnati alla stessa policy.

Un risultato Not found non deve essere considerato automaticamente un errore della policy. La chiave potrebbe non essere prevista su quella versione di Windows, dipendere da uno specifico componente hardware oppure essere creata da un’applicazione soltanto dopo l’installazione, il primo avvio o l’applicazione di una determinata configurazione. Prima di modificare il profilo è quindi opportuno verificare localmente che il percorso e il value name esistano davvero sul dispositivo analizzato.

Esistono poi situazioni nelle quali Intune non acquisisce il contenuto anche se il valore è presente. Ogni valore è limitato a 6 KB, mentre il dispositivo può raccogliere fino a 100 registry keys; i dati che superano questi limiti vengono ignorati. Lo stesso avviene quando i controlli euristici classificano un valore come potenzialmente sensibile, per esempio perché potrebbe contenere credenziali, token, certificati, chiavi private o connection string. In questi casi è necessario esaminare lo stato restituito, la configurazione della policy e la natura del dato, evitando di ricondurre tutte le mancate acquisizioni a Not found.

Anche il momento della raccolta incide sull’interpretazione. Il valore mostrato in Device Inventory rappresenta quanto rilevato nell’ultima acquisizione e potrebbe quindi non includere una modifica eseguita localmente in seguito. Prima di confrontare il dato con la configurazione corrente del dispositivo, controllate la colonna Last collection e considerate la frequenza di aggiornamento di 24 ore prevista dal profilo.

Verificare il valore direttamente sul dispositivo

Durante il pilota è utile confrontare quanto visualizzato in Device Inventory con il valore presente sul dispositivo, soprattutto quando Intune restituisce Not found oppure mostra un dato diverso da quello atteso. Questa verifica consente di capire se la differenza dipende dalla configurazione della policy, dal momento in cui è stata eseguita l’ultima raccolta o dall’effettiva assenza della chiave sul client.

Per controllare l’esempio utilizzato nella guida, aprite Windows Terminal, Windows PowerShell oppure il Prompt dei comandi ed eseguite:

reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v DisplayVersion

Il comando reg query interroga il Registro senza apportare modifiche e nell’output vengono mostrati il percorso della chiave, il nome del valore, il tipo e il contenuto rilevato; nel nostro caso, DisplayVersion è un valore REG_SZ contenente 25H2, lo stesso dato restituito da Registry Inventory nel Microsoft Intune admin center.

Per questa chiave non è normalmente necessario eseguire il terminale con privilegi amministrativi, perché il percorso è leggibile anche da un utente standard. Le autorizzazioni possono però variare per altre aree del Registro: se il comando restituisce un errore di accesso, ripetete il controllo da una sessione elevata dopo aver verificato che l’account sia autorizzato a leggere la chiave.

Se il comando restituisce il valore previsto mentre Device Inventory mostra Not found, controllate che nella policy siano stati inseriti esattamente lo stesso percorso e lo stesso value name, senza spazi aggiuntivi o errori di digitazione. È inoltre necessario confrontare l’orario della verifica locale con la colonna Last collection, perché il dato presente nel portale potrebbe risalire a un ciclo di inventory precedente.

Quando percorso e nome risultano corretti, ma il valore non compare dopo il successivo aggiornamento previsto, l’analisi può proseguire nei log del Device Inventory Agent disponibili in C:\Program Files\Microsoft Device Inventory Agent\Logs, ci arriveremo al capitolo Troubleshooting di Registry Inventory.

Limiti della prima versione

Registry Inventory è stato progettato per raccogliere informazioni associate alla configurazione del dispositivo e, nella release attuale, accetta esclusivamente percorsi sotto HKEY_LOCAL_MACHINE (HKLM).

Microsoft applica anche limiti precisi al volume dei dati: ogni valore raccolto può avere una dimensione massima di 6 KB e ciascun dispositivo può includere fino a 100 registry keys nell’inventory. Quando un valore o il dispositivo supera queste soglie, Intune ignora i dati eccedenti e restituisce il risultato previsto per quella specifica raccolta; il superamento di un limite non implica quindi, da solo, che l’intera policy abbia smesso di funzionare.

La profondità della lettura dipende inoltre dal collection pattern selezionato. All Values Under Key (Non-Recursive) acquisisce soltanto i valori presenti direttamente nella chiave indicata, mentre Same Value Across Subkeys cerca il value name nelle sottochiavi immediate. Nessuno dei due pattern attraversa ricorsivamente l’intera struttura sottostante, un comportamento che riduce il rischio di raccogliere più informazioni di quelle previste.

A questi vincoli si aggiunge una protezione dedicata ai dati potenzialmente sensibili. Intune utilizza una logica di rilevamento per individuare valori che potrebbero contenere segreti, credenziali, token di autenticazione, certificati, chiavi private, connection string o altre informazioni utilizzabili per ottenere accesso a sistemi e servizi. Quando un contenuto viene classificato come potenzialmente sensibile, il valore non viene acquisito.

Quando continuano a servire script e remediation

Registry Inventory è particolarmente adatto quando il percorso è già conosciuto e l’obiettivo consiste nel verificare quale valore sia presente sul dispositivo. La funzionalità acquisisce il dato e lo rende disponibile in Device Inventory, ma non esegue elaborazioni personalizzate, non mette in relazione più sorgenti e non modifica la configurazione locale. Il suo perimetro rimane quindi quello della visibilità e del troubleshooting dichiarato da Microsoft.

Uno script continua a essere più appropriato quando il controllo deve combinare più chiavi, leggere file o servizi, esaminare il contesto dell’utente, trasformare il contenuto oppure restituire un risultato calcolato. Se al rilevamento deve seguire una correzione, è invece possibile ricorrere a Remediations, che utilizza un detection script per individuare la condizione e un remediation script per applicare l’intervento previsto. Remediations presenta prerequisiti e requisiti di licensing propri, che devono essere verificati separatamente da quelli di Registry Inventory.

Anche la valutazione della conformità rimane un processo distinto. Le compliance policy confrontano il dispositivo con requisiti definiti dall’organizzazione e restituiscono a Intune uno stato compliant o non-compliant, che può essere utilizzato da Microsoft Entra Conditional Access per prendere decisioni di accesso. Un valore raccolto tramite Registry Inventory può fornire un’evidenza utile durante l’analisi, ma non viene trasformato automaticamente in un requisito di compliance e non determina il blocco delle risorse aziendali.

Interrompere la raccolta

Per fermare Registry Inventory è necessario modificare il profilo Properties catalog e rimuovere tutte le proprietà configurate nella categoria Registry; in alternativa, è possibile eliminare l’intera policy quando non contiene altre categorie che devono continuare a essere raccolte.

Quando una raccolta viene introdotta per un’indagine, una migrazione o un’attività temporanea, è bene registrare nella descrizione o nella documentazione operativa la data prevista per la revisione. In questo modo è possibile rimuovere le chiavi che non hanno più una finalità, liberare parte del limite per-device e tenere conto del tempo durante il quale i risultati già acquisiti potrebbero continuare a essere consultabili.

Troubleshooting di Registry Inventory

Quando i valori del Registro non compaiono in Device Inventory, è preferibile partire dal sintomo osservato e verificare in ordine la disponibilità della funzionalità, l’assegnazione della policy, la presenza locale della chiave e il momento dell’ultima raccolta. Modificare subito il profilo può rendere più difficile distinguere un errore di configurazione da un semplice ritardo nell’elaborazione dell’inventory.

Registry Inventory è stato introdotto con la service release 2607 e gli aggiornamenti di Intune vengono distribuiti progressivamente tra i tenant. La versione assegnata al proprio ambiente può essere controllata in Tenant administration > Tenant status, mentre la scheda Service health and message center raccoglie gli incidenti, gli advisory e le comunicazioni che interessano il tenant.

Se la funzionalità è disponibile e la policy risulta correttamente assegnata, bisogna considerare i tempi di elaborazione. Microsoft indica che la prima raccolta dell’inventory può richiedere fino a 24 ore; nello stesso periodo il dispositivo deve ricevere la policy, elaborare le proprietà richieste e inviare il risultato al servizio. I prerequisiti comprendono inoltre un dispositivo Windows gestito da Intune o in co-management, Microsoft Entra joined oppure Microsoft Entra hybrid joined.

Quando il portale mostra Not found, il controllo locale con reg query permette di stabilire se la chiave e il value name siano effettivamente presenti. Se il comando restituisce il dato previsto, confrontate il percorso carattere per carattere con quello configurato nel Properties catalog e verificate la colonna Last collection: il risultato visualizzato potrebbe risalire a un’acquisizione precedente rispetto alla modifica locale.

Per i problemi che persistono, i log del client sono disponibili nel percorso C:\Program Files\Microsoft Device Inventory Agent\Logs.

Nella cartella possono essere presenti il file corrente e uno o più file ruotati relativi alle raccolte precedenti. Nello screenshot, per esempio, sono visibili IntuneInventoryHarvesterLog.log, una relativa copia storica e InventoryAdaptor.log. La documentazione Microsoft non assegna pubblicamente un ruolo diagnostico distinto a ciascun file, quindi è preferibile esaminarli in base all’orario del problema, cercando errori o eventi registrati durante l’applicazione della policy e l’ultimo ciclo di inventory.

I log possono essere recuperati anche dal Microsoft Intune admin center attraverso l’azione remota Collect Diagnostics, evitando di accedere direttamente al dispositivo quando questo non è disponibile fisicamente. Microsoft indica sia il percorso locale sia questa azione remota come strumenti di troubleshooting del Properties catalog.

Prima di concludere che la raccolta non funzioni, sarebbe meglio mettere in relazione quattro elementi: lo stato della policy, la presenza locale della chiave, la data indicata in Last collection e gli eventi registrati nei log. Questa correlazione consente di separare una policy configurata in modo errato da un valore assente, da un dispositivo che non ha ancora elaborato il profilo o da un aggiornamento non ancora inviato al servizio.

Pianificare il rollout di Registry Inventory

Anche se Registry Inventory esegue una raccolta di sola lettura, è consigliabile iniziare da un gruppo pilota ristretto, composto da dispositivi che rappresentino le principali versioni di Windows, configurazioni di join e applicazioni presenti nell’ambiente. Lo scopo del test non è soltanto verificare che la policy venga applicata, ma anche accertare che i percorsi esistano sui sistemi previsti, che i valori restituiti abbiano il significato atteso e che eventuali risultati Not found siano spiegabili in base alla configurazione del dispositivo.

Durante questa fase occorre considerare anche i tempi e i limiti della raccolta. Come già detto in precedenza, la prima acquisizione può richiedere fino a 24 ore e applica un massimo di 100 registry keys per dispositivo, con una dimensione non superiore a 6 KB per ciascun valore. Una policy tecnicamente valida può quindi produrre informazioni poco utili se include percorsi troppo generici, chiavi non presenti sull’intero parco dispositivi oppure dati che nessuno ha il compito di analizzare.

Prima di estendere l’assegnazione, è utile stabilire per ogni proprietà perché viene raccolta, chi dovrà consultarla e quale decisione operativa potrà derivare dal risultato. Per esempio, un valore può servire durante la verifica di una migrazione applicativa, per confrontare dispositivi che presentano comportamenti differenti oppure per confermare lo stato di una configurazione locale. Quando manca uno scenario d’uso concreto, la raccolta tende a rimanere attiva senza offrire un beneficio reale e continua a occupare parte del limite disponibile.

Il rollout può quindi procedere ampliando gradualmente il gruppo di destinazione e confrontando, su un campione di dispositivi, i risultati presenti nel portale con quelli rilevati localmente. È opportuno associare alla policy anche una data di revisione, soprattutto quando viene creata per un’attività temporanea, in modo da rimuovere le chiavi che non servono più e mantenere l’inventory comprensibile nel tempo.

Conclusioni

Registry Inventory in Microsoft Intune porta nel Properties catalog una modalità nativa per raccogliere valori selezionati del Registro di Windows e consultarli nel Device Inventory del singolo dispositivo. L’amministratore definisce quali informazioni acquisire, mentre Intune gestisce la raccolta e presenta percorso, nome, tipo e contenuto del valore rilevato.

La funzionalità risulta particolarmente utile quando serve verificare un dato conosciuto senza sviluppare uno script dedicato, per esempio durante un’attività di troubleshooting o nel confronto tra endpoint configurati in modo simile. Rimane però uno strumento di inventory: non applica correzioni, non determina automaticamente la conformità del dispositivo e non sostituisce gli script quando il controllo richiede elaborazioni, correlazioni o interventi sulla configurazione.

Un’adozione efficace dipende quindi dalla qualità delle informazioni scelte per la raccolta. Partire con poche chiavi, verificare i risultati su dispositivi pilota e riesaminare periodicamente le policy permette di utilizzare Registry Inventory come supporto concreto alle attività amministrative, evitando di trasformarlo in un archivio di valori privi di un utilizzo definito.