Guía de perfiles de usuario de Windows - AppData y NTUSER.DAT

Este artículo resume, con carácter general, información dirigida a los departamentos de sistemas que administran Windows, a los responsables del despliegue de equipos y a los desarrolladores de aplicaciones para Windows. Los diagramas son esquemas conceptuales. En entornos Markdown compatibles con Mermaid se mostrarán como diagramas.

El contenido se basa en información oficial de Microsoft disponible hasta abril de 2026. [1][4][7][10][13][14]

Guía de lectura

Es un artículo largo, así que primero dejamos un punto de entrada según cada perfil.

En las consultas sobre Windows, la palabra «perfil» se usa con un alcance bastante amplio.

• Qué hay dentro de C:\Users\nombre de usuario
• Cómo se debe repartir el uso entre %AppData% y %LocalAppData%
• Qué es un perfil móvil en un entorno de dominio
• Qué diferencia hay entre un perfil Mandatory y un perfil Temporary
• Qué se debe elegir en un PC compartido, RDS, VDI o Azure Virtual Desktop
• Por dónde empezar a mirar cuando un perfil se corrompe

En este punto se mezclan de golpe la cuenta, la carpeta, el registro, el método de sincronización y la política operativa, por lo que la conversación se desvía enseguida.

En este artículo colocamos primero una perspectiva para ver el perfil de usuario de Windows como un único plano de diseño, y a partir de ahí ordenamos, en orden, el uso de AppData, el perfil móvil, Mandatory, Temporary, FSLogix y cómo interpretar los problemas.

1. Conclusión, primero

Antes de entrar en detalle, dejamos por delante las conclusiones prácticas.

• El perfil de usuario de Windows no es simplemente la carpeta C:\Users\nombre de usuario. Es el conjunto de archivos + la hive de registro de usuario (NTUSER.DAT). [1]
• En un PC local normal, de forma predeterminada se crea un perfil local. En el primer inicio de sesión se crea un perfil nuevo tomando C:\Users\Default como base. [11][12]
• No conviene decidir a la ligera dónde guarda datos una aplicación: como norma básica, la configuración que se desea llevar consigo por usuario va en %APPDATA%, y la caché o el estado temporal específico de ese equipo va en %LOCALAPPDATA%. [2][3]
• El perfil móvil es el mecanismo que «lleva todo el perfil a un recurso compartido», y Folder Redirection es el mecanismo que «lleva solo carpetas conocidas, como Documents, a otra ubicación»; no son lo mismo. [4][5]
• El perfil Mandatory es un perfil de solo lectura pensado para «dejar usarlo, pero no dejar guardar cambios». El perfil Temporary es una vía de escape ante errores, que se da por hecho que se elimina cada vez. [7][8][9]
• Hay que tener cuidado con los perfiles móviles que cruzan generaciones de sistema operativo. Windows 10 / Server 2016 en adelante son incompatibles con versiones anteriores, por lo que conviene partir de la base de tratar las versiones de perfil por separado. [6]
• En RDS, VDI y Azure Virtual Desktop, en muchos casos resulta mejor considerar como primera opción el contenedor de perfil de FSLogix, en lugar de forzar el uso exclusivo del perfil móvil tradicional. Microsoft también recomienda FSLogix para Azure Virtual Desktop. [13][14]
• Ante un problema, antes de tocar C:\Users directamente, suele ser más acertado revisar el registro Application, los registros Operational / Diagnostic de User Profile Service, la ruta compartida y los atributos y permisos de NTUSER.DAT / USRCLASS.DAT. [10][11][16]

En resumen, el tema de los perfiles de Windows se reduce a «dónde se coloca cada cosa, hasta dónde se lleva consigo y cómo se recupera cuando falla».

1.1 Siglas usadas en este artículo

Aquí desarrollamos las siglas que aparecen desde el principio.

2. Qué es, en primer lugar, el «perfil de usuario» de Windows

Al principio conviene separar la cuenta del perfil.

flowchart LR
    accTitle: Relación entre la cuenta de usuario y el perfil de usuario
    accDescr: Diagrama que muestra cómo la cuenta de usuario y el equipo o sistema operativo dan lugar al perfil de usuario, y cómo este se traduce en la configuración del escritorio, AppData, carpetas como Documents o Desktop, y la configuración visible en HKCU.
    A[Cuenta de usuario<br/>quién inicia sesión] --> B[Perfil de usuario<br/>configuración y datos de esa persona]
    C[Equipo / SO] --> B
    B --> D[Configuración del escritorio]
    B --> E[AppData]
    B --> F[Documents / Desktop, etc.]
    B --> G[Configuración visible en HKCU]

• La cuenta es lo que identifica a alguien
• El perfil es el entorno de trabajo concreto de esa persona
• El equipo es el lugar donde se carga y se usa ese perfil

En Microsoft Learn también se explica que el perfil de usuario incluye el conjunto de carpetas de perfil en el sistema de archivos y la hive de registro NTUSER.DAT, y que, al iniciar sesión, esta hive se carga y se utiliza como HKEY_CURRENT_USER. [1]

2.1 No es «solo carpetas»: también incluye el registro

Este es el punto importante.

flowchart TD
    accTitle: Flujo de carga del perfil durante el inicio de sesión
    accDescr: Diagrama que muestra cómo, al iniciar sesión, se identifica la carpeta de perfil, se carga NTUSER.DAT como HKCU y se preparan Desktop, Documents y AppData, hasta que la configuración de usuario queda activa.
    A[Inicio de sesión] --> B[Se identifica la carpeta de perfil]
    B --> C[Se carga NTUSER.DAT]
    C --> D[Se usa como HKCU]
    B --> E[Se preparan Desktop / Documents / AppData]
    D --> F[La configuración de usuario queda activa]
    E --> F

Es decir, con solo mirar C:\Users\nombre de usuario todavía se ve la mitad.

El perfil de Windows tiene, a grandes rasgos, estas dos capas:

