• Cloud, Guide, Microsoft 365
• 21 Gennaio 2026

Chi gestisce o utilizza Microsoft Intune lo sa bene, le Win32 apps sono uno strumento utilissimo. Il problema emerge quando l’installazione non è il classico MSI lineare e serve un minimo di logica (prerequisiti, controlli su versioni già presenti, cleanup, logging, ecc.). Fino ad oggi, quando questa logica viveva in PowerShell, nella pratica si finiva spesso per includere lo script nel contenuto del pacchetto e poi richiamare powershell.exe nell’Install command. Una soluzione funzionante ma delicata, tra quoting, considerazioni 32-bit/64-bit e la manutenzione che non era sempre immediata. Infatti, se serviva correggere anche solo una piccola parte dello script, spesso questo si traduceva in un nuovo ciclo di packaging e upload del file .intunewin.

La novità è che finalmente Intune adesso supporta nativamente PowerShell script come Installer type per le Win32 app, cioè è possibile caricare uno script PowerShell che sostituisce la classica install command line e viene eseguito nello stesso contesto dell’installazione.
In questo articolo vedremo nel dettaglio:

• Com’era lo scenario prima
  
• Cosa cambia adesso
  
• Requisiti per l’utilizzo
  
• Come questa feature cambia l’esperienza admin
  
• Mini demo
  
• Conclusioni
  

Com’era lo scenario prima

Fino a questa novità, se si voleva un’installazione un po’ più “intelligente” (check prerequisiti, fix, post-config, logging, remediation light), avevi sostanzialmente queste strade:

• richiamare PowerShell dall’install command, tipicamente con qualcosa come powershell.exe -ExecutionPolicy Bypass -File .\install.ps1
• includere lo script nel contenuto del pacchetto .intunewin perché lo script doveva essere disponibile localmente nel contesto di esecuzione
• gestire il tema 32-bit vs 64-bit che in Intune non è un dettaglio (l’Intune Management Extension gira in contesto 32-bit e, di conseguenza, anche l’esecuzione di PowerShell tende a partire in 32-bit se non si forza diversamente)

Questo approccio funzionava, ma la manutenzione diventava più macchinosa del dovuto, e quando era necessario eseguire in PowerShell 64-bit su sistemi x64/ARM64, tipicamente si usava Sysnative per bypassare la redirection dalla 32-bit, con qualcosa del genere all’interno dello script:

Infine, c’era un aspetto poco pratico. Se lo script era incluso nel pacchetto .intunewin, anche una modifica minima alla logica (letteralmente anche una virgola) spesso comportava un nuovo ciclo di packaging e upload. Questo è uno dei motivi per cui la community ha spinto tanto sul concetto di separare contenuto e logica per ridurre questo attrito operativo.

Cosa cambia adesso

Dal 12 gennaio 2026 la situazione è finalmente cambiata. Infatti, come riportato anche alla pagina What’s New – 2511: Feature added and feature removed è stato aggiunto anche il supporto nativo per gli installer via PowerShell
script per le Win32 apps.

Figura 1: PowerShell script installer per Win32 apps

Quando andrete a creare un’app Win32, sarà possibile caricare uno script di PowerShell da utilizzare come programma di installazione anziché specificare una riga di comando. Intune impacchetta lo script insieme al contenuto dell’app e lo esegue nello stesso contesto del programma di installazione dell’app stessa (System o User), consentendo flussi di lavoro e di configurazione più completi, come controlli dei prerequisiti, modifiche alla configurazione dell’app e azioni post-installazione. I risultati dell’installazione vengono visualizzati, come sempre, nell’interfaccia di amministrazione di Intune (tab Monitor o Install Status dell’app) in base all’return code dello script. Finalmente PowerShell diventa un installer type ufficiale.

Nota: Inizialmente Microsoft ha introdotto questa feature nella service release 2511 del 10 novembre 2025, ma pare che sia stata subito ritirata e reinserita il 12 gennaio 2026. Infatti, la pagina Weekly Service Release Changelog for 2511 ci mostrerà questo

Figura 2: Weekly SR changelog for 2511 – Week of November 10, 2025

Se invece facessimo una breve ricerca alla pagina What’s new in Microsoft Intune – Microsoft Intune | Microsoft Learn non troveremo traccia di questa feature nella sezione Week of November 10, 2025; la troveremo invece nella sezione Week of January 12, 2026.

