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

Den bærbare maskinen loggar på i om lag førti sekund på kontoret og brukar minutt heime, og ingen har endra ein policy i mellomtida. Det som er endra, er nettverksvegen under tre funksjonar som ser like ut og oppfører seg ulikt. Ein roaming-profil lastar inn registertilstanden og profilmappene, mappeomdirigering peikar ei skallmappe mot ei tenardeling, og offline filer held ein buffer med kvalifiserte nettverksdata. Alle tre kan leggje tid til ei pålogging, og vanlegvis er berre éin av dei ansvarleg.

Tre ventetider med tre ulike eigarar

Det er roaming-profilen som får brukarinnstillingar til å følgje ein person mellom deltakande datamaskiner, og innlastinga skjer tidleg i økta. Registergreina til brukaren og profilmappene vert kopierte eller samanslåtte ved pålogging og skrivne tilbake ved avlogging. Det arbeidet er synkront, og difor kjennest ein treg veg til profildelinga som eit tregt skrivebord og ikkje som ei treg filkopiering.

Mappeomdirigering er ein annan mekanisme. Ho flyttar utvalde skallmapper, Dokument er det vanlege dømet, til ein støtta nettverksstad og lèt dei bli der. Profilen kan då halde seg liten, fordi dataa ikkje er i han, og kostnaden flyttar seg til augneblinken då skalet eller eit program rører den mappa.

Offline filer legg til ein lokal buffer pluss synkronisering for kvalifiserte nettverksfiler. Dei svarar på eit anna spørsmål, nemleg kva som skjer når tenaren ikkje er tilgjengeleg, og dei kan bruke tid på synkronisering ved pålogging og avlogging når bufferen er utdatert. Det er handsaminga av dei tre som éi innstilling som lagar ein policy som er treg i éi retning og ubrukeleg i den andre.

Mål kva som faktisk ventar

Byrja med å lese kvar profilen bur og om han vert lasta frå ein tenarveg. Mål deretter tida for ei katalogliste på kvar deling økta rører, fordi ei deling som svarar på millisekund på LAN-et kan ta sekund gjennom ein tunnel og ein travel filtenar.

Desse to fakta avgrensar problemet raskare enn nokon policyrevisjon, og dei krev inga konfigurasjonsendring å samle inn. Køyr dei på den råka bærbare maskinen, ikkje på ein tenar som står ved sida av delinga.

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 }

Viss profilvegen er lokal og berre éi omdirigert mappe peikar på ein tenar, er ikkje profilinnlastinga ventetida di, uansett kva helpdesk-saka seier. Viss profilvegen er ekstern og lista tek sekund, ventar pålogginga på den delinga, og løysinga handlar om vegen eller storleiken på profilen og ikkje om sjølve skrivebordet. Les tala i den rekkjefølgja, og diskusjonen sluttar vanlegvis der.

Tilkoplinga kjem etter at ventetida har byrja

Ein brukartunnel som startar frå skrivebordet dukkar opp lenge etter at profilen er lasta, så han kan ikkje hjelpe fasen som var treg. Windows merkar den utilgjengelege vegen, fell tilbake til bufra påloggingsopplysningar og ein lokal profil, og økta opnar til slutt. Difor kan same bærbare maskin ta minutt ved fyrste pålogging heime og sekund ved den andre, når det finst ein bufra profil. Ventetida er reell, men tilkoplinga ho treng finst ikkje på det tidspunktet.

Å fikse det tyder å flytte tilkoplinga tidlegare, ikkje å tune profilen. Ein maskintunnel eller ei tilkopling før pålogging med datamaskinautentisering etablerer vegen før brukaren loggar på, og ho treng sin eigen sertifikatlivssyklus og eigne brannmurreglar. Bufra påloggingsopplysningar er den andre halvdelen av designet, og dei verkar berre for kontoar som har logga på før.

Test sekvensen i staden for komponentane. Logg heilt av, start tunnelen slik ein fjernbrukar ville gjere, og mål pålogginga frå påloggingsførespurnaden til eit brukbart skrivebord.

Hald dokument utanfor profilen

Profildelinga er feil stad for store dokumentsamlingar, og utplasseringsrettleiinga for roaming-profilar hjå Microsoft held nettopp difor profillagring og delingar for omdirigerte mapper fråskilde. Ein profil som ber ei Dokument-mappe på fleire gigabyte vil vere treg ved kvar pålogging og avlogging, og storleiken veks stille til nokon målar han.

Omdiriger mappene som held data, og lat profilen halde innstillingar. Utelat buffar som kan byggjast opp att, som nettlesarbuffar og mellombelse programdata, fordi overføring av dei legg til tid og endrar ingenting ein brukar ser. Hald postkassedata og andre programlager på staden programmet støttar, og ikkje på ein roaming-veg.

Ikkje gjer profildelinga tilgjengeleg offline. Offline filer høyrer til kvalifiserte datadelingar, og ei bufra profilgrein som synkroniserer i båe retningar er ein korrupsjonsrapport som ventar på å skje.

Test alle fire scenaria før du kallar det løyst

Ei pålogging som er rask på kontoret provar svært lite. Designet må tole kontortilgang, arbeid heimanfrå over tunnelen, arbeid utan tilkopling og tilbakekomsten til kontoret, fordi det er i det fjerde tilfellet synkroniseringskonfliktar dukkar opp. Mål dei same fire med éin kontrollert konto og dei ekte programma, og skriv ned tala.

Samle loggen til profiltenesta og policysettet som følgjer av den råka økta, ikkje frå 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 }

Samanlikn desse tidene med grunnlinja på kontoret og med storleiken på det som vert overført. Ei pålogging som framleis tek eitt minutt med ein liten profil og ei rask deling er ikkje eit profilproblem, og neste stad å sjå er gruppepolicyhandsaming eller eit påloggingsskript som ventar på nettverket. Viss gapet ligg der, var profilen aldri problemet. Stadfest at usynkronisert arbeid er teke vare på før du endrar ein mappepolicy eller tømmer ein buffer, sidan synkronisering og ein gjenopprettbar tryggingskopi er ulike garantiar.