Grup İlkesi: Eşlenemeyen Sürücüler yüklenemiyor, Windows Server 2012 Active Directory ve Windows Pro 10

Ağ:

• Çok alanlı alan adı.
• Her sitede 2 yerel (yerinde, aynı alt ağ) Windows Server 2012 R2 Etki Alanı denetleyicisi bulunur.
• Siteler Windows Siteleri ve Hizmetlerinde doğru şekilde tanımlanmıştır.
• SADECE her site için DNS kayıtlarında iki yerel DNS sunucusu tanımlanmıştır.
• TÜM istemciler tüm güncelleştirmelerle birlikte Windows 10 Pro 64 bittir.
• Her iki ağ da sertifikalı CAT6 kablolamaya sahip Cisco anahtarlarında tamamen gigabit çalışıyor.
• Her sitenin yerel (yerinde, aynı alt ağ) Synology depolama sunucusu vardır.
• Grup İlkesi'nin bir parçası olarak, iki ağ sürücüsü Synology sunucusundaki paylaşımlarla eşlenir.

Bağlantı Teşhisi:

• dcdiag /test:dns /v /c /ePASSTÜM sunucular ve TÜM testler için raporlar
• echo %logonserver% her zaman yerel bir DC döndürür
• nltest /dsgetdc her zaman yerel bir DC ve doğru yerel IP gösterir
• A Sitesinde, her iki ağ sürücüsü de% 0,5'lik bir hata şansıyla ortaya çıkıyor (Sürücülerin düzgün görünmediği birkaç önyükleme yaşadım).

Konu:

Site B'de, ağ sürücüleri zamanın% 30'unu gösteremez. Bazen ikisi de tahrik, bazen biri ya da diğeri. Sorun çoğunlukla rastgeledir ve belirli bir kullanıcıyı veya İş İstasyonunu takip etmiyor gibi görünmektedir.

Semptomlar:

Bir problemin ortaya çıktığı zamanın % 30'undan :

• Zamanın% 5'i a gpupdateveya gpupdate /forcesorunu giderir ve sürücüler hemen görünür. Eğer gpupdateilk denemede çalışmaz, bu olacak hemen hemen hiç bundan sonra işi (yani önyükleme için)
• Zamanın% 5'i a gpupdateveya gpupdate /forcesadece bir sürücünün görünmesine neden olur
• Zamanın% 20'si, bir gpupdatesorunu çözmeyecek, ancak bir sonraki önyükleme iyi olacak
• Zamanın% 50'si, a gpupdatesorunu çözmez, ancak bir önyükleme ve diğerinden gpupdate sonra sürücüler görünür

• Zamanın% 20'si , sürücüler görünmeden önce birden çok yeniden başlatma (ve gpupdateher önyükleme için) sürecektir . Bazen 2 önyükleme olabilir, ancak sürücüler ortaya çıkmadan önce bazen 6 veya 7 kez bir bilgisayarı nadiren yeniden başlatmak zorunda kaldım.

  • Zamanın bu son% 20'si için bazen gpupdate işleminden hata alıyorum.

    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.
    

  • Bu hata, aslında genellikle her zaman olmasa bir iyi genellikle bu hatayı, sonraki'gpupdate' veya bir sonraki çizme almak ve'gpupdate' yapacak sonra sürücüler yeniden çünkü işareti.

Drive Harita Teşhisi:

