Hvorfor logon over VPN går langsomt: profil, omdirigering eller offlinefiler

Bærbaren logger på på cirka fyrre sekunder på kontoret og tager minutter derhjemme, og ingen har ændret en politik undervejs. Det, der er ændret, er netværksvejen under tre funktioner, som ligner hinanden og opfører sig forskelligt. En roaming-profil indlæser registreringsdatabasens tilstand og profilmapper, mappeomdirigering peger en shell-mappe mod en servershare, og offlinefiler holder en cache med kvalificerede netværksdata. Alle tre kan lægge tid til et logon, og normalt er kun én af dem ansvarlig.

Tre ventetider med tre forskellige ejere

Det er roaming-profilen, der får brugerindstillinger til at følge en person mellem deltagende computere, og indlæsningen sker tidligt i sessionen. Brugerens registreringsdatabase og profilmapper kopieres eller flettes ved logon og skrives derefter tilbage ved logoff. Det arbejde er synkront, og derfor føles en langsom vej til profilsharen som et langsomt skrivebord og ikke som en langsom filkopiering.

Mappeomdirigering er en anden mekanisme. Den flytter udvalgte shell-mapper, Dokumenter er det typiske eksempel, til en understøttet netværksplacering og lader dem blive der. Profilen kan så forblive lille, fordi dataene ikke er i den, og omkostningen flytter til det øjeblik, hvor shellen eller et program rører den mappe.

Offlinefiler tilføjer en lokal cache plus synkronisering for kvalificerede netværksfiler. De svarer på et andet spørgsmål, nemlig hvad der sker, når serveren ikke kan nås, og de kan bruge tid på synkronisering ved logon og logoff, når cachen er forældet. Det er behandlingen af de tre som én indstilling, der skaber en politik, som er langsom i den ene retning og ubrugelig i den anden.

Mål hvilken der faktisk venter

Start med at læse, hvor profilen bor, og om den indlæses fra en serversti. Mål derefter en mappeliste på hver share, som sessionen rører, fordi en share, der svarer på millisekunder over LAN'et, kan tage sekunder gennem en tunnel og en travl filserver.

De to fakta indsnævrer problemet hurtigere end enhver politikrevision, og de kræver ingen konfigurationsændring at indsamle. Kør dem på den berørte bærbare, ikke på en server, der står ved siden af sharen.

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 }

Hvis profilens sti er lokal, og kun én omdirigeret mappe peger på en server, er profilindlæsningen ikke din ventetid, uanset hvad helpdesk-sagen siger. Hvis profilens sti er fjern, og listen tager sekunder, venter logon på den share, og løsningen handler om stien eller profilens størrelse og ikke om selve skrivebordet. Læs tallene i den rækkefølge, og diskussionen slutter normalt der.

Forbindelsen kommer, efter at ventetiden er begyndt

En brugertunnel, der starter fra skrivebordet, dukker op længe efter, at profilen er indlæst, så den kan ikke hjælpe den fase, der var langsom. Windows bemærker den utilgængelige sti, falder tilbage til cachelagrede legitimationsoplysninger og en lokal profil, og sessionen åbner til sidst. Derfor kan den samme bærbare tage minutter ved det første logon hjemme og sekunder ved det andet, når der er en cachelagret profil. Ventetiden er reel, men den forbindelse, den har brug for, findes ikke på det tidspunkt.

At løse det betyder at flytte forbindelsen tidligere, ikke at tune profilen. En maskintunnel eller en forbindelse før logon med computeridentifikation etablerer stien, før brugeren logger på, og den kræver sin egen certifikatlivscyklus og sine egne firewallregler. Cachelagrede legitimationsoplysninger er den anden halvdel af designet, og de virker kun for konti, der har logget på før.

Test sekvensen i stedet for komponenterne. Log helt af, start tunnelen, som en fjernbruger ville gøre, og mål logon fra legitimationsoplysningsprompten til et brugbart skrivebord.

Hold dokumenter ude af profilen

Profilsharen er det forkerte sted til store dokumentsamlinger, og Microsofts implementeringsvejledning til roaming-profiler holder netop derfor profillagring og shares til omdirigerede mapper adskilt. En profil, der bærer en Dokumenter-mappe på flere gigabyte, vil være langsom ved hvert logon og logoff, og størrelsen vokser lydløst, indtil nogen måler den.

Omdiriger de mapper, der holder data, og lad profilen holde indstillinger. Udeluk cacher, der kan genopbygges, som browsercaches og programmers midlertidige data, fordi overførsel af dem lægger tid til og ikke ændrer noget, en bruger kan se. Hold postkassedata og andre programlagre på den placering, programmet understøtter, i stedet for på en roaming-sti.

Gør ikke profilsharen tilgængelig offline. Offlinefiler hører på kvalificerede datashares, og en cachelagret profilregistreringsdatabase, der synkroniserer i begge retninger, er en korruptionsrapport, der venter på at ske.

Test alle fire scenarier, før du kalder det løst

Et logon, der er hurtigt på kontoret, beviser meget lidt. Designet skal overleve kontoradgang, hjemmearbejde over tunnelen, arbejde uden forbindelse og tilbagevenden til kontoret, fordi det er i det fjerde tilfælde, synkroniseringskonflikter viser sig. Mål de samme fire med én kontrolleret konto og de rigtige programmer, og skriv tallene ned.

Indsaml profiltjenestens log og det resulterende politiksaet fra den berørte session, ikke fra din administrative arbejdsstation.

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 }

Sammenlign de tider med kontorets baseline og med størrelsen af det, der overføres. Et logon, der stadig tager et minut med en lille profil og en hurtig share, er ikke et profilproblem, og det næste sted at kigge er gruppepolitikbehandling eller et logon-script, der venter på netværket. Hvis forskellen ligger der, har profilen aldrig været problemet. Bekræft, at usynkroniseret arbejde er bevaret, før du ændrer en mappepolitik eller rydder en cache, da synkronisering og en gendannelig sikkerhedskopi er forskellige garantier.