1. Capa de archivos Desktop, Documents, Downloads, AppData, etc.
2. Capa de registro El HKCU que resulta de cargar NTUSER.DAT

Lo que complica el tema de la corrupción de perfiles es que puede haber casos en los que solo se daña el lado de las carpetas y casos en los que el problema aparece en la hive de registro. [1][11]

2.2 En el primer inicio de sesión, Default sirve de base

Cuando un usuario nuevo inicia sesión por primera vez en ese equipo, Windows crea el perfil local tomando C:\Users\Default como base. [11]

flowchart LR
    accTitle: Creación del perfil a partir de Default en el primer inicio de sesión
    accDescr: Diagrama que muestra cómo, a partir de C:\Users\Default, el primer inicio de sesión genera C:\Users\nombre de usuario, se carga NTUSER.DAT y el resultado es un entorno propio de ese usuario.
    A[C:\Users\Default] --> B[Primer inicio de sesión]
    B --> C[Se genera C:\Users\nombre de usuario]
    C --> D[Se carga NTUSER.DAT]
    D --> E[Se convierte en el entorno propio de ese usuario]

Si en el contexto de despliegue de imágenes o de preparación de equipos (kitting) se trata este punto de forma descuidada, más adelante puede volverse bastante problemático.

Microsoft explica que, para personalizar el perfil predeterminado, el método compatible es usar CopyProfile. Copiar a mano o replicar de forma tradicional y descuidada puede introducir información innecesaria y causar problemas de estabilidad en las aplicaciones o el sistema. [12]

3. Cómo interpretar C:\Users\nombre de usuario

Visto desde el lado de las carpetas, el perfil de usuario tiene, a grandes rasgos, esta estructura:

flowchart TD
    accTitle: Estructura de carpetas del perfil de usuario
    accDescr: Diagrama que muestra cómo, bajo C:\Users\nombre de usuario, se ubican Desktop, Documents, Downloads, Pictures, AppData y NTUSER.DAT, y cómo AppData se divide en Roaming, Local y LocalLow.
    A["C:\Users\nombre de usuario"] --> B[Desktop]
    A --> C[Documents]
    A --> D[Downloads]
    A --> E[Pictures]
    A --> F[AppData]
    A --> G[NTUSER.DAT]
    F --> H[Roaming]
    F --> I[Local]
    F --> J[LocalLow]

En la práctica, los lugares que primero se revisan son, más o menos, estos:

3.1 Pensar AppData dividido en tres

En el desarrollo de aplicaciones Windows y en la investigación de problemas, este es el punto donde más se mezclan las cosas.

La guía de Microsoft recomienda usar FOLDERID_RoamingAppData (Roaming AppData) para los datos propios de la aplicación, y FOLDERID_LocalAppData para archivos temporales o datos que no se deben usar en otro equipo. [2]

Además, en la definición de las Known Folders, las rutas predeterminadas se organizan así: [3]

• %APPDATA% = %USERPROFILE%\AppData\Roaming
• %LOCALAPPDATA% = %USERPROFILE%\AppData\Local
• LocalLow = %USERPROFILE%\AppData\LocalLow

flowchart LR
    accTitle: Los tres subtipos de AppData y su uso típico
    accDescr: Diagrama que muestra cómo AppData se divide en Roaming, Local y LocalLow, con Roaming para configuración que se quiere llevar consigo y estado de usuario pequeño, Local para caché, datos regenerables y estado específico del equipo, y LocalLow para el área en la que pueden escribir los procesos de integridad baja.
    A[AppData] --> B[Roaming]
    A --> C[Local]
    A --> D[LocalLow]

    B --> B1[Configuración que se quiere llevar consigo]
    B --> B2[Estado de usuario de tamaño pequeño]

    C --> C1[Caché]
    C --> C2[Datos regenerables]
    C --> C3[Estado propio de ese equipo]

    D --> D1[Área en la que pueden escribir los procesos de integridad baja]

LocalLow no es «un lugar que no se usa», sino «el sitio para aplicaciones con permisos bajos»

De los tres, LocalLow suele ser el que menos se explica, pero es solo porque su uso es especial: el motivo de su existencia está claro.

Los procesos de Windows tienen una clasificación de permisos llamada nivel de integridad (integrity level), y los procesos que se ejecutan con integridad baja no pueden escribir en AppData\Roaming, AppData\Local ni en la mayor parte de HKCU. Como así no podrían guardar nada, se ha preparado un lugar en el que sí se puede escribir incluso con integridad baja. Ese lugar es %USERPROFILE%\AppData\LocalLow, y del lado del registro, HKEY_CURRENT_USER\Software\AppDataLow. [19]

Resumiendo, queda así:

Un ejemplo representativo son las aplicaciones, como los navegadores, diseñadas para ejecutar deliberadamente con permisos reducidos la parte que maneja directamente contenido de Internet. La idea de diseño es que «aunque ese proceso llegue a ser comprometido, el alcance del daño quede confinado dentro de LocalLow».

La conclusión desde el punto de vista del desarrollo de aplicaciones es sencilla:

• Si su aplicación no se ejecuta con integridad baja, no hay motivo para usar LocalLow. Use Local.
• Al contrario, si aparecen en LocalLow carpetas poco familiares, lo que está escribiendo ahí es algo que se ejecuta con integridad baja. Es una pista útil al investigar el uso de espacio en disco.

Cómo pensar el reparto en la práctica

ProgramData también se define, en las Known Folders de Microsoft, como datos de aplicación para todos los usuarios, pensado para datos compartidos que no se sincronizan. [3]

Aquí, lo que más conviene evitar es colocar datos de ejecución específicos de cada usuario en Program Files. El orden del perfil y el diseño de permisos se desmoronan con facilidad.

3.2 Public y Default cumplen roles distintos

Aquí también es fácil confundirse.

