Perché Active Directory da sola non basta piùMicrosoft ha recentemente pubblicato un messaggio diretto ai reparti IT: Active Directory on-premises, da sola, non è più sufficiente per reggere il modello di sicurezza richiesto oggi. Non si tratta di un annuncio di fine vita per AD — che resta il fondamento dell’identità in moltissime organizzazioni — ma di un cambio di prospettiva su cosa un’infrastruttura identity debba garantire quando lavoro ibrido, SaaS, fornitori esterni e ora anche agenti AI accedono quotidianamente a dati e sistemi aziendali.

Per chi gestisce l’infrastruttura identity in produzione, la domanda non è “AD oppure #Entra ID”, ma come costruire un’architettura ibrida che riduca la superficie d’attacco senza un rip-and-replace che nella maggior parte dei contesti enterprise non è realistico né necessario. Vediamo cosa cambia concretamente e quali strumenti usare per la modernizzazione incrementale.

I cinque segnali di un’infrastruttura identity da modernizzareIl ragionamento di Microsoft si basa su cinque aree di attrito che chi amministra AD riconoscerà facilmente:

Onere operativo: patching dei domain controller, gestione #backup, rinnovo certificati, procedure di disaster recovery. Tempo sottratto ad automazione e governance, non alla sicurezza in sé.

Un modello di trust superato: AD è nato per un perimetro di rete definito. Il lavoro ibrido richiede decisioni di accesso basate su rischio dell’utente, postura del dispositivo e contesto — non sulla semplice appartenenza alla rete aziendale.

Proliferazione SaaS: Microsoft 365, Salesforce, Workday, ServiceNow e decine di altre applicazioni #cloud richiedono un piano di identità cloud-native, non solo una federazione con AD.

Utenti esterni: contractor, partner e fornitori richiedono provisioning e deprovisioning sistematico, difficile da gestire con i soli strumenti nativi di AD.

Permessi per agenti AI: applicazioni e agenti che accedono a dati ed eseguono azioni per conto degli utenti richiedono un modello di autorizzazione granulare che AD non è stato progettato per gestire.

Il punto centrale non è la sostituzione, ma la modernizzazione incrementale: spostare autenticazione e controlli di accesso verso il cloud, mantenendo AD per i carichi che ne dipendono ancora, fino a quando anche quelli non vengono modernizzati o dismessi.

Entra Connect Sync vs Cloud Sync: quale scegliereIl primo bivio tecnico in ogni percorso di modernizzazione riguarda lo strumento di sincronizzazione tra AD on-premises e Microsoft Entra ID. Le due opzioni non sono intercambiabili e la scelta ha implicazioni architetturali concrete.

Microsoft Entra Connect Sync è il tool “storico”: richiede un server #Windows dedicato (indicativamente 4 vCPU, 8 GB RAM, 100 GB disco) con un motore di sincronizzazione basato su #SQL Server (LocalDB per ambienti piccoli, SQL Server completo oltre una certa scala). Esegue una sincronizzazione differenziale ogni 30 minuti — non è possibile scendere sotto questa soglia per limiti architetturali — e regge ambienti fino a 500.000+ oggetti. Supporta scenari che Cloud Sync non copre: Pass-through Authentication (PTA), Group Writeback per i gruppi Microsoft 365, e mapping avanzato di attributi personalizzati.

Microsoft Entra Cloud Sync è invece un agente leggero, gestito da Microsoft, installabile su un domain controller o su un server nelle vicinanze, senza alcuna dipendenza da SQL Server. Sincronizza circa ogni 2 minuti — molto più reattivo di Connect Sync — ma è limitato a circa 150.000 oggetti. Supporta solo Password Hash Sync (non PTA), non offre Group Writeback e ha opzioni di mapping attributi più limitate. In compenso offre alta disponibilità nativa tramite agenti multipli auto-ridondanti, contro la modalità staging attivo-passivo di Connect Sync che richiede failover manuale.

In sintesi: Connect Sync resta la scelta per organizzazioni grandi con requisiti di PTA o Group Writeback; Cloud Sync è preferibile per nuovi deployment con requisiti più semplici, dove la cadenza di sync più rapida e il minor carico operativo pesano più della scala massima supportata.

