De ce conectarea prin VPN se târăște: profil, redirecționare sau fișiere offline
O conectare la distanță lentă înseamnă trei așteptări într-una. Măsurați separat încărcarea profilului, folderul redirecționat și cache-ul offline înainte de a schimba o politică.
Laptopul se conectează în aproximativ patruzeci de secunde la birou și durează minute acasă, iar între timp nimeni nu a schimbat o politică. Ce s-a schimbat este calea de rețea de sub trei funcții care arată la fel și se comportă diferit. Un profil mobil încarcă starea registrului și folderele profilului, redirecționarea folderelor indică un folder shell către o partajare de server, iar fișierele offline păstrează un cache cu date de rețea eligibile. Toate trei pot adăuga timp la o conectare, iar de obicei doar una dintre ele este responsabilă.
Trei așteptări cu trei responsabili diferiți
Profilul mobil este cel care face ca setările utilizatorului să urmeze o persoană între calculatoarele participante, iar încărcarea are loc devreme în sesiune. Ramura de registru a utilizatorului și folderele profilului sunt copiate sau fuzionate la conectare, apoi scrise înapoi la deconectare. Acea muncă este sincronă, motiv pentru care o cale lentă către partajarea profilului se simte ca un desktop lent și nu ca o copiere lentă de fișiere.
Redirecționarea folderelor este un alt mecanism. Mută foldere shell selectate, Documente este exemplul obișnuit, într-o locație de rețea acceptată și le lasă acolo. Profilul poate rămâne astfel mic, pentru că datele nu sunt în el, iar costul se mută în momentul în care shell-ul sau o aplicație atinge acel folder.
Fișierele offline adaugă un cache local plus sincronizare pentru fișierele de rețea eligibile. Ele răspund la o altă întrebare, și anume ce se întâmplă când serverul nu este accesibil, și pot petrece timp sincronizând la conectare și deconectare când cache-ul este învechit. Tratarea celor trei ca o singură setare este ceea ce produce o politică lentă într-o direcție și inutilă în cealaltă.
Măsurați care așteaptă cu adevărat
Începeți prin a citi unde locuiește profilul și dacă este încărcat de pe o cale de server. Apoi măsurați timpul unei liste de director pe fiecare partajare pe care sesiunea o atinge, pentru că o partajare care răspunde în milisecunde în rețeaua locală poate dura secunde printr-un tunel și un server de fișiere aglomerat.
Aceste două fapte restrâng problema mai repede decât orice audit de politică, și nu necesită nicio modificare de configurare pentru a fi colectate. Rulați-le pe laptopul afectat, nu pe un server care stă lângă partajare.
Get-CimInstance Win32_UserProfile | Select-Object LocalPath, Loaded, SID
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\*' | Select-Object ProfileImagePath
Measure-Command { Get-ChildItem '\\fs01.corp.internal\profiles\a.singh' | Out-Null }Dacă calea profilului este locală și doar un folder redirecționat indică un server, încărcarea profilului nu este așteptarea dvs., indiferent ce spune tichetul de asistență. Dacă calea profilului este la distanță și lista durează secunde, conectarea așteaptă acea partajare, iar remedierea privește calea sau dimensiunea profilului, nu desktopul în sine. Citiți numerele în această ordine și discuția se termină de obicei acolo.
Conexiunea sosește după ce așteptarea a început
Un tunel de utilizator care pornește de pe desktop apare mult după ce profilul a fost încărcat, deci nu poate ajuta etapa care a fost lentă. Windows observă calea indisponibilă, revine la credentiale din cache și la un profil local, iar sesiunea se deschide în cele din urmă. De aceea același laptop poate dura minute la prima conectare acasă și secunde la a doua, odată ce există un profil în cache. Așteptarea este reală, dar conexiunea de care are nevoie nu există în acel moment.
Remedierea înseamnă mutarea conexiunii mai devreme, nu reglarea profilului. Un tunel de mașină sau o conexiune înainte de conectare cu autentificare de calculator stabilește calea înainte ca utilizatorul să se conecteze și are nevoie de propriul ciclu de viață al certificatului și de propriile reguli de firewall. Credentialele din cache sunt cealaltă jumătate a proiectului și funcționează doar pentru conturile care s-au conectat anterior.
Testați secvența, nu componentele. Deconectați-vă complet, porniți tunelul așa cum ar face un utilizator de la distanță și măsurați conectarea de la solicitarea de credentiale până la un desktop utilizabil.
Țineți documentele în afara profilului
Partajarea profilului este locul greșit pentru colecții mari de documente, iar ghidul de implementare a profilelor mobile de la Microsoft ține de aceea separat stocarea profilului și partajările folderelor redirecționate. Un profil care transportă un folder Documente de mai mulți gigaocteți va fi lent la fiecare conectare și deconectare, iar dimensiunea crește în tăcere până când cineva o măsoară.
Redirecționați folderele care păstrează date și lăsați profilul să păstreze setări. Excludeți cache-urile care pot fi reconstruite, cum ar fi cache-urile browserelor și datele temporare ale aplicațiilor, pentru că transferarea lor adaugă timp și nu schimbă nimic ce vede utilizatorul. Păstrați datele cutiei poștale și alte depozite ale aplicațiilor în locația pe care aplicația o acceptă, nu pe o cale mobilă.
Nu faceți partajarea profilului disponibilă offline. Fișierele offline aparțin partajărilor de date eligibile, iar o ramură de profil din cache care se sincronizează în ambele sensuri este un raport de corupție care așteaptă să se întâmple.
Testați toate cele patru scenarii înainte de a-l declara rezolvat
O conectare rapidă la birou dovedește foarte puțin. Proiectul trebuie să reziste accesului de la birou, muncii de acasă prin tunel, muncii fără conexiune și întoarcerii la birou, pentru că în al patrulea caz apar conflictele de sincronizare. Măsurați aceleași patru cu un cont controlat și aplicațiile reale, și notați numerele.
Colectați jurnalul serviciului de profiluri și setul de politici rezultat din sesiunea afectată, nu din stația dumneavoastră de lucru administrativă.
Get-WinEvent -LogName 'Microsoft-Windows-User Profile Service/Operational' -MaxEvents 30
gpresult /r /scope:user
Measure-Command { Get-ChildItem '\\fs01.corp.internal\users\a.singh\Documents' | Out-Null }Comparați acele timpi cu linia de bază a biroului și cu dimensiunea a ceea ce este transferat. O conectare care durează încă un minut cu un profil mic și o partajare rapidă nu este o problemă de profil, iar următorul loc de privit este procesarea Politicii de grup sau un script de conectare care așteaptă rețeaua. Dacă acolo este diferența, profilul nu a fost niciodată problema. Confirmați că munca nesincronizată este păstrată înainte de a schimba o politică de foldere sau de a goli un cache, deoarece sincronizarea și o copie de siguranță recuperabilă sunt garanții diferite.