Distribuire Microsoft Project 2013 con SCCM e ConfigMgr

Distribuire Project 2013 con ConfigMgr senza farsi male

Su Microsoft Project 2013 il punto non è “far partire il setup”, ma costruire un pacchetto che si comporti bene in silent install, sia rilevabile da ConfigMgr e non lasci dietro residui o conflitti con Office già presente. Se l’obiettivo è una distribuzione gestita, il lavoro vero sta nel preparare l’origine, definire bene la detection e decidere in anticipo come trattare architettura, licenza e riavvii.

Con Project 2013 la differenza tra un deployment pulito e uno che genera ticket dopo il primo ciclo di distribuzione è quasi sempre nella qualità dei parametri di installazione e nella coerenza tra media, lingua e prodotto già installato sul client. ConfigMgr non corregge una source fatta male: la consegna soltanto più in fretta.

Prima decisione: MSI puro o pacchetto Office Click-to-Run non è lo stesso problema

Project 2013 esiste in scenari diversi e qui serve chiarezza: se stai lavorando con media MSI/volume licensing, il deployment con ConfigMgr è lineare; se invece l’ambiente ha già Office in Click-to-Run, devi verificare compatibilità e coesistenza prima ancora di pensare al task sequence. In pratica, non basta dire “Project 2013”: bisogna sapere quale build, quale canale e quale famiglia di installazione stai distribuendo.

La regola operativa è semplice: prima identifichi il formato del prodotto, poi prepari il pacchetto. Se ti manca questo dato, il modo corretto per chiudere il gap è controllare la source ufficiale del software, il file `setup.exe` e i manifest del media, oppure la documentazione interna del vendor. Senza quell’informazione, qualsiasi automatismo rischia di essere solo un tentativo fortunato.

Prerequisiti che conviene verificare prima del pacchetto

Per evitare installazioni che falliscono in silenzio, conviene verificare tre punti prima della distribuzione: architettura supportata, presenza di Office compatibile e modalità di attivazione. Project 2013 a 32 bit su client con Office 32 bit è il caso più semplice; la combinazione con Office 64 bit o con installazioni miste va trattata come eccezione, non come default.

Dal lato ConfigMgr, il prerequisito vero è avere una source accessibile e immutabile: share SMB con permessi di lettura per il computer account del Distribution Point o contenuto già importato nel package source. Se la source viene modificata dopo la creazione del pacchetto, devi rigiocare il content update; se non lo fai, il DP può servire file vecchi rispetto al contenuto atteso.

Per un controllo rapido sul client di test, l’evidenza minima è la presenza di Office/Project nei programmi installati e la versione esatta dell’installer. Se usi inventory, il campo utile è quello del software installato; se usi file system, controlla la cartella di staging temporanea del setup e i log dell’installazione generati da Office.

Preparare il media: il pacchetto deve essere ripetibile

Il lavoro pulito parte sempre da una source ordinata. Non tenere il contenuto del DVD o dell’ISO “così com’è” se devi distribuirlo su larga scala: crea una cartella dedicata, documenta il nome del build e conserva i file di configurazione usati per l’installazione silente. Così puoi ricostruire il pacchetto, confrontare versioni e fare rollback senza inventarti dove fosse finito il parametro giusto.

Se il media supporta un file di configurazione, è lì che conviene centralizzare lingua, feature e licenza. In ambienti gestiti, il vantaggio è doppio: riduci gli input manuali e rendi la detection più prevedibile. Un pacchetto che cambia comportamento a seconda di chi lo lancia è un pacchetto che, prima o poi, fallisce in produzione.

Una struttura tipica di lavoro può essere questa:

D:\Sources\Project2013\
  setup.exe
  configuration.xml
  office\
  updates\
  readme-deployment.txt

La cartella `updates` è utile solo se stai integrando patch o update successivi alla baseline. Se non hai un motivo preciso per includerli, meglio partire con un media essenziale e validare prima la baseline: meno variabili, meno errori, diagnostica più semplice.

Silent install: pochi parametri, ma coerenti

Con ConfigMgr il comando deve essere non interattivo e prevedibile. L’idea è che il client lanci il setup senza finestre, senza richieste all’utente e con un exit code leggibile dal programma di distribuzione. In pratica, il setup deve comportarsi bene anche se nessuno è seduto davanti al PC.