Privileged Identity Management: ridurre l’esposizione degli account con ruoli elevatiUno dei controlli più efficaci per ridurre la superficie d’attacco descritta da Microsoft è l’eliminazione degli account con ruoli privilegiati assegnati in modo permanente (“standing access”). Microsoft Entra Privileged Identity Management (PIM) sposta il modello verso assegnazioni eligible (idonee ma non attive) che l’utente attiva solo quando necessario, per una durata limitata e con giustificazione registrata a fini di audit.

Con Microsoft Graph PowerShell, la gestione di questo flusso è completamente scriptabile. Assegnazione di un ruolo idoneo per 10 ore:

Connect-MgGraph -Scopes "RoleManagement.ReadWrite.Directory"

$params = @{
"PrincipalId" = "d29e358a-a443-4d83-98b3-499a5405bb5b"
"RoleDefinitionId" = "88d8e3e3-8f55-4a1e-953a-9b9898b8876b"
"Justification" = "Aggiunta assegnazione idonea"
"DirectoryScopeId" = "/"
"Action" = "AdminAssign"
"ScheduleInfo" = @{
"StartDateTime" = Get-Date
"Expiration" = @{
"Type" = "AfterDuration"
"Duration" = "PT10H"
}
}
}

New-MgRoleManagementDirectoryRoleEligibilityScheduleRequest -BodyParameter $params |
Format-List Id, Status, Action, RoleDefinitionId, Justification, PrincipalIdL’utente attiva poi il ruolo solo quando serve, per un tempo limitato (qui un’ora):

$params = @{
"PrincipalId" = "d29e358a-a443-4d83-98b3-499a5405bb5b"
"RoleDefinitionId" = "88d8e3e3-8f55-4a1e-953a-9b9898b8876b"
"Justification" = "Attivazione ruolo per intervento pianificato"
"DirectoryScopeId" = "/"
"Action" = "SelfActivate"
"ScheduleInfo" = @{
"StartDateTime" = Get-Date
"Expiration" = @{
"Type" = "AfterDuration"
"Duration" = "PT1H"
}
}
}

New-MgRoleManagementDirectoryRoleAssignmentScheduleRequest -BodyParameter $paramse la disattiva esplicitamente al termine, o lascia che scada automaticamente:

$params = @{
"PrincipalId" = "d29e358a-a443-4d83-98b3-499a5405bb5b"
"RoleDefinitionId" = "88d8e3e3-8f55-4a1e-953a-9b9898b8876b"
"Justification" = "Fine intervento"
"DirectoryScopeId" = "/"
"Action" = "SelfDeactivate"
}

New-MgRoleManagementDirectoryRoleAssignmentScheduleRequest -BodyParameter $paramsIl parametro DirectoryScopeId impostato a / assegna il ruolo a livello di intero tenant; per limitare lo scope a una specifica unità amministrativa si usa un AppScopeId o lo scope dell’unità stessa. Automatizzare questi flussi via Graph PowerShell (ad esempio da una pipeline di onboarding/offboarding) è spesso più affidabile che affidarsi esclusivamente al portale, soprattutto quando serve integrare l’attivazione dei ruoli con sistemi di ticketing o approvazione esterni.

Autenticazione phishing-resistant e riduzione dei protocolli legacyLa seconda area indicata da Microsoft riguarda i metodi di autenticazione. Nella pratica, questo significa due interventi concreti su ogni tenant: primo, abilitare metodi resistenti al phishing come le chiavi di sicurezza FIDO2 o Windows Hello for Business al posto di SMS e app authenticator basate solo su OTP, che restano vulnerabili ad attacchi MFA fatigue e a proxy AiTM (adversary-in-the-middle). Secondo, disattivare progressivamente i protocolli di autenticazione legacy (Basic Auth su Exchange, POP/IMAP non moderni) che bypassano completamente la Conditional Access basata su rischio, perché non supportano la valutazione di device compliance o segnali di rischio in tempo reale.

Un percorso pragmatico per chi parte da AD puroPer chi gestisce ancora un’infrastruttura AD-centrica, l’indicazione pratica che emerge da questo cambio di approccio è di procedere per fasi, senza inseguire una migrazione big-bang:

Distribuire Entra Connect Sync o Cloud Sync (in base alla scala e ai requisiti di PTA/Group Writeback discussi sopra) per portare le identità in Entra ID mantenendo AD come source of truth.

