Migrazione file server virtuale da Windows Server 2008 R2 a Windows Server 2019

In questo post raccoglierò alcune note derivate da una recente migrazione di un file server virtuale Windows Server 2008 R2 a Windows Server 2019. Lo scenario di migrazione era il seguente:

  • Vecchio file server:
    • Nome SRVFS01
    • OS: Windows Server 2008 R2
    • Disco virtuale dedicato per i file condivisi
  • Nuovo file server:
    • Nome SRVFS02
    • OS: Windows Server 2019
    • Disco virtuale dedicato per i file condivisi

Entrambi i server erano membri di Active Directory.

Per quanto riguarda il deploy del nuovo file server SRVFS02 si è proceduto come segue:

  • Creazione della VM configurandola solo con il disco dedicato al sistema operativo
  • Installazione del sistema operativo Windows Server 2019 e aggiornamento del sistema con gli ultimi aggiornamenti disponibili
  • Copia del disco virtuale contente i file condivisi del vecchio file server SRVFS01 e collegamento della copia del disco alla VM del nuovo file server SRVFS02

Per ricreare le share sul nuovo file server è possibile procedere all’esportazione delle chiavi di registro contenenti le impostazioni delle share sul vecchio file server e importarle sul nuovo file server come indicato nella KB125996 Saving and restoring existing Windows shares. Le impostazioni riguardanti le share sono contente nella chiave di registro HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares, mentre le impostazioni di sicurezza delle share sono memorizzate nella chiave di registro HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares\Security.

Dopo l’importazione delle impostazioni delle share sul nuovo file server occorre creare una share di test che potrà poi essere eliminata per consentire al sistema di eseguire le configurazioni necessarie al ruolo Servizi file e archiviazione.

Nel caso in cui il vecchio file server era utilizzato da sistemi legacy ancora da dismettere come Windows Server 2003/XP potrebbe essere necessario abilitare sul nuovo file server anche l’SMB v1, a riguardo si veda How to detect, enable and disable SMBv1, SMBv2, and SMBv3 in Windows. Per abilitare l’SMB 1.0 / CIFS Client e l’SMB 1.0 / CIFS Server è possibile utilizzare l’interfaccia grafica o i comandi powershell:

Enable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

Set-SmbServerConfiguration -EnableSMB1Protocol $false

Ovviamente quando vengono dismessi i sistemi legacy occorre disabilitare l’SMB 1 per ridurre la superficie di attacco.

Per quanto riguarda la risoluzione del nome del file server è conveniente avere un record CNAME su DNS che punti al nome reale del file server in questo modo una volta corretto il record CNAME i client della rete punteranno al nuovo file server, nel caso in cui un record CNAME non fosse stato definito in precedenza è comunque utile crearlo perché così future migrazioni saranno più semplici.

Nel caso in cui sia necessario accedere al nuovo file server con il nome DNS del vecchio file server occorrerà eliminare l’account computer del vecchio file server da Active Directory e creare un record CNAME faccia puntare al nuovo file server tramite il nome del vecchio file server.

Ovviamente è anche conveniente utilizzare il servizio DFS che permette di evitare l’utilizzo del nome del file server per accedere alle share.

Vi sono più casi in cui alcuni host accedevano al vecchio file server mediante NetBios, in questo caso può essere necessario configurare il nuovo file server a rispondere al nome/i NetBios del vecchio file server impostando la chiave di registro HKLM\System\CurrentControlSet\Services\LanManServer\Parameters\OptionalNames, a riguardo si veda anche la KB2965564 Errors when you connect to a shared printer by using a CNAME record in Windows.

In caso di problemi ad accedere tramite il nome NetBios potrebbe anche essere necessario impostare a 1 il valore REG_DWORD DisableStrictNameChecking in HKLM\System\CurrentControlSet\Services\LanManServer\Parameters (nel caso il valore non esista occorrerà crearlo), a riguardo si veda la KB3181029 SMB file server share access is unsuccessful through DNS CNAME alias e Add DisableStrictNameChecking Registry Key.

Nel caso fosse necessario è possibile configurare su un sistema più nomi DNS tramite il valore REG_MULTI_SZ AlternateComputerNames nella chiave di registro HKLM\System\ CurrentControlSet\Services\DNSCache\Parameters.

Inoltre per la gestione dei nomi DNS e dei record DNS relativi al Kerberos Service Principal Name (SPN) è anche possibile ricorrere al comando Netdom computername a riguarda si veda Using Computer Name Aliases in place of DNS CNAME Records.

Sempre a riguardo dei nomi alternativi DNS e NetBios si veda anche il post Multiple Server Names on Windows.