flowchart LR
    accTitle: Diferencia de roles entre Default y Public
    accDescr: Diagrama que muestra cómo, bajo C:\Users, Default sirve de semilla para crear perfiles nuevos, Public es el recurso compartido visible para todos los usuarios y cada carpeta de usuario es la instancia real de esa persona.
    A["C:\Users"] --> B[Default]
    A --> C[Public]
    A --> D[Cada usuario]

    B --> B1[Semilla para crear perfiles nuevos]
    C --> C1[Recurso compartido visible para todos los usuarios]
    D --> D1[Instancia real de cada usuario]

• Default es la plantilla para crear perfiles nuevos
• Public es el área compartida que se muestra a todos los usuarios
• La carpeta de cada usuario es la instancia real de esa persona

Estos tres se parecen a primera vista, pero cumplen roles completamente distintos.

4. Cómo organizar los tipos de perfil

Aunque se hable de «perfil» en un único término, en la práctica operativa existen al menos estos tipos:

flowchart TD
    accTitle: Tipos de perfil de Windows
    accDescr: Diagrama que muestra cómo el perfil de Windows se divide en perfil local, perfil móvil, perfil Mandatory, perfil Temporary y contenedor de perfil de FSLogix.
    A[Perfil de Windows] --> B[Perfil local]
    A --> C[Perfil móvil]
    A --> D[Perfil Mandatory]
    A --> E[Perfil Temporary]
    A --> F[Contenedor de perfil de FSLogix]

4.1 Perfil local

En un PC normal, esto es lo predeterminado.

• Se crea en el disco local de ese equipo
• No se lleva de forma automática a otros equipos
• Es lo más sencillo en un PC individual

Microsoft también explica que, de forma predeterminada, Windows crea un perfil de usuario local. [14]

4.2 Perfil móvil (roaming)

Microsoft Learn indica que el perfil de usuario móvil se guarda en un recurso compartido de servidor, y permite recibir la misma configuración de sistema operativo y de aplicaciones en varios equipos. [4][5]

flowchart LR
    accTitle: Perfil móvil compartido entre varios equipos
    accDescr: Diagrama que muestra cómo el perfil almacenado en el servidor compartido se conecta en ambos sentidos con los equipos PC-A, PC-B y PC-C.
    A[Perfil en el servidor compartido] <--> B[PC-A]
    A <--> C[PC-B]
    A <--> D[PC-C]

Sin embargo, en la práctica hay que tener en cuenta estas advertencias:

• La copia o la sincronización al iniciar o cerrar sesión tiende a volverse pesada
• Si AppData\Local acumula datos grandes, se vuelve problemático
• Se ve afectado por diferencias entre versiones de sistema operativo
• Depende en gran medida de la ruta compartida y de la calidad de la red

4.3 Perfil Mandatory

El perfil Mandatory es un «perfil móvil que no guarda cambios», creado por el administrador. [7][8]

Según la explicación de Microsoft, en un perfil Mandatory, aunque el usuario haga cambios durante la sesión, estos no se guardan como ocurriría en un perfil móvil normal. [7]

Además, la documentación de Win32 explica que:

• Al renombrar NTUSER.DAT como NTUSER.MAN se convierte en Mandatory
• Al terminar el nombre de la carpeta de la ruta del perfil en .man se convierte en Super-mandatory

según se explica en la documentación. [8]

flowchart LR
    accTitle: Ciclo de un perfil Mandatory
    accDescr: Diagrama que muestra cómo, a partir de un perfil preparado por el administrador, el usuario inicia sesión, puede modificarlo durante el uso, cierra sesión y los cambios no se guardan.
    A[Perfil preparado por el administrador] --> B[El usuario inicia sesión]
    B --> C[Puede modificarlo mientras lo usa]
    C --> D[Cierra sesión]
    D --> E[Los cambios no se guardan]

Por ejemplo, es un método adecuado para usos como estos:

• Equipos educativos
• Equipos de recepción
• Quioscos
• Equipos compartidos en los que se quiere volver a un estado limpio cada vez

4.4 Perfil Temporary

El perfil Temporary no es algo que se elija por diseño, sino el destino de emergencia que aparece cuando un error impide cargar el perfil original. [9]

Microsoft Learn explica que, cuando una condición de error impide cargar el perfil original, se emite un perfil Temporary, que se elimina al finalizar la sesión y cuyos cambios se pierden. [9]

flowchart TD
    accTitle: Flujo de activación de un perfil Temporary
    accDescr: Diagrama de decisión que muestra cómo, al iniciar la carga del perfil normal, si se puede cargar se produce un inicio de sesión normal, y si no se puede, se inicia sesión con un perfil Temporary que permite trabajar pero pierde los cambios al cerrar sesión.
    A[Se inicia la carga del perfil normal] --> B{¿Se puede cargar?}
    B -->|Sí| C[Inicio de sesión normal]
    B -->|No| D[Inicio de sesión con perfil Temporary]
    D --> E[Se puede trabajar]
    E --> F[Los cambios se pierden al cerrar sesión]

Es decir, estar funcionando con un perfil Temporary es, en sí mismo, una señal de anomalía.

4.5 Contenedor de perfil de FSLogix

Microsoft Learn describe FSLogix como el mecanismo que hace consistente la experiencia del perfil de usuario de Windows en entornos de escritorio virtual. [13]

El contenedor de perfil de FSLogix es un método que mantiene el perfil de usuario completo como un VHD / VHDX, y lo monta (attach) al iniciar sesión para que se muestre como un perfil nativo. [13][14]

flowchart LR
    accTitle: Funcionamiento del contenedor de perfil de FSLogix
    accDescr: Diagrama que muestra cómo el perfil almacenado en un VHD o VHDX se monta al iniciar sesión, se ve como C:\Users\usuario en el host de sesión y se desmonta al cerrar sesión.
    A[Perfil en VHD / VHDX] --> B[Se monta al iniciar sesión]
    B --> C[Se ve como C:\Users\usuario en el host de sesión]
    C --> D[Se desmonta al cerrar sesión]