Attivare Conditional Access basata su rischio utente e postura del dispositivo per le applicazioni cloud, riducendo la dipendenza dal solo perimetro di rete.

Migrare gli account con privilegi elevati a PIM, eliminando le assegnazioni permanenti dei ruoli critici.

Mappare quali applicazioni legacy dipendono ancora da Kerberos/NTLM puro e pianificarne la modernizzazione o l’isolamento in un segmento di rete dedicato.

Estendere la governance delle identità (lifecycle, access review periodiche) anche a utenti esterni, applicazioni registrate e, dove presenti, agenti AI con accesso a dati aziendali.

Nessuno di questi passaggi richiede di spegnere i domain controller. Il valore pratico dell’approccio ibrido è proprio questo: ridurre progressivamente la superficie d’attacco esposta dai componenti legacy, senza interrompere le applicazioni che oggi dipendono ancora da AD, fino a quando la modernizzazione di quelle stesse applicazioni non renderà possibile una dismissione più ampia.

Articolo ispirato e approfondito a partire da: Microsoft Says Active Directory Alone is No Longer Enough for Modern Identity Security, Petri IT Knowledgebase.

Chi amministra Microsoft #Entra ID conosce bene il problema dei “gruppi nidificati”: per anni non è stato possibile costruire un gruppo dinamico che includesse automaticamente i membri di un altro gruppo. La regola preview memberOf, introdotta proprio per colmare questa lacuna, sta però per essere ritirata. Dal 3 novembre 2026 tutte le configurazioni che la usano smetteranno di aggiornarsi, restando congelate all’ultimo stato elaborato correttamente. Se gestite gruppi dinamici, unità amministrative dinamiche o policy di entitlement management basate su memberOf, è il momento di pianificare la migrazione.

Cos’è (stato) l’operatore memberOfIn anteprima pubblica, memberOf ha permesso di creare gruppi a membership dinamica popolati a partire dall’appartenenza ad altri gruppi, di sicurezza, Microsoft 365 o sincronizzati da Active Directory on-premises. La regola si scriveva nella sintassi avanzata del rule editor, non essendo mai stata supportata dal rule builder grafico:

// Regola per un gruppo dinamico di utenti
user.memberof -any (group.objectId -in ['<groupObjectId>'])

// Regola per un gruppo dinamico di device
device.memberof -any (group.objectId -in ['<groupObjectId>'])

// Più gruppi sorgente contemporaneamente
user.memberof -any (group.objectId -in ['<groupObjectId1>', '<groupObjectId2>'])Era possibile usarla per gruppi dinamici veri e propri, per unità amministrative dinamiche e per policy di auto-assignment in Entra ID Governance, con limiti già stringenti in preview: 500 gruppi memberOf per tenant, massimo 50 gruppi sorgente per regola, nessuna combinazione con altri operatori o con altre regole memberOf annidate.

Perché Microsoft la ritiraDurante la preview, Microsoft ha osservato che l’uso di memberOf può rallentare l’elaborazione della membership dinamica per tutti i gruppi del tenant, non solo per quelli che la utilizzano: un singolo gruppo configurato con questo operatore può introdurre ritardi di elaborazione a livello di tenant. Per questo motivo Microsoft ha deciso di ritirare l’operatore dalla preview, pur riconoscendo la validità dello scenario d’uso, e sta sviluppando una soluzione alternativa più scalabile, senza però fornire ancora una data di disponibilità.

Cosa succede dopo il 3 novembre 2026Le configurazioni che usano ancora memberOf non genereranno errori visibili: semplicemente smetteranno di aggiungere o rimuovere membri quando cambia l’appartenenza ai gruppi sorgente, restando congelate all’ultimo stato noto. È un comportamento subdolo perché non c’è un evento di rottura evidente, solo un progressivo disallineamento tra la realtà organizzativa e ciò che Entra ID applica. Gli effetti possono includere:

Accessi Teams e SharePoint non più aggiornati per utenti entrati o usciti da un gruppo sorgente

Targeting delle policy di Conditional Access basato su appartenenze obsolete

Licenze assegnate tramite group-based licensing non più coerenti con l’organico reale

Ambiti amministrativi (administrative unit) che non riflettono più la struttura corrente

Assegnazioni di access package in Entra ID Governance bloccate sullo stato congelato

