• Cloud, Guide, Microsoft 365, Sistemi Operativi
• 29 Settembre 2026

Negli ambienti gestiti con Microsoft Intune, la distribuzione dei driver e stampanti può diventare spesso un punto abbastanza delicato quando i dispositivi Windows sono Microsoft Entra joined e la configurazione non viene più gestita tramite le Group Policy di dominio. Esistono tecnologie come Universal Print, che offre un modello cloud dedicato, con provisioning tramite Settings Catalog, ma non è sempre la scelta più adatta: possono incidere licenze, compatibilità dei dispositivi, architettura di rete, requisiti di stampa locali o semplicemente una migrazione non ancora pianificata. Il provisioning di Universal Print tramite Intune richiede infatti una configurazione dedicata e account con accesso al servizio e alle stampanti condivise.

In questi scenari è possibile distribuire driver e stampanti TCP/IP usando una Win32 app di Intune che contiene i file del driver e script PowerShell. L’app viene eseguita in contesto System, copia il driver nel Driver Store, registra il driver di stampa, crea la porta TCP/IP e aggiunge la coda locale sul dispositivo. In questa guida vedremo una procedura pulita, strutturata e adattata a un modello controllabile per ambienti enterprise.

L’obiettivo non è sostituire ogni soluzione di print management, ma l’approccio che descriverò è indicato quando serve distribuire una o più stampanti di rete raggiungibili direttamente dai client, senza usare Universal Print e senza delegare al client il download del driver da un print server. Nei contesti con print server, pull printing, badge release, regole complesse per sede o code utente dinamiche, suggerisco di valutare con attenzione se questo modello sia sufficiente o se sia preferibile usare una soluzione di stampa dedicata.

Disclaimer: la procedura è stata validata in laboratorio con una EPSON WF-2510 Series. Nomi delle code, indirizzi, gruppi e parametri devono essere adattati all’ambiente di destinazione. Prima del rollout è necessario verificare compatibilità e comportamento del driver sulla versione di Windows utilizzata.

Scenario di riferimento

Vediamo subito qual è lo scenario di questo articolo: la guida prende come riferimento una stampante di rete raggiungibile tramite indirizzo IP o DNS, installata sui dispositivi Windows come coda locale TCP/IP. Il driver viene distribuito insieme alla Win32 app, evitando che Windows debba scaricarlo da un print server o che l’utente debba installarlo manualmente. Nel nostro esempio useremo questi valori:

Tabella 1: Parametri utilizzati nello scenario di esempio per la distribuzione della stampante

Chiaramente i valori indicati in tabella devono essere sostituiti con quelli reali dell’ambiente che gestite, inoltre fate attenzione al nome del driver: è particolarmente importante che corrisponda al nome con cui il driver viene registrato in Windows, non al nome commerciale della stampante e non necessariamente al nome del file INF.

Perché usare una Win32 app di Intune?

Le Win32 app sono il metodo più adatto per questo scenario perché consentono di distribuire una cartella contenente più file, eseguire comandi di installazione e disinstallazione, definire regole di rilevamento e monitorare l’esito dal portale Intune. Le app Win32 vengono elaborate dalla Microsoft Intune Management Extension, che viene installata automaticamente quando un’app Win32 o uno script PowerShell viene assegnato a un utente o a un dispositivo gestito.

Il pacchetto viene creato con Microsoft Win32 Content Prep Tool, che comprime la cartella sorgente in un file con estensione .intunewin. La cartella sorgente deve contenere tutti i file richiamati durante l’installazione, inclusi script, INF, CAT, CAB, DLL e altri file del driver. Lo strumento supporta i parametri -c, -s, -o e -q, utili per indicare cartella sorgente, file di setup, cartella di output e modalità non interattiva.

Tabella 2: Componenti utilizzati per distribuire driver e stampante tramite Win32 app

Quando scegliere questo approccio

