Distribuire Microsoft Teams con SCCM e installer MSI

Perché Teams va trattato come un’applicazione “mobile” anche in SCCM

Microsoft Teams non si comporta come un classico software statico da distribuire una volta e dimenticare. Cambia spesso, ha componenti per utente e per macchina, dipende dal profilo di accesso e, soprattutto, tende a generare confusione quando si mescolano installer diversi: MSI, bootstrapper, versioni per macchina e installazioni per-user. Se l’obiettivo è una distribuzione controllata con SCCM, conviene partire da una scelta netta: gestire Teams come pacchetto aziendale con ciclo di vita definito, non come installazione manuale lasciata all’utente o al primo avvio di Office.

La domanda vera non è “come installo Teams”, ma quale variante voglio governare. In un ambiente endpoint ordinato, la risposta migliore è quasi sempre la stessa: installazione machine-wide, detection robusta, aggiornamento prevedibile, rimozione pulita della variante legacy e nessuna dipendenza dal comportamento del singolo utente. Questo è il punto in cui SCCM fa il suo mestiere: standardizza, misura e consente rollback.

MSI, bootstrapper e New Teams: scegliere il pacchetto giusto evita metà dei problemi

Il primo errore operativo è usare il file sbagliato per lo scenario sbagliato. Storicamente Teams è stato distribuito con installer diversi, e oggi bisogna distinguere almeno tre casi: il vecchio client classico, il nuovo Teams e il modello di installazione che si appoggia a componenti per macchina o a un bootstrapper. In SCCM la regola pratica è semplice: non costruire una strategia di package management su un file pensato per uso interattivo.

Se hai un MSI disponibile e supportato per lo scenario che vuoi governare, usalo come base del deployment. Se hai un bootstrapper, trattalo come wrapper e verifica sempre cosa installa davvero, dove mette i binari e quale detection puoi usare senza ambiguità. In altre parole: il nome del file conta poco, conta il comportamento post-installazione. Una distribuzione SCCM ben fatta si fonda su un artefatto verificabile, non su una speranza.

Per evitare ambiguità, conviene validare in laboratorio questi tre punti prima di mettere il pacchetto in produzione:

• quale eseguibile viene creato e con quale versione;
• se l’installazione è per-machine o per-user;
• quale chiave di detection resta stabile dopo il reboot e dopo l’aggiornamento.

Struttura del pacchetto SCCM: contenuto, detection e comandi silenziosi

In SCCM il pacchetto deve essere pensato come un oggetto ripetibile. Il contenuto va distribuito a un Distribution Point, il comando di installazione deve essere silenzioso, e la detection method deve rispondere a una logica che non cambi con ogni patch minore. Se il client è installato correttamente ma la detection è fragile, SCCM continuerà a reinstallare o a marcare l’applicazione come non conforme. È qui che molti ambienti si rompono senza clamore: non c’è un vero problema di installazione, c’è un problema di stato.

Per un MSI, il comando base resta quello standard di Windows Installer, con logging sempre attivo durante le prime prove. Un esempio tipico è il seguente:

msiexec /i TeamsMachineInstaller.msi /qn /norestart /l*v C:\Windows\Temp\Teams-install.log

Il log non è un optional: è la tua prova forense minima. Se l’installazione fallisce, senza il log stai facendo ipotesi. Con il log puoi leggere errori MSI, problemi di permessi, dipendenze mancanti o ritorni anomali. Per una distribuzione in produzione, il file di log deve essere parte della procedura, non un’aggiunta a posteriori.

La detection method va costruita con prudenza. Una buona detection non si basa solo sulla presenza di una cartella, perché quella può rimanere dopo una disinstallazione incompleta. Meglio una combinazione di versione file, chiave di registro o product code, a seconda di ciò che il pacchetto espone in modo stabile. Se usi il registro, verifica il percorso effettivo sul client dopo l’installazione e dopo un update. Se usi un file versionato, controlla che il path non cambi tra release diverse.

Se la detection è debole, SCCM non “vede” il vero stato del software. E quando lo stato è incerto, il risultato è quasi sempre una ridistribuzione inutile o una falsa conformità.

Gestire la convivenza con il vecchio Teams e con Office

Uno dei punti più delicati è la coesistenza con il client legacy. In molti ambienti il vecchio Teams è ancora presente perché installato da precedenti pacchetti Office, da profili utente o da installazioni manuali. Se distribuisci il nuovo client senza pulire il vecchio, rischi due problemi: duplicazione percepita dagli utenti e comportamenti incoerenti nelle associazioni del client di meeting. Il sintomo più comune è banale ma fastidioso: l’utente apre Teams e non sa quale versione stia effettivamente usando.

La strategia corretta è separare le fasi. Prima rimozione controllata del legacy, poi installazione del nuovo client. In ambienti grandi, la rimozione deve essere gestita come change controllato, con test su un pilota e con un criterio di esclusione per macchine già in stato corretto. Se il pacchetto di rimozione tocca componenti per utente, bisogna anche considerare cosa succede ai profili già presenti sul device. Non basta togliere il binario: bisogna verificare anche residui, task, chiavi di registro e eventuali riferimenti in Start Menu o nel profilo dell’utente.

