Problemes de sincronització amb Offline Files al Windows: guia completa

Quan els fitxers sense connexió de Windows (Offline Files) es torcen, el resultat sol ser el mateix: usuaris enfadats, portàtils que fora de l'oficina es queden “buits” i administradors sense tenir gaire clar per on començar a mirar. Encara que pugui semblar una funció secundària, la memòria cau darxius sense connexió és crítica en molts entorns sense connexió amb portàtils i perfils mòbils.

En aquest article trobaràs una guia molt detallada per entendre, configurar, diagnosticar i reparar problemes amb Offline Files, el Centre de sincronització i la memòria cau CSC en diferents versions de Windows (especialment Windows 7, 10 i 11). Veurem des de fallades clàssiques com que el sistema no torni al mode en línia, el Centre de sincronització encallat a “Pendent”, fins com controlar la funció per Directives de Grup o auditar-la amb PowerShell.

Què són exactament els fitxers sense connexió a Windows

La característica de fitxers sense connexió és una tecnologia client/servidor de Windows que permet que el contingut de recursos compartits SMB es copiï i mantingui en una memòria cau local anomenada CSC (Client Side Caching) . Gràcies a això, el sistema pot simular les rutes UNC fins i tot quan lequip està desconnectat de la xarxa corporativa.

A la pràctica, l'usuari accedeix a les seves carpetes de xarxa (per exemple, \\Servidor\Usuaris\Nom ) com sempre, però quan no hi ha connexió, Windows redirigeix ​​silenciosament l'accés a la còpia que resideix a la memòria cau local. Quan la xarxa torna a estar disponible, el Centre de sincronització compara canvis entre el servidor i la memòria cau i els sincronitza automàticament.

Aquesta tecnologia és especialment útil per a portàtils amb perfils mòbils o carpetes redirigides (Escriptori, Documents, Imatges, etc.). Això no obstant, si s'habilita en carpetes compartides per molts usuaris o en dades sensibles (bases de dades, fitxers compartits de departaments) pot provocar conflictes de dades, sobrecàrrega de xarxa i còpies duplicades per tota l'organització.

Perquè Offline Files funcioni correctament, el servidor de fitxers, la carpeta compartida i el client Windows han de suportar la tecnologia i tenir el servei de fitxers sense connexió actiu . Si el servei està deshabilitat al client o el recurs no és compatible, la funció no entrarà en joc encara que s'intenti forçar.

Funcionament intern: MUP, redirectors SMB i CSC

A Windows Vista, Windows 7 i versions posteriors, totes les sol·licituds d'accés a sistemes de fitxers remots s'enruten a través del Proveïdor UNC múltiple (MUP) . MUP rep una ruta UNC com a \\Servidor\Recurs\Carpeta i decideix quin redirector de xarxa (proveïdor UNC) s'ha d'encarregar: normalment el client SMB (LanmanWorkstation), però també en podrien ser altres.

MUP envia una operació de resolució de prefix (IOCTL_REDIR_QUERY_PATH) al redirector adequat. Aquesta operació analitza la ruta UNC i comprova, pas a pas, l'accessibilitat de cada component: primer \\Servidor , després \\Servidor\Recurso$ , i així successivament. Si algun d'aquests passos torna errors com STATUS_LOGON_FAILURE o STATUS_ACCESS_DENIED , MUP marca la ruta com a no accessible.

El component d' emmagatzematge a la memòria cau del costat client (CSC) intercepta aquestes sol·licituds que passarien al redirector de xarxa. Si la resolució de prefixos falla, però la ruta estava marcada anteriorment com a disponible sense connexió, CSC decideix servir les dades des de la memòria cau local en lloc de continuar intentant accedir al servidor.

Aquest comportament explica molts dels problemes “rars” dels fitxers sense connexió: l'usuari pot veure algunes carpetes de xarxa en línia , però les que estan configurades per treballar sense connexió se segueixen servint des de la memòria cau fins i tot amb la xarxa disponible, cosa que genera incoherències, conflictes de sincronització o sensació de “dades desfasades”.