En Azure Virtual Desktop, Microsoft recomienda el uso de contenedores de perfil de FSLogix. [14]

5. Qué diferencia hay entre el perfil móvil, Folder Redirection y FSLogix

Estos tres suelen mencionarse como si fueran lo mismo, pero cumplen roles distintos.

flowchart TD
    accTitle: Tres formas de llevar consigo el estado del usuario
    accDescr: Diagrama que muestra cómo el objetivo de llevar consigo el estado del usuario se resuelve mediante el perfil móvil, que lleva todo el perfil a un recurso compartido, Folder Redirection, que lleva solo las carpetas conocidas, o FSLogix, que monta un VHD o VHDX.
    A[Llevar consigo el estado del usuario] --> B[Perfil móvil]
    A --> C[Folder Redirection]
    A --> D[FSLogix]

    B --> B1[Todo el perfil hacia un recurso compartido]
    C --> C1[Solo las carpetas conocidas hacia otra ubicación]
    D --> D1[Se monta un VHD/VHDX]

Siguiendo el criterio de Microsoft Learn, la diferencia se entiende mejor así: [4][5][14]

5.1 Folder Redirection solo desplaza «las carpetas conocidas»

Microsoft Learn explica que Folder Redirection es el mecanismo que redirige la ruta de una carpeta conocida (known folder) hacia otra ubicación. [4]

Por ejemplo, si se redirige Documents a un recurso compartido de archivos, el usuario lo ve igual que si fuera local, pero el contenido real está en otro lugar. [4]

flowchart LR
    accTitle: Ejemplo de redirección de carpetas conocidas
    accDescr: Diagrama que muestra cómo Documents tiene su contenido real en un recurso compartido de archivos, mientras que Desktop puede tener una configuración distinta si hace falta y AppData puede quedarse igual o usar otro método.
    A[Documents] --> B[El contenido real está en el recurso compartido]
    C[Desktop] --> D[Configuración distinta si hace falta]
    E[AppData] --> F[Se queda igual o usa otro método]

Es decir, Folder Redirection no sustituye al perfil completo, sino que reubica carpetas de forma individual.

5.2 No mezcle sin cuidado un perfil móvil entre distintas generaciones de sistema operativo

Microsoft explica que los perfiles móviles de Windows 10 / Server 2016 en adelante son incompatibles con versiones anteriores de Windows. [6]

flowchart LR
    accTitle: Incompatibilidad de versiones de perfil móvil entre generaciones de sistema operativo
    accDescr: Diagrama que muestra cómo Windows 7 y 8.1, y Windows 10 o Server 2016 en adelante, comparten el mismo recurso compartido con precaución de mezcla, lo que puede causar inconsistencias o errores en el menú Inicio o la barra de tareas.
    A[Windows 7 / 8.1] -.precaución al mezclar.-> B[Mismo recurso compartido]
    C[Windows 10 / Server 2016 en adelante] -.precaución al mezclar.-> B
    B --> D[Causa de inconsistencias, errores del menú Inicio o de la barra de tareas]

Aquí lo importante es:

• Separar la versión del perfil según la generación del sistema operativo
• No dar por hecho que «como es el mismo usuario, sirve la misma carpeta»
• En el despliegue o la renovación de equipos, incluir la compatibilidad de perfiles en el plan de migración

son los puntos clave a tener en cuenta. [6]

6. Ubicaciones de almacenamiento que desarrolladores y responsables de operación deben decidir de antemano

El tema del perfil termina volviendo siempre aquí: qué se guarda y dónde.

flowchart TD
    accTitle: Árbol de decisión para elegir dónde guardar los datos
    accDescr: Diagrama de decisión que, partiendo de los datos que se quieren guardar, pregunta si son un resultado creado por el usuario, si son específicos de ese equipo, si son configuración por usuario o si son datos variables compartidos por todos los usuarios, y en cada caso indica Documents, %LOCALAPPDATA%, %APPDATA%, ProgramData con ACL o reconsiderar la ubicación.
    A[Datos que se quieren guardar] --> B{¿Es un resultado creado por el usuario?}
    B -->|Sí| C[Documents, etc.]
    B -->|No| D{¿Es específico de ese equipo?}
    D -->|Sí| E[%LOCALAPPDATA%]
    D -->|No| F{¿Es configuración por usuario?}
    F -->|Sí| G[%APPDATA%]
    F -->|No| H{¿Son datos variables compartidos por todos los usuarios?}
    H -->|Sí| I[ProgramData + ACL]
    H -->|No| J[Reconsiderar la ubicación]

6.1 Separar los archivos que crea el usuario del estado interno de la aplicación

Si esto se mezcla, tanto las copias de seguridad como las migraciones tienden a romperse.

• Resultados que el usuario maneja de forma consciente Documents, Pictures, carpetas de almacenamiento de trabajo
• Estado interno de la aplicación Configuración, caché, miniaturas, información de sesión, archivos de trabajo

Lo primero son datos de negocio; lo segundo, cuestión de la propia aplicación. Aunque en ambos casos se trate de «archivos», conviene tratarlos de forma separada.

6.2 Qué colocar en %APPDATA%

Aquí se coloca, más o menos, esto:

• Configuración de tamaño pequeño
• Preferencias por usuario
• Estado que se quiere ver igual en varios equipos
• Todo lo que puede llevarse consigo junto con el perfil sin problema

La documentación de Fast User Switching también recomienda FOLDERID_RoamingAppData como ubicación para los datos propios de la aplicación. [2]

6.3 Qué colocar en %LOCALAPPDATA%

Aquí conviene desplazar lo que, desde el punto de vista de la regeneración y de si se lleva o no consigo, debe quedar confinado a lo local.

• Caché que se puede regenerar
• Estado que solo tiene sentido de forma local
• Archivos de trabajo grandes
• Todo lo que, por rendimiento, no interesa llevar consigo

En la definición de Known Folders, LocalAppData también corresponde a %USERPROFILE%\AppData\Local. [3]

