Hvorfor pålogging over VPN går sakte: profil, omdirigering eller offline filer

Bærbaren logger på i omtrent førti sekunder på kontoret og bruker minutter hjemme, og ingen har endret en policy i mellomtiden. Det som er endret, er nettverksbanen under tre funksjoner som ser like ut og oppfører seg ulikt. En roaming-profil laster inn registertilstanden og profilmappene, mappeomdirigering peker en skallmappe mot en serverdeling, og offline filer holder en buffer med kvalifiserte nettverksdata. Alle tre kan legge tid til en pålogging, og vanligvis er bare én av dem ansvarlig.

Tre ventetider med tre forskjellige eiere

Det er roaming-profilen som får brukerinnstillinger til å følge en person mellom deltakende datamaskiner, og innlastingen skjer tidlig i økten. Brukerens registergren og profilmappene kopieres eller flettes ved pålogging og skrives tilbake ved avlogging. Det arbeidet er synkront, og derfor føles en treg bane til profildelingen som et tregt skrivebord og ikke som en treg filkopiering.

Mappeomdirigering er en annen mekanisme. Den flytter utvalgte skallmapper, Dokumenter er det vanlige eksempelet, til et støttet nettverkssted og lar dem bli der. Profilen kan da forbli liten, fordi dataene ikke er i den, og kostnaden flyttes til øyeblikket da skall eller et program berører den mappen.

Offline filer legger til en lokal buffer pluss synkronisering for kvalifiserte nettverksfiler. De svarer på et annet spørsmål, nemlig hva som skjer når serveren ikke er tilgjengelig, og de kan bruke tid på synkronisering ved pålogging og avlogging når bufferen er utdatert. Det er behandlingen av de tre som én innstilling som lager en policy som er treg i én retning og ubrukelig i den andre.

Mål hvilken som faktisk venter

Begynn med å lese hvor profilen bor og om den lastes fra en serverbane. Mål deretter tiden for en katalogliste på hver deling økten berører, fordi en deling som svarer på millisekunder på LAN-et kan ta sekunder gjennom en tunnel og en travel filserver.

Disse to faktaene snevrer inn problemet raskere enn noen policyrevisjon, og de krever ingen konfigurasjonsendring å samle inn. Kjør dem på den berørte bærbaren, ikke på en server som står ved siden av delingen.

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 profilbanen er lokal og bare én omdirigert mappe peker på en server, er ikke profilinnlastingen din ventetid, uansett hva helpdesk-saken sier. Hvis profilbanen er ekstern og listen tar sekunder, venter påloggingen på den delingen, og løsningen handler om banen eller profilens størrelse og ikke om selve skrivebordet. Les tallene i den rekkefølgen, og diskusjonen slutter vanligvis der.

Tilkoblingen kommer etter at ventingen har begynt

En brukertunnel som starter fra skrivebordet dukker opp lenge etter at profilen er lastet, så den kan ikke hjelpe fasen som var treg. Windows merker den utilgjengelige banen, faller tilbake til bufrede påloggingsopplysninger og en lokal profil, og økten åpnes til slutt. Derfor kan samme bærbare ta minutter ved første pålogging hjemme og sekunder ved den andre, når det finnes en bufret profil. Ventingen er reell, men tilkoblingen den trenger finnes ikke på det tidspunktet.

Å fikse det betyr å flytte tilkoblingen tidligere, ikke å tune profilen. En maskintunnel eller en tilkobling før pålogging med datamaskinautentisering etablerer banen før brukeren logger på, og den trenger sin egen sertifikatlivssyklus og egne brannmurregler. Bufrede påloggingsopplysninger er den andre halvdelen av designet, og de virker bare for kontoer som har logget på før.

Test sekvensen i stedet for komponentene. Logg helt av, start tunnelen slik en fjernbruker ville gjort, og mål påloggingen fra påloggingsforespørselen til et brukbart skrivebord.

Hold dokumenter utenfor profilen

Profildelingen er feil sted for store dokumentsamlinger, og Microsofts utplasseringsveiledning for roaming-profiler holder nettopp derfor profillagring og delinger for omdirigerte mapper atskilt. En profil som bærer en Dokumenter-mappe på flere gigabyte vil være treg ved hver pålogging og avlogging, og størrelsen vokser stille til noen måler den.

Omdiriger mappene som holder data, og la profilen holde innstillinger. Utelat buffere som kan bygges opp igjen, som nettleserbuffere og midlertidige programdata, fordi overføring av dem legger til tid og ikke endrer noe en bruker ser. Hold postkassedata og andre programlagre på stedet programmet støtter, og ikke på en roaming-bane.

Ikke gjør profildelingen tilgjengelig offline. Offline filer hører til kvalifiserte datadelinger, og en bufret profilgren som synkroniserer i begge retninger er en korrupsjonsrapport som venter på å skje.

Test alle fire scenarioene før du kaller det løst

En pålogging som er rask på kontoret beviser svært lite. Designet må tåle kontortilgang, arbeid hjemmefra over tunnelen, arbeid uten tilkobling og tilbakekomsten til kontoret, fordi det er i det fjerde tilfellet synkroniseringskonflikter dukker opp. Mål de samme fire med én kontrollert konto og de ekte programmene, og skriv ned tallene.

Samle loggen til profiltjenesten og policiesettet som følger av den berørte økten, ikke fra din administrative arbeidsstasjon.

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 disse tidene med kontorets grunnlinje og med størrelsen på det som overføres. En pålogging som fortsatt tar et minutt med en liten profil og en rask deling er ikke et profilproblem, og neste sted å se er gruppepolicybehandling eller et påloggingsskript som venter på nettverket. Hvis gapet ligger der, var profilen aldri problemet. Bekreft at usynkronisert arbeid er bevart før du endrer en mappepolicy eller tømmer en buffer, siden synkronisering og en gjenopprettbar sikkerhetskopi er forskjellige garantier.