Un esempio di approccio è usare il setup con file di configurazione e logging esplicito. La sintassi precisa dipende dal media e dalla struttura del pacchetto, ma il concetto resta lo stesso: installazione silente, log su disco, exit code gestito da ConfigMgr.

setup.exe /config configuration.xml /log install.log

Se il tuo media non usa quella sintassi, non forzare un comando “simile”: verifica il file `setup.exe /?` oppure la documentazione del pacchetto specifico. Il gap va chiuso prima di pubblicare il deployment, perché un comando sbagliato in ConfigMgr si traduce in tentativi ripetuti su più client e in una coda di errori difficile da ripulire.

Per evitare sorprese, definisci sempre gli exit code attesi nel programma di installazione di ConfigMgr. Se il setup restituisce codici di riavvio o codici non standard, ConfigMgr deve saperli interpretare. Altrimenti rischi che un’installazione riuscita venga marcata come fallita, o viceversa.

Detection method: il punto dove si rompe metà dei deployment

La detection non deve essere “creativa”, deve essere affidabile. Per Project 2013 la strada più robusta è basarsi su una combinazione di chiave di registro, versione del prodotto o presenza di file/versione binaria, a seconda del packaging effettivo. Il criterio migliore è quello che ti dice in modo univoco se il prodotto è davvero installato, non solo se un componente esiste sul disco.

Se usi ConfigMgr, la detection rule va testata su almeno due stati: client pulito e client già installato. Devi vedere un comportamento binario chiaro: non presente prima, presente dopo. Se la regola è ambigua, il client può reinstallare a ogni ciclo di valutazione o, peggio, considerare installato qualcosa che manca davvero.

Un controllo tipico è la presenza della chiave di prodotto sotto il ramo di Office, oppure la verifica del file eseguibile principale con versione coerente. La verifica va sempre fatta con una macchina reale, non solo con la teoria del packaging.

Distribuzione in ConfigMgr: Application meglio di Package quando puoi

Se stai usando ConfigMgr moderno, per Project 2013 conviene quasi sempre modellare il deployment come Application e non come semplice Package. L’Application ti dà detection, supersedence, requisiti e reporting migliori. Il Package va bene per casi semplici o legacy, ma ti lascia meno controllo sulla logica di stato e sulla manutenzione nel tempo.

La sequenza pratica è questa: importi la source, definisci il programma di installazione, imposti detection, distribuisci il contenuto ai DP e poi fai il deployment su una collection pilota. Non saltare il pilota: è il solo modo per vedere conflitti con versioni Office già presenti, problemi di permessi o riavvii indesiderati prima di allargare l’impatto.

Se devi limitare il blast radius, usa una collection di test con pochi dispositivi rappresentativi: almeno un client pulito, uno con Office già presente e uno con policy di sicurezza più restrittive. È un test molto più utile di cinquanta device casuali che non rappresentano il parco reale.

Distribuzione del contenuto: DP, boundary e tempi reali

Molti deployment falliscono non perché il setup sia sbagliato, ma perché il contenuto non è arrivato al Distribution Point giusto o il client non lo raggiunge. Qui la verifica minima è banale: contenuto distribuito, DP healthy, boundary group corretta e client che vede quel DP come preferito. Se il boundary è errato, il client può andare a cercare il pacchetto altrove e fallire per puro routing logico.

Per un controllo rapido, nel console di ConfigMgr verifica lo stato del content su DP e la status message del deployment. Sul client, i log di riferimento dipendono dalla versione di ConfigMgr e dal tipo di installazione, ma il punto è sempre lo stesso: devi vedere che il contenuto viene localizzato, scaricato e poi eseguito. Se il download non parte, il problema è prima del setup.

Se la rete è lenta o i DP sono remoti, valuta pre-cache o distribuzione in finestre orarie. Project 2013 non è enorme, ma in ambienti con link stretti e tanti client in parallelo anche pochi gigabyte moltiplicati per cento endpoint diventano un problema reale.

Licenza e attivazione: non lasciare il tema in sospeso

Project 2013 può richiedere attivazione in base al modello di licenza. Questo va deciso prima del rollout, non dopo. In ambienti enterprise il comportamento atteso deve essere chiaro: attivazione tramite volume licensing, KMS o altro meccanismo autorizzato, con eventuale configurazione già prevista nel pacchetto o nel post-install.