Figura 3: Annuncio feature Microsoft Learn – Week of January 12, 2026

Requisiti principali per il supporto PowerShell script come Installer type

• Dimensione massima script: 50 KB
• L’esecuzione dovrà essere silent (niente UI, niente prompt)
• Return code = success/error per il reporting
• Stesso contesto dell’app (System/User)

Quando è utile utilizzare PowerShell come installer type

Ci sono diversi scenari in cui questa feature può essere estremamente utile, ad esempio quando:

• L’app richiede la convalida dei prerequisiti prima dell’installazione
• È necessario eseguire modifiche o configurazioni extra insieme all’installazione dell’app
• Il processo di installazione richiede logica extra
• Sono necessarie azioni post installazione (es. modifiche al registro di sistema, log strutturato, finalizzazione installazione ecc.)

Importante: se nel tenant hai abilitato il Multi-Admin Approval (MAA), non potrete caricare lo script durante la creazione dell’app, ma dovrete prima creare l’app e poi aggiungere/modificare lo script. Inoltre, alcune proprietà (es. enforceSignatureCheck, runAs32Bit) oggi risultano modificabili senza richiesta MAA, ma Microsoft segnala che questo comportamento cambierà nelle prossime release.

Come questa feature cambia l’esperienza admin

Cosa cambia davvero per gli amministratori che usano Intune per distribuire applicazioni Win32? Più di quanto sembri. Il punto non è solo poter usare PowerShell (perché PowerShell lo abbiamo sempre richiamato anche prima), la differenza è che oggi diventa una modalità supportata nativamente, quindi più pulita e più semplice da gestire nel tempo. Dal punto di vista operativo, uno script PowerShell usato come installer è molto più facile da trattare come codice: si versiona meglio, si commenta e si testa con più ordine, e soprattutto è più semplice da far prendere in carico a chi subentrerà dopo di voi nella gestione dell’ambiente.

C’è anche un altro vantaggio molto più pratico, che secondo me è quello che fa sul serio la differenza. Se dovesse capitare di correggere la logica di installazione di una Win32 app, potreste non dover rigenerare e ricaricare l’intero pacchetto e limitarvi a modificare lo script PowerShell, a condizione che non cambi il contenuto nel file .intunewin; in quel caso ovviamente il contenuto andrà aggiornato.

Mini demo: come creare una Win32 app con PowerShell installer

Vediamo adesso nel pratico come creare una app Win32 con il supporto PowerShell come installer type.

Per questa demo distribuiremo Microsoft Edge WebView2 Runtime, ma con un approccio volutamente “furbo” per evidenziare il valore della nuova funzionalità: il contenuto del pacchetto .intunewin resterà invariato nel tempo, mentre tutta la logica di installazione (e l’eventuale manutenzione) sarà demandata allo script PowerShell configurato come installer.

Invece di impacchettare un installer classico che cambiare versione ed è soggetto ad aggiornamenti continui (e quindi costringerci a rigenerare e ricaricare il pacchetto ad ogni nuova release), useremo un payload statico e uno script che scarica ed esegue l’Evergreen Bootstrapper di WebView2. All’interno dello script gestiremo anche aspetti tipici di un deployment enterprise, come logging, controlli preliminari e retry in caso di problemi temporanei di rete.

In questo modo, se durante il pilot o nel tempo emergono nuove esigenze (es. migliorare i log, aggiungere un controllo di prerequisiti, ecc), per mantenere l’app sarà sufficiente
aggiornare lo script in Intune senza dover ricreare e ricaricare il file .intunewin. È esattamente il tipo di scenario in cui questa feature fa davvero la differenza nella vita quotidiana di un admin.

I prerequisiti per questo scenario di esempio sono:

• app Win32 già pacchettizzata in .intunewin con il Win32 Content Prep Tool
• script PowerShell (es. install.ps1) < 50 Kb

Il file .intunewin conterrà un file di testo (anche vuoto) e potrete chiamarlo come preferite (es. WebView2Bootstrapper.txt); quando utilizzeremo il Win32 Content Prep Tool sceglieremo proprio questo file fittizio come setup file

Figura 4: Creazione file .intunewin tramite Win32 Content Prep Tool

Una volta completata l’operazione, nella nostra output folder ritroveremo, oltre al file di testo fittizio iniziale, anche il file .intunewin appena creato

Figura 5: Output folder con file di testo fittizio + file .intunewin