1. gpresult /h gpresult.html gösterileri:

   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. Grup ilkesi ortamı hata ayıklama günlüğünü etkinleştirdim ( http://social.technet.microsoft.com/wiki/contents/articles/4506.group-policy-debug-log-settings.aspx kayıt defteri girdisi başına [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics] "GPSvcDebugLevel"=dword:00030002). Giriş dosyası c:\Windows\debug\UserMode\gpsvc.logbana herhangi bir net hata göstermedi, ne de google üzerinden fazla yardım bulamadım. İşte aldığım bazı ilginç mesajlar:

   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. Drive Haritalar için grup ilkesi tercihlerinde hata ayıklamayı etkinleştirdim ( http://blogs.technet.com/b/askds/archive/2008/07/18/enabling-group-policy-preferences-debug-logging-using-the -rsat.aspx seti Drive Map Policy Processingiçin Enabledve açık Event Loggingözelliklerinde \Computer Configuration\Policies\Administrative Templates\System\Group Policy\Logging and tracing). İçindeki günlük dosyası C:\ProgramData\GroupPolicy\Preference\Trace\User.logherhangi bir hata döndürmedi.

   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. Ayrıca, sürücüler yüklenemeyen bir girişin birkaç netmon görüntüsüne sahibim, ancak yakalamanın nereden başlayacağından emin değilim.

5. Başarısız bir girişten sonra doğrudan göz atmaya çalışırsam \\SynologyServer\ShareName\paylaşım her zaman hatasız olarak yüklenir. Bağlantı veya izin sorunu belirtisi yok.

Soru:

Neden bu sorun bir sitede bu kadar sık ​​oluyor ama neredeyse hiçbir zaman diğer sitede bulunmuyor, ikisi de aynı etki alanındayken, aynı ilkeye sahip ve aynı yazılımı çalıştırıyorlar?

Düşünebildiğim tek yazılım farkı, Site A'da tüm bilgisayarların Windows 8.1 Pro çalıştırdığı ve Windows 10 Pro'ya yükseltildiği, Site B'de ise tüm bilgisayarların yeni Windows 10 Pro yüklemeleri olduğu.

Neredeyse hiç temsilcim olmadığı için henüz soru soramıyorum, bu yüzden bir cevap gönderirken bir soru sormaya çalışacağım ve umarım konserve alamadım. ;)

Bu GPO'yu başka bir Windows sistemindeki "geleneksel" UNC paylaşımına karşı test ederek bu davanın GPO bölümünün sorun olmadığını garanti edeceğim. Bence önemli eksik bilgiler, Synology cihazlarının etki alanına katılıp katılmadığıdır. Synology, QNAP ve diğerleri gibi bir çok Linux tabanlı NAS biriminde, Active Directory etki alanlarına katılmalarını sağlayan yazılım bileşenleri bulunur. Bu cihazın alan adına katılıp katılmadığı çözümü etkiler.

Bununla birlikte, ağımdaki T1 devreleriyle birbirine bağlı uzak tesislerim var. Sistem gereksinimleri nedeniyle tüm sistemlerde Acronis görüntüleme yedeklerinin kullanılmasını istiyoruz. Bu nedenle, Windows iş istasyonlarının çoklu GB görüntülerini T1'ler üzerinden uzaktan yedeklemek başlatıcı değildir. Bu nedenle, bunun üstesinden gelmek ve bize biraz hata toleransı vermek için Drobo NAS birimlerini her yerel segmente yerleştirdik. Bu belirli Drobosların AD alanına katılma yetenekleri yoktur.

UNC paylaşımlarını yapılandırıldığı gibi etkinleştirmek için iki ana şey ayarlamamız gerekiyordu. İlk olarak, düzgün ad çözümlemesine izin vermek için DNS sunucularında statik DNS girdileri oluşturduk. İkincisi, DISA'nın çoğu alan üyesi için normal olarak önerdiği iki politikayı "gevşetmek" zorunda kaldık. Bu politikaları yalnızca yedekleme sunucusunda ve iş istasyonlarının "yavaş bağlantı" sitelerinde yedeklendiği için gevşettik, çünkü bunlar ilgili paylaşımlara erişmesi gereken tek sistemdi:

• Bilgisayar Yapılandırması \ Windows Ayarları \ Güvenlik Ayarları \ Güvenlik Seçenekleri:
  • Microsoft Ağ İstemcisi: İletişimi Dijital Olarak İmzala (Her Zaman) = Devre Dışı
  • Microsoft Ağ İstemcisi: Üçüncü Taraf SMB sunucularına Şifrelenmemiş Parola Gönder = Etkin
  • Microsoft Ağ Sunucusu: İletişimi Dijital Olarak İmzala (Her Zaman) = Devre Dışı

"Müzakere Edildiyse İletişimi Dijital Olarak İmzala" GPO'ları hala Etkin olarak ayarlanmış ve bu da bir miktar güvenlik riskini azaltır. Bu değişiklikleri etkinleştirdikten sonra, hisselere hemen UNC yolu üzerinden erişilebilirken, daha önce imkansızdı.

Bu yüzden daha önce söyledim, NAS'larınızın etki alanına katılıp katılmayacağına bağlı olarak çözüm yolunu belirler. Katılabilirlerse, DNS ve "KOBİ" grup politikaları sizin için sorun teşkil etmeyecektir ve bu nedenle çözüm başka bir yerde olacaktır. Eğer katılamıyorlarsa (NAS'larım gibi), bu sizin çözümünüz olabilir.

