Come distribuire Microsoft PC Manager con Intune

Microsoft PC Manager si presta bene a una distribuzione con Intune quando vuoi standardizzare un tool di ottimizzazione e supporto su un parco Windows gestito, senza passare da installazioni manuali o script sparsi. Il punto non è solo “pubblicare l’app”, ma decidere con precisione come impacchettarla, a chi assegnarla, come verificarne l’esito e come ritirarla senza lasciare residui inutili.

In pratica, il flusso corretto è questo: scarichi il pacchetto ufficiale o ottieni il binario consentito dalla tua policy, lo trasformi in una Win32 app per Intune, definisci detection rule affidabili, assegni l’installazione a un gruppo ristretto per il pilot e osservi i log prima di allargare il rollout. Se salti detection e monitoraggio, rischi di credere che l’installazione sia riuscita quando in realtà il client ha solo scaricato il contenuto.

Quando ha senso distribuirlo

PC Manager non è un componente infrastrutturale critico, quindi la distribuzione va trattata come change controllato. Ha senso se vuoi offrire agli utenti interni uno strumento uniforme per pulizia file temporanei, gestione startup, controllo processi e alcune funzioni di manutenzione base. Ha meno senso se il tuo ambiente è già molto bloccato, se usi policy più restrittive per evitare tool di “ottimizzazione” lato endpoint, oppure se vuoi evitare qualsiasi software aggiuntivo non strettamente necessario.

Prima di procedere, chiarisci due aspetti: il tool è consentito dalla tua baseline di sicurezza e il suo uso è davvero richiesto dal supporto interno. Se la risposta a uno dei due è no, il problema non è tecnico ma di governance. In quel caso la chiusura è semplice: apri un ticket di approvazione con motivazione, impatto atteso e ambito di distribuzione. Senza questo passaggio, il rollout diventa facile da avviare e altrettanto facile da contestare.

Prerequisiti operativi su Intune

Per distribuire un’app Win32 con Intune servono alcuni elementi minimi: il tenant Intune operativo, dispositivi Windows registrati e un metodo di packaging compatibile con Microsoft Win32 Content Prep Tool oppure un pacchetto già pronto in formato .intunewin. Serve anche una strategia di assegnazione: gruppi di utenti o dispositivi ben definiti, non un contenitore generico “All Users” usato per comodità.

La verifica preliminare più utile è capire se il software ha un installer silenzioso affidabile. Se il vendor fornisce un setup con parametri di installazione, bene. Se non li fornisce, devi prima testare in locale la modalità silent con un account amministrativo su una macchina di prova. Il comando preciso dipende dal pacchetto che hai in mano, quindi questo è un gap da chiudere sul file ufficiale o sulla documentazione del vendor: cerca i parametri in /?, nella guida prodotto o nel log di installazione generato dal setup.

Packaging: il punto che decide metà del successo

La via più pulita è trattare Microsoft PC Manager come una Win32 app. Anche quando il pacchetto sembra semplice, evitare la distribuzione “a mano” ti dà controllo su detection, retry, uninstall e reporting. Il contenuto viene compresso in un file .intunewin e pubblicato come app aziendale. Questo è il formato giusto se vuoi un ciclo di vita gestibile nel tempo.

La struttura del packaging dovrebbe essere essenziale: un folder sorgente, un installer, eventuali file di supporto e uno script di installazione se ti serve normalizzare parametri o controlli preliminari. Non mischiare sorgenti, output e log nello stesso percorso. Tieni separato ciò che distribuisci da ciò che osservi. È una distinzione banale, ma evita errori quando devi rifare il pacchetto o confrontare una versione nuova con la precedente.

Un esempio pratico di struttura locale può essere questo:

C:uild
pcmanageriles
elease
pcmanager-setup.exe
C:uild
pcmanageriles
eadme.txt
C:uild
pcmanageruild
pcmanager.intunewin

Se il nome esatto del setup cambia o il vendor distribuisce il software in un canale diverso, non forzare ipotesi. Prendi il nome dal file effettivo scaricato e verifica con un hash interno o con un controllo manuale della firma digitale, se presente. Per ambienti sensibili, controllare la firma del binario è una misura minima di igiene operativa.

Creazione del pacchetto .intunewin

La preparazione del pacchetto si fa con lo strumento Microsoft per il content prep. Il principio è semplice: indichi cartella sorgente, file di setup e cartella di output, poi ottieni il contenuto pronto per Intune. Il comando preciso dipende dal nome dell’eseguibile della toolchain che hai scaricato, ma il flusso è questo:

IntuneWinAppUtil.exe -c C:uild
pcmanageriles -s npcmanager-setup.exe -o C:uild
pcmanageruild

Il controllo da fare subito dopo è banale ma decisivo: il file .intunewin deve esistere nel percorso di output e la dimensione deve essere coerente con il contenuto sorgente. Se il pacchetto risulta anomalo, il problema di solito è uno di questi: file sorgente errato, cartella vuota, installer non accessibile o path sbagliato. In cinque minuti lo falsifichi aprendo la directory di output e verificando il nome del setup usato nel comando.

Configurazione dell’app in Intune

Nel portale Intune, la creazione passa dalla sezione Apps. Il percorso tipico è Apps → Windows → Add → Win32 app. Carichi il file .intunewin, compili i dati base e definisci il comportamento dell’installazione. Qui non devi essere generico: nome chiaro, descrizione utile, publisher corretto e categoria coerente con il catalogo interno.

