Varför inloggning via VPN går långsamt: profil, omdirigering eller offlinefiler

Den bärbara datorn loggar in på cirka fyrtio sekunder på kontoret och tar minuter hemma, och ingen har ändrat en princip under tiden. Det som har ändrats är nätverksvägen under tre funktioner som ser likadana ut och beter sig olika. En roaming-profil läser in registertillståndet och profilmapparna, mappomdirigering pekar en skalmapp mot en serverresurs, och offlinefiler håller en cache med kvalificerade nätverksdata. Alla tre kan lägga tid till en inloggning, och vanligtvis är bara en av dem ansvarig.

Tre väntetider med tre olika ansvariga

Det är roaming-profilen som får användarinställningar att följa en person mellan deltagande datorer, och inläsningen sker tidigt i sessionen. Användarens registergren och profilmapparna kopieras eller sammanfogas vid inloggning och skrivs tillbaka vid utloggning. Det arbetet är synkront, och därför känns en långsam väg till profilresursen som ett långsamt skrivbord och inte som en långsam filkopiering.

Mappomdirigering är en annan mekanism. Den flyttar valda skalmappar, Dokument är det vanliga exemplet, till en plats i nätverket som stöds och låter dem stanna där. Profilen kan då förbli liten, eftersom data inte finns i den, och kostnaden flyttas till det ögonblick då skalet eller ett program rör den mappen.

Offlinefiler lägger till en lokal cache plus synkronisering för kvalificerade nätverksfiler. De svarar på en annan fråga, nämligen vad som händer när servern inte är nåbar, och de kan lägga tid på synkronisering vid in- och utloggning när cachen är inaktuell. Det är behandlingen av de tre som en enda inställning som skapar en princip som är långsam i en riktning och oanvändbar i den andra.

Mät vilken som faktiskt väntar

Börja med att läsa var profilen bor och om den läses in från en serversökväg. Mät sedan tiden för en kataloglista på varje resurs som sessionen rör, eftersom en resurs som svarar på millisekunder i det lokala nätet kan ta sekunder genom en tunnel och en upptagen filserver.

Dessa två fakta begränsar problemet snabbare än någon principgranskning, och de kräver ingen konfigurationsändring för att samlas in. Kör dem på den drabbade bärbara datorn, inte på en server som står bredvid resursen.

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 }

Om profilsökvägen är lokal och bara en omdirigerad mapp pekar på en server, är profilinläsningen inte din väntetid, vad supportärendet än säger. Om profilsökvägen är fjärransluten och listan tar sekunder, väntar inloggningen på den resursen, och rättelsen handlar om sökvägen eller profilens storlek och inte om själva skrivbordet. Läs siffrorna i den ordningen och diskussionen slutar oftast där.

Anslutningen kommer efter att väntan har börjat

En användartunnel som startar från skrivbordet dyker upp långt efter att profilen har lästs in, så den kan inte hjälpa det steg som var långsamt. Windows märker den otillgängliga sökvägen, faller tillbaka på cachelagrade autentiseringsuppgifter och en lokal profil, och sessionen öppnas till slut. Därför kan samma bärbara dator ta minuter vid den första inloggningen hemma och sekunder vid den andra, när det finns en cachelagrad profil. Väntan är verklig, men den anslutning den behöver finns inte i det ögonblicket.

Att åtgärda det innebär att flytta anslutningen tidigare, inte att trimma profilen. En maskintunnel eller en anslutning före inloggning med datorautentisering upprättar vägen innan användaren loggar in, och den behöver sin egen certifikatlivscykel och sina egna brandväggsregler. Cachelagrade autentiseringsuppgifter är den andra halvan av designen, och de fungerar bara för konton som har loggat in tidigare.

Testa sekvensen och inte komponenterna. Logga ut helt, starta tunneln som en fjärranvändare skulle göra, och mät inloggningen från autentiseringsbegäran till ett användbart skrivbord.

Håll dokument utanför profilen

Profilresursen är fel plats för stora dokumentsamlingar, och Microsofts distributionsguide för roaming-profiler håller just därför profillagring och resurser för omdirigerade mappar åtskilda. En profil som bär en Dokument-mapp på flera gigabyte blir långsam vid varje in- och utloggning, och storleken växer tyst tills någon mäter den.

Omdirigera mapparna som håller data, och låt profilen hålla inställningar. Uteslut cacheminnen som kan byggas upp igen, som webbläsarcache och tillfälliga programdata, eftersom överföringen av dem lägger till tid och inte ändrar något som en användare ser. Håll postlådedata och andra programlager på den plats som programmet stöder, och inte på en roaming-sökväg.

Gör inte profilresursen tillgänglig offline. Offlinefiler hör till kvalificerade dataresurser, och en cachelagrad profilgren som synkroniserar i båda riktningarna är en korruptionsrapport som väntar på att inträffa.

Testa alla fyra scenarier innan du kallar det löst

En snabb inloggning på kontoret bevisar mycket lite. Designen måste klara kontorsåtkomst, arbete hemifrån via tunneln, arbete utan anslutning och återkomsten till kontoret, eftersom det är i det fjärde fallet som synkroniseringskonflikter dyker upp. Mät samma fyra med ett kontrollerat konto och de riktiga programmen, och skriv ned siffrorna.

Samla in loggen för profiltjänsten och den resulterande principuppsättningen från den drabbade sessionen, inte från din administrativa arbetsstation.

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 }

Jämför de tiderna med kontorets baslinje och med storleken på det som överförs. En inloggning som fortfarande tar en minut med en liten profil och en snabb resurs är inte ett profilproblem, och nästa ställe att titta på är grupprincipbehandling eller ett inloggningsskript som väntar på nätverket. Om gapet ligger där var profilen aldrig problemet. Bekräfta att osynkroniserat arbete är bevarat innan du ändrar en mapprincip eller rensar en cache, eftersom synkronisering och en återställbar säkerhetskopia är olika garantier.