Bu konuları buldum ve benimkiyle neredeyse aynı bir durum gibi geliyor:

Windows 10: Grup İlkesi önyüklemeden hemen sonra uygulanamıyor, daha sonra başarılı oluyor

Windows 8.1 / 10 GPO eşlemeli sürücüler bağlanmıyor

Görünüşe göre bu sorun Microsoft'un Windows 10'da UNC Sertleştirmesini varsayılan olarak etkinleştirmesinden kaynaklanıyor. Bu bir güvenlik açığını düzeltmektir, ancak görünüşe göre yanlışlıkla Haritalanan Sürücülerin güvenilir olmayan bir şekilde monte edilmesine neden olur. Beklendiği gibi, Microsoft'un bu hatayı henüz ele almamış gibi görünüyor (veya var mı?)

Bu aynı zamanda Site A'da neden sorun yaşamadığımı da açıklıyor. Buradaki tüm bilgisayarlar Windows 8.1 Pro'dan Windows 10'a yükseltildiğinden, UNC Hardening ile ilgili ayarların Windows 8'den aktarıldığını ve kapalı kaldığını , yeni Windows'un 10 yüklemek UNC sertleştirme varsayılan kullanılan üzerinde .

Çözümü aslında henüz denemedim, ancak semptomlarımın uygun olmaması için çok mükemmel görünüyor. Sistemimi daha fazla güvenlik tehdidine açan bir çözüm konusunda endişeliyim, bu yüzden alternatifler arıyorum. Bunu grup ilkesi aracılığıyla ayarlama fikrini sevmiyorum ve yalnızca kayıt defterini el ile düzenleyerek UNC Hardening'i kapatmanın mümkün olup olmadığını merak ediyorum. Daha sonra ne yapacağımıza karar vermeden önce birkaç bilgisayarda deneme yapmak istiyorum. Ancak, ayarı şu anda yalnızca GPO veya GPP ile değiştirmek için adımlar bulabilirim ...

Düşüncesi olan var mı?

Sadece bunu güncellemek ve bir noktada büyük Windows 10 güncellemelerinden birinin bu sorunu çözdüğünü söylemek istiyorum. Bu eski bir soru, ama her ihtimale karşı işleri asılı bırakmak istemiyorum.

Daniel güncellemesinde sağladığınız her şeyi okuduktan sonra, aslında, UNC sertleşmesinin, ilgili olsa da, buradaki temel neden olmadığını ve aslında 2. postanın OP'sinin "fastboot" seçeneği olabileceğini söyledi. . UNC sertleştirme ile ilgili tüm bu bilgiler, varsayılan olarak sertleştirilen SYSVOL ve NETLOGON paylaşımlarına atıfta bulunmaktadır. Bu sorun, müşterilerinizin GP güncellemelerini almasını engelleyecek olsa da, Drive Map GPO'nun söz konusu istemcilere en az bir kez zaten uygulanmış olması ve yürütmek için her yeniden başlatmadan sonra (yine de) yeniden başvurması GEREKMEZ haritalama.

Açıkçası, her seçeneği diğerinden bağımsız olarak test etmek isteyeceksiniz, ancak hangi seçeneğin işe yarayıp yaramayacağına bakılmaksızın, bu akıl yürütme çizgisi, sorunun temel nedenine yakın görünecektir.