Kebijakan Grup: Drive yang Dipetakan gagal memuat, Windows Server 2012 Active Directory dan Windows Pro 10

Jaringan:

• Domain multi-situs.
• Setiap situs memiliki 2 pengontrol Domain Windows Server 2012 R2 lokal (di tempat, subnet yang sama).
• Situs didefinisikan dengan benar di Situs dan Layanan Windows.
• Catatan DNS untuk setiap situs HANYA memiliki dua server DNS lokal yang ditentukan.
• SEMUA klien adalah Windows 10 Pro 64-bit dengan semua pembaruan.
• Kedua jaringan sepenuhnya gigabit berjalan pada switch Cisco dengan pemasangan kabel CAT6 bersertifikat.
• Setiap situs memiliki server penyimpanan Synology lokal (di tempat, subnet yang sama).
• Sebagai bagian dari Kebijakan Grup, dua drive jaringan dipetakan untuk dibagikan di server Synology.

Diagnostik Konektivitas:

• dcdiag /test:dns /v /c /elaporan PASSuntuk SEMUA server dan SEMUA tes
• echo %logonserver% selalu mengembalikan DC lokal
• nltest /dsgetdc selalu menunjukkan DC lokal dan IP lokal yang benar
• Di Situs A, kedua drive jaringan muncul, dengan kemungkinan kegagalan 0,5% (saya telah mengalami beberapa boot di mana drive tidak muncul dengan benar).

Isu:

Di Situs B, drive jaringan gagal muncul mungkin 30% dari waktu. Kadang-kadang keduanya drive, kadang-kadang satu atau yang lain. Masalahnya sebagian besar acak, dan tampaknya tidak mengikuti pengguna atau Workstation tertentu.

Gejala:

Dari 30% waktu di mana masalah muncul dengan sendirinya:

• 5% dari waktu a gpupdateatau gpupdate /forceakan memperbaiki masalah dan drive akan segera muncul. Jika gpupdatetidak berhasil pada upaya pertama, itu tidak akan berhasil setelah itu (untuk boot itu)
• 5% dari waktu a gpupdateatau gpupdate /forceakan menyebabkan hanya satu drive muncul
• 20% dari waktu, a gpupdatetidak akan memperbaiki masalah, tetapi boot berikutnya akan baik-baik saja
• 50% dari waktu, a gpupdatetidak akan memperbaiki masalah, tetapi setelah satu boot dan yang lain gpupdate , drive akan muncul

• 20% dari waktu, dibutuhkan beberapa kali reboot (dan gpupdateuntuk setiap boot) sebelum drive muncul. Terkadang 2 boot, tetapi saya jarang harus reboot komputer kadang-kadang 6 atau 7 kali sebelum drive muncul.

  • Untuk 20% terakhir ini, saya terkadang akan mendapatkan kesalahan dari proses gpupdate.

    The processing of Group Policy failed. Windows attempted to read the file 
    \domain\SysVol\domain.local\Policies{5898270F-33D0-41E8-A516-56B3E6D2DBAB}\gpt.ini 
    from a domain controller and was not successful. Group Policy settings may not be 
    applied until this event is resolved. This issue may be transient and could be 
    caused by one or more of the following:  
    
    a) Name Resolution/Network Connectivity to the current domain controller.  
    b) File Replication Service Latency (a file created on another domain controller 
       has not replicated to the current domain controller).  
    c) The Distributed File System (DFS) client has been disabled.
    

  • Kesalahan ini sebenarnya, biasanya tetapi tidak selalu, pertanda yang baik karena umumnya setelah saya mendapatkan kesalahan ini, 'update' berikutnya atau boot berikutnya dan 'update' akan membuat drive muncul kembali.

Diagnostik Peta Drive:

1. gpresult /h gpresult.html menunjukkan:

   Drive Map (Drive: X)
    The following settings have applied to this object. Within this category, settings nearest the top of the report are the prevailing settings when resolving conflicts.
      X:
       Winning GPO  DriveMaps 
        General Settings
         Result: Success
   

