1 25/10/2026 9 min

La Technical Preview 1807 di System Center Configuration Manager è una release da laboratorio, pensata per provare in anticipo funzioni, correzioni e cambi di comportamento prima che arrivino nel ramo stabile. Chi la installa deve farlo con un obiettivo chiaro: validare compatibilità, distribuzioni e procedure interne, non costruire un ambiente di produzione.

Il punto pratico è semplice: se hai già un site di preview o un’installazione precedente della Technical Preview, l’aggiornamento va trattato come un change controllato. Se invece parti da zero, conviene predisporre una macchina dedicata, isolata dal resto della rete di test, con SQL supportato, AD DS disponibile e diritti amministrativi completi sul server che ospita il site.

Prima di installare: cosa verificare davvero

Prima di lanciare l’installer, conviene controllare tre cose: il sistema operativo del server, la versione di SQL Server e la salute dei prerequisiti di Windows. In laboratorio si tende a saltare questi passaggi, ma è il modo più rapido per ritrovarsi con errori poco leggibili durante il setup o con un site che parte ma poi fallisce su ruoli secondari e componenti console.

Il server dovrebbe essere un host pulito o comunque dedicato. Se lo usi già per altri ruoli, il blast radius aumenta: IIS, WSUS, SQL Express o componenti di test possono interferire con installazione e troubleshooting. In questo caso conviene documentare prima la configurazione esistente e prevedere un rollback con snapshot o backup completo della VM.

Per una verifica rapida dei prerequisiti operativi, la prima domanda non è “si installa?”, ma “il server risponde in modo coerente alle dipendenze che SCCM si aspetta?”. Una checklist minima include: DNS funzionante, connettività verso il dominio, spazio disco sufficiente per content library e log, e una versione supportata di SQL. Se uno di questi punti è ambiguo, meglio fermarsi prima del wizard.

Installazione della Technical Preview 1807 in laboratorio

