Windows Server 2025 / Creare una checklist pratica per la manutenzione del server

Una checklist di manutenzione utile verifica che gli utenti possano usare i servizi, che i dati siano ripristinabili e che le modifiche recenti non abbiano effetti indesiderati. Per ogni controllo definite risultato atteso, frequenza, prova da conservare, responsabile e azione in caso di errore: una casella spuntata da sola non dimostra che il server funzioni correttamente.

Definire il funzionamento normale per ruolo

Preparate un inventario per server con nome, indirizzo IP, ruoli, responsabile, dipendenze, accesso amministrativo e destinazione dei backup. Per ogni ruolo descrivete un’operazione normale da un client rappresentativo e il suo risultato atteso. Una console raggiungibile o un servizio in esecuzione non dimostrano che autenticazione, file e applicazioni siano utilizzabili.

L’accesso al dominio con informazioni memorizzate nella cache può riuscire senza contattare un controller, quindi non basta per verificare Active Directory. Analogamente, un amministratore può accedere a una condivisione anche quando gli utenti ordinari incontrano problemi di autorizzazione. Scegliete un account e un percorso rappresentativi senza aumentare i privilegi per far riuscire il test. Un rifiuto atteso è significativo solo se la stessa risorsa funziona per l’utente autorizzato.

Programmare controlli giornalieri, settimanali e mensili

Le frequenze della tabella sono esempi da adattare alle conseguenze di un’interruzione e alla rapidità dei cambiamenti. Un backup fallito o un certificato vicino alla scadenza non devono attendere il controllo mensile se servizio o recupero sono a rischio. Definite destinatario dell’avviso, termine di risposta e contatto a cui inoltrarlo se nessuno interviene. Se un controllo non è stato eseguito, indicatelo come non effettuato o in sospeso; non riportate un risultato precedente come nuova osservazione.

Raccogliere lo stato di base e verificare i ruoli

Eseguite queste query in Windows PowerShell sul server previsto, con i diritti di lettura necessari e privilegi elevati quando richiesti dai registri. Verificate prima il nome restituito e annotate orario e fuso orario. I comandi mostrano informazioni: non creano un rapporto e non provano il funzionamento di tutti i ruoli. Salvate ogni esecuzione secondo la vostra procedura di rendicontazione in un percorso protetto, identificando server e istante senza sovrascrivere le prove precedenti:

hostname
Get-CimInstance Win32_OperatingSystem | Select-Object LastBootUpTime
Get-Volume | Select-Object DriveLetter,FileSystemLabel,Size,SizeRemaining
Get-WinEvent -FilterHashtable @{LogName='System';StartTime=(Get-Date).AddDays(-1);Level=1,2} -MaxEvents 30

La seconda riga mostra l’ultimo avvio. In Get-Volume, Size e SizeRemaining sono valori in byte. Confrontate spazio libero, capacità, crescita e necessità di aggiornamenti e backup; calcolate una percentuale solo se Size è maggiore di zero. Un volume privo di lettera non è automaticamente guasto: non modificate le partizioni per questo motivo. L’ultima riga legge solo System, livelli 1 e 2 —critico ed errore— nelle ultime 24 ore, con un massimo dei 30 eventi più recenti. Esclude avvisi, Application e altri canali dei ruoli. La documentazione di Get-WinEvent indica che i permessi possono impedire la lettura: distinguete il fallimento della query dall’assenza di corrispondenze. Conservate provider, ID, orario e messaggio; ampliate intervallo o limite se manca l’inizio dell’incidente. L’assenza di eventi restituiti non garantisce un sistema senza problemi; un servizio arrestato può essere normale se ha avvio manuale o attivato da trigger.

Sui controller controllate DNS e la diagnostica della replica AD, inclusi partner, ultimo successo ed errori, senza forzare sincronizzazioni o cambiare DNS come attività di routine. Per DHCP consultate le statistiche degli ambiti IPv4 sul server corretto e confermate un lease da un client di prova autorizzato. Non rilasciate l’indirizzo di un computer in uso soltanto per un controllo. Per i backup, verificate le versioni nella destinazione effettiva e il computer di origine: l’elenco senza destinazione può includere copie non più disponibili. Una voce di catalogo non dimostra un ripristino. Aggiungete solo controlli dei ruoli installati, senza installare moduli o servizi superflui per eseguire tutti i comandi.

Registrare prove e attività successive

Su FS1 una condizione di prova può essere «dal client con sales.user1 leggere e scrivere un proprio file in Sales; accesso a Support negato». Se anche Sales non funziona, non considerate corretto il rifiuto di Support senza controllare connettività e autenticazione. Collegate il problema a prove, responsabile e scadenza, poi ripetete entrambe le verifiche nello stesso contesto. Per il recupero usate il ripristino di file in una posizione separata e registrate il risultato reale, senza inventare durate o test riusciti.

Per password, token e chiavi di recupero annotate soltanto il riferimento alla posizione sicura, mai il segreto nel foglio o nel rapporto. Proteggete anche i registri con account, percorsi e indirizzi interni. Distinguete esecuzione dello script riuscita, backup dichiarato riuscito e ripristino utilizzabile effettivamente verificato. Gli errori ripetuti non diventano normali: mantenete responsabile, scadenza e condizione per rivedere ogni eccezione.

Verificare nuovamente dopo le modifiche

Dopo aggiornamenti o modifiche a rete, autorizzazioni, certificati e archiviazione, ripetete l’operazione utente e la misura di riferimento interessate. Prima della modifica documentate valori iniziali, procedura di recupero e accesso alla console se l’amministrazione remota non funziona più. Applicate un cambiamento pianificato e circoscritto alla volta. Se il risultato peggiora, fermatevi, valutate l’impatto e usate la procedura di annullamento approvata, senza accumulare altre modifiche.

• Ripristinate in una posizione separata e controllate dati, elenchi di controllo di accesso (ACL) e durata. Potete così confrontare contenuto e permessi senza sostituire l’originale.
• Considerate il guasto di host o archiviazione condivisi anche con più macchine virtuali. Due server sullo stesso supporto non garantiscono indipendenza da quel guasto.
• Dopo il rinnovo di un certificato, verificate dal client che il servizio presenti quello nuovo per il nome corretto e con catena valida. Il rinnovo nell’archivio non dimostra che l’associazione del servizio sia stata aggiornata.
• Prima di dismettere account, regole o criteri, individuate servizi, attività e utenti dipendenti. Conservate stato iniziale e procedura di annullamento e ripetete il controllo dopo la modifica.

Aggiornate la checklist quando cambiano ruoli, server o responsabili. Un nuovo servizio richiede una verifica funzionale e un metodo di recupero; quando dismettete un server, chiudete esplicitamente monitoraggio e accessi e decidete la conservazione dei backup secondo la politica prevista. Non eliminate l’ultima copia utile solo perché il server scompare dall’inventario. Chiudete una segnalazione quando la verifica pertinente torna al risultato atteso e la decisione è documentata.