Quant al rendiment, el Centre de sincronització executa comparacions entre la llista de directoris local i la que exposa el servidor remot mitjançant SMB (CIFS/SMB/SMB2/SMB3). Els servidors de fitxers Windows que usen NTFS retornen les entrades de directori ordenades alfabèticament , però molts servidors de tercers, o els que treballen sobre sistemes de fitxers com FAT32, tornen llistes desordenades, obligant el client a realitzar més consultes i perjudicant seriosament la velocitat de sincronització.

Problema típic: Windows no torna al mode en línia

Un dels errors més comentats, sobretot a Windows 7 SP1 , és que després de passar a mode desconnectat el sistema no reprèn automàticament el mode en línia quan la xarxa torna a estar disponible. L'usuari veu que la connexió de xarxa ja funciona, pot accedir a altres recursos compartits, però els elements marcats com a “disponibles sense connexió” segueixen tractant-se com si la màquina estigués fora de la xarxa.

En aquests casos, el botó per a “Treballar sense connexió / Treballar en línia” pot desaparèixer de l'Explorador de Windows després d'una transició, i l'emmagatzematge en memòria cau CSC roman en estat fora de línia fins al següent reinici de l'ordinador. A sobre, el Centre de sincronització no mostra informació actualitzada sobre la relació de sincronització i no és possible forçar una sincronització de la ruta UNC afectada.

El símptoma típic és que l'usuari obre una carpeta compartida i es troba que alguns recursos de xarxa estan en línia i funcionen, però aquells que estan configurats per estar disponibles sense connexió es mostren sempre des de la memòria cau local. Podeu crear fitxers nous o modificar els existents, però aquests canvis no es pugen al servidor i romanen només al disc del portàtil.

Un escenari que dispara aquest comportament és quan es proporciona un recurs compartit de la forma \\ServerName\ShareName$\dir1\dir2 , on l'usuari té permisos suficients a les subcarpetes dir1 i dir2 , però no disposa de permisos per veure el contingut del recurs compartit arrel ShareName$.

En aquest context, en analitzar la ruta UNC, Windows comprova amb èxit \\ServerName , però falla quan intenta validar \\ServerName\ShareName$ per manca de permisos a aquest nivell. Aquesta denegació fa que l'operació remota es marqui com a errònia, i per disseny CSC torna el contingut de la memòria cau si la ruta havia estat sincronitzada anteriorment.

Permisos recomanats en recursos compartits i NTFS

La solució en aquest tipus de problemes passa per revisar que l'usuari pugui recórrer cada tram de la ruta UNC amb prou permisos mínims, tant a nivell de recurs compartit SMB com de permisos NTFS. Per a una ruta com a \\ServerName\ShareName$\dir1\dir2 , on l'usuari sincronitza la subcarpeta dir1 , cal ajustar la seguretat amb cura.

Al recurs compartit de fitxers sense connexió (per exemple, ShareName$ ), la recomanació habitual és eliminar el grup “Tots” dels permisos de compartició, i utilitzar un grup de seguretat que inclogui els usuaris que realment han d'utilitzar aquest recurs per concedir permisos de Canvi o superiors. D'aquesta manera, s'evita exposició innecessària, però s'assegura que qui tingui accés a les subcarpetes pugui resoldre el prefix UNC sense errades.

A nivell de NTFS a la carpeta arrel del recurs compartit, se solen establir entrades de l'estil: CREATOR OWNER amb control total en subcarpetes i fitxers , SYSTEM amb control total , i un grup de seguretat per als usuaris amb permisos de “Mostrar carpeta/llegir dades” sobre aquesta carpeta . El grup “Tots” es deixa sense permisos per endurir la seguretat, i els administradors poden tenir accés directe o delegar en grups específics segons la política de l'organització.

A les subcarpetes d'usuari concret (per exemple, dir1 i dir2 ), l'habitual és atorgar a l'usuari propietari permisos de lectura i escriptura , mantenir SYSTEM amb control total , i retirar permisos innecessaris a “Tots” i, en molts entorns, a “Administradors” sobre el contingut de cada carpeta d'usuari, depenent de la política de privadesa.