6.4 Qué colocar en ProgramData

Los datos comunes a todos los usuarios, pero que cambian durante la ejecución, son candidatos para el lado de ProgramData. [3]

Por ejemplo:

• Diccionarios compartidos
• Archivos de definición comunes a todos los usuarios
• Datos variables compartidos entre el servicio y varios usuarios

Ahora bien, aquí hay que pensarlo incluyendo el diseño de la ACL. En lugar de «como es compartido, va a ProgramData sin más», es importante decidir quién lee y quién escribe.

6.5 Cuando se quiere personalizar el perfil predeterminado

En el despliegue de imágenes, es habitual querer que «todos los usuarios nuevos reciban la misma configuración inicial». En ese caso, lo más seguro es no tocar Default a la ligera, sino construirlo con el método basado en CopyProfile que Microsoft tiene soportado. [12]

flowchart LR
    accTitle: Flujo de personalización del perfil predeterminado con CopyProfile
    accDescr: Diagrama que muestra cómo, tras configurar el estado inicial con una cuenta de administrador, se ejecuta Sysprep con CopyProfile, se refleja en el perfil Default y ese resultado se aplica a los usuarios nuevos que se creen a partir de entonces.
    A[Configuración inicial con cuenta de administrador] --> B[Sysprep + CopyProfile]
    B --> C[Se refleja en el perfil Default]
    C --> D[Se aplica a los usuarios nuevos posteriores]

Hacer algo como «copiar a mano C:\Users\A de un equipo hacia Default en otro equipo» puede parecer rápido a simple vista, pero es fácil que termine rompiendo algo más adelante. [12]

7. Cómo interpretar un perfil corrupto, convertido en temporal o que no se sincroniza

Este es el punto donde más problemas surgen en la práctica. Además, como los síntomas se parecen entre sí, si la separación se hace de forma descuidada, es fácil acabar investigando demasiado a fondo en la dirección equivocada.

7.1 Primero, dividir el síntoma en tres

flowchart TD
    accTitle: Árbol de clasificación de síntomas de problemas de perfil
    accDescr: Diagrama de decisión que, partiendo de un posible problema de perfil, pregunta si se puede iniciar sesión, si el aspecto parece haberse reiniciado, y si solo parte de la configuración vuelve a su estado anterior, para clasificar entre fallo de carga, perfil Temporary o corrupción, problemas de perfil móvil o redirección, o un posible problema individual de la aplicación.
    A[Posible problema de perfil] --> B{¿Se puede iniciar sesión?}
    B -->|Sí| C{¿El aspecto parece haberse reiniciado?}
    B -->|No| D[Problema de tipo fallo de carga]
    C -->|Sí| E[Temporary / corrupción / otro perfil]
    C -->|No| F{¿Solo vuelve parte de la configuración?}
    F -->|Sí| G[Problema de tipo perfil móvil / redirección / sincronización]
    F -->|No| H[Posible problema individual de la aplicación]

A grandes rasgos, se dividen en estos tres grupos:

1. Falla al iniciar sesión
2. Se puede iniciar sesión, pero parece que se ha reiniciado
3. Solo una parte no se sincroniza

7.2 Los registros que conviene revisar primero

Microsoft Learn recomienda revisar, en la investigación de problemas de perfil, en este orden: [10]

1. Registro Application
2. Registro Operational de User Profile Service
3. Si hace falta, el registro Diagnostic
4. Si hace falta todavía más, el rastreo ETL

Las rutas concretas son las siguientes: [10]

• Visor de eventos (Event Viewer) Registros de aplicaciones y servicios > Microsoft > Windows > User Profile Service > Operational
• Para ver más detalle ... > User Profile Service > Diagnostic

En el Visor de eventos de la versión en japonés de Windows, el árbol de la izquierda se muestra como アプリケーションとサービス ログ > Microsoft > Windows > User Profile Service > Operational. A partir del nombre del proveedor, el texto permanece en inglés.

flowchart LR
    accTitle: Orden de escalado de los registros de diagnóstico
    accDescr: Diagrama que muestra el orden de revisión desde el registro Application, pasando por el registro Operational, el registro Diagnostic, hasta el rastreo ETL.
    A[Registro Application] --> B[Registro Operational]
    B --> C[Registro Diagnostic]
    C --> D[Rastreo ETL]

En la práctica, es más seguro usar el registro para identificar primero la dirección del problema (fallo de carga, fallo de copia, acceso denegado, ruta demasiado larga, no se puede escribir en el recurso compartido, etc.), en lugar de empezar directamente reparando el registro o eliminando carpetas.

Los tres registros están en «lugares distintos»

Este es el punto donde más se confunde uno al principio, así que lo organizamos antes de nada. [10]

El registro Diagnostic no aparece en el árbol tal cual. Hay que activar Vista > Mostrar registros de análisis y depuración, en la ventana Acciones del Visor de eventos, luego seleccionar Diagnostic y ejecutar Habilitar registro. Una vez terminada la investigación, hay que volver a desactivarlo sin falta. Es un registro demasiado detallado, y no es el tipo de registro que conviene dejar activado de forma permanente. [10]

Ver lo mismo sin abrir la interfaz gráfica

Cuando se quiere aumentar la reproducibilidad, o cuando se investiga un equipo remoto, es más fiable obtener la información por comando. En lugar de explicar la pantalla del Visor de eventos de palabra, resulta más rápido poder decir «ejecute este comando y envíeme el resultado».

# 1) Ver solo los eventos de User Profile Service del registro Application, del más reciente al más antiguo
Get-WinEvent -FilterHashtable @{
    LogName      = 'Application'
    ProviderName = 'Microsoft-Windows-User Profiles Service'
} -MaxEvents 50 | Select-Object TimeCreated, Id, LevelDisplayName, Message

# 2) Ver directamente el registro Operational
Get-WinEvent -LogName 'Microsoft-Windows-User Profile Service/Operational' -MaxEvents 50 |
    Select-Object TimeCreated, Id, LevelDisplayName, Message

