ทำไมการลงชื่อเข้าใช้ผ่าน VPN จึงช้า: โปรไฟล์ การเปลี่ยนเส้นทาง หรือไฟล์ออฟไลน์

แล็ปท็อปลงชื่อเข้าใช้ที่ออฟฟิศในราวสี่สิบวินาที และใช้เวลาหลายนาทีที่บ้าน โดยไม่มีใครเปลี่ยนนโยบายในระหว่างนั้น สิ่งที่เปลี่ยนไปคือเส้นทางเครือข่ายใต้คุณสมบัติสามอย่างที่ดูคล้ายกันแต่ทำงานต่างกัน โปรไฟล์แบบ roaming จะโหลดสถานะรีจิสทรีและโฟลเดอร์โปรไฟล์ การเปลี่ยนเส้นทางโฟลเดอร์ชี้โฟลเดอร์เชลล์ไปยังแชร์ของเซิร์ฟเวอร์ และไฟล์ออฟไลน์เก็บแคชของข้อมูลเครือข่ายที่เข้าเกณฑ์ ทั้งสามอย่างเพิ่มเวลาให้การลงชื่อเข้าใช้ได้ และโดยปกติมีเพียงอย่างเดียวที่เป็นสาเหตุ

การรอสามอย่างกับเจ้าของสามคนที่ต่างกัน

โปรไฟล์แบบ roaming คือสิ่งที่ทำให้การตั้งค่าผู้ใช้ติดตามคนหนึ่งไปมาระหว่างคอมพิวเตอร์ที่เข้าร่วม และการโหลดเกิดขึ้นช่วงต้นของเซสชัน สาขารีจิสทรีของผู้ใช้และโฟลเดอร์โปรไฟล์จะถูกคัดลอกหรือรวมตอนลงชื่อเข้าใช้ แล้วเขียนกลับตอนลงชื่อออก งานนั้นเป็นแบบซิงโครนัส จึงทำให้เส้นทางที่ช้าไปยังแชร์โปรไฟล์รู้สึกเหมือนเดสก์ท็อปที่ช้า ไม่ใช่เหมือนการคัดลอกไฟล์ที่ช้า

การเปลี่ยนเส้นทางโฟลเดอร์เป็นกลไกอีกแบบ มันย้ายโฟลเดอร์เชลล์ที่เลือก โดยเอกสารเป็นตัวอย่างทั่วไป ไปยังตำแหน่งเครือข่ายที่รองรับและปล่อยไว้ที่นั่น โปรไฟล์จึงเล็กอยู่ได้เพราะข้อมูลไม่ได้อยู่ข้างใน และต้นทุนจะย้ายไปยังช่วงเวลาที่เชลล์หรือแอปพลิเคชันแตะโฟลเดอร์นั้น

ไฟล์ออฟไลน์ เพิ่มแคชภายในเครื่องและการซิงค์สำหรับไฟล์เครือข่ายที่เข้าเกณฑ์ มันตอบคำถามอีกข้อ คือเกิดอะไรขึ้นเมื่อเข้าถึงเซิร์ฟเวอร์ไม่ได้ และอาจใช้เวลาซิงค์ตอนลงชื่อเข้าใช้และออกเมื่อแคชล้าสมัย การมองทั้งสามอย่างเป็นค่าเดียวคือสิ่งที่สร้างนโยบายที่ช้าในทิศทางหนึ่งและไร้ประโยชน์ในอีกทิศทาง

วัดว่าอะไรกำลังรออยู่จริง

เริ่มจากอ่านว่าโปรไฟล์อยู่ที่ใดและโหลดจากเส้นทางเซิร์ฟเวอร์หรือไม่ จากนั้นวัดเวลาการแสดงรายการไดเรกทอรีบนแชร์ทุกตัวที่เซสชันแตะ เพราะแชร์ที่ตอบสนองในระดับมิลลิวินาทีบนเครือข่ายท้องถิ่นอาจใช้เวลาหลายวินาทีผ่านอุโมงค์และเซิร์ฟเวอร์ไฟล์ที่ทำงานหนัก

ข้อเท็จจริงสองข้อนี้ทำให้ปัญหาคมชัดเร็วขึ้นกว่าการตรวจสอบนโยบายใด ๆ และไม่ต้องเปลี่ยนการกำหนดค่าเพื่อเก็บข้อมูล รันบนแล็ปท็อปที่ได้รับผลกระทบ ไม่ใช่บนเซิร์ฟเวอร์ที่ตั้งอยู่ข้างแชร์

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 สังเกตเห็นเส้นทางที่ใช้ไม่ได้ ถอยกลับไปใช้ข้อมูลรับรองที่แคชไว้และโปรไฟล์ภายในเครื่อง และเซสชันก็เปิดขึ้นในที่สุด นี่คือเหตุผลที่แล็ปท็อปเครื่องเดียวกันอาจใช้เวลาหลายนาทีในการลงชื่อเข้าใช้ครั้งแรกที่บ้าน และหลายวินาทีในครั้งที่สอง เมื่อมีโปรไฟล์ที่แคชไว้แล้ว การรอเป็นเรื่องจริง แต่การเชื่อมต่อที่มันต้องการไม่มีอยู่ ณ ขณะนั้น

