Kāpēc pieteikšanās caur VPN ir lēna: profils, novirzīšana vai bezsaistes faili

Klēpjdators birojā pieteicas apmēram četrdesmit sekundēs, bet mājās tas aizņem minūtes, un starplaikā neviens nav mainījis politiku. Mainījies ir tīkla ceļš zem trim funkcijām, kas izskatās līdzīgas un uzvedas atšķirīgi. Klejojošais profils ielādē reģistra stāvokli un profila mapes, mapju novirzīšana norāda apvalka mapi uz servera koplietojumu, un bezsaistes faili tur kešatmiņu ar piemērotiem tīkla datiem. Visas trīs var pievienot laiku pieteikšanās procesam, un parasti atbildīga ir tikai viena no tām.

Trīs gaidīšanas ar trim dažādiem atbildīgajiem

Tieši klejojošais profils liek lietotāja iestatījumiem sekot cilvēkam starp dalības datoriem, un ielāde notiek sesijas sākumā. Lietotāja reģistra atzars un profila mapes pieteikšanās laikā tiek kopētas vai apvienotas, bet izrakstīšanās laikā ierakstītas atpakaļ. Šis darbs ir sinhrons, tāpēc lēns ceļš uz profila koplietojumu tiek uztverts kā lēns darbvirsma, nevis kā lēna failu kopēšana.

Mapju novirzīšana ir cits mehānisms. Tā pārvieto atlasītās apvalka mapes, un Dokumenti ir ierastais piemērs, uz atbalstītu tīkla vietu un atstāj tās tur. Tad profils var palikt mazs, jo dati tajā nav, un izmaksas pāriet uz to brīdi, kad apvalks vai lietojumprogramma pieskaras šai mapei.

Bezsaistes faili pievieno vietēju kešatmiņu un sinhronizāciju piemērotiem tīkla failiem. Tie atbild uz citu jautājumu, proti, kas notiek, kad serveris nav sasniedzams, un tie var tērēt laiku sinhronizācijai pieteikšanās un izrakstīšanās laikā, kad kešatmiņa ir novecojusi. Tieši visu trīs uztveršana kā viens iestatījums rada politiku, kas ir lēna vienā virzienā un bezjēdzīga otrā.

Izmēriet, kas patiešām gaida

Sāciet ar to, kur dzīvo profils un vai tas tiek ielādēts no servera ceļa. Pēc tam izmēriet kataloga saraksta laiku katrā koplietojumā, kam pieskaras sesija, jo koplietojums, kas vietējā tīklā atbild milisekundēs, caur tuneli un noslogotu failu serveri var aizņemt sekundes.

Šie divi fakti sašaurina problēmu ātrāk nekā jebkurš politikas audits, un to vākšanai nav vajadzīgas konfigurācijas izmaiņas. Palaidiet tos skartajā klēpjdatorā, nevis serverī, kas stāv blakus koplietojumam.

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 }

Ja profila ceļš ir vietējs un tikai viena novirzītā mape norāda uz serveri, profila ielāde nav jūsu gaidīšana, lai ko teiktu atbalsta biļete. Ja profila ceļš ir attālināts un saraksts aizņem sekundes, pieteikšanās gaida šo koplietojumu, un risinājums attiecas uz ceļu vai profila lielumu, nevis uz pašu darbvirsmu. Lasiet skaitļus šajā secībā, un diskusija parasti tur arī beidzas.

Savienojums pienāk pēc tam, kad gaidīšana jau sākusies

Lietotāja tunelis, kas sākas no darbvirsmas, parādās krietni pēc tam, kad profils jau ielādēts, tāpēc tas nevar palīdzēt posmam, kas bija lēns. Windows pamana nepieejamo ceļu, atgriežas pie kešatmiņā saglabātajiem akreditācijas datiem un vietējā profila, un sesija galu galā atveras. Tāpēc viens un tas pats klēpjdators mājās pirmajā pieteikšanās reizē var aizņemt minūtes, bet otrajā – sekundes, tiklīdz ir kešatmiņā saglabāts profils. Gaidīšana ir reāla, bet savienojums, kas tam vajadzīgs, tajā brīdī nepastāv.

To labot nozīmē pārcelt savienojumu agrāk, nevis regulēt profilu. Mašīnas tunelis vai savienojums pirms pieteikšanās ar datora autentifikāciju izveido ceļu pirms lietotājs pieteicas, un tam vajadzīgs savs sertifikāta dzīves cikls un savi ugunsmūra noteikumi. Kešatmiņā saglabātie akreditācijas dati ir otra dizaina puse, un tie darbojas tikai kontiem, kuri jau iepriekš ir pieteikušies.

Pārbaudiet secību, nevis komponentus. Izrakstieties pilnībā, palaidiet tuneli tā, kā to darītu attālināts lietotājs, un izmēriet pieteikšanos no akreditācijas datu pieprasījuma līdz lietojamai darbvirsmai.

Turiet dokumentus ārpus profila

Profila koplietojums ir nepareizā vieta lielām dokumentu kolekcijām, un Microsoft klejojošo profilu izvietošanas rokasgrāmata tieši tāpēc tur profila glabātuvi un novirzīto mapju koplietojumus atsevišķi. Profils, kas nes vairāku gigabaitu Dokumentu mapi, būs lēns katrā pieteikšanās un izrakstīšanās reizē, un lielums klusi aug, līdz kāds to izmēra.

Novirziet mapes, kurās glabājas dati, un ļaujiet profilam glabāt iestatījumus. Izslēdziet kešatmiņas, ko var atjaunot, piemēram, pārlūku kešatmiņas un lietojumprogrammu pagaidu datus, jo to pārvietošana pievieno laiku un nemaina neko, ko lietotājs redz. Turiet pastkastes datus un citas lietojumprogrammu glabātuves vietā, ko atbalsta lietojumprogramma, nevis klejojošā ceļā.

Nepadariet profila koplietojumu pieejamu bezsaistē. Bezsaistes faili pieder pie piemērotiem datu koplietojumiem, un kešatmiņā saglabāts profila atzars, kas sinhronizējas abos virzienos, ir bojājumu ziņojums, kas gaida notikšanu.

Pārbaudiet visus četrus scenārijus, pirms to nosaukt par atrisinātu

Ātra pieteikšanās birojā pierāda ļoti maz. Dizainam jāiztur piekļuve no biroja, darbs no mājām caur tuneli, darbs bez savienojuma un atgriešanās birojā, jo tieši ceturtajā gadījumā parādās sinhronizācijas konflikti. Izmēriet tos pašus četrus ar vienu kontrolētu kontu un īstām lietojumprogrammām, un pierakstiet skaitļus.

Apkopojiet profila pakalpojuma žurnālu un iegūto politikas kopumu no skartās sesijas, nevis no savas administratīvās darbstacijas.

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 }

Salīdziniet šos laikus ar biroja bāzes līniju un ar pārvietojamo datu apjomu. Pieteikšanās, kas ar mazu profilu un ātru koplietojumu joprojām aizņem minūti, nav profila problēma, un nākamā vieta, kur skatīties, ir grupu politikas apstrāde vai tīklu gaidošs pieteikšanās skripts. Ja starpība ir tur, profils nekad nav bijis problēma. Pirms mapju politikas maiņas vai kešatmiņas tīrīšanas apstipriniet, ka nesinhronizētais darbs ir saglabāts, jo sinhronizācija un atjaunojams dublējums ir dažādas garantijas.