# 3) Filtrar solo el Event ID 1509, causado por rutas demasiado largas
Get-WinEvent -FilterHashtable @{
    LogName      = 'Application'
    ProviderName = 'Microsoft-Windows-User Profiles Service'
    Id           = 1509
} | Format-List TimeCreated, Id, Message

Aquí hay una trampa. El nombre de origen del lado del registro Application es Microsoft-Windows-User Profiles Service (Profiles, en plural), mientras que el nombre de canal del registro Operational es Microsoft-Windows-User Profile Service/Operational (Profile, en singular). Cuando el copiar y pegar no funciona, casi siempre es por esto.

El Event ID 1509 aparece en el registro Application, no en el registro Operational. Su nivel es de advertencia, y el cuerpo del mensaje tiene la forma «Windows no puede copiar el archivo \\servidor\recurso\... a C:\Users\...», seguido de DETAIL - The filename or extension is too long.. Esta última línea es la que confirma que la causa es la longitud de la ruta. [16]

Hay otro dato que, en la práctica, ahorra tiempo. Microsoft indica de forma explícita que el evento 1530 de User Profile Service, «El archivo de registro todavía está siendo usado por otra aplicación o servicio», se puede ignorar. [10] Perseguir este evento suele ser en vano.

7.3 Causas habituales

Atributos o permisos de NTUSER.DAT / USRCLASS.DAT

Microsoft explica que, si NTUSER.DAT o USRCLASS.DAT tienen el atributo de solo lectura, o no cuentan con los permisos de acceso necesarios, la carga del perfil puede fallar. [11]

Es un detalle discreto, pero si se pasa por alto, el problema se alarga.

flowchart LR
    accTitle: Efecto del acceso al archivo DAT sobre la carga del perfil
    accDescr: Diagrama de decisión que muestra cómo, al cargar el perfil, si no se puede acceder al archivo DAT se produce un fallo de inicio de sesión, un escritorio inicial o un perfil Temporary, y si se puede acceder, se produce la carga normal.
    A[Carga del perfil] --> B{¿Se puede acceder al archivo DAT?}
    B -->|No| C[Fallo de inicio de sesión / escritorio inicial / Temporary]
    B -->|Sí| D[Carga normal]

Ruta demasiado larga al copiar en el perfil móvil

El KB de Microsoft explica casos en los que, porque el nombre del servidor o del recurso compartido en la ruta compartida es largo, la ruta completa de destino de la copia se vuelve demasiado larga, y esto provoca que se caiga a un perfil temporal junto con el Event ID 1509. [16]

Aunque parezca una simple restricción de longitud de ruta, en realidad a veces la causa está en el propio diseño del destino móvil.

Información de registro o de carpeta que queda tras una eliminación incompleta

Microsoft tiene un artículo con un script de ejemplo para limpiar la información huérfana que queda en el registro y en C:\Users, y evitar así perfiles TEMP. [15]

Esto deja claro que no basta con eliminar solo la carpeta.

flowchart LR
    accTitle: Cómo una eliminación descuidada provoca perfiles TEMP
    accDescr: Diagrama que muestra cómo eliminar un perfil antiguo de forma descuidada deja información en el registro, lo que provoca una inconsistencia en el siguiente inicio de sesión y termina en un perfil TEMP o carpetas adicionales.
    A[Eliminación descuidada de un perfil antiguo] --> B[Queda información en el registro]
    B --> C[Inconsistencia en el siguiente inicio de sesión]
    C --> D[Causa de perfil TEMP o carpetas adicionales]

7.4 Qué comprobar primero

8. Qué método conviene elegir

Aquí no hay «una única respuesta correcta». Depende de la forma de uso.

flowchart TD
    accTitle: Elección del método de perfil según la forma de uso
    accDescr: Diagrama que muestra cómo, según la forma de uso, un PC personal apunta a un enfoque local, un PC de trabajo unido a un dominio combina Folder Redirection o perfil móvil según necesidad, un PC compartido o educativo usa Mandatory, Shared PC o limpieza, y RDS, VDI o AVD tienen a FSLogix como primera opción.
    A[Forma de uso] --> B[PC de uso personal]
    A --> C[PC de trabajo unido a un dominio]
    A --> D[PC compartido / equipo educativo]
    A --> E[RDS / VDI / AVD]

    B --> B1[Enfoque principalmente local]
    C --> C1[Folder Redirection / perfil móvil según necesidad]
    D --> D1[Mandatory / Shared PC / limpieza]
    E --> E1[FSLogix como primera opción]

8.1 PC de uso personal

En general, basta con el perfil local.

• La configuración de usuario va en AppData
• Los resultados de trabajo van en Documents
• Si hace falta, la sincronización de documentos se resuelve en otra capa, como OneDrive

Esta configuración es la más sencilla.

8.2 PC de trabajo unido a un dominio

Según los requisitos, se combinan estos:

• Si se quiere gestionar de forma centralizada los datos de documentos → Folder Redirection
• Si además se quiere mantener la misma configuración en varios equipos → Perfil móvil
• Si hay mezcla de sistemas operativos o perfiles muy grandes → Diseño cuidadoso, o replantear el método

Microsoft Learn también indica que Folder Redirection y Roaming User Profiles ayudan a la centralización, al uso sin conexión y a facilitar las copias de seguridad. [4]

8.3 PC compartido / equipo educativo / quiosco

En este tipo de uso, más que «conservar la personalización individual», es importante volver cada vez a un estado limpio.

Los candidatos son estos tres:

• Perfil Mandatory
• Modo Shared PC
• Directiva de eliminación automática de perfiles antiguos

Microsoft tiene una directiva llamada Delete user profiles older than a specified number of days on system restart, que permite eliminar al reiniciar los perfiles que no se han usado en un número determinado de días. [17]

Además, la guía de Shared PC también plantea la idea de combinar la gestión y eliminación automática de cuentas y perfiles en equipos compartidos. [18]