Questo modello funziona bene quando le stampanti sono raggiungibili direttamente dai client e l’azienda vuole mantenere il controllo del driver installato sul dispositivo. Inoltre, è utile anche nei casi in cui gli utenti non devono avere privilegi locali e l’installazione deve avvenire in modo automatico o tramite Company Portal. Una soluzione come Universal Print rimane una soluzione cloud specifica per la stampa Microsoft 365 e dispone di un percorso di provisioning dedicato in Intune, ma questa guida affronta volutamente lo scenario senza Universal Print. Le aziende che usano Universal Print devono considerare anche licensing, condivisione delle stampanti e supporto dei client Windows previsti dalla documentazione del servizio. Se dovesse interessarvi questo servizio, trovate una guida pubblicata su ICT Power alla pagina Microsoft 365 – Gestione delle stampanti in cloud con Universal Print.

Tabella 3: Scenari di utilizzo dell’approccio Win32 app per la distribuzione delle stampanti

Prerequisiti

Prima di creare il pacchetto separiamo per bene i prerequisiti tecnici da quelli operativi perché il rischio maggiore, in questi scenari, non è la creazione della Win32 app, ma la distribuzione di un driver incompleto, il riferimento a un nome driver errato o una detection rule troppo debole.

• dal punto di vista Intune servono dispositivi Windows gestiti, una licenza Intune valida per gli utenti o i dispositivi interessati, un gruppo pilota e autorizzazioni amministrative sufficienti per creare e assegnare app. Per la gestione ordinaria è preferibile usare ruoli Intune con il principio del privilegio minimo, come ruoli built-in o ruoli custom, evitando l’uso continuativo di Global Administrator o Intune Administrator per attività di routine
• dal punto di vista Windows servono un driver compatibile con la versione e l’architettura del sistema operativo, un pacchetto completo con INF, CAT e tutti i file referenziati dal driver, una stampante raggiungibile in rete e un nome porta stabile. Se si usa l’indirizzo IP, l’indirizzo deve essere statico o riservato a livello DHCP. Se si usa un nome DNS, la risoluzione deve funzionare in modo affidabile per tutti i dispositivi assegnati

Tabella 4: Prerequisiti tecnici e operativi per il deployment della stampante tramite Intune

Attenzione: Windows 10 22H2 può ancora essere gestito da Intune, ma è fuori supporto generale dal 14 ottobre 2025 e la funzionalità non è garantita; verificare separatamente eventuali scenari LTSC o ESU.

Come funziona l’installazione del driver

Windows non installa un driver partendo da un file INF isolato se mancano i file dichiarati nel pacchetto. Il Driver Store contiene i pacchetti driver validati e tutti i file richiamati dall’INF; se il file INF referenzia un componente non presente, il pacchetto non viene copiato nello store. Lo staging del driver e l’installazione del dispositivo sono operazioni distinte, quindi il driver deve prima essere reso disponibile nel Driver Store e poi registrato come driver di stampa.

Il comando PnPUtil consente di aggiungere pacchetti driver al Driver Store con la sintassi pnputil /add-driver <filename.inf>. Lo strumento è incluso in Windows e il parametro /add-driver aggiunge il pacchetto nello store; il parametro /install serve invece per installare o aggiornare il driver su dispositivi corrispondenti, ma per la coda di stampa TCP/IP di questa guida useremo lo staging del pacchetto e poi i cmdlet del modulo PrintManagement.

Dopo lo staging del driver, la procedura usa tre cmdlet PowerShell:

Tabella 5: Cmdlet PowerShell utilizzati per registrare il driver, creare la porta e aggiungere la stampante

Add-PrinterDriver installa un driver di stampa sul computer specificato e richiede credenziali amministrative, mentre Add-Printer consente di aggiungere una stampante locale o una connessione a stampante di rete. Add-PrinterPort supporta la creazione di porte TCP/IP specificando nome porta e indirizzo della stampante.

Preparare la cartella sorgente

Fatte le dovute premesse, vediamo come predisporre il tutto. Il primo passaggio consiste nello scaricare il driver dal sito del produttore ed estrarre il pacchetto in una cartella di lavoro. In molti casi il file scaricato contiene un installer grafico (il classico setup.exe), ma per una distribuzione tramite Intune è preferibile individuare i file effettivi del driver e installarli in modo silenzioso con PowerShell; in questo caso estraiamo i driver dal setup in un percorso comodo per lavorare.

