Condividi tramite

Testare la migrazione

Testare sempre il piano di migrazione in un'impostazione di laboratorio controllato prima di distribuirlo nell'intera organizzazione. Nell'ambiente di test è necessario almeno un computer per ogni tipo di sistema operativo da cui viene eseguita la migrazione dei dati.

Dopo aver testato l'intero processo di migrazione in un singolo computer che esegue ognuno dei sistemi operativi di origine dell'organizzazione, eseguire una migrazione pilota con un piccolo gruppo di utenti. Dopo aver migrato alcuni stati utente tipici nell'archivio intermedio, prendere nota dello spazio necessario e modificare i calcoli iniziali di conseguenza. Per informazioni dettagliate sulla stima dello spazio necessario per la migrazione, vedere Stimare le dimensioni dell'archivio migrazione. Le informazioni sull'impostazione del Registro di sistema e sulla posizione dei file potrebbero dover essere modificate nei file delle regole di migrazione. Se vengono apportate modifiche, testare di nuovo la migrazione e verificare che tutti i dati e le impostazioni siano stati migrati come previsto. Una migrazione pilota offre anche l'opportunità di testare le stime dello spazio per l'archivio intermedio.

Se la migrazione di test rileva errori, esaminare i log ScanState e LoadState per ottenere il codice restituito usmt (User State Migration Tool) esatto e i messaggi di errore associati o il messaggio di errore API (Application Programming Interface) di Windows. Per altre informazioni sui codici restituiti USMT e sui messaggi di errore, vedere Codici restituiti. Per altre informazioni sui codici di errore di sistema di Windows elencati, digitare quanto segue in una finestra del prompt dei comandi:

net.exe helpmsg <error_number>

dove <error_number> è il numero di codice di errore generato dal messaggio di errore. Per altre informazioni sui codici di errore di sistema, vedere Codici di errore di sistema (0-499).

Nella maggior parte dei casi, i log ScanState e LoadState indicano il motivo per cui una migrazione USMT ha esito negativo. Microsoft consiglia di usare l'opzione durante il /v:5 test della migrazione. Questo livello di dettaglio può essere regolato in una migrazione di produzione. La riduzione del livello di dettaglio potrebbe rendere più difficile diagnosticare gli errori riscontrati durante le migrazioni di produzione. È possibile usare livelli di dettaglio più elevati se i file di log devono essere restituiti per passare a un debugger.

Nota

L'esecuzione degli strumenti ScanState e LoadState con l'opzione /v:5 crea un file di log dettagliato. Anche se questa opzione rende il file di log di grandi dimensioni, è utile per determinare dove si sono verificati errori di migrazione.

Dopo aver verificato che la migrazione pilota ha eseguito correttamente la migrazione dei file e delle impostazioni specificati, USMT è pronto per essere usato nell'ambiente per la migrazione dei dati. Ad esempio, usando USMT con Microsoft Configuration Manager. Per altre informazioni, vedere [Gestire lo stato utente in Configuration Manager]/(mem/configmgr/osd/get-started/manage-user-state).

Nota

A scopo di test, è possibile creare un archivio non compresso che usa l'opzione /hardlink /nocompress . Quando la compressione è disabilitata, lo strumento ScanState salva i file e le impostazioni in una cartella nascosta denominata File in <StorePath>\USMT. L'archivio non compresso può essere usato per visualizzare l'archivio USMT archiviato o per risolvere un problema. È anche possibile eseguire un'utilità antivirus sui file. Inoltre, è possibile usare gli elementi seguenti per risolvere i problemi relativi alla migrazione:

  • Opzione /listfiles della riga di comando.
  • Log di diagnostica che elenca i file raccolti.