8.4 RDS / VDI / Azure Virtual Desktop

Aquí hay muchos casos en los que el perfil móvil tradicional por sí solo resulta insuficiente.

Microsoft recomienda los contenedores de perfil de FSLogix para Azure Virtual Desktop, explicando que se monta el VHDX / VHD al iniciar sesión y se trata como un perfil de usuario nativo. [14]

flowchart LR
    accTitle: Arquitectura de FSLogix en varios hosts de sesión
    accDescr: Diagrama que muestra cómo varios hosts de sesión acceden a un almacenamiento compartido, donde reside el perfil de usuario en VHDX, y cómo este se monta en el host al que se conecta el usuario.
    A[Varios hosts de sesión] --> B[Almacenamiento compartido]
    B --> C[Perfil de usuario en VHDX]
    C --> D[Se monta en el host al que se conecta]

En particular, en condiciones como estas, vale la pena considerar FSLogix como primera opción:

• El host de sesión cambia cada vez
• Se usan Outlook, OneDrive o el conjunto de Microsoft 365
• Se necesita llevar el perfil consigo en un VDI no persistente
• El retraso al iniciar sesión con perfil móvil es un problema

9. Errores de interpretación habituales

9.1 «Si se crea la cuenta, el perfil también se usa igual en cualquier lugar»

No es así. La cuenta es un identificador; el perfil es la instancia concreta del lado del equipo. Hasta dónde se lleva consigo depende del método: local, móvil, Folder Redirection, FSLogix, etc. [4][14]

9.2 «Si se copia C:\Users\nombre de usuario, ya se puede migrar»

Una copia descuidada es peligrosa.

• La compatibilidad de versión de sistema operativo
• NTUSER.DAT
• Los permisos
• El estado propio de cada aplicación
• La posible mezcla con el perfil predeterminado

son motivos para ello. En particular, en un perfil móvil con diferencia de generación de sistema operativo, Microsoft también da por hecho que hay que separar las versiones del perfil. [6]

9.3 «Mandatory y Temporary son más o menos lo mismo»

Estos dos son cosas distintas. Mandatory es un perfil de solo lectura creado intencionadamente por el administrador; Temporary es el destino de emergencia cuando un error impide leer el perfil original. [8][9]

9.4 «Si se quiere sincronizar, basta con meterlo todo en Roaming»

Eso es arriesgado. Si se mete en la misma caja la configuración y una caché enorme, el inicio y el cierre de sesión, y el tratamiento ante fallos, se vuelven pesados. Conviene separar lo que se quiere sincronizar (Roaming) de lo que debe quedar confinado en Local. [2][3]

9.5 «Aunque se pase a un perfil temporal, se puede seguir usando tal cual»

Es mejor evitarlo. Como se da por hecho que el perfil Temporary desaparece al cerrar sesión, si se continúa trabajando en ese estado existe el riesgo de dejar datos importantes en un lugar que después desaparecerá. [9]

10. Resumen

El perfil de usuario de Windows no es simplemente una expresión para referirse a la carpeta bajo C:\Users.

• El conjunto de archivos
• El registro de usuario centrado en NTUSER.DAT
• El método operativo de dónde se guarda ese perfil, cómo se sincroniza y cómo se elimina

Si se piensa todo esto como un único diseño, la perspectiva se aclara.

En la práctica, conviene fijar de antemano estos seis puntos:

• En un PC individual, pensar primero en el perfil local como base
• Separar el destino de guardado de las aplicaciones entre Roaming / Local / ProgramData
• En un entorno de dominio, no confundir el perfil móvil con Folder Redirection
• En un equipo compartido, considerar Mandatory / limpieza / Shared PC
• En RDS / VDI / AVD, colocar FSLogix como primera opción
• Cuando algo se rompe, revisar primero el registro de User Profile Service

En definitiva, el diseño del perfil no consiste en «dónde guardarlo», sino en diseñar «de quién es cada cosa y hasta dónde se lleva consigo». Cuando esto está bien definido, el despliegue de equipos, el diseño de aplicaciones Windows y la investigación de problemas resultan mucho más sencillos.

11. Artículos relacionados

• ¿Cuándo hace falta el privilegio de administrador en Windows? UAC, áreas protegidas y cómo distinguirlo desde el diseño
• Cómo acelerar la validación del desarrollo de aplicaciones Windows con el Sandbox de Windows

12. Servicios relacionados con este tema

Desarrollo de aplicaciones Windows

Decidir cómo separar la configuración de usuario, los registros, la caché y los datos compartidos influye de forma directa en la operabilidad y el mantenimiento de las aplicaciones de Windows. Si se busca abarcar desde la definición de requisitos hasta el diseño, la implementación y la operación a largo plazo, es un tema que encaja bien con el desarrollo de aplicaciones Windows.

Ver el servicio / Contacto

Consultoría técnica y revisión de diseño

Elegir entre local, móvil o FSLogix, cómo cambiar la operación de los equipos existentes o cómo dividir los destinos de almacenamiento son decisiones en las que ordenar bien las cosas antes de implementar marca una diferencia considerable. Si se quiere organizar la selección del método o el diseño de límites, es un tema que se presta bien a plantearse como consultoría técnica y revisión de diseño.

Ver el servicio / Contacto

Investigación de fallos y análisis de causas

La conversión a perfil Temporary, los fallos de inicio de sesión, los fallos al guardar al cerrar sesión y la identificación de problemas en torno a rutas compartidas encajan bastante bien con la investigación de fallos. Es una vía de consulta útil cuando se quiere acotar, a partir de registros, eventos, permisos y configuración compartida, un problema de perfil difícil de reproducir.

Ver el servicio / Contacto

13. Referencias

Como hay muchas fuentes, primero dejamos un índice al que acceder por tema.

1. Microsoft Learn, About User Profiles (Windows) Componentes del perfil de usuario, NTUSER.DAT, fundamentos del perfil Temporary.

