Com migrar perfils d’usuari amb USMT

Migrar perfils d’usuari amb USMT (User State Migration Tool) sembla, en teoria, una tasca ben resolta. Microsoft dona eines, hi ha documentació i receptes diverses arreu. Però si ho has fet en producció —de veritat—, saps que està ple de zones grises: coses que no es migren com un espera, errors difícils de rastrejar, diferències subtils entre versions de Windows, i decisions petites que acaben tenint un impacte molest.

Perquè continuar fent servir USMT el 2025?

USMT continua sent vàlid per a certs escenaris on es necessita control fi, especialment en migracions en bloc, imatges personalitzades o actualitzacions grans de parc. Eines comercials més modernes (com ProfileUnity, ForensiT, Zinstall o fins i tot Intune en escenaris cloud) estan bé per a entorns concrets, però no sempre substitueixen el control que USMT et dona. Si ja estàs a Microsoft Endpoint Manager, probablement no estiguis llegint això. Però si treballes amb domini on-prem, GPOs, entorns mixtos, o si necessites fer migracions netes sense arrossegar residus, USMT continua sent útil.

USMT: El mínim necessari per a fer-ho bé

USMT té dos executables clau: scanstate.exe i loadstate.exe. Es llencen des de línia de comandaments i requereixen privilegis elevats. El kit d’eines ve inclòs en l’ADK (Assessment and Deployment Kit) de Windows, que cal instal·lar des de la versió que coincideixi el més possible amb la versió de destinació.

Punt crític: fes servir sempre l’ADK de la versió més nova que vagis a tocar. Encara que sigui temptador fer servir el que ja tens a la màquina, si estàs migrant des de Windows 10 1909 a 22H2, instal·la l’ADK de 22H2. USMT és retrospectiu en compatibilitat, però no sempre cap endavant. Això preveu errors de càrrega en perfils moderns amb components que el vell USMT ni entén.

Quins perfils migrar, com, i per què no tots

Una de les decisions més importants és quins perfils migrar. Aquí és on molts cometen el primer error: pensar que n’hi ha prou amb fer servir /all i confiar.

Si fas servir /all, t’emportes també els perfils per defecte, els de servei, o fins i tot perfils corruptes. Alguns perfils trencats poden provocar errors silenciosos en loadstate, o pitjor encara, perfils buits que es carreguen sobre usuaris vàlids.

Recomanació pràctica: fes servir el modificador /ui:domini\usuari per cada perfil que t’interessi i teingues sempre una llista clara abans de començar. Si automatitzes, genera aquesta llista amb un script PowerShell que filtri perfils no actius en els darrers X dies, i sempre deixa fora:

• Default
• Grup d’aplicacions per defecte
• Public
• Administrator (llevat que tinguis un motiu clar)
• Perfils temporals (TEMP, TEMP. DOMINI)

Exemple de comandament bàsic per escanejar només certs perfils:

scanstate \\server\usmtstore /i:miguser.xml /i:migapp.xml /v:13 /c /o /uel:30 /ui:DOMINI\usuari1 /ui:DOMINI\usuari2 /hardlink /nocompress

Sobre els XML: edítals o prepara’t per a sorpreses

Els arxius miguser.xml, migapp.xml i migdocs.xml no són sagrats. Són plantilles. Fer-les servir sense revisar és un altre error comú. Per exemple:

• miguser.xml no migra contingut fora del perfil de l’usuari tret d’excepcions concretes.
• Si tens redirecció de carpetes en ús, Documents i companyia poden estar a D:\Usuaris o en un DFS. USMT no els toca per defecte.
• migapp.xml rara vegada compleix el que promet amb configuracions d’aplicacions específiques. No migra claus de registre de tercers ben organitzades a HKLM\Software\Vendor\… llevat que ho ajustis.

Modifica aquests arxius segons el teu entorn real. Si fas servir aplicacions que guarden dades en ubicacions no estàndard (per exemple, AutoCAD en %APPDATA%\Autodesk, o configuracions d’eines pròpies en HKCU\Software\NomApp), afegeix-les tu. Microsoft no ho farà per tu.

Un bloc típic que podem afegir quan volem assegurar-nos que certes configuracions es migrin:

<component type="Documents">
  <include>
    <objectSet>
      <pattern type="File">%APPDATA%\VendorXYZ\*</pattern>
      <pattern type="File">%USERPROFILE%\Scripts\*</pattern>
      <pattern type="Registry">HKCU\Software\MiApp\*</pattern>
    </objectSet>
  </include>
