Problema

En entornos corporativos donde los perfiles de usuario se almacenan en una unidad de red (por ejemplo, P:) y la redirección de carpetas se gestiona mediante GPO, es frecuente habilitar Offline Files (CSC) para que los usuarios puedan trabajar sin conexión y que los cambios se sincronicen automáticamente.

El síntoma típico es que, para ciertos usuarios, Sync Center (o mobsync.exe) no muestra ninguna partnership (asociación) con la unidad redirigida, aunque:

  • La política CachingEnabled está activada a nivel de máquina.
  • Otros usuarios en el mismo equipo sincronizan sin problemas.
  • No existen claves AssignedOfflineFolders ni valores de anulación en HKCU\Software\Microsoft\Windows\CurrentVersion\NetCache.
  • El registro de eventos de Microsoft-Windows-OfflineFiles/Operational no contiene errores críticos.

El problema persiste después de reiniciar la máquina y de vaciar la caché CSC, pero desaparece cuando el usuario vuelve a crear su perfil o cuando la ruta redirigida se mueve fuera de un DFS Namespace. En otras palabras, la asociación CSC se “pierde” de forma silenciosa y no se vuelve a crear automáticamente.

Causa

Los fallos de partnership en CSC suelen originarse en la interacción entre tres componentes:

  1. Política de redirección de carpetas (GPO)

    • La creación de la asociación depende de que el cliente reciba la directiva Folder Redirection y, al mismo tiempo, la política Offline Files esté habilitada. Si la directiva se entrega después de que el cliente haya inicializado CSC, la asociación puede quedar pendiente y nunca completarse.

  2. DFS Namespace

    • Cuando la ruta redirigida es un DFS link (por ejemplo, \\domain\dfsroot\home\%username%), el cliente primero resuelve el enlace y luego abre el recurso. Si la resolución falla temporalmente (cambio de servidor, replicación incompleta, o permisos de lectura insuficientes), CSC no crea la asociación y no registra un error explícito.
    • Además, DFS introduce un cache de enlaces que, si está corrupto, devuelve una ruta equivocada al servicio CSC, impidiendo la creación del partnership.

  3. Perfil de usuario y estado del caché

    • Cambios bruscos en el perfil (migraciones, borrados manuales, restauraciones) pueden dejar referencias a un CSC ID que ya no existe. El cliente sigue intentando reutilizar ese ID y, al no encontrar el recurso, abandona la asociación sin generar eventos de error.
    • Un reset del caché elimina los archivos físicos, pero no borra la información de asociación almacenada en el registro del perfil (HKCU\Software\Microsoft\Windows\CurrentVersion\NetCache\*). Esa información persiste hasta que el perfil se vuelve a crear o se limpia manualmente.

En la práctica, la combinación de GPO tardío + DFS con enlaces desincronizados es la causa más frecuente de “partnership missing” sin rastro en los logs.

Solución

1. Verificar la entrega de GPO y la resolución de DFS

  1. En una máquina afectada, abre una consola de Resultant Set of Policy (RSOP.msc) o usa gpresult /h rsop.html para confirmar que la política Folder Redirection y Offline Files aparecen como Applied.
  2. Desde la misma sesión, ejecuta dfsutil /pktinfo y revisa que el DFS cache muestre la ruta correcta y que el TTL no esté expirado.
  3. Si el enlace muestra “Stale” o “Not Found”, fuerza una actualización con dfsutil /pktflush y vuelve a intentar la redirección.

2. Forzar la recreación de la asociación CSC

  1. Eliminar la información residual del perfil

    • Borra la rama HKCU\Software\Microsoft\Windows\CurrentVersion\NetCache (solo para el usuario afectado).
    • Elimina cualquier carpeta C:\Windows\CSC\v2.0.6 que pertenezca al SID del usuario (se puede identificar con whoami /user).

  2. Reiniciar los servicios relacionados

    net stop cscservice
net start cscservice
    • El reinicio del servicio obliga a CSC a volver a evaluar las políticas y a crear nuevas asociaciones.

  3. Aplicar la política de forma inmediata

    gpupdate /force
    • Después de gpupdate, abre una ventana del Explorador apuntando a la unidad redirigida (P:). Si la carpeta se muestra como “Disponible offline”, la asociación se ha creado.

