რატომ ნელდება VPN-ით შესვლა: პროფილი, გადამისამართება თუ ოფლაინ ფაილები
ნელი დისტანციური შესვლა სამი ლოდინია ერთში. გაზომეთ პროფილის ჩატვირთვა, გადამისამართებული საქაღალდე და ოფლაინ ქეში ცალ-ცალკე, სანამ პოლიტიკას შეცვლით.
ნოუთბუქი ოფისში დაახლოებით ორმოც წამში შედის, სახლში კი წუთები სჭირდება, და ამასობაში არავის შეუცვლია პოლიტიკა. რაც შეიცვალა, არის ქსელური გზა სამი ფუნქციის ქვეშ, რომლებიც მსგავსად გამოიყურებიან და განსხვავებულად იქცევიან. მოძრავი პროფილი ტვირთავს რეესტრის მდგომარეობას და პროფილის საქაღალდეებს, საქაღალდეების გადამისამართება shell-ის საქაღალდეს სერვერის გაზიარებაზე მიუთითებს, ხოლო ოფლაინ ფაილები ინახავს შესაბამისი ქსელური მონაცემების ქეშს. სამივე შესაძლოა დრო დაუმატოს შესვლას, და ჩვეულებრივ მხოლოდ ერთი მათგანია პასუხისმგებელი.
სამი ლოდინი სამი სხვადასხვა მფლობელით
სწორედ მოძრავი პროფილი აიძულებს მომხმარებლის პარამეტრებს მიჰყვეს ადამიანს მონაწილე კომპიუტერებს შორის, და ჩატვირთვა სესიის დასაწყისში ხდება. მომხმარებლის რეესტრის განშტოება და პროფილის საქაღალდეები შესვლისას კოპირდება ან ერწყმის, შემდეგ კი გასვლისას უკან იწერება. ეს სამუშაო სინქრონულია, ამიტომ პროფილის გაზიარებამდე ნელი გზა ნელი სამუშაო მაგიდის შთაბეჭდილებას ტოვებს და არა ნელი ფაილის კოპირებისას.
საქაღალდეების გადამისამართება სხვა მექანიზმია. ის შერჩეულ shell-ის საქაღალდეებს, რომელთა ჩვეულებრივი მაგალითია დოკუმენტები, მხარდაჭერილ ქსელურ ადგილას გადააქვს და იქვე ტოვებს. მაშინ პროფილი შეიძლება პატარა დარჩეს, რადგან მონაცემები მის შიგნით არ არის, და ხარჯი გადადის იმ მომენტში, როცა shell ან აპლიკაცია ამ საქაღალდეს ეხება.
ოფლაინ ფაილები ამატებენ ლოკალურ ქეშს და სინქრონიზაციას შესაბამისი ქსელური ფაილებისთვის. ისინი სხვა კითხვას პასუხობენ: რა ხდება, როცა სერვერი მიუწვდომელია, და მათ შეუძლიათ დრო დახარჯონ სინქრონიზაციაზე შესვლისა და გასვლისას, როცა ქეში მოძველებულია. სწორედ სამივეს ერთ პარამეტრად განხილვა ქმნის პოლიტიკას, რომელიც ერთი მიმართულებით ნელია და მეორეთი უსარგებლო.
გაზომეთ, რომელი რეალურად ელოდება
დაიწყეთ იმის კითხვით, სად ცხოვრობს პროფილი და იტვირთება თუ არა ის სერვერის გზიდან. შემდეგ გაზომეთ დირექტორიის სიის დრო თითოეულ გაზიარებაზე, რომელსაც სესია ეხება, რადგან ლოკალურ ქსელში მილიწამებში პასუხის გამცემ გაზიარებას გვირაბსა და დატვირთულ ფაილურ სერვერში გავლისას წამები შეიძლება დასჭირდეს.
ეს ორი ფაქტი პრობლემას უფრო სწრაფად ავიწროებს, ვიდრე ნებისმიერი პოლიტიკის აუდიტი, და მათ შეგროვებას კონფიგურაციის ცვლილება არ სჭირდება. გაუშვით ისინი დაზარალებულ ნოუთბუქზე, და არა გაზიარების გვერდით მდგომ სერვერზე.
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 }თუ პროფილის გზა ლოკალურია და მხოლოდ ერთი გადამისამართებული საქაღალდე მიუთითებს სერვერზე, პროფილის ჩატვირთვა თქვენი ლოდინი არ არის, რაც უნდა თქვას დახმარების ბილეთმა. თუ პროფილის გზა დისტანციურია და სიას წამები სჭირდება, შესვლა სწორედ ამ გაზიარებას ელოდება, და გამოსწორება გზას ან პროფილის ზომას ეხება და არა თავად სამუშაო მაგიდას. წაიკითხეთ რიცხვები ამ თანმიმდევრობით და კამათი ჩვეულებრივ იქვე მთავრდება.
კავშირი მოდის მას შემდეგ, რაც ლოდინი დაიწყო
მომხმარებლის გვირაბი, რომელიც სამუშაო მაგიდიდან იწყება, პროფილის ჩატვირთვიდან გაცილებით გვიან ჩნდება, ამიტომ მას არ შეუძლია დაეხმაროს იმ ეტაპს, რომელიც ნელი იყო. Windows ამჩნევს მიუწვდომელ გზას, უბრუნდება ქეშირებულ ავტორიზაციის მონაცემებს და ლოკალურ პროფილს, და სესია საბოლოოდ იხსნება. ამიტომ ერთი და იგივე ნოუთბუქს სახლში პირველ შესვლაზე შეიძლება წუთები დასჭირდეს, მეორეზე კი წამები, როცა ქეშირებული პროფილი უკვე არსებობს. ლოდინი რეალურია, მაგრამ კავშირი, რომელიც მას სჭირდება, იმ მომენტში არ არსებობს.
ამის გამოსწორება ნიშნავს კავშირის ადრე გადატანას და არა პროფილის რეგულირებას. მანქანის გვირაბი ან შესვლამდე კავშირი კომპიუტერის ავთენტიფიკაციით გზას ამყარებს მანამ, სანამ მომხმარებელი შევა, და მას სჭირდება საკუთარი სერტიფიკატის სასიცოცხლო ციკლი და საკუთარი firewall-ის წესები. ქეშირებული ავტორიზაციის მონაცემები დიზაინის მეორე ნახევარია, და ისინი მხოლოდ იმ ანგარიშებისთვის მუშაობს, რომლებსაც ადრე შესული აქვთ.
შეამოწმეთ თანმიმდევრობა და არა კომპონენტები. მთლიანად გახვიდეთ, ჩართეთ გვირაბი ისე, როგორც დისტანციური მომხმარებელი გააკეთებდა, და გაზომეთ შესვლა ავტორიზაციის მოთხოვნიდან გამოსადეგ სამუშაო მაგიდამდე.
შეინახეთ დოკუმენტები პროფილის გარეთ
პროფილის გაზიარება არასწორი ადგილია დოკუმენტების დიდი კოლექციებისთვის, და Microsoft-ის მოძრავი პროფილების განთავსების გზამკვლევი სწორედ ამიტომ ინახავს ცალკე პროფილის საცავს და გადამისამართებული საქაღალდეების გაზიარებებს. პროფილი, რომელიც რამდენიმე გიგაბაიტიან დოკუმენტების საქაღალდეს ატარებს, ნელი იქნება ყოველ შესვლასა და გასვლაზე, და ზომა ჩუმად იზრდება, სანამ ვინმე გაზომავს.
გადაამისამართეთ მონაცემების შემცველი საქაღალდეები, და პროფილს დაუტოვეთ პარამეტრები. გამორიცხეთ ხელახლა ასაგები ქეშები, როგორიცაა ბრაუზერების ქეშები და აპლიკაციების დროებითი მონაცემები, რადგან მათი გადატანა დროს ამატებს და იმას არაფერს ცვლის, რასაც მომხმარებელი ხედავს. საფოსტო ყუთის მონაცემები და სხვა აპლიკაციის საცავები შეინახეთ იმ ადგილას, რომელსაც აპლიკაცია მხარს უჭერს, და არა მოძრავ გზაზე.
ნუ გახდით პროფილის გაზიარებას ოფლაინ ხელმისაწვდომს. ოფლაინ ფაილები შესაბამის მონაცემთა გაზიარებებს ეკუთვნის, და ქეშირებული პროფილის განშტოება, რომელიც ორივე მიმართულებით სინქრონიზდება, დაზიანების ანგარიშია, რომელიც დადგომას ელოდება.
შეამოწმეთ ოთხივე სცენარი, სანამ გამოსწორებულად ჩათვლით
ოფისში სწრაფი შესვლა ძალიან ცოტას ამტკიცებს. დიზაინმა უნდა გაუძლოს ოფისიდან წვდომას, სახლიდან გვირაბით მუშაობას, კავშირის გარეშე მუშაობას და ოფისში დაბრუნებას, რადგან სწორედ მეოთხე შემთხვევაში ჩნდება სინქრონიზაციის კონფლიქტები. გაზომეთ იგივე ოთხი ერთი კონტროლირებული ანგარიშით და რეალური აპლიკაციებით, და ჩაწერეთ რიცხვები.
შეაგროვეთ პროფილის სერვისის ჟურნალი და მისგან მიღებული პოლიტიკის ნაკრები დაზარალებული სესიიდან, და არა თქვენი ადმინისტრაციული სამუშაო სადგურიდან.
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 }შეადარეთ ეს დროები ოფისის საბაზისო მაჩვენებელს და გადასატანი მონაცემების ზომას. შესვლა, რომელსაც პატარა პროფილითა და სწრაფი გაზიარებითაც კი ჯერ კიდევ წუთი სჭირდება, პროფილის პრობლემა არ არის, და შემდეგი ადგილი, სადაც უნდა შევხედოთ, არის ჯგუფური პოლიტიკის დამუშავება ან ქსელს რომ ელოდება შესვლის სკრიპტი. თუ სხვაობა სწორედ იქ არის, პროფილი არასდროს ყოფილა პრობლემა. დაადასტურეთ, რომ არასინქრონიზებული სამუშაო შენახულია, სანამ საქაღალდის პოლიტიკას შეცვლით ან ქეშს გაასუფთავებთ, რადგან სინქრონიზაცია და აღდგენადი სარეზერვო ასლი სხვადასხვა გარანტიაა.