Si aquests permisos no estan alineats, MUP pot marcar la ruta com a inaccessible per denegació d'accés al nivell del recurs compartit, i Offline Files continuarà servint dades des de la memòria cau sense tornar al mode en línia, cosa que es tradueix en sincronitzacions fallides o absents.

Centre de sincronització encallat a «Pendent» i memòria cau CSC corrupta

Un altre dels errors clàssics és el Centre de sincronització quedant-se eternament en estat “Pendent” per a les associacions d'Offline Files. No hi ha un error clar, l'interfície amb prou feines dóna pistes i l'usuari només veu que no s'acaba mai de sincronitzar.

Aquest tipus de problema sol apuntar a una memòria cau CSC danyada o en un estat inconsistent . Una forma efectiva (tot i que una mica dràstica) d'arreglar-ho és desactivar la característica de fitxers sense connexió, netejar completament la carpeta C:\Windows\CSC i tornar a habilitar la funció perquè es regeneri la memòria cau des de zero.

El procediment típic seria una cosa així: primer es deshabiliten els fitxers sense connexió des del Centre de sincronització , es reinicia l'equip perquè el servei deixi d'estar actiu, i després es pren possessió de la carpeta C:\Windows\CSC , ja que per defecte està protegida i pertany al sistema.

Per prendre possessió es pot fer servir el menú contextual de “Prendre possessió” si s'ha afegit mitjançant el registre, o bé recórrer a la línia d'ordres amb privilegis d'administrador i executar alguna cosa de l'estil: takeown /f c:\windows\csc /r /a /dy , seguit d' icacls "c:\windows\qs" . Amb això, s'atorguen permisos de control total al grup d'administradors sobre tota l'estructura.

Un cop assegurat l'accés, cal fer una còpia de seguretat de la carpeta CSC per si l'usuari té dades sense sincronitzar que calgui recuperar manualment. Després, és important esborrar la carpeta sencera C:\Windows\CSC i no només el contingut; si es deixa la carpeta amb ACL incorrectes, el sistema pot tornar a quedar encallat a “Pendent”. Després de l'esborrament, es reactiven els fitxers sense connexió al Centre de sincronització i es reinicia de nou perquè es regeneri l'estructura de la memòria cau.

En casos més complicats, quan la carpeta CSC no es deixa esborrar ni canviant permisos, es pot recórrer a eines com PsExec (SysInternals) per obrir una consola com a compte del sistema (SYSTEM) i fer servir rmdir /s sobre la carpeta interna (per exemple, C:\Windows\CSC\v2.0.6 ). Una altra alternativa és arrencar a l'entorn de recuperació de Windows (WinRE), anar al símbol de sistema, reanomenar la carpeta CSC (per exemple ren csc csc1 ) i crear una nova buida amb md csc.

Rendiment lent en sincronitzar amb servidors que no són Windows

Pot passar que les sincronitzacions de fitxers sense connexió triguin molt més del normal quan el servidor de fitxers que hi ha al darrere no és un Windows Server clàssic (per exemple, NAS de tercers o servidors Linux amb Samba) o quan el sistema de fitxers subjacent no és NTFS.

El motiu és que el Centre de sincronització basa gran part de la seva lògica en comparar la llista de continguts local amb què torna el servidor per SMB. Els servidors de Microsoft que usen NTFS retornen les entrades de directori ja ordenades alfabèticament , el que fa que el client pugui confrontar dades de forma eficient.

No obstant això, molts sistemes de fitxers no mantenen llistes internes ordenades , ni en implementacions SMB de tercers ni en altres formats com FAT32. En aquests escenaris, el client de Windows rep directoris desordenats, cosa que l'obliga a fer més consultes tant al sistema de fitxers local com al servidor remot , especialment quan hi ha centenars o milers de fitxers amb noms llargs i el desordre en l'ordenació és gran.

Com més volum de fitxers hi hagi i més desordre tinguin els llistats que retorna el servidor, més es dispara el nombre d'operacions necessàries per determinar què ha canviat i què no. Tot i que això no provoca errors d integritat, sí que es tradueix en sincronitzacions molt lentes i un impacte notable en l experiència de l usuari.