2. Microsoft Learn, Fast User Switching Criterio de usar FOLDERID_RoamingAppData para los datos propios de la aplicación y FOLDERID_LocalAppData para los datos que no se deben usar en otro equipo.

3. Microsoft Learn, KNOWNFOLDERID, CSIDL Definición de las carpetas conocidas como %APPDATA%, %LOCALAPPDATA%, LocalLow y ProgramData.

4. Microsoft Learn, Folder Redirection and Roaming User Profiles in Windows and Windows Server Diferencia entre Folder Redirection y Roaming User Profiles, criterio de gestión centralizada.

5. Microsoft Learn, Deploy roaming user profiles Procedimiento práctico de despliegue del perfil móvil, permisos del recurso compartido, GPO y versionado.

6. Microsoft Learn, Roaming user profiles of earlier versions of Windows are incompatible with Windows 10, Windows Server 2016, and later versions Incompatibilidad entre generaciones de sistema operativo y versionado de perfiles.

7. Microsoft Learn, Create mandatory user profiles Uso y método de creación del perfil de usuario Mandatory.

8. Microsoft Learn, Mandatory User Profiles Definición de NTUSER.MAN y del perfil Super-mandatory.

9. Microsoft Learn, Temporary User Profiles Definición y propiedades del perfil Temporary.

10. Microsoft Learn, Troubleshoot user profiles with events Identificación de problemas mediante los registros Application, Operational y Diagnostic.

11. Microsoft Learn, Error occurs during desktop setup and desktop location is unavailable when you log on to Windows for the first time Creación de un perfil nuevo a partir de C:\Users\Default, problemas de atributos y permisos de NTUSER.DAT / USRCLASS.DAT.

12. Microsoft Learn, Customize the default local user profile when you prepare an image of Windows Método compatible de personalización del perfil predeterminado mediante CopyProfile.

13. Microsoft Learn, What is FSLogix, Types of Containers Fundamentos de FSLogix, concepto del Profile Container.

14. Microsoft Learn, User profile management for Azure Virtual Desktop with FSLogix profile containers, Configure profile containers using FSLogix Recomendación para Azure Virtual Desktop, método de contenedor de perfil mediante VHD / VHDX.

15. Microsoft Learn, Scripts: Clean up profile folder information and prevent TEMP user profiles from being created Relación entre la información huérfana de perfiles y el perfil TEMP.

16. Microsoft Learn, User profile cannot be loaded with Event ID 1509: DETAIL - The filename or extension is too long Problema de ruta demasiado larga al guardar el perfil móvil.

17. Microsoft Learn, ADMX_UserProfiles Policy CSP Definición de directivas como Delete user profiles older than a specified number of days on system restart.

18. Microsoft Learn, Configure a shared or guest Windows device Modo Shared PC y gestión de cuentas y perfiles en equipos compartidos.

19. Microsoft Learn, Designing Applications to Run at a Low Integrity Level Que %USERPROFILE%\AppData\LocalLow y HKEY_CURRENT_USER\Software\AppDataLow están preparados como lugares en los que puede escribir un proceso de integridad baja.

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Qué es NTUSER.DAT?

NTUSER.DAT es el archivo físico de la hive de registro de usuario incluida en el perfil de usuario de Windows. Se encuentra directamente bajo C:\Users\nombre de usuario, se carga al iniciar sesión y se utiliza como HKEY_CURRENT_USER (HKCU). Es decir, el perfil de usuario está compuesto por dos capas: el conjunto de archivos como Desktop y AppData, y la capa de registro centrada en NTUSER.DAT. Si NTUSER.DAT tiene el atributo de solo lectura o no cuenta con los permisos de acceso necesarios, la carga del perfil falla, lo que provoca errores de inicio de sesión o la creación de un perfil temporal.

¿Qué es un perfil de usuario de Windows? ¿Es distinto de la cuenta?

La cuenta identifica «quién inicia sesión», mientras que el perfil de usuario es el entorno de trabajo concreto de esa persona. El perfil no es simplemente la carpeta C:\Users\nombre de usuario, sino el conjunto formado por carpetas como Desktop, Documents y AppData, junto con la hive de registro de usuario NTUSER.DAT. Cuando un usuario nuevo inicia sesión por primera vez, se crea un perfil nuevo tomando C:\Users\Default como base. Hasta qué punto se transporta la configuración depende del método elegido: local, móvil, Folder Redirection o FSLogix.

¿Cómo se debe repartir el uso entre %APPDATA% y %LOCALAPPDATA%?

Como norma básica, la configuración que se desea llevar consigo entre equipos se guarda en %APPDATA% (AppData\Roaming), y la caché o el estado temporal específico de ese equipo se guarda en %LOCALAPPDATA% (AppData\Local). Si se deja que la caché regenerable o los archivos de trabajo grandes viajen con el perfil móvil, el inicio y el cierre de sesión tienden a volverse lentos, por lo que conviene desplazarlos hacia el lado Local. Los datos variables comunes a todos los usuarios son candidatos para ProgramData, pero hay que pensarlo junto con el diseño de la ACL de quién lee y quién escribe. Debe evitarse colocar datos de ejecución específicos de cada usuario en Program Files.

¿Qué se debe hacer cuando el inicio de sesión se realiza con un perfil temporal (Temporary profile)?

El perfil Temporary es una vía de escape de emergencia que se emite cuando un error impide cargar el perfil original; se elimina al cerrar sesión y los cambios se pierden. Continuar trabajando en ese estado supone el riesgo de perder datos importantes, por lo que debe evitarse. En la investigación, en lugar de tocar C:\Users directamente, conviene revisar antes el registro Application, el registro Operational de User Profile Service y, si hace falta, el registro Diagnostic. Entre las causas habituales están los problemas de atributos o permisos de NTUSER.DAT / USRCLASS.DAT, las rutas de destino móvil demasiado largas y la información de registro que queda tras una eliminación incompleta.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.