FSLogix + Azure NetApp Files en AVD: guía 2026
En pocas palabras: Para AVD, Microsoft documenta guardar los perfiles FSLogix como contenedores VHD(X) en un volumen SMB de Azure NetApp Files, con Continuous Availability activado. La configuración requiere crear una cuenta NetApp, un capacity pool, conexión a Active Directory, el volumen SMB y aplicar los registros Enabled y VHDLocations en cada session host.
Si administrás Azure Virtual Desktop y estás evaluando dónde guardar los perfiles de usuario, FSLogix con Azure NetApp Files (ANF) es la combinación que Microsoft documenta como referencia para entornos multisesión: un contenedor VHD(X) montado por SMB, con baja latencia y alto throughput garantizados por un servicio de storage gestionado.
FSLogix es la tecnología de Microsoft que guarda el perfil completo de un usuario (configuración, archivos, datos de aplicaciones) en un contenedor VHD(X) que se monta al iniciar sesión en un session host de AVD. Azure NetApp Files es el servicio de storage gestionado que aloja ese contenedor como recurso SMB, con la latencia y el throughput que un entorno de escritorios virtuales no persistentes necesita para no volverse lento.
En este artículo:
- En 30 segundos
- ¿Qué es Azure NetApp Files y por qué se usa para perfiles FSLogix en AVD?
- Profile Container vs ODFC Container: diferencias según la documentación de FSLogix
- Requisitos previos antes de implementar ANF con AVD
- Cómo crear la cuenta NetApp, el capacity pool y la conexión a Active Directory
- Cómo crear el volumen SMB para los contenedores de perfil
- Qué claves de registro configurar en el session host para FSLogix
- Cómo verificar que FSLogix con ANF está funcionando correctamente
- Errores comunes al implementar FSLogix con Azure NetApp Files
- Preguntas Frecuentes
- Conclusión
- Fuentes
En 30 segundos
- FSLogix guarda el perfil en un contenedor VHD(X) que Azure NetApp Files sirve como recurso SMB, con Continuous Availability activado (recomendado puntualmente para FSLogix).
- Profile Container guarda el perfil completo; ODFC Container separa solo los datos de Office; Cloud Cache no es un tercer tipo, es una configuración opcional sobre los anteriores.
- Los volúmenes SMB en ANF van de 50 GiB a 100 TiB de cuota, según la guía técnica de FSLogix sobre Azure NetApp Files.
- En el registro solo hay dos valores obligatorios: Enabled (DWORD 1) y VHDLocations (MULTI_SZ con la ruta UNC del volumen).
- Cada NetApp account admite una sola conexión a Active Directory, y solo una subnet por VNet puede delegarse a ANF.
¿Qué es Azure NetApp Files y por qué se usa para perfiles FSLogix en AVD?
Azure NetApp Files es un servicio de storage SMB gestionado por Microsoft, pensado para escenarios de alto rendimiento como los contenedores de perfil de FSLogix en Azure Virtual Desktop. FSLogix, del otro lado, guarda cada perfil en un archivo VHD(X) que se adjunta al session host en el momento del login. La combinación resuelve el problema clásico de los entornos no persistentes: que el perfil sobreviva al reinicio de la máquina virtual.
Ponele que tenés un pool de session hosts multisesión que se reciclan cada semana. Sin un contenedor de perfil persistente, cada usuario arrancaría de cero: sin wallpaper, sin configuración de Outlook, sin nada guardado. FSLogix con Azure NetApp Files AVD soluciona justamente eso: el perfil vive en el storage, no en la VM. Sobre eso hablamos en certificaciones de Azure según tu rol técnico.
Nada de esto funciona sin un dominio de Active Directory Domain Services (AD DS) ya operativo. Es un prerequisito, no un detalle menor. La guía técnica que documenta este flujo prueba este procedimiento sobre un entorno de AVD y ANF configurado en septiembre de 2026, justamente partiendo de esa base.
Profile Container vs ODFC Container: diferencias según la documentación de FSLogix
Profile Container guarda el perfil de usuario completo en un único VHD(X). ODFC Container separa solo los datos relacionados con Office en un contenedor aparte. Cloud Cache no es un tercer tipo: es una configuración opcional que podés aplicar sobre cualquiera de los dos anteriores.
| Tipo | Qué guarda |
|---|---|
| Profile Container | El perfil de usuario completo en un VHD(X) |
| ODFC Container | Solo los datos de Office, en un contenedor separado |
| Cloud Cache | No es un tipo: es una configuración opcional sobre los contenedores anteriores |
¿Cuál conviene? Si arrancás de cero, Profile Container. Es el escenario base que documenta Microsoft y el que usa la guía técnica citada arriba.
Requisitos previos antes de implementar ANF con AVD
Antes de tocar el portal de Azure necesitás cuatro cosas resueltas: una cuenta con permisos de contributor o administrador, una subnet delegada exclusivamente a Azure NetApp Files, un dominio AD DS accesible y claridad sobre la topología de red, porque ANF solo se puede acceder desde la misma VNet o una VNet peered en la misma región.
- Permisos de Azure: cuenta con rol contributor o administrador sobre la suscripción donde vas a crear los recursos.
- Subnet delegada: ANF necesita una subnet propia dentro de la VNet, y esa VNet solo puede tener una subnet delegada a ANF, no dos.
- Conexión a Active Directory: cada NetApp account admite una sola conexión a AD. Si tenés múltiples dominios, planificá cuántas cuentas NetApp vas a necesitar.
- Cuenta de dominio para el join: un usuario de AD DS con permisos para crear cuentas de equipo en la OU que vayas a usar.
- Red compartida: acceso solo desde la misma VNet o desde una VNet peered en la misma región. Nada de cross-region.
Cómo crear la cuenta NetApp, el capacity pool y la conexión a Active Directory
El flujo arranca con tres pasos en el portal de Azure: crear la NetApp account en la misma región que tus session hosts, después el capacity pool eligiendo nivel de servicio (Standard, Premium o Ultra), y por último la conexión a Active Directory con los datos de DNS y la cuenta de dominio. Más contexto en comparativa completa entre Microsoft y GitHub.
La NetApp account tiene que crearse en la misma región donde vas a desplegar los volúmenes. No hay forma de eludir esto. El capacity pool define cuánto storage total vas a repartir entre volúmenes, y ahí el nivel de servicio (Standard, Premium o Ultra) determina el throughput disponible.
Para la conexión a AD necesitás Primary DNS, Secondary DNS, el nombre de dominio completo (por ejemplo contoso.com), el AD Site Name (por default Default-First-Site-Name), un prefijo para las cuentas de equipo SMB, el usuario y contraseña del join, y la ruta LDAP de la OU en formato OU=nivel2,OU=nivel1. Si no especificás OU, ANF crea las cuentas en el contenedor CN=Computers por default.
Ojo con un detalle: si tu entorno usa Microsoft Entra Domain Services, no actives LDAP over TLS en la conexión. La documentación oficial de FSLogix en Microsoft Learn lo desaconseja de forma explícita.
Cómo crear el volumen SMB para los contenedores de perfil
El volumen SMB se crea en dos pestañas del wizard de Azure NetApp Files: Basics, donde definís nombre, capacity pool, cuota (entre 50 GiB y 100 TiB) y la subnet delegada, y Protocol, donde elegís SMB, asociás la conexión de AD y activás Continuous Availability, opción que Microsoft recomienda puntualmente para FSLogix.
- Continuous Availability: activala. Es la opción recomendada para FSLogix y evita interrupciones ante un failover del lado de ANF.
- SMB3 Protocol Encryption: si la activás, los clientes que no soporten cifrado SMB3 quedan afuera del volumen. Verificá compatibilidad antes de prenderla en producción.
- Access Based Enumeration: oculta carpetas a usuarios sin permiso de acceso. Útil si compartís el mismo volumen entre varios grupos.
Una vez creado el volumen, el portal muestra el Mount path en la pestaña Overview. Esa ruta es la que vas a necesitar en el paso siguiente, la de la clave de registro VHDLocations. Ya lo cubrimos antes en repos de Microsoft comprometidos con malware.
Qué claves de registro configurar en el session host para FSLogix
En el session host hay que tocar el registro en HKEY_LOCAL_MACHINE\SOFTWARE\FSLogix\Profiles. De toda la lista que documenta Microsoft, solo dos valores son estrictamente obligatorios: Enabled y VHDLocations. El resto son recomendados o quedan en su valor por default.
| Valor | Tipo | Valor recomendado | Clasificación |
|---|---|---|---|
| Enabled | DWORD | 1 | Obligatorio |
| VHDLocations | MULTI_SZ | \\<anf-fqdn>\<share-name> | Obligatorio |
| VolumeType | REG_SZ | VHDX | Recomendado |
| DeleteLocalProfileWhenVHDShouldApply | DWORD | 1 | Recomendado |
| FlipFlopProfileDirectoryName | DWORD | 1 | Recomendado |
| LockedRetryCount | DWORD | 3 | Recomendado |
| LockedRetryInterval | DWORD | 15 | Recomendado |
| ReAttachIntervalSeconds | DWORD | 15 | Recomendado |
| ReAttachRetryCount | DWORD | 3 | Recomendado |
| SizeInMBs | DWORD | 30000 | Default |
Subís el volumen, lo delegás a la subnet correcta, configurás la conexión a AD, creás el share SMB, seteás Enabled y VHDLocations en el session host y recién ahí el usuario se loguea y ve su perfil, así que si te salteás un solo paso del medio, lo que vas a ver es un perfil temporal y un ticket de soporte.
Podés setear todo esto a mano con New-ItemProperty en PowerShell, clave por clave, o distribuirlo por GPO usando las plantillas ADMX/ADML que Microsoft publica para FSLogix (destino: %systemroot%\sysvol\domain\policies\PolicyDefinitions). Si administrás más de un pool de session hosts, la opción de GPO ahorra repetir el proceso máquina por máquina.
Cómo verificar que FSLogix con ANF está funcionando correctamente
La verificación tiene tres pasos: confirmar que el servicio frxsvc está corriendo, chequear que las claves de registro se aplicaron bien, y probar que el perfil viaja entre session hosts. Los tres se hacen desde línea de comandos o File Explorer, sin herramientas extra. Tema relacionado: el crecimiento de ingresos de Azure.
- Servicio activo: corré
sc query frxsvcen el session host y confirmá que el STATE diga RUNNING. - Registro aplicado: corré
reg query HKLM\SOFTWARE\FSLogix\Profilesy verificá que Enabled esté en 0x1 y que VHDLocations apunte a la ruta de ANF. - Archivo VHD presente: abrí el mount path del volumen en File Explorer y buscá una ruta con el formato
\\<anf-volume-fqdn>\<share-name>\<username>_<SID>\Profile_<username>.vhd. - Roaming real: cerrá sesión en un session host, abrí sesión en otro, y si el wallpaper y la organización de archivos se mantienen, funciona.
¿Y si el perfil no viaja entre hosts? Ahí el problema casi siempre está en VHDLocations mal escrito o en un permiso NTFS que falta sobre el share.
Errores comunes al implementar FSLogix con Azure NetApp Files
Casi todos los problemas de esta configuración vienen de saltarse un requisito de red o de registro, no de un bug de FSLogix en sí.
- Delegar más de una subnet a ANF por VNet: Azure lo rechaza directamente. Cada VNet admite una sola subnet delegada a Azure NetApp Files.
- No activar Continuous Availability en el volumen SMB: genera desconexiones intermitentes que después cuestan diagnosticar, porque el síntoma parece un problema de red y no de configuración del volumen.
- Ignorar la ruta de OU al crear la conexión AD: si no la especificás, las cuentas de equipo van a parar a CN=Computers en vez de la OU que corresponde según la política de la empresa.
- Activar LDAP over TLS junto con Microsoft Entra Domain Services: la documentación oficial lo desaconseja de forma explícita, y mezclarlos suele romper la autenticación del join.
Preguntas Frecuentes
¿Qué es FSLogix y para qué sirve en AVD?
FSLogix es la tecnología de Microsoft que empaqueta el perfil de usuario en un contenedor VHD(X) y lo monta al iniciar sesión en un session host de Azure Virtual Desktop. Sirve para que el perfil (configuración, datos de apps, archivos) persista aunque la máquina virtual sea no persistente o multisesión.
¿Cómo funciona FSLogix con Azure NetApp Files?
Azure NetApp Files aloja el contenedor VHD(X) como un recurso SMB de alto rendimiento. El session host lo monta por red al momento del login usando la ruta configurada en VHDLocations, y Microsoft recomienda activar Continuous Availability en el volumen para este escenario específico.
¿Cuánto cuesta Azure NetApp Files?
El precio depende del nivel de servicio elegido (Standard, Premium o Ultra) y del tamaño del capacity pool, que va de 50 GiB a 100 TiB por volumen según la guía técnica de FSLogix sobre Azure NetApp Files. No hay una cifra de costo fija publicada en esa fuente, así que conviene revisar la calculadora de precios oficial de Azure antes de dimensionar el pool.
¿Qué diferencia hay entre Profile Container y ODFC Container?
Profile Container guarda el perfil de usuario completo en un solo VHD(X). ODFC Container separa únicamente los datos relacionados con Office en un contenedor aparte, útil si querés versionar o migrar esos datos de forma independiente del resto del perfil.
¿Qué claves de registro son obligatorias para que FSLogix funcione?
Solo dos: Enabled, que tiene que estar en 1 (DWORD), y VHDLocations, que tiene que apuntar a la ruta UNC del volumen SMB de ANF. El resto de los valores de configuración son recomendados o quedan en su default sin bloquear el funcionamiento básico.
Conclusión
FSLogix con Azure NetApp Files AVD resuelve un problema puntual: que el perfil de usuario sobreviva al ciclo de vida de una VM no persistente, con la latencia que un servicio de storage gestionado puede ofrecer. La configuración no es larga (seis pasos desde la NetApp account hasta la verificación), pero cada paso tiene un requisito que, si te lo salteás, recién lo vas a notar cuando un usuario llame para avisar que perdió el wallpaper y la configuración de Outlook.
Como criterio práctico antes de pasar esto a producción: probalo primero con un grupo piloto chico, confirmá el roaming entre al menos dos session hosts, y recién después escalá al resto del pool. Es una verificación simple, pero evita sorpresas masivas el día del rollout.
Si tu organización también gestiona hosting o dominios propios en Argentina además de la infraestructura de AVD, vale la pena tener a mano un proveedor local como donweb.com para esa parte del stack.