Se il prodotto si installa ma poi resta in stato di not activated, il deployment è solo parzialmente riuscito. Dal punto di vista operativo, conviene trattare l’attivazione come requisito funzionale: il software deve essere installato e utilizzabile, non semplicemente presente nel menu Start.

Qui non c’è spazio per improvvisare: i dati di licenza non vanno messi in chiaro nei pacchetti o nei log. Se devi configurare parametri sensibili, redigili nei documenti operativi e conserva gli estremi in un vault o in un sistema di gestione segreti approvato.

Logging: senza log non hai diagnostica, hai opinioni

Il logging va attivato sempre, anche se pensi che il pacchetto sia semplice. Per l’installazione Office-based i log sono la fonte primaria per capire perché il setup si è fermato. In ConfigMgr, il log lato client ti dice se il comando è partito, se il contenuto è stato scaricato e quale exit code è stato restituito.

La pratica corretta è raccogliere almeno tre elementi: log del setup, log del client ConfigMgr e stato del deployment. Se uno dei tre manca, non hai ancora abbastanza evidenza per dire dove sia il problema. Il primo check utile è sempre questo: il processo è partito? il contenuto era disponibile? il setup ha restituito successo o errore?

Su un client test puoi verificare rapidamente il risultato con la presenza dell’applicazione nel pannello programmi e con la versione del binario principale. Se il software appare installato ma non si avvia, il problema è già fuori dal perimetro del deployment e va trattato come guasto applicativo o conflitto con policy di sicurezza.

Rollback pratico: come tornare indietro senza caos

Il rollback di un deployment di Project 2013 non dovrebbe mai essere improvvisato. Il minimo sindacale è poter disabilitare il deployment in ConfigMgr, rimuovere il content dai DP se necessario e avere un piano per disinstallare il prodotto dai client pilota. Se il change è ancora in fase di test, spesso basta sospendere l’assegnazione alla collection e fermare la propagazione.

Se invece hai già coinvolto utenti reali, il rollback va gestito con attenzione al blast radius: prima blocchi nuove installazioni, poi valuti la rimozione solo dove il prodotto ha creato incompatibilità o problemi di licenza. Non fare pulizie massive senza una finestra e senza un criterio preciso di selezione dei client impattati.

Come controllo finale, verifica che il deployment non stia più applicando lo stato Desired ai client e che i log non mostrino nuovi tentativi di installazione. Se l’Application resta disponibile ma non più assegnata, il rollback operativo è coerente e reversibile.

Checklist operativa che evita i problemi più comuni

Prima di pubblicare in produzione, conviene passare da una checklist breve ma concreta. È più utile di un documento lungo che nessuno rilegge quando il deployment fallisce alle 18:30.

• Source verificata e immutabile, con `setup.exe` e file di configurazione coerenti.
• Silent install testata su client pulito con log abilitati.
• Detection rule valida su stato installato e non installato.
• Content distribuito ai DP corretti e boundary group coerenti.
• Exit code mappati correttamente in ConfigMgr.
• Licenza e attivazione definite prima del rollout.
• Rollback deciso: disabilitazione deployment, eventuale uninstall, contenuto rimovibile.

Se vuoi ridurre il rischio ancora di più, fai un controllo incrociato tra console e client: stato del deployment in ConfigMgr, log di installazione sul dispositivo e presenza reale del prodotto. Quando questi tre elementi coincidono, il pacchetto è abbastanza maturo da uscire dal pilota.

Quando conviene fermarsi e rivedere il design

Se il tuo ambiente ha Office misto, più canali di installazione o vincoli di sicurezza molto stretti, potrebbe non bastare un semplice application deployment. In quel caso conviene rivedere il design: standardizzare la famiglia Office, separare i target per architettura o introdurre requisiti più rigidi nella collection. È più costoso all’inizio, ma riduce il costo operativo nel tempo.

La distribuzione di Project 2013 con ConfigMgr funziona bene quando il pacchetto è trattato come un componente gestito, non come un installer da copiare in giro. Source pulita, installazione silente, detection seria, logging e rollback: il resto è solo rumore operativo.