Come prepararsi: audit prima della deadlineIl primo passo è mappare ogni configurazione che dipende da memberOf. Per i gruppi dinamici, si può esportare l’elenco dall’Entra admin center oppure interrogare Microsoft Graph #PowerShell cercando la stringa nella proprietà MembershipRule:

Connect-MgGraph -Scopes "Group.Read.All"

Get-MgGroup -All -Filter "groupTypes/any(c:c eq 'DynamicMembership')" `
-Property Id, DisplayName, MembershipRule |
Where-Object { $_.MembershipRule -match 'memberof' } |
Select-Object Id, DisplayName, MembershipRulePer le unità amministrative dinamiche e le policy di auto-assignment dell’entitlement management non esiste (ancora) un filtro diretto lato server sulla regola: occorre enumerare gli oggetti e verificare la proprietà della regola dinamica, ad esempio:

Unità amministrative dinamiche

Get-MgDirectoryAdministrativeUnit -All -Property Id, DisplayName, MembershipRule |
Where-Object { $_.MembershipRule -match 'memberof' }

Policy di auto-assignment (Entitlement Management)

Get-MgEntitlementManagementAccessPackageAssignmentPolicy -All |
Where-Object { $_.AutomaticRequestSettings.RequestAccessForAllowedTargets -ne $null }Per le policy di entitlement management è comunque consigliabile incrociare l’output con la revisione manuale in Entra ID Governance, dato che la struttura della regola può variare a seconda di come è stata configurata.

Strategie di migrazioneUna volta identificate le configurazioni a rischio, Microsoft indica due strade principali:

Sostituire la regola con operatori dinamici supportati (ad esempio basati su attributi utente o dispositivo), quando esiste un equivalente funzionale

Convertire a membership assegnata quando non è possibile replicare la logica di nesting con le regole standard, accettando la gestione manuale o tramite automazione esterna (es. script PowerShell schedulati o Logic App)

In entrambi i casi, prima di considerare chiusa la migrazione bisogna validare concretamente: verificare che la membership finale del gruppo coincida con quella attesa, controllare che le assegnazioni di licenza, gli scope di Conditional Access e i pacchetti di accesso continuino a comportarsi correttamente, ed eliminare le configurazioni ormai inutilizzate invece di lasciarle come debito tecnico silente.

ConclusioneIl ritiro di memberOf è un promemoria di un principio più generale nel #cloud amministrato: le funzionalità in preview non vanno mai considerate stabili in produzione, per quanto risolvano un problema reale. Con circa tre mesi di margine dalla data di scrittura di questo articolo al 3 novembre 2026, il momento giusto per l’audit è ora, prima che il “congelamento” silenzioso della membership diventi un problema di accesso scoperto in produzione da un utente che segnala di aver perso l’accesso a un canale Teams.

Fonte: Microsoft Learn – Configure dynamic membership groups with the memberOf operator, con approfondimenti da 4sysops e Petri IT Knowledgebase.

Il problema non è la mancanza di strumenti, è l’ordine in cui si usanoWindows include più utility diagnostiche di quante un amministratore ne userà mai tutte. Eppure la causa più comune di sessioni di troubleshooting infruttuose non è l’ignoranza dei tool, ma la sequenza sbagliata: si parte da un comando di riparazione (sfc /scannow, un reset di Windows Update, un DISM al buio) prima ancora di aver capito quale sottosistema sta effettivamente fallendo. Il risultato è tempo perso, evidenze diagnostiche distrutte dal riavvio, e spesso la causa radice che resta lì, pronta a ripresentarsi la settimana successiva.

Vale la pena fermarsi a formalizzare un metodo, perché è quello che separa un troubleshooting efficace da un’accozzaglia di tentativi casuali. Di seguito un processo in cinque passi, seguito da una rassegna degli strumenti chiave e da una tabella sintesi sintomo → strumento che può diventare un riferimento rapido da tenere a portata di mano durante un incidente.

Un processo ripetibile prima di toccare qualsiasi comandoLa maggior parte delle sessioni di troubleshooting falliscono prima ancora che venga lanciato il primo comando. Un amministratore vede un errore, prova un comando di riparazione che conosce, riavvia, e scopre che il problema originale è ancora lì. Un approccio più solido richiede di rallentare abbastanza da stabilire una baseline:

Confermare o riprodurre il problema: è cronico o è stato un episodio isolato?

Registrare il sintomo esatto: messaggio di errore, orario, utente coinvolto, dispositivo, modifiche recenti.

Raccogliere le evidenze dal sistema più probabilmente coinvolto.

Applicare una modifica alla volta, partendo dall’opzione meno invasiva.

Verificare il risultato e documentare cosa è effettivamente cambiato.

Un esempio concreto: se Windows Update fallisce con un errore generico, la tentazione è resettare tutti i componenti di aggiornamento in blocco. Il primo passo corretto è invece capire in quale fase è avvenuto il fallimento — scan, download, staging, installazione o riavvio — perché questa distinzione determina se bisogna guardare i log di Windows Update, i log di servicing, lo stato del disco, la configurazione delle policy o la connettività di rete.

Event Viewer: il primo posto dove cercare quando c’è un timestampEvent Viewer è il punto di partenza quando il sintomo ha un orario preciso: un crash applicativo, un riavvio inatteso, un servizio che si ferma, un problema di driver, un’installazione fallita. Si parte dai Windows Logs, filtrando Application, System e Setup per eventi Critical, Error e Warning nell’intorno temporale del problema, per poi individuare l’event source, l’event ID, il modulo che genera il fault, il nome del servizio o del driver coinvolto.

Il criterio per separare il segnale dal rumore è la ripetibilità: un warning isolato di ieri è quasi sempre rumore; un errore che compare sistematicamente ogni volta che si apre una determinata applicazione è un segnale affidabile. Le evidenze diagnostiche più utili sono quelle correlate nel tempo e riproducibili, non gli eventi isolati.

SFC prima, DISM solo se SFC non bastaSystem File Checker (SFC) è uno strumento di riparazione mirato per i file di sistema protetti. Si usa quando una feature nativa di Windows si comporta in modo anomalo, un componente integrato non parte, oppure Event Viewer punta a file del sistema operativo mancanti o corrotti:

sfc /scannowSFC è utile perché verifica e sostituisce i file protetti senza richiedere una reinstallazione, ma dipende dal component store locale come sorgente di riparazione. Se quello store è danneggiato, SFC può segnalare corruzione trovata ma non riparabile del tutto. A quel punto il passo successivo è DISM, non ripetere SFC all’infinito sperando in un risultato diverso.

Deployment Image Servicing and Management (DISM) opera a livello di image e component store, uno strato sotto SFC. Va usato quando SFC non riesce a completare le riparazioni, quando l’installazione di Windows Update o di una feature fallisce ripetutamente, o quando il problema è a livello di servicing. Il comando di riparazione online più comune:

DISM /Online /Cleanup-Image /RestoreHealthIn ambienti enterprise, DISM può aver bisogno di una sorgente di riparazione affidabile — supporto di installazione, un’immagine montata, o una posizione di contenuto gestita — soprattutto quando gli endpoint non possono scaricare i contenuti di riparazione da Windows Update. Dopo che DISM completa con successo, conviene rilanciare SFC, così i file protetti possono essere riparati da un component store ormai sano.

Windows Update: capire in quale fase fallisce prima di resettare tuttoIl troubleshooting di Windows Update deve partire dall’identificazione della fase fallita. Un fallimento nello scan suggerisce problemi di policy, rete, proxy o sorgente di aggiornamento. Un fallimento nel download indica problemi di connettività, disponibilità dei contenuti o cache. Un fallimento nell’installazione punta spesso allo servicing stack, al component store, allo spazio su disco, a un riavvio pendente o a un driver in conflitto.

Sulle versioni moderne di Windows, Windows Update si basa su dati Event Tracing for Windows (ETW) piuttosto che scrivere un semplice log testuale in continuo. Per generare un log leggibile quando serve un dettaglio più approfondito lato client, si usa PowerShell:

Get-WindowsUpdateLogVale anche controllare Event Viewer nei log operativi del client di Windows Update e il Setup log per gli eventi di installazione. Se lo stesso pacchetto KB fallisce ripetutamente, conviene verificare se l’aggiornamento è applicabile, se esiste un aggiornamento che lo sostituisce, e da quale sorgente il dispositivo riceve gli update — Windows Update diretto, Microsoft Update, WSUS, oppure una piattaforma di gestione come Intune o Configuration Manager.

Un reset completo di Windows Update dovrebbe essere un passo tardivo, non il primo. Resettare i servizi e svuotare le cache può sbloccare client incastrati, ma distrugge anche evidenze utili. Meglio catturare prima il codice di errore, i log e la cronologia degli aggiornamenti.

“La rete non funziona” è quasi sempre DNS o configurazioneI sintomi di rete richiedono un punto di partenza diverso, perché gli utenti spesso descrivono come “la rete è giù” un problema che in realtà è DNS, routing, autenticazione, policy del firewall o un singolo endpoint applicativo che non risponde. È corretto partire dalla configurazione TCP/IP locale prima di testare i servizi remoti.

Un errore comune tra amministratori meno esperti è dare per scontato che “il ping non risponde” equivalga a “la rete è giù”. In ambienti enterprise questa assunzione è spesso sbagliata: molti sistemi sono configurati per ignorare le richieste ICMP pur continuando a erogare regolarmente il servizio previsto. Un firewall può bloccare ICMP, una policy di sicurezza può disabilitare le risposte, un servizio cloud può non rispondere mai al ping. La domanda giusta non è se un dispositivo risponde al ping, ma se il servizio richiesto è effettivamente raggiungibile: bisogna sempre testare ciò che l’utente sta effettivamente cercando di usare, con strumenti come ipconfig, nslookup e tracert mirati sul servizio specifico.

Tabella di riferimento rapido: sintomo → strumentoSintomoPartire daPerchéApp che va in crash o si chiude inaspettatamenteEvent Viewer, poi Reliability MonitorIdentifica moduli in fault, errori applicativi e pattern di modifiche recentiWindows Update fallisce ripetutamenteLog di Windows Update, Setup log, DISMSepara i fallimenti di scan, download, installazione e servicingFeature di Windows mancanti o instabiliSFC, poi DISM se SFC non riparaRipara i file di sistema protetti e il component store sottostanteUtenti non raggiungono risorse di reteipconfig, ping, nslookup, tracertValida configurazione locale, raggiungibilità, DNS e routing in ordineLe performance degradano improvvisamenteTask Manager, Resource Monitor, Event ViewerCorrela la pressione sulle risorse con servizi, driver ed erroriReliability Monitor merita una menzione a parte perché offre una vista a timeline di crash applicativi, fallimenti di Windows, installazioni di driver ed eventi di aggiornamento. È meno dettagliato di Event Viewer, ma resta eccellente per individuare rapidamente cosa è cambiato immediatamente prima che iniziasse un problema ricorrente.

Costruire il proprio toolkit di troubleshootingPer un professionista IT, l’abilità di troubleshooting più preziosa non è memorizzare comandi, ma sapere quale fonte di evidenza fidarsi per una determinata classe di problema. Event Viewer dice cosa Windows ha registrato; Reliability Monitor mostra quando i problemi sono iniziati. Una checklist pratica da seguire durante un incidente:

Registrare sintomi esatti, orario, dispositivo, utente e modifiche recenti.

Controllare i log più rilevanti prima di applicare riparazioni ad ampio raggio.

Eseguire i comandi di riparazione da un terminale elevato e catturarne l’output.

Cambiare una variabile alla volta, per sapere con certezza cosa ha risolto il problema.

Verificare dal punto di vista dell’utente, non solo dalla console amministrativa.

Questa disciplina previene due errori tipici: eseguire riparazioni distruttive troppo presto, e dichiarare vittoria prima di aver verificato il flusso di lavoro reale. Se un utente non riesce ad aprire una condivisione di rete, un ping riuscito non è il traguardo: il traguardo è l’utente che apre la condivisione, accede ai file attesi e conferma che il problema non si ripresenta.

ConclusioneLa differenza tra una sessione di troubleshooting produttiva e una frustrante raramente sta nella conoscenza di comandi avanzati. Sta nel partire dal sintomo invece che dal comando, chiedersi quale evidenza confermerebbe o smentirebbe la causa più probabile, e solo a quel punto scegliere lo strumento che fornisce quell’evidenza nel modo più veloce. È questa disciplina che trasforma una collezione di utility in un vero toolkit diagnostico.

Fonte: Critical Windows Troubleshooting Tools: Stop Wasting Time on the Wrong Fixes, Petri IT Knowledgebase

Intune, Win32 app e detection rule: quale file version guarda davvero https://gioxx.org/2026/07/17/intune-detection-rule-win32app

#intune #lavoro #microsoft #microsoftwindows #powershell