</component>

I sí: en entorns reals, toca provar. Fes sempre almenys una migració de prova completa en un entorn el més semblant possible al real.

Hardlink: sí, però amb reserves

L’opció /hardlink accelera molt les migracions al lloc (refresh migrations), ja que no copia físicament els arxius fora del disc. Tot s’enllaça al mateix sistema d’arxius. Això redueix dràsticament el temps de migració i l’espai que es fa servir.

Ara bé, si has de reinstal·lar Windows des de zero (bare metal), oblida-ho. Tampoc facis servir hardlinks si hi ha sospites d’errors de sistema d’arxius, perfils corruptes, o discos amb sectors danyats. En aquests casos, és millor tenir una còpia separada i ben emmagatzemada.

Un altre problema comú: si combines /hardlink amb /nocompress, assegura’t que ningú esborri el contingut entre scanstate i loadstate. Pot passar en automatitzacions on l’instal·lador de Windows neteja el disc abans de restaurar.

Migrar a un domini nou: fes-ho explícit

Quan migres usuaris a un nou domini o un de renovat, has de fer servir /mu:oldDomain\user:newDomain\user en loadstate. Si no ho fas, USMT crearà el perfil com si fos nou, encara que tingui el SID vell migrat. Això acaba en doble perfil, normalment alguna cosa com:

• C:\Users\usuari
• C:\Users\usuari. DOMINI

Evitar-ho estalvia molt de temps després, especialment si hi ha scripts o GPOs que apunten a rutes absolutes.

Exemple de càrrega amb múltiples usuaris remapejats:

loadstate \\server\usmtstore /i:miguser.xml /i:migapp.xml /v:13 /c /mu:DOMINIANTERIOR\usuari:DOMININOU\usuari /lac /lae

Problemes recurrents

• Error 27 (Invalid store path): sovint és una ruta mal escrita o un problema de permisos en xarxa. Assegura’t que scanstate i loadstate s’executen com a administrador amb accés a l’UNC.
• Arxius omesos: per una configuració per defecte. Fes servir /listfiles i revisa el que realment s’està emportant. No donis res per fet.
• Claus de registre que no es carreguen: moltes vegades, configuracions de programari estan sota HKLM i requereixen que USMT s’ executi en context de sistema. Fes servir  una tasca programada si és necessari.
• Migració parcial en perfils compartits: si diversos usuaris comparteixen estació, però només un migra, assegura’t de no sobreescriure perfils existents a la màquina de destí.

Automatització i scripting

No confiïs a fer-ho a mà si són més de cinc equips. L’habitual és tenir un script PowerShell o un batch que:

• Detecta els perfils actius.
• Llença scanstate amb paràmetres personalitzats.
• Guarda logs i estat.
• Després de la reinstal·lació, llença loadstate i genera un report.

També convé tenir un arxiu .csv amb el mapeig d’usuaris, especialment si hi ha canvis de domini o normalització de noms (usuari.joan → joan.petit).

Algunes decisions que solen fer-se per inèrcia i no convenen

• Fer servir el mateix XML per a tots els usuaris. Si hi ha diferents perfils de treball (enginyers, suport, finances), el normal és que no tots necessitin el mateix. Divideix.
• Ometre el log detallat. El paràmetre /v:13 genera força informació, però quan alguna cosa falla, és l’únic que ajuda.
• No netejar perfils abans de migrar. Usuaris amb 10 GB de caché de Teams o Dropbox inflen innecessàriament els temps de còpia i provoquen fallades. Si pots, automatitza un script de neteja prèvia.

Què fer amb OneDrive i els perfils al núvol

USMT no es porta bé amb OneDrive sincronitzat. No perquè no pugui copiar els arxius, sinó perquè moltes vegades migra carpetes físiques que després es barregen amb les sincronitzades del nou inici de sessió, i acabes amb duplicats o conflictes. Això es torna especialment problemàtic si OneDrive està fent servir el mode Files On-Demand, on hi ha punters a arxius al núvol que no estan realment en disc.

La millor pràctica en aquests casos és excloure la carpeta de OneDrive explícitament de l’XML. Pots fer-ho així:

<exclude>
  <objectSet>
    <pattern type="File">%USERPROFILE%\OneDrive\*</pattern>
  </objectSet>
</exclude>

I després que l’usuari torni a sincronitzar després del login, si cal.

