Perfiles móviles: propuesta experimental
Esta página consolida la discusión del issue #8. El issue se cerró después del análisis de viabilidad, pero no se desplegaron perfiles móviles ni cambios de dominio. El contenido siguiente es una propuesta de piloto, no una descripción del estado de producción.
Objetivo
Permitir que archivos y, cuando resulte necesario, parte de la configuración de una persona estén disponibles al iniciar sesión en distintos equipos del dominio, sin trasladar indiscriminadamente todo el perfil de Windows.
Alternativas consideradas
| Alternativa | Uso adecuado | Observaciones |
|---|---|---|
| Redirección de carpetas | Documentos y Escritorio |
Menor volumen y menor impacto en el inicio de sesión |
| Perfil móvil clásico | Perfil de Windows entre equipos | Compatible, pero sensible a tamaño, latencia y versiones del perfil |
| FSLogix | Perfil completo en contenedor VHD/VHDX | Requiere validar compatibilidad, licenciamiento y almacenamiento SMB |
Home de Linux por SMB/NFS y autofs |
Equipos Linux | Es una solución independiente; no comparte directamente el perfil de Windows |
Recomendación por rol
- Alumnos (
AL): conservar un perfil local desechable y redirigir sóloDocumentosyEscritorio. No mover cachés ni todo el perfil. - Administrativos (
AD) y docentes (DO): iniciar con redirección de carpetas. Evaluar FSLogix únicamente si el piloto demuestra que también deben acompañar al usuario la configuración de aplicaciones y el resto del perfil. - Linux: diseñar un home de red separado. No intentar reutilizar el perfil de Windows como directorio personal de Linux.
El Auth Broker podría asignar en el futuro atributos como profilePath o
homeDirectory al crear o actualizar la cuenta. La GPO seguiría controlando el
comportamiento por grupo. Actualmente el broker no escribe esos atributos y la
infraestructura de perfiles no está habilitada.
La personalización de fondo de pantalla de SGU puede seguir generándose localmente al iniciar sesión; no requiere que la imagen renderizada viaje con el perfil.
Riesgos y requisitos
El diseño actual concentra controlador de dominio, Auth Broker y otros servicios en el mismo servidor. Agregar almacenamiento de perfiles allí aumenta el radio de impacto: una caída, un volumen lleno o un SMB lento puede degradar o bloquear inicios de sesión.
Antes de cualquier piloto se requiere como mínimo:
- un recurso SMB dedicado, por ejemplo
Profiles$, con ACL por usuario; - cuotas, capacidad y alertas de espacio;
- copias de seguridad y una restauración probada;
- limpieza de cachés y exclusiones para archivos temporales o pesados;
- separación por versión cuando se usen perfiles móviles clásicos;
- mediciones de latencia, duración de inicio/cierre y comportamiento sin red;
- un procedimiento para retirar la GPO sin perder los datos del usuario.
No debe almacenarse el perfil en el controlador de dominio para una implantación de producción sin evaluar capacidad, disponibilidad, seguridad y recuperación.
Piloto propuesto
- Seleccionar un grupo pequeño y reversible de usuarios y equipos.
- Crear un almacenamiento SMB de prueba con ACL individuales, cuota y copia de seguridad.
- Aplicar mediante GPO únicamente la redirección de
DocumentosyEscritorio. - Probar cambios de equipo, desconexión de red, volumen lleno y recuperación de archivos.
- Medir el tiempo de inicio y cierre, errores de sincronización y consumo por usuario.
- Decidir con evidencia si
ADyDOnecesitan FSLogix o si la redirección de carpetas cubre el caso de uso.
Criterio para considerar la función implementada
La propuesta sólo debe marcarse como desplegada cuando existan almacenamiento, ACL, cuotas, copia de seguridad, GPO segmentada, prueba de desconexión, procedimiento de reversión y evidencia del piloto. Cerrar el issue de análisis no satisface esos controles.