Per mitigar el problema es recomana dividir les dades en carpetes més petites (ja sigui reduint el nombre de fitxers per directori o la mida dels noms) i, quan sigui possible, ordenar o reestructurar el sistema de fitxers subjacent de manera que la creació de fitxers segueixi un patró menys caòtic, ajudant que el client no hagi de fer tantes consultes.

Controlar fitxers sense connexió amb directives de grup (GPO)

En entorns corporatius amb Active Directory, el més assenyat és controlar Offline Files mitjançant GPO tant a nivell d'equip com d'usuari. Això permet decidir amb precisió qui pot fer servir la funció, en quins equips, i com es comporta davant de connexions lentes, desconnexions o determinats tipus de fitxers.

Una estratègia comuna passa per separar les polítiques “Habilitat” i “Deshabilitat” per poder assignar-les a diferents Unitats Organitzatives (OU). Per exemple, es pot crear una OU “Equips” i, dins, subcarpetes per a “Portàtils” i “Estacions de treball”. Als portàtils se'ls aplica una GPO que habilita fitxers sense connexió, ia les estacions de treball d'oficina una GPO que els deshabilita.

Les opcions principals es troben a les plantilles administratives sota Configuració de l'equip > Directives > Plantilles administratives > Xarxa > Fitxers sense connexió , on es pot ajustar l'ús global de la característica mitjançant la directiva “Permetre o denegar l'ús de la característica Fitxers sense connexió” . En establir-la a “Deshabilitada”, el servei s'apaga completament i l'usuari no el pot modificar des del Centre de sincronització.

A nivell d'usuari, a Configuració de l'usuari > Directives > Plantilles administratives > Xarxa > Arxius sense connexió , es controlen aspectes com l'acció per defecte en perdre connexió, quines extensions no s'han d'emmagatzemar a la memòria cau o l'execució de sincronitzacions a l'inici i al tancament de sessió. Per limitar l'abast a certes persones, se sol crear un grup de seguretat específic (per exemple, “Usuaris amb fitxers sense connexió”) i utilitzar el filtratge de seguretat de GPO, eliminant “Usuaris autenticats” i afegint únicament aquest grup.

En configurar els permisos de la carpeta d'usuaris al servidor, cal assegurar-se que el grup de seguretat emprat a la GPO té els permisos adequats a NTFS : mostrar carpeta/llegir dades, crear carpeta/annexar dades i permisos de lectura sobre la carpeta arrel; mentre que SYSTEM, CREATOR OWNER i els administradors mantenen control total on sigui procedent, seguint les millors pràctiques per a perfils mòbils i redireccions.

Personalització avançada d'Offline Files per polítiques

Més enllà d'habilitar o deshabilitar la característica, les GPO permeten afinar el comportament dels fitxers sense connexió per adaptar-lo a diferents escenaris. Algunes de les opcions més útils que sol configurar un administrador en producció són:

Definir l' acció en desconnectar del servidor i establir que l'equip passi automàticament a “Treballar sense connexió” quan detecta la pèrdua de la connexió. Així s'evita que l'usuari es quedi mirant errors de xarxa i es garanteix que segueixi veient els seus fitxers des de la memòria cau sense talls bruscos.

Configurar una llista d' ”arxius no emmagatzemats en memòria cau” , on s'inclouen extensions problemàtiques com *.mdb, *.dbf o altres tipus de bases de dades que no porten gens bé l'existència de còpies desconnectades. Marcar-les perquè mai se sincronitzin redueix enormement el risc de corrupció i conflictes.

Habilitar l'opció de “Cifrar la memòria cau de fitxers sense connexió” de manera obligatòria. Daquesta manera, encara que el portàtil es perdi o el robin, la informació emmagatzemada a la memòria cau CSC queda xifrada i no pot ser llegida fàcilment sense les credencials de lusuari.

Forçar la sincronització de tots els fitxers sense connexió tant en iniciar sessió com en tancar sessió . Això garanteix que els canvis realitzats fora de la xarxa corporativa s'enviïn al servidor quan l'usuari es torni a connectar, reduint el temps durant el qual hi ha discrepàncies entre la còpia local i la remota.

