Ti è mai capitato di configurare una detection rule su una Win32 app in Intune, scegliere “File” come metodo di rilevamento, mettere la versione che ti mostra Windows nelle proprietà del file e ritrovarti la stessa app che viene reinstallata in loop a ogni check-in? Errore abbastanza comune, ammetto che agli inizi ci ho perso pure io quel classico “quarto d’ora di troppo” prima di capire che la colpa non era mia (o meglio, non del tutto): il numero di versione che ti mostra la GUI di Windows non è sempre quello che Intune legge davvero.

Generalmente ce ne si accorge quando si tenta di fare del debug e si va ad aprire IntuneManagementExtension.log: l’installazione va a buon fine, il servizio fa partire la detection rule, non trova match e marca l’applicazione come “non installata”. Risultato: al successivo ciclo l’app viene reinstallata. E così via, all’infinito, finché non capisci dove sta l’inghippo.

L’esempio che ho trovato spiegato sul blog di Jon Conway riguarda la distribuzione di CMTrace.exe (sì, la vecchia gloria del mondo Configuration Manager, che tantissimi ancora rilasciano via Intune per avere un lettore di log decente sui client, io me la cavo usando questa versione web che avevo portato a bordo di Nebula.KB, giusto per far prima).

Se apri le proprietà del file da Esplora risorse, la scheda “Dettagli” ti dice 5.0.9068.1000. Sembra una versione a modo, la copi, la incolli nella detection rule di Intune, salvi tutto e ti aspetti di aver chiuso la pratica. Peccato che Intune, sotto il cofano, non guardi quella stringa: legge la proprietà FileVersion dei metadati del binario, che nel caso specifico vale 5.00.9068.1000. Uno zero in più tra il primo e il secondo blocco, ma per Intune quello zero fa la differenza tra “già installata” e “reinstalla”.

Come verificare la FileVersion “reale” con PowerShell

La regola generale è semplice: non fidarti mai di quello che vedi nella UI di Windows quando devi scrivere una detection rule basata su file version.
Chiedilo a PowerShell, che va a leggere gli stessi metadati che Intune userà per fare il confronto.

Due comandi equivalenti, scegli quello che ti piace di più:

[System.Diagnostics.FileVersionInfo]::GetVersionInfo("C:\Cartella\Eseguibile.exe").FileVersion
(Get-Item -Path "C:\Cartella\Eseguibile.exe").VersionInfo.FileVersion

Entrambi tirano fuori la stringa esatta che poi devi incollare nella configurazione della detection rule su Intune. Nel caso di CMTrace.exe restituiscono 5.00.9068.1000, non 5.0.9068.1000. Puoi lanciarli direttamente su una macchina di test dove hai già installato l’applicazione con il pacchetto che poi distribuirai via Intune (importantissimo: usa lo stesso installer che caricherai su Intune, non uno “simile”, perché a volte le build differiscono anche solo per il metadato interno).

Se vuoi, ho incluso all’interno del modulo IntuneWinAppUtilGUI un comando rapido per fare la medesima cosa (almeno non devi ricordarti per forza uno dei due comandi poco sopra):

Get-IntuneFileVersion percorso-del-tuo-file

Ti basterà semplicemente aggiornare la tua copia del modulo alla versione 1.0.9. Se non sai neanche di cosa sto parlando, ti consiglio di dare una sbirciata all’indirizzo kb.gioxx.org/Projects/M365/intunewinapputilgui. Trovi un minimo di spiegazione rapida sulla nuova funzione anche nel file README del progetto.

Perché succede

Il problema non è di Intune, è di come le applicazioni vengono compilate.
Un binario Windows può avere più numeri di versione nei propri metadati (FileVersion, ProductVersion, versione dell’assembly .NET, e così via), e ogni sviluppatore ci mette dentro quello che gli pare, non sempre in modo coerente. La UI di Windows a volte usa un piccolo “trucchetto” di visualizzazione (ad esempio togliendo lo zero di padding), mentre Intune legge il valore grezzo. Da qui il disallineamento.

Il consiglio pratico è: ogni volta che stai per usare “File version” come detection method, fermati due secondi e prendi la stringa da PowerShell. Ti risparmi il loop di reinstallazione e la sessione di debug del giorno dopo su IntuneManagementExtension.log.

In conclusione

Detection rule basate su file version sono comode, ma è troppo facile inciampare sul metadato sbagliato. Quando prepari una nuova Win32 app in Intune, apri PowerShell sulla macchina di test, esegui uno dei due comandi qui sopra e usa quella stringa nella detection rule. Zero fantasie, zero interpretazioni della UI, un giro in meno di reinstallazioni inutili sui client dei tuoi utenti.

Io spesso evito di fare quel tipo di controllo e carico uno script personalizzato che ho costruito per andare a sbirciare direttamente all’interno delle Program Files, ne parlo al plurale perché così posso essere in grado di controllare sia C:\Program Files che C:\Program Files (x86) sulle macchine a 64 bit.

Ho pensato di farti cosa gradita caricando lo script sempre all’interno del repo di IntuneWinAppUtil GUI, lo trovi qui: github.com/gioxx/IntuneWinAppUtilGUI/blob/main/Scripts/Intune_CheckAppInstallation.ps1.
Sbircia in testata allo script, troverai sufficienti commenti per capire come funziona, in alternativa anche nel README del progetto. Se hai ancora dubbi in merito puoi sempre usare l’area commenti che si trova qui di seguito.

#KeepItSimple

Credits: jonconwayuk.wordpress.com/2025/05/31/understanding-the-correct-file-version-used-for-intune-win32-app-detection-method