Laptop masuk dalam sekitar empat puluh detik di kantor dan butuh beberapa menit di rumah, dan tidak ada yang mengubah kebijakan di antaranya. Yang berubah adalah jalur jaringan di bawah tiga fitur yang terlihat serupa dan berperilaku berbeda. Profil roaming memuat status registri dan folder profil, pengalihan folder mengarahkan folder shell ke share server, dan File Offline menyimpan cache data jaringan yang memenuhi syarat. Ketiganya dapat menambah waktu pada proses masuk, dan biasanya hanya satu yang bertanggung jawab.

Tiga penantian dengan tiga pemilik berbeda

Profil roaming adalah yang membuat pengaturan pengguna mengikuti seseorang di antara komputer yang berpartisipasi, dan pemuatannya terjadi di awal sesi. Hive registri pengguna dan folder profil disalin atau digabungkan saat masuk, lalu ditulis kembali saat keluar. Pekerjaan itu sinkron, itulah sebabnya jalur lambat ke share profil terasa sebagai desktop lambat, bukan sebagai penyalinan file yang lambat.

Pengalihan folder adalah mekanisme lain. Ia memindahkan folder shell tertentu, Dokumen adalah contoh umum, ke lokasi jaringan yang didukung dan membiarkannya di sana. Profil kemudian dapat tetap kecil, karena data tidak ada di dalamnya, dan biayanya berpindah ke saat shell atau aplikasi menyentuh folder itu.

File Offline menambahkan cache lokal plus sinkronisasi untuk file jaringan yang memenuhi syarat. Mereka menjawab pertanyaan lain, yaitu apa yang terjadi saat server tidak dapat dijangkau, dan mereka dapat menghabiskan waktu untuk menyinkronkan saat masuk dan keluar ketika cache sudah usang. Memperlakukan ketiganya sebagai satu pengaturan itulah yang menghasilkan kebijakan yang lambat di satu arah dan tidak berguna di arah lain.

Ukur mana yang benar-benar menunggu

Mulailah dengan membaca di mana profil berada dan apakah profil dimuat dari jalur server. Lalu ukur waktu daftar direktori pada setiap share yang disentuh sesi, karena share yang merespons dalam milidetik di LAN bisa memakan waktu beberapa detik melalui tunnel dan server file yang sibuk.

Dua fakta itu mempersempit masalah lebih cepat daripada audit kebijakan mana pun, dan keduanya tidak memerlukan perubahan konfigurasi untuk dikumpulkan. Jalankan di laptop yang terdampak, bukan di server yang berdiri di samping share.

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 }

Jika jalur profil lokal dan hanya satu folder yang dialihkan menunjuk ke server, pemuatan profil bukan penantian Anda, apa pun kata tiket dukungan. Jika jalur profil jarak jauh dan daftar memakan waktu beberapa detik, proses masuk menunggu share itu, dan perbaikannya menyangkut jalur atau ukuran profil, bukan desktop itu sendiri. Baca angkanya dalam urutan itu dan perdebatan biasanya berakhir di sana.

Koneksi datang setelah penantian dimulai

Tunnel pengguna yang dimulai dari desktop muncul jauh setelah profil dimuat, jadi ia tidak dapat membantu tahap yang lambat. Windows menyadari jalur yang tidak tersedia, beralih ke kredensial cache dan profil lokal, dan sesi akhirnya terbuka. Itulah sebabnya laptop yang sama bisa memakan waktu menit pada proses masuk pertama di rumah dan detik pada yang kedua, begitu ada profil yang di-cache. Penantiannya nyata, tetapi koneksi yang dibutuhkannya tidak ada pada saat itu.

Memperbaikinya berarti memindahkan koneksi lebih awal, bukan menyetel profil. Tunnel mesin atau koneksi sebelum login dengan autentikasi komputer menetapkan jalur sebelum pengguna masuk, dan memerlukan siklus hidup sertifikatnya sendiri serta aturan firewallnya sendiri. Kredensial cache adalah separuh lainnya dari desain, dan hanya berfungsi untuk akun yang pernah masuk sebelumnya.

Uji urutannya, bukan komponennya. Keluar sepenuhnya, mulai tunnel seperti yang akan dilakukan pengguna jarak jauh, dan ukur proses masuk dari perintah kredensial hingga desktop yang dapat digunakan.

Simpan dokumen di luar profil

Share profil adalah tempat yang salah untuk koleksi dokumen besar, dan panduan penerapan profil roaming Microsoft memisahkan penyimpanan profil dan share folder yang dialihkan justru karena alasan itu. Profil yang membawa folder Dokumen berukuran beberapa gigabyte akan lambat pada setiap proses masuk dan keluar, dan ukurannya tumbuh diam-diam sampai seseorang mengukurnya.

Alihkan folder yang menyimpan data, dan biarkan profil menyimpan pengaturan. Kecualikan cache yang dapat dibangun ulang, seperti cache browser dan data sementara aplikasi, karena memindahkannya menambah waktu dan tidak mengubah apa pun yang dilihat pengguna. Simpan data kotak surat dan penyimpanan aplikasi lain di lokasi yang didukung aplikasi, bukan di jalur roaming.

Jangan membuat share profil tersedia offline. File Offline diperuntukkan bagi share data yang memenuhi syarat, dan hive profil yang di-cache yang menyinkronkan ke dua arah adalah laporan korupsi yang menunggu terjadi.

Uji keempat skenario sebelum menyebutnya beres

Proses masuk yang cepat di kantor membuktikan sangat sedikit. Desain harus bertahan terhadap akses kantor, kerja dari rumah melalui tunnel, kerja tanpa koneksi, dan kembali ke kantor, karena pada kasus keempat konflik sinkronisasi muncul. Ukur keempatnya dengan satu akun terkontrol dan aplikasi nyata, lalu catat angkanya.

Kumpulkan log layanan profil dan kumpulan kebijakan yang dihasilkan dari sesi yang terdampak, bukan dari stasiun kerja administratif Anda.

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 }

Bandingkan waktu itu dengan garis dasar kantor dan dengan ukuran yang sedang ditransfer. Proses masuk yang masih memakan satu menit dengan profil kecil dan share cepat bukan masalah profil, dan tempat berikutnya untuk diperiksa adalah pemrosesan Kebijakan Grup atau skrip login yang menunggu jaringan. Jika di situlah celahnya, profil tidak pernah menjadi masalah. Pastikan pekerjaan yang belum tersinkron tetap terjaga sebelum mengubah kebijakan folder atau membersihkan cache, karena sinkronisasi dan cadangan yang dapat dipulihkan adalah dua jaminan berbeda.

Artikel terkait