Passiamo adesso al Microsoft Intune Admin Center e vediamo step-by-step come implementare questa novità. Il processo sarà lo stesso per la creazione di una qualunque Win32 app, quindi navighiamo in Apps > Windows

Figura 6: Creazione Win32 app – Parte 1

A questo punto fate click su Create e, all’apparizione della finestra sulla destra dello schermo selezionare Windows app (Win32) come App type; infine, fare click su Select.

Figura 7: Creazione Win32 app – Parte 2

Nella pagina App information procediamo a selezionare e caricare il nostro file .intunewin facendo click su Select app package file e caricando il nostro file tramite la finestra di explorer che si aprirà; successivamente procedete con Ok.

Figura 8: Creazione Win32 app – Parte 3

A questo punto, configuriamo le informazioni della nostra app. Per lo scopo di questa demo configurerò solamente alcuni campi. Quando avrete fatto, fare click su Next.

Figura 9: Creazione Win32 app – Parte 4

Eccoci adesso al punto focale di questa demo; infatti adesso andremo a configurare nella pagina Program la nostra Win32 app per essere eseguita direttamente con uno script PowerShell.
Attualmente il design di Intune ci mostrerà il campo Installer type
con solamente la voce Command line non modificabile e non dandoci ancora la possibilità di selezionare altro (probabilmente sistemeranno nelle prossime release).

Figura 10: Creazione Win32 app – Parte 5

Per “sbloccare” questa situazione è sufficiente digitare qualcosa nel campo sottostante Install command (anche una sola lettera è sufficiente) noterete che la lista del campo Installer type non sarà più in grigio.

Figura 11: Creazione Win32 app – Parte 6

A questo punto possiamo selezionare PowerShell script dalla lista e alla voce Install script facciamo click su Select custom script. Alla destra dello schermo comparirà la sezione per caricare lo script e completare i dettagli richiesti. Settiamo su No il toggle button “Enforce script signature check” e anche “Run script as 32-bit process on 64-bit clients“. Quando avrete terminato, fare click su Ok.

Figura 12: Creazione Win32 app – Parte 7

A questo punto dobbiamo configurare anche le voci dedicate alle informazioni sulla disinstallazione della nostra Win32 app. Come già visto in precedenza per le voci dedicate all’installazione, anche per la disinstallazione vedremo il campo Uninstaller type con solamente la voce Command line non modificabile e non dandoci ancora la possibilità di selezionare altro.

Figura 13: Creazione Win32 app – Parte 8

Analogamente a quanto fatto prima per “sbloccare” la situazione, procediamo a scrivere qualsiasi cosa nel campo Uninstall command e la lista del campo Uninstaller type non sarà più in grigio. Se vorrete, adesso potrete selezionare la voce PowerShell script anche per eseguire la disinstallazione del software.

Figura 14: Creazione Win32 app – Parte 9

Per lo scopo di questa demo, proseguiremo comunque via command line. Configurate le opzioni Allow available uninstall, Install behavior e Device restart behavior secondo necessità. Nel caso di questa demo metteremo rispettivamente Yes, System e No specific action. Inoltre, se nello script vi siete basati su return code diversi da quelli di default indicati nella pagina, potrete aggiungerli. Nel nostro caso quelli di default sono sufficienti. Quando avrete terminato, fate click su Next.

Figura 15: Creazione Win32 app – Parte 10

La parte in riferimento alla nuova feature è terminata, da adesso possiamo proseguire con i prossimi step come di consueto per la creazione di una app Win32. Quindi nella pagina Requirements configureremo i requisiti minimi che i dispositivi dovranno avere per avviare l’installazione dell’app (es. solo sistemi x64 e OS minimo Windows 11 23H2), poi proseguire facendo click su Next.

Figura 16: Creazione Win32 app – Parte 11

Nella pagina Detection rules per questo esempio configureremo una detection rule basata sul registry di sistema. Quando avremo terminato, fare click su Next.

Figura 17: Creazione Win32 app – Parte 12

Nella pagina Dependencies possiamo configurare delle applicazioni che verranno installate prima di quella principale. In questo caso non ne avremo bisogno, dunque fare click su Next.

Figura 18: Creazione Win32 app – Parte 13

Anche nella pagina Supersedence, anche in questo caso, non dovremo fare nulla. Procedere facendo click su Next.

Figura 19: Creazione Win32 app – Parte 14