Di seguito vi lascio l’esempio di struttura che utilizzerò per questa guida: la cartella Source conterrà lo script di installazione, lo script di disinstallazione e la sottocartella Drivers con tutti i file del driver. La cartella Output, utilizzata per salvare il file .intunewin, va invece mantenuta fuori da Source, come mostrato nella Figura 1 seguente. Gli script di installazione, disinstallazione e di detection potete trovarli nei capitoli successivi.

Figura 1: Struttura delle cartelle utilizzate per preparare il pacchetto Win32 della stampante

Il file INF va aperto e controllato prima del packaging, in particolare bisogna verificare quali file vengono richiamati, quale file CAT è associato al pacchetto e quale nome driver sarà disponibile in Windows dopo l’installazione.

Figura 2: Verifica del file INF per identificare le informazioni del driver prima della distribuzione con Intune

In alternativa, su una macchina di laboratorio, si può installare manualmente il driver e poi leggere il nome esatto con PowerShell:

Get-PrinterDriver | Sort-Object Name | Select-Object Name, Manufacturer, DriverVersion

Figura 3: Identificazione del nome esatto del driver EPSON WF-2510 Series tramite PowerShell

Se il nome del driver non corrisponde, Add-PrinterDriver può fallire anche quando pnputil.exe ha aggiunto correttamente il pacchetto al Driver Store, e questo è uno degli errori più frequenti nelle distribuzioni di stampanti via Intune.

Attenzione: non rinominare, spostare o rimuovere file dal pacchetto driver dopo aver identificato l’INF. Se il file INF fa riferimento a un file non presente nella cartella distribuita, lo staging nel Driver Store può fallire o produrre un’installazione incompleta.

Figura 4: Contenuto della cartella Source del pacchetto Win32 della stampante

Figura 5: Struttura della cartella Drivers per il pacchetto Win32 della stampante

Script di installazione

Per questo scenario ho pubblicato sul mio repository GitHub tre script PowerShell per gestire l’installazione, la disinstallazione e il rilevamento delle stampanti tramite Microsoft Intune. Gli script sono progettati per essere riutilizzati con stampanti di produttori e modelli differenti, personalizzando i parametri relativi al driver, all’indirizzo IP e alla coda di stampa. Nel file README.md della cartella PrinterDrivers trovate gli script, i prerequisiti, le istruzioni per adattarli al vostro ambiente e i passaggi necessari per creare e distribuire il pacchetto Win32 con Intune.

Per semplicità vi riporto qui una versione ridimensionata per l’articolo: lo script seguente installa una stampante TCP/IP locale. Prima verifica il file INF, aggiunge il driver al Driver Store con pnputil.exe, registra il driver di stampa, crea la porta TCP/IP se non esiste e aggiunge la stampante. Se trova una stampante con lo stesso nome ma con driver o porta diversi, la rimuove e la ricrea con i valori attesi. Il log viene scritto in C:\ProgramData\EndpointNinja\PrinterDeployment, così può essere letto anche quando l’installazione viene eseguita in contesto System da Intune.

Attenzione: come vedremo più avanti, per evitare problemi di reindirizzamento tra PowerShell a 32 bit e 64 bit, il comando di installazione della Win32 app userà SysNative, così lo script verrà eseguito nella PowerShell a 64 bit anche quando viene lanciato da un processo a 32 bit.

Attenzione: se esiste già una stampante con lo stesso nome ma con driver o porta differenti, lo script la rimuove e la ricrea. Prima del rollout verificare l’impatto su eventuali processi di stampa in coda e configurazioni specifiche della stampante.

Script di disinstallazione

Anche per la disinstallazione trovate i riferimenti su GitHub, mentre qui vi lascio una versione semplificata per lo scenario. Lo script di rimozione elimina la stampante e, se richiesto, anche la porta TCP/IP quando non è più usata da altre stampanti. Il driver viene lasciato installato per impostazione predefinita, perché potrebbe essere condiviso da altre code di stampa o da stampanti dello stesso modello.