Una altra opció que podem fer servir en entorns mixtos és deixar que OneDrive ho gestioni tot excepte les dades locals que l’usuari hagi guardat fora de les carpetes sincronitzades. Això requereix deixar molt clar als usuaris què es migra i què no.

Què passa amb l’Start Menu, Taskbar i altres “moderns”?

Des de Windows 10 1709 en endavant, Microsoft va començar a distribuir certes configuracions (com el layout del menú inici, barra de tasques, configuracions d’apps modernes) en estructures internes i en el compte Microsoft de l’usuari, si està associada. USMT no sempre les captura.

El layout del menú, per exemple, està a:

• %LOCALAPPDATA%\TileDataLayer (antic)
• %APPDATA%\Microsoft\Windows\Start Menu
• I en alguns casos, fins i tot en bases de datos SQLite sota  %LOCALAPPDATA%\Packages

Migrar això de forma confiable no sempre val la pena. El més pràctic pot ser fer servir polítiques o scripts posteriors per configurar un layout base, i deixar que l’usuari el personalitzi si vol. Intentar arrossegar aquests ajustos sovint genera frustració, especialment quan apareixen duplicats d’accessos directes, apps que ja no existeixen, o tiles que no es poden esborrar.

Checklist previ

Abans de llençar qualsevol migració amb USMT en producció, repassa:

• Els perfils que vas a migrar estan actius i no són temporals?
• Tens accés complet a C:\Users en origen i destí?
• Les rutes UNC estan accessibles des de WinPE (si estàs fent bare metal)?
• Els XML reflecteixen exactament el que vols migrar?
• Tens backups o snapshots previs? Si alguna cosa surt malament, ho agrairàs.
• Estàs fent servir /c per continuar davant d’errors no crítics?
• Tens logs guardats per màquina?

I una que s’oblida molt: estàs migrant credencials? Per defecte, USMT no migra ni certificats ni credencials emmagatzemades al Credential Manager. Això afecta sobretot usuaris amb mapatges de xarxa persistents, connexions VPN o certificats de correu digital. Si són crítics, documenta com recuperar-los després.

Eines auxiliars que complementen bé a USMT

• CloneApp (per Mirinsoft): útil per a aplicacions que no migren bé amb USMT (ex. Notepad++, VLC, etc.). En casos puntuals és útil.
• USMT GUI wrappers com User Profile Wizard (de ForensiT): permeten gestionar SID mapping de forma més neta, tot i que no sempre són compatibles amb hardlink.
• PowerShell DSC o scripts de postconfiguració per a apps, layout, printers i altres. Intentar migrar-ho tot amb USMT és temptador però contraproduent.
• Sysinternals AccessChk per revisar permisos abans/després de la migració. Hi ha perfils migrats que perden l’herència NTFS sense motiu aparent.

USMT com a part d’un procés, no com a solució màgica

L’eina fa la seva part, però no és infal·lible. Molts dels problemes que podem trobar no es deuen a fallades d’USMT, sinó a expectatives mal plantejades. Pensar que es pot fer una migració perfecta i silenciosa dels usuaris sense ajustar res, és ingenu. Hi ha moltes variables fora de l’abast d’USMT: redireccions, sincronització al núvol, polítiques de grup, programari que guarda dades en rutes no estàndard, perfils corruptes, SIDs orfes, etc.

Sempre convé veure USMT com una fase dins d’un procés més gran:

• Preparació prèvia: identificar perfils, netejar, planificar l’ entorn destí.
• Extracció: scanstate amb logs detallats, revisió per mostres.
• Reinstal·lació o migració de sistema.
• Restauració: loadstate, verificació manual i automàtica.
• Postconfiguració: apps, credencials, printers, mapejos, etc.
• Documentació i seguiment.

Migrar és més que copiar perfils

Migrar perfils no és només moure dades. És mantenir continuïtat per a l’usuari, que espera tornar a encendre el seu equip i veure “tot com abans”. USMT ajuda, però no és una vareta màgica. El que funciona millor és assumir que part de la feina no la pot fer cap eina: cal conèixer l’entorn, entendre què espera l’usuari, i tenir procediments sòlids per al que no es migra.

Si has de fer servir USMT, fes-ho bé. Prent-te el temps per preparar els XML, automatitza el que puguis, i no intentis migrar més del que té sentit. El que no es migra bé, sovint és millor recrear-lo net.

I com sempre: prova, prova i torna a provar abans de tocar producció.