A questo punto, nella pagina Assignments, possiamo assegnare la nostra Win32 app al gruppo desiderato. Nella nostra demo renderemo l’applicazione available, quindi fare click su Add groups nella sezione Available for enrolled devices, cercare il gruppo desiderato, selezionarlo con l’apposita checkbox ed infine fare click su Select.

Figura 20: Creazione Win32 app – Parte 15

Sempre nella pagina di Assignments verifichiamo che il gruppo selezionato sia stato aggiunto alla lista dei gruppi per il deploy available. Per questa demo non abbiamo bisogno di aggiungere filtri, modificare i metodi di notifica e la availability del deploy, quindi continuare cliccando nuovamente su Next.

Figura 21: Creazione Win32 app – Parte 16

Nella pagina Review + create controlliamo nuovamente la correttezza di tutte le informazioni configurate per la nostra Win32 app; se è tutto ok, procediamo alla creazione dell’app facendo click su Create.

Figura 22: Creazione Win32 app – Parte 17

Dopo poco tempo, Intune avrà creato la nostra Win32 app con successo.

Figura 23: Creazione Win32 app – Parte 18

Spostiamoci adesso su un dispositivo facente parte del gruppo a cui abbiamo distribuito la nostra app e vediamo che cosa succede. Per questa demo, una volta avviata l’installazione, lo script caricato come Installer type della nostra Win32 app eseguirà questi step:

• Creazione del percorso %Programdata%\ICTPower\Intune\MicrosoftEdgeWebview2
• Scrittura dei log al percorso %Programdata%\ICTPower\Intune\MicrosoftEdgeWebview2\Logs dentro al file WebView2-install.log
• Verifica preliminare della presenza del software
• Download dell’eseguibile MicrosoftEdgeWebview2Setup.exe nella cartella %Programdata%\ICTPower\Intune\MicrosoftEdgeWebview2 con gestione dei timeout
• Installazione dell’eseguibile MicrosoftEdgeWebview2Setup.exe
• Chiusura logging ed exit code finale

Come prima cosa, apriamo il Company Portal e, appena troviamo la nostra nuova app, procediamo ad installarla
facendo click su Installa.

Figura 24: Overview installazione app da Company portal

L’IME avvierà il download e l’installazione della nostra app.

Figura 25: Download ed installazione applicazione da Company Portal

Dopo poco tempo, l’applicazione risulterà installata con successo.

Figura 26: Overview applicazione installata con successo

A questo punto possiamo aprire il nostro file di log che, come citato, per questa demo è stato configurato al percorso %Programdata%\ICTPower\Intune\MicrosoftEdgeWebview2\Logs\WebView2-install.log

Figura 27: File di log contenente tutto il processo loggato tramite l’installer via script PowerShell

Come possiamo notare dalla Figura 27, nel file di log è visibile l’intero flusso gestito dallo script (download del bootstrapper, verifica, installazione e detection finale), con la tracciatura puntuale di ogni passaggio. Questo approccio semplifica anche la manutenzione, infatti se in futuro fosse necessario intervenire sulla logica (ad esempio rendere i log meno verbosi, gestire un edge case, aggiungere controlli o aggiornare l’URL di download), sarà sufficiente caricare in Intune una nuova versione dello script PowerShell configurato come Installer type, senza dover ricreare e ricaricare il file .intunewin. In questo scenario, infatti, il pacchetto resta invariato e tutta la logica applicativa è demandata allo script.

Conclusioni

La possibilità di eseguire molto più di una semplice installazione al momento dell’esecuzione apre di fatto la strada a tutto ciò che è possibile programmare in uno script: controlli di prerequisiti, gestione di versioni preesistenti, installazioni concatenate, configurazioni post-install, logging avanzato e validazioni finali. Il valore della novità, però, non è PowerShell in sé (che abbiamo sempre usato), ma il fatto che oggi diventa un’opzione supportata nativamente per le Win32 app. Questo si traduce in un processo più pulito, meno fragile e più semplice da mantenere, soprattutto quando l’installazione richiede logica e non una singola command line.

In scenari come quello visto nella demo, dove il contenuto del pacchetto può rimanere statico, il vantaggio è ancora più evidente poiché eventuali correzioni o miglioramenti si applicano aggiornando solo lo script configurato come Installer type. Quando la logica vive nello script, la manutenzione smette di essere un repack e torna a essere un semplice update.