Attenzione: lo script non rimuove automaticamente il driver dopo la disinstallazione della coda, perché lo stesso driver potrebbe essere utilizzato da altre stampanti. La rimozione del driver va gestita dopo aver verificato che non sia più in uso.

Creare il pacchetto .intunewin

Dopo aver preparato la cartella sorgente, si può creare il pacchetto con IntuneWinAppUtil.exe. Il parametro -c indica la cartella sorgente, -s il file di setup di riferimento, -o la cartella di output e -q esegue il comando in modalità non interattiva. Tutti i file e le sottocartelle presenti nella cartella sorgente vengono compressi nel pacchetto .intunewin.

Esempio:

Il file generato sarà caricato nel portale Intune come Windows app (Win32).

Figura 6: Creazione del pacchetto .intunewin con Microsoft Win32 Content Prep Tool

Figura 7: Pacchetto .intunewin generato per la distribuzione del driver e della stampante tramite Intune

Creare la Win32 app in Microsoft Intune

Adesso che abbiamo tutti gli elementi a disposizione, possiamo creare la nuostra app in. Apriamo il Microsoft Intune admin center e nel portale apriamo Apps > All Apps e creiamo una nuova app tramite l’apposito pulsante Create. Nel pannello Select app type selezioniamo la piattaforma Windows e
Windows app (Win32) come tipo di app e proseguire con il pulsante Select.

Figura 8: Selezione di Windows app (Win32) durante la creazione dell’applicazione in Intune

Nella sezione App information caricare il file .intunewin generato nei passaggi precedenti e completare le informazioni dell’applicazione con un nome chiaro, ad esempio Printer – IT Floor 1 – EPSON WF-2510. Il nome deve permettere di capire rapidamente sede, piano, modello o funzione della stampante, soprattutto quando il tenant contiene molte code.

Figura 9: Caricamento del pacchetto Install-Printer.intunewin nella Win32 app

Dopo aver compilato i campi richiesti, proseguiamo con il pulsante Next.

Figura 10: Configurazione delle informazioni della Win32 app per la stampante

Nella sezione Program configurare i comandi di installazione e disinstallazione. L’esecuzione deve avvenire in contesto System, perché l’installazione del driver richiede privilegi amministrativi e non deve dipendere dai privilegi dell’utente connesso.

Comando di installazione:

Comando di disinstallazione:

Impostazioni consigliate nella sezione Program:

Tabella 6: Impostazioni della sezione Program della Win32 app

Dopo aver compilato i campi necessari, possiamo proseguire facendo click sul pulsante Next.

Figura 11: Configurazione dei comandi di installazione e disinstallazione nella sezione Program

Nella sezione Requirements selezionare l’architettura e la versione minima di Windows coerenti con il driver. Per ambienti moderni, il requisito più comune sarà 64-bit e una versione minima allineata allo standard aziendale. Evitare di distribuire lo stesso driver a dispositivi con versioni di Windows non testate. Una volta definiti i requirements, proseguiamo con Next.

Figura 12: Configurazione dei requisiti della Win32 app

Detection rule

La detection rule deve confermare che la stampante sia realmente installata con il driver e la porta attesi. Una semplice chiave di registro può bastare in scenari molto lineari, ma una detection PowerShell è più precisa perché consente di verificare il nome della stampante, il driver, il nome della porta, l’indirizzo configurato e il numero di porta TCP. Per questa guida, creare un file Detect-Printer.ps1 con il contenuto seguente e usarlo come custom detection script nella Win32 app (trovate anche questo su GitHub):

Quando si usa uno script di detection per una Win32 app, lo script deve restituire un esito in linea con le regole di Intune: un codice di uscita diverso da zero indica errore o applicazione non rilevata; con codice 0 e output su STDOUT, l’app viene considerata installata. In alternativa, si può usare una detection rule di tipo Registry:

Tabella 7: Detection rule alternativa basata sulla presenza della chiave di registro della stampante

La detection via registro è più semplice, ma non conferma che la porta e il driver siano quelli corretti. Per questo motivo, negli ambienti dove si aggiornano driver o si riutilizzano nomi stampante già esistenti, è preferibile usare lo script. Una detection rule troppo generica può far risultare installata una stampante configurata in modo errato. Per i deployment in produzione è consigliabile verificare almeno nome stampante, nome driver e nome porta.