La parte più delicata è il comando di installazione. Se il setup supporta l’installazione silenziosa, va usato senza finestre interattive. La sintassi esatta dipende dal pacchetto, quindi non inventarla: verifica nei parametri ufficiali del setup o nella documentazione del vendor. Se vuoi chiudere il gap subito, l’artefatto da cercare è il log dell’installer o l’output /? del file eseguibile, perché ti dice quali switch sono davvero supportati.

Per la detection rule, la scelta migliore è quella più stabile nel tempo. In molti casi conviene usare un file, una chiave di registro o un identificatore applicativo che non cambi a ogni aggiornamento. Evita detection troppo “creative”, come il solo nome del processo, perché basta un update minore per romperle. Se il software installa in Program Files, controlla il percorso reale sul sistema di test prima di impostare la regola. Se usa registry, identifica la chiave con regedit o con una query mirata e conserva il valore esatto.

Un approccio robusto è questo: detection basata su file presente e versione minima. In alternativa, una chiave di registro con valore noto. Il punto è che la detection deve rispondere a una domanda binaria: “è installato oppure no?”. Se la tua regola richiede interpretazioni, nel tempo ti tradirà.

Assegnazione: pilot prima, poi broad rollout

Non assegnare subito a tutta l’organizzazione. Crea un gruppo pilot con pochi dispositivi rappresentativi: una macchina standard, una con utente power user, una con profilo più restrittivo e, se necessario, un endpoint in rete remota. Questo ti dice se il comportamento è uniforme o se emergono blocchi di permessi, conflitti con endpoint protection o problemi di download.

In Intune puoi scegliere tra assegnazione Required e Available. Se il tool deve essere installato come standard aziendale, Required ha senso. Se vuoi lasciare l’installazione a richiesta, Available è più prudente. La decisione non è solo tecnica: dipende da quanto quel software deve essere presente su ogni endpoint e da quanto vuoi ridurre il rumore di supporto.

Qui il blast radius è chiaro: un’assegnazione errata a un gruppo ampio può portare il software su migliaia di endpoint in poche ore. Il rollback deve essere già pronto: rimuovi l’assegnazione, verifica la policy refresh sui client e, se necessario, pianifica la disinstallazione con un profilo separato. Non aspettare che il problema emerga sugli utenti finali per pensare alla ritirata.

Monitoraggio dell’installazione e log utili

Il successo apparente in Intune non basta. Devi guardare anche sul client. I log più utili sono quelli dell’Agent di Intune Management Extension, che su Windows si trovano tipicamente in C:\\ProgramData\Microsoft\IntuneManagementExtension\Logs\. Il file di interesse spesso è IntuneManagementExtension.log, dove vedi download, esecuzione del comando, detection e codice di uscita.

Se la distribuzione non parte, le cause più frequenti sono tre: il client non riceve la policy, il contenuto non viene scaricato, oppure il comando di installazione fallisce. In cinque minuti puoi falsificarle così: controlli la sincronizzazione del device in Intune, apri il log IME e cerchi il codice di errore, poi verifichi se il pacchetto è stato effettivamente scaricato nella cache locale. Se il download c’è ma l’installazione no, il problema è quasi sempre nel comando o nei prerequisiti del setup.

Quando il pacchetto viene eseguito ma la detection non torna, il sintomo tipico è l’installazione ripetuta o lo stato “failed” pur avendo il software presente. Questo è un classico errore di detection rule. La soluzione non è rilanciare la distribuzione a caso, ma correggere la regola e ripubblicare la versione aggiornata del pacchetto o della policy. Se il software è già installato, una detection sbagliata può creare più rumore che valore.

Disinstallazione e rollback pulito

Ogni distribuzione seria deve prevedere anche il ritiro. In Intune, il rollback è più semplice se hai preparato in anticipo un comando di uninstall affidabile o un secondo pacchetto destinato alla rimozione. Senza questo, togliere l’assegnazione non basta: i client che hanno già installato il software potrebbero conservarlo fino a intervento manuale.

La sequenza corretta è: rimuovere l’assegnazione o spostarla su un gruppo di esclusione, verificare che il client riceva la nuova policy, poi eseguire la disinstallazione sui dispositivi coinvolti. Se il vendor offre un uninstall silenzioso, usalo. Se non esiste, devi documentare il metodo alternativo e validarlo prima del rollout. Anche qui il gap va chiuso prima, non dopo.

Per il rollback operativo conserva sempre tre cose: versione del pacchetto precedente, detection originale e note sul comportamento osservato nel pilot. Questo ti consente di tornare indietro senza improvvisare. In un ambiente aziendale, la memoria del cambiamento vale quanto il cambiamento stesso.

Checklist pratica prima del rilascio ampio

Prima di estendere la distribuzione, verifica questi punti in modo esplicito:

Se uno di questi punti manca, non andare in broad rollout. Il costo di un pilot allungato è minore del costo di un’installazione fallita su larga scala, soprattutto quando il supporto deve gestire ticket ripetitivi e utenti che vedono software installati a metà.

Osservazione finale sul metodo

Distribuire Microsoft PC Manager con Intune non è complicato, ma richiede disciplina. La parte tecnica vera non è il click nel portale: è il controllo del pacchetto, la detection corretta, il pilot ristretto e il rollback già pronto. Se tratti il software come un’app qualsiasi, il rollout può sembrare facile; se lo tratti come un change governato, diventa gestibile e prevedibile.

Assunzione: il pacchetto ufficiale e i parametri di installazione possono variare in base alla versione distribuita; vanno verificati sul binario reale e sulla documentazione del vendor prima della pubblicazione in Intune.