Il flusso tipico parte con il media della Technical Preview e l’esecuzione del setup sul server designato come site server. In un contesto di test, l’obiettivo è arrivare a una baseline ripetibile: stessa immagine OS, stessi prerequisiti, stessa versione di SQL, stesso dominio o foresta di prova. Più il laboratorio è standardizzato, più i risultati sono utili quando devi confrontarli con un ambiente reale.

  • Prepara il server con Windows aggiornato, .NET richiesto, IIS e i componenti indicati dal setup. Se vuoi ridurre errori, annota subito il nome host, il dominio e la versione di SQL installata.

  • Avvia il setup della Technical Preview con un account amministrativo locale e, se serve, con privilegi adeguati in dominio. In fase iniziale il controllo più utile è il log del setup, non la console.

  • Seleziona l’opzione per creare un nuovo site o per aggiornare un’installazione già esistente, a seconda del tuo scenario. In laboratorio è preferibile non mischiare installazione pulita e upgrade nello stesso host se vuoi isolare i problemi.

  • Completa i parametri di site code, site name, percorso dei file di installazione e database. Qui l’errore più comune è un path troppo corto in spazio disco o un nome site scelto senza coerenza con gli standard interni.

  • Al termine, verifica che la console si apra e che i ruoli principali risultino online. Se il setup termina ma la console non vede il site, il problema è spesso nei servizi o nella connettività verso SQL.

    • Durante l’installazione, i log sono più utili della UI. I file da controllare dipendono dalla fase, ma in generale i riferimenti chiave sono i log di setup e i log del site server. Se il setup si interrompe, la prima cosa da cercare è il punto esatto del fallimento, non il messaggio finale generico.

    Se hai bisogno di una verifica rapida da shell sul server, puoi controllare lo stato dei servizi principali dopo l’installazione. Un esempio utile è questo:

    Get-Service SMS_Executive, CcmExec, W3SVC | Select-Object Name, Status

    L’output atteso è uno stato Running per i servizi che devono essere attivi. Se uno dei tre è fermo, il problema va analizzato prima di procedere con test più complessi come distribuzione contenuti, discovery o client install.

    Novità da validare nella 1807

    Le Technical Preview servono soprattutto a capire cosa cambia nel comportamento operativo. Nella 1807 la logica da seguire è sempre la stessa: non limitarti a leggere la lista delle novità, ma prova i flussi che tocchi ogni giorno. Una funzione nuova è davvero utile solo se regge il confronto con il tuo processo di lavoro, i tuoi boundary di sicurezza e la tua rete.

    Tra le aree da testare con priorità ci sono la gestione del client, i controlli di conformità, la distribuzione applicazioni e il reporting operativo. Se la preview introduce modifiche nell’interfaccia o nel comportamento di un wizard, il rischio non è solo l’errore umano: spesso cambia anche il modo in cui vengono generati i log o come si interpreta lo stato di un deployment.

    Un approccio sensato è questo: prendi tre scenari reali del tuo laboratorio, per esempio una baseline di software, una task sequence e un deployment di applicazione, e verifica se la 1807 cambia tempi, messaggi di errore o ordine delle operazioni. Se un processo diventa più rapido ma meno chiaro nel debug, il guadagno non è automatico.

    Client management e comportamento lato endpoint

    La parte client va sempre testata con almeno due macchine: una pulita e una già usata in precedenza. Questo perché molte regressioni emergono solo quando il client eredita policy, cache o vecchi certificati. Verifica che l’agent si registri correttamente, che riceva policy e che riesca a scaricare contenuti dal distribution point di test.

    Per un controllo rapido, osserva lo stato del client e la connettività verso il site. Se il comportamento è anomalo, non partire subito con reinstallazioni: prima verifica i log del client, la risoluzione DNS del management point e l’eventuale presenza di proxy o firewall locali.

    Se vuoi controllare la presenza dell’agent e la sua attività di base, puoi usare una verifica semplice sul sistema di test:

    Get-Service CcmExec | Select-Object Name, Status

    Il risultato corretto è Running. Se il servizio è fermo, la domanda successiva non è “riavvio e basta”, ma perché il client non riesce a inizializzarsi: WMI, certificati, policy o installazione corrotta sono le cause più comuni.

    Task sequence e distribuzione contenuti

    Le task sequence vanno provate con attenzione perché sono il punto in cui si sommano più variabili: accesso al boot image, driver, contenuti, rete e dipendenze applicative. Una novità di preview può sembrare innocua finché non la inserisci in un flusso di provisioning reale. In quel caso, il minimo errore nel content distribution o nella sequenza dei passaggi si trasforma in un deploy fallito o in un client che si blocca in preboot.

    La verifica più utile è misurare se il contenuto viene distribuito e raggiungibile dal DP previsto. Se il pacchetto risulta distribuito ma il client non lo scarica, controlla prima boundary group, path del contenuto e stato del DP. In molti ambienti il problema non è il package, ma la relazione tra site, boundary e rete.

    Quando il test riguarda il content library, conviene controllare anche lo spazio disponibile sul volume dedicato. Una preview installata su una VM piccola può funzionare fino al primo ciclo di distribuzione, poi saturare il disco e generare errori a cascata. In laboratorio è un classico caso di “sembra tutto corretto” che in realtà nasconde un limite di capacity planning.

    Console, ruoli e operatività quotidiana

    La console è il punto in cui molte preview mostrano la differenza tra una feature davvero pronta e una ancora da rifinire. Verifica che le viste principali si aprano, che i ruoli rispondano e che i dati vengano popolati senza ritardi anomali. Se una nuova build introduce anche solo un piccolo cambiamento nel refresh delle viste, in un ambiente con molti oggetti può diventare un problema concreto di operatività.

    Non limitarti a guardare la home della console. Prova almeno una query, un deployment, una proprietà di collection e una vista di monitoring. Se una sezione carica ma restituisce dati incompleti, il problema può essere nella replica, nel provider o in una query WMI degradata. In quei casi il sintomo è spesso ambiguo: la console “si apre”, ma non è davvero utilizzabile.

    Verifiche tecniche dopo l’installazione

    Dopo l’installazione, il controllo più sensato è seguire il percorso del dato: il site risponde, i servizi sono attivi, i log non mostrano errori ricorrenti, la console si connette e il client riceve policy. Se uno di questi passaggi si interrompe, hai già il perimetro del problema senza dover toccare la configurazione a caso.

    Una verifica utile riguarda anche i log di installazione e i log di runtime. Non serve leggere tutto: basta cercare errori ripetuti, time-out, problemi di permessi o riferimenti a componenti mancanti. Se il pattern si ripete, è molto più probabile un problema di prerequisiti o di servizi che non un bug casuale della preview.

    Se vuoi una traccia operativa minima, usa questa sequenza:

  • Controlla lo stato dei servizi principali con Get-Service e verifica che siano Running.

  • Apri la console e conferma che il site venga visualizzato senza errori di connessione.

  • Verifica almeno un deployment verso un client di test e osserva se policy e contenuti arrivano correttamente.

  • Controlla i log più recenti del site server se trovi rallentamenti, errori o oggetti non aggiornati.

    • Rollback e gestione del rischio

    Essendo una Technical Preview, il rollback va pensato prima dell’installazione. La strada più pulita è una VM con snapshot precedente al change oppure un backup completo del sistema e del database, se il laboratorio è abbastanza vicino a un ambiente realistico da meritare una protezione seria. Se fai esperimenti senza rollback, non stai testando la preview: stai creando debito operativo.

    Il blast radius maggiore è sul site server e sul database. Se qualcosa va storto, la correzione non dovrebbe mai partire da modifiche casuali ai servizi: prima si ripristina il punto di partenza, poi si rifà il test con un solo cambiamento alla volta. In un contesto di preview, questa disciplina è più importante della velocità.

    Se l’installazione fallisce in modo parziale, non forzare più tentativi senza pulizia. Meglio raccogliere i log, salvare lo stato corrente e tornare alla baseline. La regola pratica è semplice: ogni retry deve avere una motivazione tecnica diversa, altrimenti stai solo ripetendo lo stesso errore.

    Assunzione: ambiente di laboratorio dedicato, con site server singolo, SQL supportato e snapshot o backup disponibili prima del change.