Ajustar la mida màxima de la memòria cau mitjançant la directiva “Mida de memòria cau predeterminada”, on el valor s'indica com a percentatge amb dos decimals sense coma (per exemple 2550 per a un 25,50%). És important tenir en compte la capacitat real dels discos dels portàtils i el volum de dades que es pretén mantenir sense connexió.

Usuaris amb connexions lentes o sempre fora de l'oficina

Hi ha perfils d'usuaris que gairebé mai no trepitgen la xarxa corporativa amb una bona connexió, o que gairebé sempre es connecten mitjançant VPN amb poc ample de banda . Per a aquests casos pot resultar útil que treballin sempre en mode desconnectat i que la sincronització es faci només en moments concrets o sota determinades condicions.

La directiva “Configurar el mode d'enllaç de baixa velocitat” permet definir recursos compartits concrets que, per al sistema, s'han de tractar com si sempre estiguessin en un enllaç lent, establint paràmetres com Latency=1 per forçar la consideració d'aquesta ruta com a connexió lenta en sistemes espanyol o anglès.

Combinat amb això, es pot habilitar l'opció “Habilitar la sincronització de fitxers en xarxes estimades” , de manera que la sincronització automàtica sigui més respectuosa amb l'amplada de banda i no inundi connexions mòbils o Wi-Fi febles amb trànsit d'actualització de fitxers.

Amb la combinació correcta d'aquestes polítiques, es pot aconseguir que l'usuari treballi sempre des de la còpia local, i que els seus canvis se sincronitzin quan la màquina detecta una connexió més decent, reduint temps d'espera i queixes per lentitud.

Diagnòstic de problemes: Centre de sincronització, visor d'esdeveniments i PowerShell

Davant de qualsevol comportament estrany amb Offline Files, el primer punt de referència hauria de ser sempre el Centre de sincronització . Des d'aquí podeu revisar errors, conflictes i l'estat de cada associació de sincronització. És possible llançar sincronitzacions manuals, tant globals com sobre una carpeta o fitxer concret, la qual cosa ajuda a reproduir fallades sota demanda.

Quan el Centre de sincronització no dóna prou llum, el següent pas és acudir al Visor d'esdeveniments , a la ruta Registres d'aplicacions i serveis > Microsoft > Windows > OfflineFiles > Operatiu . En aquest registre s'emmagatzema un històric d'operacions, errors i advertiments emesos pel component de fitxers sense connexió, molt útil per identificar patrons recurrents o codis d'error específics.

En entorns grans, on hi ha desenes o centenars d'equips potencialment afectats, és pràctic estirar PowerShell i WMI per recollir informació de manera massiva. La classe Win32_OfflineFilesCache permet comprovar si la memòria cau de fitxers sense connexió està habilitada i activa, però es queda curta si volem saber quins elements concrets s'estan sincronitzant.

Per aprofundir més, es pot fer servir la classe Win32_OfflineFilesItem , que torna un llistat detallat de tot el que forma part d'Offline Files en un equip. Cada entrada inclou una propietat ItemType que indica si es tracta d'un servidor (3), un recurs compartit (2), un directori (1) o un fitxer (0), cosa que permet filtrar ràpidament aquells equips que realment estan sincronitzant fitxers i no només tenen restes d'associacions antigues.

Aquesta informació és especialment útil quan s'està preparant, per exemple, un script que deshabiliti automàticament Offline Files mitjançant una GPO local en equips on no s'està usant de debò la funció. Si un dispositiu només té elements de tipus “servidor” o “share” sense fitxers (tipus 0), es pot considerar segur desactivar la característica sense risc de perdre dades de l'usuari.

Com veus, els fitxers sense connexió són una eina potentíssima per mantenir la productivitat dels usuaris que treballen fora de la xarxa corporativa, però també una font habitual de maldecaps quan els permisos del servidor no estan ben ajustats, la memòria cau CSC es fa malbé o les polítiques de grup no s'han definit amb afecte. Entendre com funciona MUP, saber llegir el registre d'esdeveniments d'OfflineFiles, tenir clares les bones pràctiques de permisos UNC i dominar les opcions de GPO i PowerShell marca la diferència entre una infraestructura estable i una en què els usuaris perden confiança en les seves pròpies dades.