Proč se přihlášení přes VPN vleče: profil, přesměrování, nebo offline soubory

Notebook se v kanceláři přihlásí za zhruba čtyřicet sekund a doma mu to trvá minuty, a přitom nikdo žádnou zásadu nezměnil. Změnila se síťová cesta pod třemi funkcemi, které vypadají podobně a chovají se jinak. Cestovní profil načítá stav registru a složky profilu, přesměrování složek ukazuje složku prostředí na serverový share a offline soubory drží mezipaměť vhodných síťových dat. Všechny tři mohou přidat čas k přihlášení a obvykle je odpovědná jen jedna z nich.

Tři čekání se třemi různými vlastníky

Cestovní profil je ten, který nechává uživatelská nastavení následovat člověka mezi zúčastněnými počítači, a načtení probíhá brzy v relaci. Větev registru uživatele a složky profilu se při přihlášení zkopírují nebo sloučí a při odhlášení se zapíšou zpět. Tato práce je synchronní, a proto se pomalá cesta ke sdílené složce profilu projeví jako pomalá plocha, ne jako pomalé kopírování souborů.

Přesměrování složek je jiný mechanismus. Přesouvá vybrané složky prostředí, Dokumenty jsou obvyklý příklad, na podporované síťové umístění a nechává je tam. Profil pak může zůstat malý, protože data v něm nejsou, a náklad se přesouvá do okamžiku, kdy se složky dotkne prostředí nebo aplikace.

Offline soubory přidávají místní mezipaměť a synchronizaci pro vhodné síťové soubory. Odpovídají na jinou otázku, totiž co se stane, když je server nedostupný, a mohou trávit čas synchronizací při přihlášení a odhlášení, když je mezipaměť zastaralá. Právě to, že se s těmito třemi zachází jako s jedním nastavením, vytváří zásadu, která je v jednom směru pomalá a v druhém k ničemu.

Změřte, které z nich skutečně čeká

Začněte tím, kde profil žije a zda se načítá ze serverové cesty. Potom změřte výpis adresáře na každém share, kterého se relace dotkne, protože share, který přes LAN odpoví za milisekundy, může přes tunel a vytížený souborový server trvat sekundy.

Tyto dva údaje zúží problém rychleji než jakýkoli audit zásad a k jejich získání není potřeba měnit konfiguraci. Spusťte je na postiženém notebooku, ne na serveru, který stojí vedle shares.

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 }

Pokud je cesta profilu místní a na server ukazuje jen jedna přesměrovaná složka, načtení profilu není vaše čekání, ať tiket podpory říká cokoli. Pokud je cesta profilu vzdálená a výpis trvá sekundy, přihlášení čeká na tento share a oprava se týká cesty nebo velikosti profilu, ne samotné plochy. Čtěte čísla v tomto pořadí a spor obvykle tam skončí.

Připojení dorazí až po začátku čekání

Uživatelský tunel, který startuje z plochy, se objeví až dlouho potom, co je profil načtený, takže nemůže pomoci fázi, která byla pomalá. Windows si nedostupné cesty všimne, sáhne po uložených přihlašovacích údajích a místním profilu a relace se nakonec otevře. Proto stejný notebook může při prvním přihlášení doma trvat minuty a při druhém sekundy, jakmile je přítomný profil v mezipaměti. Čekání je skutečné, ale připojení, které potřebuje, v tom okamžiku neexistuje.

Oprava znamená posunout připojení dřív, ne ladit profil. Tunel počítače nebo připojení před přihlášením s ověřováním počítače ustaví cestu dřív, než se uživatel přihlásí, a potřebuje vlastní životní cyklus certifikátu a vlastní pravidla firewallu. Uložené přihlašovací údaje jsou druhá polovina návrhu a fungují jen pro účty, které se už někdy přihlásily.

Testujte sled, ne komponenty. Úplně se odhlaste, spusťte tunel tak, jak by to udělal vzdálený uživatel, a změřte přihlášení od výzvy k zadání údajů po použitelnou plochu.

Nechte dokumenty mimo profil

Sdílená složka profilu je špatné místo pro velké sbírky dokumentů a průvodce Microsoftu nasazením cestovních profilů právě proto drží úložiště profilů a shares přesměrovaných složek oddělené. Profil, který nese několika-gigabajtovou složku Dokumenty, bude pomalý při každém přihlášení a odhlášení a velikost tiše roste, dokud ji někdo nezměří.

Přesměrujte složky, které drží data, a profilu nechte nastavení. Vylučte mezipaměti, které lze znovu postavit, jako mezipaměti prohlížečů a dočasná data aplikací, protože jejich přenos přidává čas a nemění nic, co by uživatel viděl. Data poštovní schránky a další úložiště aplikací držte v umístění, které aplikace podporuje, ne na cestovní cestě.

Nedělejte sdílenou složku profilu dostupnou offline. Offline soubory patří na vhodné datové shares a větev profilu v mezipaměti, která se synchronizuje oběma směry, je zpráva o poškození, která čeká, až se stane.

Než to označíte za opravené, otestujte všechny čtyři scénáře

Přihlášení rychlé v kanceláři dokazuje velmi málo. Návrh musí přežít přístup z kanceláře, práci z domova přes tunel, práci bez připojení a návrat do kanceláře, protože právě ve čtvrtém případě se objevují konflikty synchronizace. Změřte tytéž čtyři případy na jednom kontrolovaném účtu a se skutečnými aplikacemi a čísla si zapište.

Seberte protokol služby profilů a výslednou sadu zásad z postižené relace, ne ze své administrativní pracovní stanice.

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 }

Porovnejte tyto časy s kancelářskou základnou a s velikostí toho, co se přenáší. Přihlášení, které i s malým profilem a rychlým sharem trvá minutu, není problém profilu a dalším místem, kam se podívat, je zpracování zásad skupiny nebo přihlašovací skript, který čeká na síť. Pokud je mezera tam, profil nikdy problémem nebyl. Než změníte zásadu složek nebo vymažete mezipaměť, potvrďte, že nesynchronizovaná práce je zachovaná, protože synchronizace a obnovitelná záloha jsou různé záruky.