การแก้ไขหมายถึงการเลื่อนการเชื่อมต่อให้เร็วขึ้น ไม่ใช่ปรับแต่งโปรไฟล์ อุโมงค์เครื่องหรือการเชื่อมต่อก่อนลงชื่อเข้าใช้ด้วยการพิสูจน์ตัวตนของคอมพิวเตอร์จะสร้างเส้นทางก่อนผู้ใช้ลงชื่อเข้าใช้ และต้องมีวงจรชีวิตใบรับรองของตัวเองกับกฎไฟร์วอลล์ของตัวเอง ข้อมูลรับรองที่แคชไว้เป็นอีกครึ่งของการออกแบบ และใช้ได้เฉพาะบัญชีที่เคยลงชื่อเข้าใช้มาก่อน

ทดสอบลำดับ ไม่ใช่องค์ประกอบ ออกจากระบบให้หมด เริ่มอุโมงค์เหมือนที่ผู้ใช้ระยะไกลจะทำ และวัดการลงชื่อเข้าใช้ตั้งแต่พรอมต์ข้อมูลรับรองจนถึงเดสก์ท็อปที่ใช้งานได้

เก็บเอกสารไว้นอกโปรไฟล์

แชร์โปรไฟล์เป็นที่ที่ไม่เหมาะสมสำหรับคอลเลกชันเอกสารขนาดใหญ่ และคู่มือการปรับใช้โปรไฟล์แบบ roaming ของ Microsoft แยกที่เก็บโปรไฟล์กับแชร์ของโฟลเดอร์ที่เปลี่ยนเส้นทางออกจากกันด้วยเหตุผลนั้น โปรไฟล์ที่บรรจุโฟลเดอร์เอกสารหลายกิกะไบต์จะช้าทุกครั้งที่ลงชื่อเข้าใช้และออก และขนาดจะโตขึ้นอย่างเงียบ ๆ จนกว่าจะมีคนวัด

เปลี่ยนเส้นทางโฟลเดอร์ที่เก็บข้อมูล และปล่อยให้โปรไฟล์เก็บการตั้งค่า ยกเว้นแคชที่สร้างใหม่ได้ เช่นแคชเบราว์เซอร์และข้อมูลชั่วคราวของแอปพลิเคชัน เพราะการย้ายมันเพิ่มเวลาและไม่เปลี่ยนอะไรที่ผู้ใช้เห็น เก็บข้อมูลกล่องจดหมายและที่เก็บอื่น ๆ ของแอปพลิเคชันไว้ในตำแหน่งที่แอปพลิเคชันรองรับ ไม่ใช่บนเส้นทาง roaming

อย่าทำให้แชร์โปรไฟล์ใช้งานได้แบบออฟไลน์ ไฟล์ออฟไลน์เป็นของแชร์ข้อมูลที่เข้าเกณฑ์ และสาขาโปรไฟล์ที่แคชไว้ซึ่งซิงค์ทั้งสองทางคือรายงานความเสียหายที่รอจะเกิดขึ้น

ทดสอบทั้งสี่สถานการณ์ก่อนบอกว่าแก้แล้ว

การลงชื่อเข้าใช้ที่เร็วในออฟฟิศพิสูจน์ได้น้อยมาก การออกแบบต้องทนต่อการเข้าถึงจากออฟฟิศ การทำงานจากบ้านผ่านอุโมงค์ การทำงานแบบไม่เชื่อมต่อ และการกลับมาที่ออฟฟิศ เพราะกรณีที่สี่คือที่ที่ความขัดแย้งในการซิงค์ปรากฏ วัดทั้งสี่ด้วยบัญชีควบคุมหนึ่งบัญชีและแอปพลิเคชันจริง แล้วจดตัวเลขไว้

เก็บล็อกของบริการโปรไฟล์และชุดนโยบายที่ได้จากเซสชันที่ได้รับผลกระทบ ไม่ใช่จากเวิร์กสเตชันสำหรับผู้ดูแลของคุณ

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 }

เปรียบเทียบเวลาเหล่านั้นกับเส้นฐานในออฟฟิศและกับขนาดของสิ่งที่ถูกโอน ถ้าการลงชื่อเข้าใช้ยังใช้เวลาหนึ่งนาทีทั้งที่มีโปรไฟล์เล็กและแชร์เร็ว นั่นไม่ใช่ปัญหาโปรไฟล์ และที่ต่อไปที่ต้องดูคือการประมวลผลนโยบายกลุ่มหรือสคริปต์ลงชื่อเข้าใช้ที่รอเครือข่าย ถ้าช่องว่างอยู่ตรงนั้น โปรไฟล์ก็ไม่เคยเป็นปัญหา ยืนยันว่างานที่ยังไม่ได้ซิงค์ถูกเก็บไว้ก่อนเปลี่ยนนโยบายโฟลเดอร์หรือล้างแคช เพราะการซิงค์กับการสำรองที่กู้คืนได้เป็นการรับประกันที่ต่างกัน