In pratica, il flusso più solido è questo:

1. rilevare la presenza del client legacy con una detection dedicata;
2. distribuire una fase di rimozione con finestra temporale e logging;
3. verificare che il client legacy non sia più rilevato;
4. solo dopo, distribuire il nuovo pacchetto Teams.

Sequenza di distribuzione: pilota, anello intermedio, produzione

Distribuire Teams direttamente su tutta la popolazione è il modo più rapido per trasformare un aggiornamento in un incidente. L’approccio corretto con SCCM è per anelli: gruppo pilota, gruppo intermedio, produzione. Nel pilota non ti limiti a “vedere se parte”: osservi login, avvio, presenza nella tray, apertura meeting, autenticazione, integrazione con Outlook se prevista e consumo risorse nei primi minuti. L’obiettivo non è solo l’installazione, ma la funzionalità operativa.

Durante il pilota è utile raccogliere almeno tre evidenze: successo del task sequence o dell’application deployment, assenza di errori nel log di installazione e presenza del binario o della chiave di detection attesa. Se una di queste tre cose manca, non hai ancora un deployment affidabile. In questa fase non serve essere creativi: serve essere noiosi e rigorosi.

Un dettaglio spesso sottovalutato è la tempistica. Teams tende a mostrare il suo vero comportamento dopo il primo riavvio o dopo il primo login utente, non solo al termine dell’installer. Per questo il collaudo deve includere almeno un ciclo completo di accesso utente, non una semplice verifica da amministratore locale subito dopo il setup.

Logging utile: dove guardare quando il deployment non torna

Quando qualcosa non funziona, i log da controllare dipendono dal punto di rottura. Se il problema è nel package SCCM, il primo riferimento è il log del client Configuration Manager sul device. Se il problema è nell’installer, guarda il log MSI creato con il parametro di tracing. Se il problema è nel comportamento dell’applicazione dopo l’installazione, sposta l’attenzione sui log del client Teams, sugli eventi applicativi e sul comportamento della detection.

Non serve memorizzare percorsi esatti di ogni versione se non li hai verificati nel tuo ambiente. È più utile impostare una procedura: apri il log di installazione, verifica il codice di ritorno, controlla il timestamp del file o del registro atteso, poi osserva il client con un account standard. Se il pacchetto è davvero corretto, la prova deve reggere anche fuori dal contesto amministrativo.

Un esempio pratico di check post-installazione può essere questo:

powershell -NoProfile -Command "Get-Item 'C:\Program Files\Microsoft Teams\current\Teams.exe' | Select-Object Name,Length,LastWriteTime"

Se il path non esiste, non assumere automaticamente che l’installazione sia fallita: verifica dove il pacchetto ha effettivamente posizionato i binari. Questo è il punto in cui molti ambienti si affidano a un path “storico” e poi inseguono falsi negativi per settimane.

Disinstallazione e rollback: il vero banco di prova

Un deployment serio non si misura solo sull’installazione. Si misura sulla capacità di tornare indietro senza lasciare il parco macchine in uno stato ambiguo. Per questo il rollback deve essere previsto prima di premere “Deploy”. Se il pacchetto causa problemi, devi sapere come rimuoverlo, come ristabilire la versione precedente e come evitare che SCCM riproponga immediatamente lo stesso stato errato.

La disinstallazione va testata con gli stessi criteri della distribuzione: comando silenzioso, logging, detection di rimozione e verifica finale. Se il pacchetto supporta un codice di uninstall MSI, usalo. Se richiede un eseguibile dedicato, documenta la sintassi esatta e conserva il comando in una nota operativa interna. Un rollback non documentato non è un rollback: è un’intenzione.

Prima di una distribuzione estesa, prepara anche una regola di esclusione o una collezione di rollback in SCCM. In caso di regressione, il blast radius rimane confinato e non devi rincorrere manualmente ogni endpoint. Questo vale ancora di più se Teams è parte di un pacchetto più ampio con Office, WebView2 o altri prerequisiti: il rollback deve colpire solo ciò che hai cambiato, non l’intero stack utente.

Un modello operativo che regge nel tempo

La distribuzione di Microsoft Teams con SCCM funziona bene quando smetti di trattarla come una semplice installazione software e la trasformi in un piccolo processo di service management. Il pacchetto va versionato, la detection va verificata a ogni release, il logging va conservato per un periodo congruo e la rimozione del legacy va pianificata come parte del progetto, non come pulizia postuma. Il vantaggio è concreto: meno ticket, meno reinstallazioni manuali, meno anomalie tra gruppi di utenti diversi.

Se vuoi un criterio semplice per capire se il lavoro è fatto bene, usa questa domanda: posso spiegare in tre minuti come verifico installazione, aggiornamento e rollback su una macchina campione? Se la risposta è no, la procedura è ancora fragile. Se la risposta è sì, hai una base solida per scalare la distribuzione senza improvvisare.