Ad ogni modo, dopo aver completato la pagina di Detection rules, possiamo proseguire con Next.

Figura 13: Configurazione dello script PowerShell come custom detection rule

Assegnazione e pilota

Le tab Dependencies, Supersedence e Scope Tags non sono importanti per lo scopo di questa guida, quindi passiamo direttamente alla pagina di Assignments.
La prima assegnazione dovrebbe essere limitata a un gruppo pilota di dispositivi. La distribuzione Required è indicata quando la stampante deve essere installata automaticamente; la distribuzione Available è utile quando si vuole lasciare agli utenti la scelta dal Company Portal, tenendo conto del comportamento previsto nel proprio tenant e del tipo di gruppo usato. Una sequenza di rollout ragionevole prevede prima un dispositivo di laboratorio, poi alcuni dispositivi IT, quindi un gruppo ristretto della sede interessata e infine il resto dei dispositivi. Questo modello riduce il rischio di distribuire un driver errato o una coda non raggiungibile a un numero elevato di utenti.

Tabella 8: Fasi consigliate per il test e il rollout della stampante

Come indicato nella Tabella 1 del capitolo Scenario di riferimento, per questa demo utilizzeremo un gruppo pilota chiamato INTUNE-WIN-PRINTERS-PILOT e faremo un’assegnazione di tipo Required. Dopo aver incluso il gruppo, possiamo proseguire con il pulsante Next.

Figura 14: Assegnazione della Win32 app al gruppo pilota con intent Required

Dopo l’assegnazione verifichiamo nella sezione Review + create che tutte le informazioni siano state impostate correttamente, quindi procedere alla creazione dell’applicazione con l’apposito pulsante Create.

Figura 15: Verifica della configurazione nella pagina Review + create

Verifica lato client

Dopo l’installazione, la verifica va eseguita sia dal lato Intune sia direttamente sul dispositivo Windows. Nel Microsoft Intune admin center è possibile aprire Apps > All Apps, selezionare la Win32 app che abbiamo creato e verificare lo stato dalla sezione Monitor, utilizzando in particolare Device install status per controllare l’esito sui singoli dispositivi. Lo stato Installed conferma che Intune ha ricevuto un risultato di installazione e detection positivo per il dispositivo.

Se il primo controllo serve a confermare che la Win32 app sia stata distribuita correttamente, sul client è necessario invece verificare che siano presenti driver, porta TCP/IP e coda di stampa. Un primo riscontro può arrivare dal Portale aziendale (o Company Portal), nella sezione Download e aggiornamenti, dove l’applicazione può risultare installata con lo stato previsto. Questo controllo è utile per confermare che il deployment sia stato ricevuto dal dispositivo, ma non è sufficiente da solo a dimostrare che la stampante sia stata configurata correttamente.

PowerShell

Per la verifica tecnica partirei da PowerShell, i seguenti comandi permettono di controllare la presenza della stampante, della porta e del driver:

Se i valori restituiti corrispondono a quelli attesi, il dispositivo ha ricevuto correttamente gli elementi principali della configurazione. In particolare, la stampante deve risultare associata alla porta IP_192.168.0.126 e al driver EPSON WF-2510 Series. Quando si vuole verificare anche la raggiungibilità della stampante sulla rete, è utile aggiungere un controllo TCP verso la porta di stampa:

Se il risultato mostra TcpTestSucceeded : True, il client riesce a raggiungere la stampante sulla porta prevista. Questo test non sostituisce la prova di stampa, ma aiuta a distinguere i problemi di packaging o configurazione dai problemi di rete.

Console Gestione Stampa

Oltre ai controlli da riga di comando, è utile una verifica grafica tramite printmanagement.msc, quando disponibile. Nella console Gestione stampa è possibile confermare in modo immediato:

• la presenza del driver nella sezione Driver
• la presenza della coda nella sezione Stampanti
• la corrispondenza tra nome stampante e driver associato