3. Normalizar la configuración de DFS

  • Desactivar el caché de enlaces en los clientes que presentan problemas críticos: 
    reg add "HKLM\SYSTEM\CurrentControlSet\Services\Dfs" /v EnableCache /t REG_DWORD /d 0 /f
    • Reinicia el equipo o el servicio Dfs (net stop dfs && net start dfs).
  • Asegurar replicación completa de los enlaces antes de que los usuarios inicien sesión. En entornos con varios controladores de dominio, verifica que la zona DFS se haya replicado a todos los servidores.

4. Automatizar la detección de asociaciones rotas

Crea un script que recorra los usuarios del dominio y compruebe si la carpeta redirigida tiene la bandera de offline (attrib -R). Si no la tiene, registra el SID y ejecuta los pasos de limpieza descritos arriba. Esto permite corregir el problema antes de que el usuario note la falta de sincronización.

Cuándo aplicar esta solución

  • Síntomas: En Sync Center no aparece ninguna partnership para la unidad redirigida, aunque Offline Files está habilitado y otras cuentas funcionan.
  • Entorno: GPO de Folder Redirection + Offline Files + DFS Namespace.
  • Escenarios típicos:
    • Migraciones de perfiles que dejan huellas de CSC.
    • Cambios recientes en la topología DFS (nuevo servidor, cambio de enlace).
    • Políticas GPO aplicadas después del primer inicio de sesión del usuario.

No aplicar si:

  • La unidad redirigida es una ruta local o un recurso SMB sin DFS.
  • Los logs de Offline Files muestran errores críticos (en ese caso, el problema es distinto).

Código

# 1. Vaciar la rama NetCache del usuario actual
reg delete "HKCU\Software\Microsoft\Windows\CurrentVersion\NetCache" /f

# 2. Eliminar los archivos CSC del SID del usuario
set SID=%USERDOMAIN%\%USERNAME%
for /d %%G in ("C:\Windows\CSC\v2.0.6\*") do (
    if "%%~nG"=="%SID%" rmdir /s /q "%%G"
)

# 3. Reiniciar el servicio CSC y forzar GPO
net stop cscservice
net start cscservice
gpupdate /force

Verificación

  1. Comprobar la presencia de la asociación

    • Abre Sync Center → Manage offline files → View your offline files. La unidad P: debe aparecer bajo “Partnerships”.

  2. Validar que los archivos están marcados como offline

    • En una ventana de CMD, ejecuta attrib P:\* /S /D. Los archivos deben mostrar la letra O (offline).

  3. Revisar los logs

    • En el Visor de eventos, filtra por Microsoft-Windows-OfflineFiles/Operational. No deben aparecer eventos de tipo Error relacionados con la creación de partnership.

  4. Prueba de desconexión

    • Desconecta la red, abre la unidad P: y verifica que los archivos siguen accesibles. Reconecta y comprueba que los cambios se sincronizan automáticamente.

Notas adicionales

  • DFS cache persistente: En algunos dominios el cliente mantiene el caché de DFS durante 24 h. Si el problema ocurre justo después de un cambio de enlace, espera al menos una hora o ejecuta dfsutil /pktflush para acelerar la actualización.
  • Política “Do not automatically make redirected folders available offline”: Asegúrate de que no exista una GPO que anule la disponibilidad offline a nivel de usuario; esa política crea una clave HKCU\Software\Microsoft\Windows\CurrentVersion\NetCache\Enabled que sobrescribe la configuración global.
  • Backup de la rama NetCache: Antes de borrar la rama del registro, exporta una copia (reg export HKCU\Software\Microsoft\Windows\CurrentVersion\NetCache backup.reg) por si necesitas restaurarla.
  • Impacto en VDI: En entornos VDI la caché CSC se comparte entre sesiones. Si varios usuarios comparten la misma máquina, un error de asociación en uno puede “contaminar” al resto. Aplicar los pasos de limpieza a nivel de máquina (HKLM\SYSTEM\CurrentControlSet\Services\CSC\Parameters) ayuda a evitar la propagación.