Waarom aanmelden via VPN traag gaat: profiel, omleiding of offline bestanden

De laptop meldt zich op kantoor in ongeveer veertig seconden aan en doet er thuis minuten over, en niemand heeft intussen een beleid gewijzigd. Wat is veranderd, is het netwerkpad onder drie functies die er hetzelfde uitzien en zich anders gedragen. Een roamingprofiel laadt de registerstatus en de profielmappen, mapomleiding wijst een shellmap naar een servershare, en Offline bestanden houden een cache bij van geschikte netwerkgegevens. Alle drie kunnen tijd aan een aanmelding toevoegen, en meestal is maar één ervan verantwoordelijk.

Drie wachttijden met drie verschillende eigenaren

Het roamingprofiel is degene die gebruikersinstellingen een persoon laat volgen tussen deelnemende computers, en het laden gebeurt vroeg in de sessie. De registercomponent van de gebruiker en de profielmappen worden bij aanmelding gekopieerd of samengevoegd en bij afmelding teruggeschreven. Dat werk is synchroon, waardoor een traag pad naar de profielshare aanvoelt als een traag bureaublad en niet als een trage bestandskopie.

Mapomleiding is een ander mechanisme. Het verplaatst geselecteerde shellmappen, Documenten is het gebruikelijke voorbeeld, naar een ondersteunde netwerklocatie en laat ze daar staan. Het profiel kan dan klein blijven, omdat de gegevens er niet in zitten, en de kosten verschuiven naar het moment waarop de shell of een toepassing die map aanraakt.

Offline bestanden voegen een lokale cache plus synchronisatie toe voor geschikte netwerkbestanden. Ze beantwoorden een andere vraag, namelijk wat er gebeurt als de server onbereikbaar is, en ze kunnen bij aanmelding en afmelding tijd aan synchronisatie besteden wanneer de cache verouderd is. Juist het behandelen van de drie als één instelling levert een beleid op dat in de ene richting traag en in de andere nutteloos is.

Meet welke echt wacht

Begin met te lezen waar het profiel woont en of het van een serverpad wordt geladen. Meet daarna de tijd van een mapvermelding op elke share die de sessie aanraakt, want een share die op het LAN in milliseconden antwoordt, kan via een tunnel en een drukke fileserver seconden kosten.

Die twee feiten beperken het probleem sneller dan welke beleidsaudit dan ook, en ze vereisen geen configuratiewijziging om te verzamelen. Voer ze uit op de getroffen laptop, niet op een server die naast de share staat.

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 }

Als het profielpad lokaal is en slechts één omgeleide map naar een server wijst, is het laden van het profiel niet uw wachttijd, wat het helpdeskticket ook zegt. Als het profielpad extern is en de vermelding seconden kost, wacht de aanmelding op die share, en de oplossing gaat over het pad of de profielgrootte en niet over het bureaublad zelf. Lees de cijfers in die volgorde en de discussie eindigt meestal daar.

De verbinding komt pas nadat het wachten is begonnen

Een gebruikers-tunnel die vanaf het bureaublad start, verschijnt ruim nadat het profiel is geladen, dus kan die de fase die traag was niet helpen. Windows merkt het onbeschikbare pad op, valt terug op in de cache opgeslagen referenties en een lokaal profiel, en de sessie gaat uiteindelijk open. Daarom kan dezelfde laptop bij de eerste aanmelding thuis minuten en bij de tweede seconden nodig hebben, zodra er een profiel in de cache staat. Het wachten is echt, maar de verbinding die het nodig heeft bestaat op dat moment niet.

Dat oplossen betekent de verbinding eerder leggen, niet het profiel afstellen. Een machinetunnel of een verbinding vóór aanmelding met computerauthenticatie legt het pad voordat de gebruiker zich aanmeldt, en heeft zijn eigen certificaatlevenscyclus en eigen firewallregels nodig. In de cache opgeslagen referenties zijn de andere helft van het ontwerp, en ze werken alleen voor accounts die zich eerder hebben aangemeld.

Test de volgorde en niet de onderdelen. Meld u volledig af, start de tunnel zoals een externe gebruiker dat zou doen, en meet de aanmelding van de referentievraag tot een bruikbaar bureaublad.

Houd documenten buiten het profiel

De profielshare is de verkeerde plek voor grote documentverzamelingen, en de implementatiehandleiding voor roamingprofielen van Microsoft houdt daarom profielopslag en shares van omgeleide mappen gescheiden. Een profiel dat een map Documenten van meerdere gigabytes draagt, is bij elke aan- en afmelding traag, en de grootte groeit stil door tot iemand hem meet.

Leid de mappen om die gegevens bevatten, en laat het profiel instellingen bevatten. Sluit caches uit die opnieuw kunnen worden opgebouwd, zoals browsercaches en tijdelijke toepassingsgegevens, want het overbrengen ervan kost tijd en verandert niets dat een gebruiker ziet. Houd mailboxgegevens en andere toepassingsopslag op de locatie die de toepassing ondersteunt, en niet op een roamingpad.

Maak de profielshare niet offline beschikbaar. Offline bestanden horen op geschikte gegevensshares, en een registercomponent van een profiel in de cache die in beide richtingen synchroniseert, is een corruptierapport dat staat te wachten om te gebeuren.

Test alle vier scenario's voordat u het opgelost noemt

Een snelle aanmelding op kantoor bewijst heel weinig. Het ontwerp moet kantoortoegang, thuiswerken via de tunnel, werken zonder verbinding en de terugkeer naar kantoor doorstaan, want in het vierde geval verschijnen de synchronisatieconflicten. Meet dezelfde vier met één gecontroleerd account en de echte toepassingen, en schrijf de cijfers op.

Verzamel het logboek van de profielservice en de resulterende beleidsset uit de getroffen sessie, niet vanaf uw administratieve werkstation.

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 }

Vergelijk die tijden met de basislijn van kantoor en met de grootte van wat wordt overgedragen. Een aanmelding die met een klein profiel en een snelle share nog een minuut duurt, is geen profielprobleem, en de volgende plek om te kijken is de verwerking van groepsbeleid of een aanmeldingsscript dat op het netwerk wacht. Als daar de kloof zit, was het profiel nooit het probleem. Controleer of niet-gesynchroniseerd werk bewaard blijft voordat u een mapbeleid wijzigt of een cache leegmaakt, want synchronisatie en een herstelbare back-up zijn verschillende garanties.