2. Saya telah mengaktifkan pendataan debug lingkungan kebijakan grup (per http://social.technet.microsoft.com/wiki/contents/articles/4506.group-policy-debug-log-settings.aspx membuat entri registri [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics] "GPSvcDebugLevel"=dword:00030002). File log in c:\Windows\debug\UserMode\gpsvc.logbelum menunjukkan kesalahan yang jelas kepada saya, saya juga tidak dapat menemukan banyak bantuan melalui google. Berikut beberapa pesan menarik yang saya terima:

   GPSVC(158.33c) 23:33:24:921 CheckGPOs: No GPO changes but extension Group Policy Drive Maps's returned error status 183 earlier.  
   GPSVC(158.c24) 23:38:12:203 ProcessGPOs(Machine): Extension Group Policy Drive Maps skipped with flags 0x110057. 
   GPSVC(158.157c) 23:08:08:216 ProcessGPOs(User): Extension Group Policy Drive Maps ProcessGroupPolicy failed, status 0xb7.
   

3. Saya telah mengaktifkan debug preferensi kebijakan grup untuk Drive Maps (sesuai http://blogs.technet.com/b/askds/archive/2008/07/18/enabling-group-policy-preferences-debug-logging-using-the- -rsat.aspx diatur Drive Map Policy Processingke Enableddan dihidupkan Event Loggingdi properti dari \Computer Configuration\Policies\Administrative Templates\System\Group Policy\Logging and tracing). File log in C:\ProgramData\GroupPolicy\Preference\Trace\User.logbelum mengembalikan kesalahan apa pun.

   2015-11-21 17:47:38.849 [pid=0x22c,tid=0xcd0] Starting class <Drive> - X:.
   2015-11-21 17:47:38.864 [pid=0x22c,tid=0xcd0] Adding child elements to RSOP.
   2015-11-21 17:47:38.880 [pid=0x22c,tid=0xcd0] Beginning drive mapping.
   2015-11-21 17:47:38.896 [pid=0x22c,tid=0xcd0] Set user security context.
   2015-11-21 17:47:38.927 [pid=0x22c,tid=0xcd0] User does not have a split token.
   2015-11-21 17:47:38.927 [pid=0x22c,tid=0xcd0] Drive doesn't exist (full token).
   2015-11-21 17:47:39.114 [pid=0x22c,tid=0xcd0] Connected with access name x:.
   2015-11-21 17:47:39.146 [pid=0x22c,tid=0xcd0] SendNotification Session ID is 2.
   2015-11-21 17:47:39.146 [pid=0x22c,tid=0xcd0] SendNotification discovered drive mask of 8388608.
   2015-11-21 17:47:39.161 [pid=0x22c,tid=0xcd0] Set system security context.
   2015-11-21 17:47:39.161 [pid=0x22c,tid=0xcd0] SendNotification drive event broadcast sent.
   2015-11-21 17:47:39.161 [pid=0x22c,tid=0xcd0] Set user security context.
   2015-11-21 17:47:39.177 [pid=0x22c,tid=0xcd0] SendNotification to Shell.
   2015-11-21 17:47:39.177 [pid=0x22c,tid=0xcd0] Set system security context.
   2015-11-21 17:47:39.177 [pid=0x22c,tid=0xcd0] Properties handled.
   2015-11-21 17:47:39.177 [pid=0x22c,tid=0xcd0] Handle Children.
   2015-11-21 17:47:39.192 [pid=0x22c,tid=0xcd0] EVENT : The element of user preferences 'X:' of the group policy object 'DriveMaps {06FEB8B9-632C-4A1C-A7C9-5A05E1041BEE}' was applied correctly.
   2015-11-21 17:47:39.192 [pid=0x22c,tid=0xcd0] Completed class <Drive> - X:.
   

4. Saya juga memiliki beberapa tangkapan netmon login dengan drive gagal memuat, tetapi tangkapan tersebut memiliki begitu banyak informasi sehingga saya tidak yakin harus mulai dari mana.

5. Jika, setelah gagal masuk, saya mencoba menjelajah langsung ke \\SynologyServer\ShareName\, berbagi selalu dimuat segera tanpa kesalahan. Tidak ada tanda-tanda masalah koneksi atau izin.

Pertanyaan:

Mengapa masalah ini terjadi begitu sering di satu situs, tetapi hampir tidak pernah di situs lain, ketika keduanya berada di domain yang sama, memiliki kebijakan yang sama, dan menjalankan perangkat lunak yang sama?

Satu-satunya perbedaan perangkat lunak yang dapat saya pikirkan adalah bahwa di Situs A, semua komputer menjalankan Windows 8.1 Pro dan ditingkatkan ke Windows 10 Pro, sedangkan di Situs B, semua komputer memiliki instalasi baru Windows 10 Pro.

Karena saya hampir tidak memiliki perwakilan, saya belum bisa mengajukan pertanyaan, jadi saya akan mencoba mengajukan pertanyaan sambil mengirim jawaban dan berharap saya tidak dikalengkan. ;)

Saya akan berasumsi bahwa Anda telah mengasuransikan bahwa bagian GPO dari kasus ini bukan merupakan masalah, dengan menguji GPO ini terhadap bagian UNC "tradisional" pada sistem Windows lain. Informasi penting yang hilang meskipun menurut saya adalah apakah perangkat Synology bergabung dengan domain atau tidak. Banyak unit NAS berbasis Linux seperti Synology, QNAP, dkk, memiliki komponen perangkat lunak tertanam yang memungkinkan mereka untuk berpartisipasi dalam domain Active Directory. Apakah perangkat ini berpartisipasi atau tidak dalam domain mempengaruhi solusi.

Yang sedang berkata, saya memiliki fasilitas jarak jauh di jaringan saya yang terhubung dengan sirkuit T1. Kami memerlukan penggunaan cadangan pencitraan Acronis di semua sistem karena persyaratan sistem. Dengan demikian, membuat cadangan jauh dari gambar-gambar multi-GB dari workstation Windows lebih dari T1 adalah non-starter. Jadi kami menempatkan unit Drobo NAS di setiap segmen lokal untuk mengatasi hal ini dan memberi kami sedikit toleransi kesalahan. Drobos khusus ini tidak memiliki kemampuan untuk berpartisipasi dalam domain AD.

Untuk mengaktifkan saham UNC yang telah dikonfigurasi, kami harus menyiapkan dua hal utama. Pertama, kami membuat entri DNS statis pada server DNS untuk memungkinkan resolusi nama yang tepat. Dan kedua, kami harus "melonggarkan" dua kebijakan yang biasanya direkomendasikan oleh DISA untuk sebagian besar anggota domain. Kami hanya melonggarkan kebijakan ini di server cadangan, dan workstation didukung di situs "tautan lambat", karena ini adalah satu-satunya sistem yang perlu mengakses masing-masing bagian:

• Computer Config \ Pengaturan Windows \ Pengaturan Keamanan \ Opsi Keamanan:
  • Klien Jaringan Microsoft: Komunikasi Masuk Secara Digital (Selalu) = Dinonaktifkan
  • Klien Jaringan Microsoft: Kirim Kata Sandi Terenkripsi ke server SMB Pihak Ketiga = Diaktifkan
  • Microsoft Network Server: Komunikasi Masuk Secara Digital (Selalu) = Dinonaktifkan

GPO untuk "Menandatangani Komunikasi secara Digital jika dinegosiasikan" masih diatur ke Diaktifkan, mengurangi sedikit risiko keamanan yang terlibat. Setelah kami mengaktifkan perubahan ini, pembagian dapat segera diakses melalui jalur UNC, padahal sebelumnya tidak mungkin.

Inilah sebabnya saya katakan sebelumnya bahwa tergantung pada apakah NAS Anda dapat berpartisipasi dalam domain atau tidak menentukan jalur solusi. Jika mereka dapat berpartisipasi, maka DNS dan kebijakan grup "SMB" seharusnya tidak menjadi masalah bagi Anda, dan dengan demikian solusinya akan terletak di tempat lain. Jika mereka TIDAK BISA berpartisipasi (seperti NAS saya), maka ini mungkin solusi Anda.

Yah, saya menemukan utas-utas ini, dan kedengarannya seperti situasi yang hampir identik dengan saya:

Windows 10: Kebijakan Grup gagal diterapkan langsung setelah boot, berhasil nanti

Drive Windows 8.1 / 10 GPO yang dipetakan tidak akan terhubung

Rupanya masalah ini disebabkan oleh Microsoft mengaktifkan Pengerasan UNC di Windows 10 secara default. Ini untuk memperbaiki kelemahan keamanan, tetapi tampaknya secara tidak sengaja menyebabkan Mapped Drives untuk dipasang dengan tidak dapat diandalkan. Tidak mengherankan, sepertinya Microsoft belum mengatasi bug ini (atau bukan?)

Ini juga menjelaskan mengapa saya tidak mengalami masalah di Situs A. Karena semua komputer di sana telah ditingkatkan dari Windows 8.1 Pro ke Windows 10, saya berasumsi bahwa pengaturan mengenai UNC Hardening ditransfer dari Windows 8 dan tidak aktif , sedangkan komputer dengan yang baru instal Windows 10 menggunakan default UNC Hardening on .

Saya belum benar-benar mencoba solusinya, tetapi tampaknya terlalu cocok untuk gejala saya untuk tidak relevan. Saya khawatir tentang solusi yang membuka sistem saya hingga lebih banyak ancaman keamanan, jadi saya mencari alternatif. Saya tidak suka ide pengaturan ini melalui kebijakan grup, dan saya bertanya-tanya apakah mungkin untuk mematikan UNC Hardening melalui pengeditan registri secara manual saja. Saya ingin bereksperimen di beberapa komputer terlebih dahulu sebelum saya memutuskan apa yang harus saya lakukan selanjutnya. Namun, saya hanya dapat menemukan langkah-langkah untuk mengubah pengaturan melalui GPO atau GPP saat ini ...

Adakah pikiran?

Saya hanya ingin memperbarui ini dan mengatakan bahwa pada satu titik salah satu pembaruan Windows 10 utama memperbaiki masalah ini. Ini adalah pertanyaan lama tapi saya tidak suka membiarkan hal-hal tergantung, untuk berjaga-jaga.

Setelah membaca semua yang Anda berikan dalam pembaruan Daniel, saya benar-benar akan menyarankan bahwa pengerasan UNC, sementara terkait, bukan penyebab utama di sini, dan bahwa itu mungkin benar-benar menjadi pilihan "fastboot" OP dari posting ke-2 mengatakan memperbaiki masalahnya . Semua informasi tentang pengerasan UNC mengacu pada saham SYSVOL dan NETLOGON yang mengeras secara default. Meskipun masalah itu akan mencegah klien Anda dari menerima pembaruan GP, ​​faktanya adalah bahwa Drive Map GPO telah diterapkan setidaknya satu kali untuk klien yang bersangkutan, dan tidak PERLU untuk mengajukan permohonan kembali setelah setiap reboot (meskipun memang demikian) untuk mengeksekusi pemetaan.

Tentunya Anda akan ingin menguji setiap opsi secara independen dari yang lain, tetapi terlepas dari opsi mana yang mungkin atau tidak berhasil, garis penalaran ini tampaknya dekat dengan akar penyebab masalah Anda.