Figura 16: Verifica del driver EPSON WF-2510 Series nella console Gestione stampa

Figura 17: Verifica della coda IT Floor 1 – EPSON WF-2510 nella console Gestione stampa

Questa verifica è particolarmente utile durante il collaudo, perché consente di confrontare rapidamente lo stato del sistema prima e dopo il deployment.

Registro di Sistema

Come controllo aggiuntivo, si può verificare anche la presenza della chiave di registro della stampante al percorso HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Printers. All’interno della chiave è possibile controllare almeno i valori Name, Port e Printer Driver. Questa verifica è utile per troubleshooting o per validare una detection rule alternativa basata sul registro, ma non dovrebbe essere considerata l’unico controllo di corretto funzionamento.

Figura 18: Verifica nel registro della configurazione della stampante distribuita tramite Intune

Windows Settings

Per un riscontro lato interfaccia utente, si può infine controllare la presenza della stampante in Settings > Bluetooth & devices > Printers & scanners. Anche in questo caso, la presenza della coda conferma che la stampante è visibile al sistema, ma la validazione completa richiede comunque il controllo di driver, porta e connettività.

Figura 19: Verifica della presenza della stampante nelle impostazioni di Windows

Logs

Per la parte dei log potete approfondire alla pagina Microsoft Intune Management Extension logs: guida pratica al troubleshooting, ed i file locali della Microsoft Intune Management Extension si trovano in C:\ProgramData\Microsoft\IntuneManagementExtension\Logs. Per le Win32 app, i file più utili sono:

• IntuneManagementExtension.log
• AppWorkload.log
• AppActionProcessor.log

Nel caso del nostro scenario è disponibile anche un log dedicato generato dagli script utilizzati, che potete trovare al percorso C:\ProgramData\EndpointNinja\PrinterDeployment (potete modificare il percorso a vostro piacimento)
e consente di capire se l’errore riguarda il file INF, il nome del driver, la creazione della porta TCP/IP oppure l’aggiunta della stampante.

Figura 20: Verifica del log generato dallo script di installazione della stampante

Infine, per concludere la validazione, dopo i controlli tecnici è consigliabile eseguire anche una stampa di prova, così da confermare non solo la presenza della coda, ma anche l’effettiva funzionalità della stampante dal dispositivo gestito.

Troubleshooting

Quando la distribuzione non produce il risultato atteso, è utile individuare in quale fase si interrompe il processo: esecuzione della Win32 app, staging del driver, registrazione del driver di stampa, creazione della porta TCP/IP, aggiunta della coda oppure detection finale. Gli script utilizzati in questa guida scrivono le operazioni eseguite nel log dedicato, che può quindi essere confrontato con i log della Microsoft Intune Management Extension.

Nella tabella seguente ho sintetizzato i principali problemi che possono verificarsi durante il deployment di driver e stampanti tramite Microsoft Intune, indicando per ciascun sintomo le possibili cause, i controlli da eseguire e le azioni consigliate per il troubleshooting:

Tabella 9: Troubleshooting del deployment di driver e stampanti tramite Microsoft Intune

Stampanti condivise da print server

La guida è orientata alle stampanti TCP/IP dirette, ma in alcuni ambienti esistono ancora print server Windows con code condivise. PowerShell supporta anche l’aggiunta di una stampante di rete tramite Add-Printer -ConnectionName \\printServer\printerName, ma questo scenario introduce dipendenze diverse: autenticazione, raggiungibilità del server, driver disponibili sul client, Point and Print e relative restrizioni di sicurezza.

Le impostazioni Point and Print sono gestibili anche via CSP e includono criteri come PointAndPrintRestrictions e RestrictDriverInstallationToAdministrators. Disabilitare o allentare queste restrizioni per risolvere rapidamente un problema di installazione driver può aumentare il rischio operativo e va evitato senza una valutazione di sicurezza.

Quando si usano print server, è preferibile mantenere una linea chiara: driver firmati, server approvati, configurazioni coerenti tra client e server, test su dispositivi non amministrativi e documentazione delle eccezioni. Se l’obiettivo è eliminare la dipendenza dai driver di terze parti sui client, occorre valutare scenari IPP, Windows Protected Print Mode o Universal Print, sapendo che la modalità di stampa protetta di Windows limita l’uso di driver di terze parti e cambia il modello legacy di stampa.

Attenzione: non usate la distribuzione Intune come pretesto per disabilitare in modo generalizzato le restrizioni Point and Print. Se l’ambiente richiede print server e driver legacy, la configurazione deve essere valutata insieme ai requisiti di sicurezza dello spooler e alle policy di stampa già applicate ai client.

Gestione di più stampanti e aggiornamento dei driver

Se l’ambiente contiene poche stampanti, un pacchetto per ciascuna coda è semplice da gestire, quando invece molte stampanti condividono lo stesso driver può essere molto più conveniente separare il pacchetto driver dalla creazione della coda. In questo modello, la Win32 app del driver viene installata come dipendenza e le singole app delle stampanti si limitano a creare porta e coda.

Tabella 10: Modelli di packaging per ambienti con più stampanti

Per aggiornare un driver, non conviene sovrascrivere file nella cartella del Driver Store. Il driver va distribuito come nuovo pacchetto, con una Win32 app aggiornata e una propria detection rule. Nei casi più delicati, è preferibile rimuovere e ricreare la coda con il nuovo driver durante una finestra controllata (evitando modifiche massive durante l’orario di lavoro).

Sicurezza e limiti

La distribuzione di driver di stampa è una modifica a livello dispositivo e deve essere trattata come tale. I driver devono provenire da fonti attendibili, devono essere firmati e devono essere testati su un campione rappresentativo di dispositivi. Anche se lo script viene eseguito in contesto System, non elimina i controlli di integrità del driver e non risolve problemi di compatibilità del pacchetto.

Occorre inoltre considerare il ciclo di vita dello spooler e delle tecnologie di stampa in Windows. Le funzionalità più moderne, come la stampa IPP e Windows Protected Print Mode, puntano a ridurre la dipendenza dai driver legacy di terze parti, mentre gli ambienti che mantengono driver tradizionali devono continuare a gestire patching, compatibilità, restrizioni e test di regressione.

Va inoltre considerata l’evoluzione del modello di stampa di Windows: dal 15 gennaio 2026, per Windows 11 e Windows Server 2025 e versioni successive, non vengono più pubblicati nuovi driver di stampa tramite Windows Update; dal 1° luglio 2026 il ranking dei driver privilegia il driver IPP incluso in Windows. I driver forniti direttamente dai produttori possono continuare a essere installati mediante pacchetti separati, come avviene nella procedura descritta in questa guida, ma per nuovi progetti è opportuno verificare anche la disponibilità di stampa IPP/Mopria e il ciclo di vita del driver legacy utilizzato. Potete trovare maggiori informazioni alla pagina ufficiale Microsoft End of servicing plan for third-party printer drivers on Windows.

Tabella 11: Principali limiti operativi della distribuzione delle stampanti tramite Win32 app

Attenzione: questa procedura non è compatibile con una configurazione in cui Windows Protected Print Mode impedisce l’uso del driver di terze parti richiesto dalla stampante. Quando la modalità è attiva, le stampanti che utilizzano driver di terze parti vengono rimosse e tali driver non possono essere utilizzati finché la modalità resta abilitata.

Conclusioni

Distribuire driver e stampanti con Microsoft Intune senza Universal Print è una soluzione praticabile quando l’obiettivo è installare code TCP/IP locali su dispositivi Windows gestiti. Il modello funziona bene se viene trattato come un normale processo di packaging: driver completo, script idempotente, detection robusta, gruppo pilota, log leggibili e rollout graduale.

La parte più importante resta la validazione del driver: se il pacchetto del produttore è incompleto, se il nome driver non è corretto o se la detection controlla solo la presenza superficiale della stampante, Intune può distribuire il contenuto correttamente ma il risultato sul client può non essere utilizzabile. Con una struttura pulita e controlli lato client ben definiti, invece, la Win32 app diventa un metodo affidabile per gestire le stampanti tradizionali anche in ambienti cloud-first.