Gruppenrichtlinie: Zugeordnete Laufwerke können nicht geladen werden, Windows Server 2012 Active Directory und Windows Pro 10

Netzwerk:

• Domain mit mehreren Standorten.
• Jeder Standort verfügt über zwei lokale Windows Server 2012 R2-Domänencontroller (vor Ort und im selben Subnetz).
• Sites werden in Windows Sites and Services korrekt definiert.
• Für DNS-Einträge für jeden Standort sind NUR die beiden lokalen DNS-Server definiert.
• ALLE Clients sind Windows 10 Pro 64-Bit mit allen Updates.
• Beide Netzwerke sind auf Cisco-Switches mit zertifizierter CAT6-Verkabelung vollständig Gigabit-fähig.
• Jeder Standort verfügt über einen lokalen Synology-Speicherserver (vor Ort, dasselbe Subnetz).
• Im Rahmen der Gruppenrichtlinie werden zwei Netzwerklaufwerke Freigaben auf dem Synology Server zugeordnet.

Konnektivitätsdiagnose:

• dcdiag /test:dns /v /c /eBerichte PASSfür ALLE Server und ALLE Tests
• echo %logonserver% Gibt immer einen lokalen DC zurück
• nltest /dsgetdc Zeigt immer einen lokalen DC und die korrekte lokale IP an
• Auf Standort A werden beide Netzlaufwerke mit einer Ausfallwahrscheinlichkeit von 0,5% angezeigt (ich habe einige Startvorgänge erlebt, bei denen die Laufwerke nicht richtig angezeigt werden).

Problem:

An Standort B werden Netzlaufwerke möglicherweise 30% der Zeit nicht angezeigt. Manchmal sind es beide Laufwerke, manchmal ist es das eine oder andere. Das Problem ist größtenteils zufällig und scheint keinem bestimmten Benutzer oder Arbeitsplatz zu folgen.

Symptome:

Von den 30% der Zeit, in denen ein Problem auftritt:

• In 5% der Fälle wird ein gpupdateoder gpupdate /forcedas Problem beheben und die Laufwerke werden sofort angezeigt. Wenn das gpupdatebeim ersten Versuch nicht funktioniert, wird es danach so gut wie nie mehr funktionieren (für diesen Start)
• In 5% der Fälle wird ein gpupdateoder gpupdate /forcenur ein Laufwerk angezeigt
• In 20% der gpupdateFälle wird das Problem nicht behoben, aber der nächste Start ist in Ordnung
• In 50% der gpupdateFälle behebt a das Problem nicht, aber nach einem Neustart und einem anderen gpupdate werden die Laufwerke angezeigt

• In 20% der Fälle sind mehrere Neustarts (und gpupdatefür jeden Start) erforderlich, bevor die Laufwerke angezeigt werden. Manchmal sind es 2 Starts, aber ich musste selten einen Computer 6 oder 7 Mal neu starten, bevor die Laufwerke angezeigt werden.

  • In den letzten 20% der Fälle erhalte ich manchmal Fehler beim gpupdate-Prozess.

    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.
    

  • Dieser Fehler ist in der Regel, aber nicht immer, ein gutes Zeichen, da die Laufwerke im Allgemeinen beim nächsten ´gpupdate´ oder beim nächsten Booten und ´gpupdate´ wieder angezeigt werden.

Laufwerkskartendiagnose:

1. gpresult /h gpresult.html zeigt an:

   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. Ich habe die Debugprotokollierung für Gruppenrichtlinienumgebungen aktiviert (gemäß dem von http://social.technet.microsoft.com/wiki/contents/articles/4506.group-policy-debug-log-settings.aspx erstellten Registrierungseintrag [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics] "GPSvcDebugLevel"=dword:00030002). Die Log-Datei in c:\Windows\debug\UserMode\gpsvc.loghat mir keine eindeutigen Fehler angezeigt, und ich konnte über Google keine große Hilfe finden. Hier sind einige interessante Nachrichten, die ich erhalten habe:

   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. Ich habe das Debuggen der Gruppenrichtlinieneinstellungen für Drive Maps aktiviert (gemäß http://blogs.technet.com/b/askds/archive/2008/07/18/enabling-group-policy-preferences-debug-logging-using-the) -rsat.aspx Satz Drive Map Policy Processingauf Enabledund schaltete Event Loggingin Eigenschaften \Computer Configuration\Policies\Administrative Templates\System\Group Policy\Logging and tracing). Die Protokolldatei in C:\ProgramData\GroupPolicy\Preference\Trace\User.loghat keine Fehler zurückgegeben.

   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. Ich habe auch mehrere Netmon-Captures eines Logins mit Laufwerken, die nicht geladen werden können, aber das Capture enthält so viele Informationen, dass ich nicht sicher bin, wo ich anfangen soll.

5. Wenn ich nach einer fehlgeschlagenen Anmeldung versuche, direkt zu browsen, \\SynologyServer\ShareName\wird die Freigabe immer sofort und ohne Fehler geladen. Es gibt keine Anzeichen für Verbindungs- oder Berechtigungsprobleme.

Frage:

Warum tritt dieses Problem an einem Standort so häufig auf, an dem anderen jedoch fast nie, wenn sich beide in derselben Domäne befinden, dieselbe Richtlinie haben und dieselbe Software ausführen?

Der einzige Softwareunterschied, den ich mir vorstellen kann, ist, dass an Standort A auf allen Computern Windows 8.1 Pro ausgeführt und ein Upgrade auf Windows 10 Pro durchgeführt wurde, während an Standort B auf allen Computern Windows 10 Pro neu installiert wurde.

Da ich fast keinen Repräsentanten habe, kann ich noch keine Fragen stellen. Daher versuche ich, eine Frage zu stellen, während ich eine Antwort poste, und hoffe, dass ich nicht in die Dose komme. ;)

Ich gehe davon aus, dass Sie versichert haben, dass der GPO-Teil dieses Falls kein Problem darstellt, indem Sie dieses GPO mit einer "traditionellen" UNC-Freigabe auf einem anderen Windows-System getestet haben. Die wichtige fehlende Information ist meiner Meinung nach, ob die Synology-Geräte der Domain angehören oder nicht. In vielen Linux-basierten NAS-Geräten wie Synology, QNAP usw. sind Softwarekomponenten integriert, mit denen sie an Active Directory-Domänen teilnehmen können. Ob dieses Gerät an der Domäne teilnimmt oder nicht, wirkt sich auf die Lösung aus.

Abgesehen davon habe ich entfernte Einrichtungen in meinem Netzwerk, die mit T1-Leitungen verbunden sind. Aufgrund der Systemanforderungen ist die Verwendung von Acronis Imaging-Backups auf allen Systemen erforderlich. Daher ist das Remote-Sichern von Abbildern mit mehreren GB von Windows-Arbeitsstationen über T1s kein Starter. Deshalb haben wir Drobo NAS-Einheiten in jedem lokalen Segment platziert, um dies zu überwinden und uns ein wenig Fehlertoleranz zu verschaffen. Diese bestimmten Drobos können nicht an der AD-Domäne teilnehmen.

Um die konfigurierten UNC-Freigaben zu aktivieren, mussten wir zwei Hauptfunktionen einrichten. Zuerst haben wir statische DNS-Einträge auf den DNS-Servern erstellt, um eine ordnungsgemäße Namensauflösung zu ermöglichen. Und zweitens mussten wir zwei Richtlinien "lockern", die DISA normalerweise für die meisten Domain-Mitglieder empfiehlt. Wir haben diese Richtlinien nur auf dem Sicherungsserver gelockert und die Arbeitsstationen an Standorten mit langsamer Verbindung gesichert, da dies die einzigen Systeme waren, die auf die jeweiligen Freigaben zugreifen mussten:

• Computerkonfiguration \ Windows-Einstellungen \ Sicherheitseinstellungen \ Sicherheitsoptionen:
  • Microsoft Network Client: Kommunikation digital signieren (immer) = Deaktiviert
  • Microsoft Network Client: Unverschlüsseltes Kennwort an SMB-Server von Drittanbietern senden = Aktiviert
  • Microsoft-Netzwerkserver: Kommunikation digital signieren (immer) = Deaktiviert

Die Gruppenrichtlinienobjekte für "Kommunikation digital signieren, wenn sie ausgehandelt werden" sind weiterhin auf "Aktiviert" gesetzt, wodurch das Sicherheitsrisiko etwas gemindert wird. Sobald wir diese Änderungen aktiviert hatten, konnte sofort über den UNC-Pfad auf die Freigaben zugegriffen werden, während dies zuvor unmöglich war.

Aus diesem Grund habe ich bereits gesagt, dass der Pfad der Lösung davon abhängt, ob Ihre NASs an der Domäne teilnehmen können oder nicht. Wenn sie teilnehmen können, sollten DNS und die "SMB" -Gruppenrichtlinien für Sie kein Problem darstellen, und daher würde die Lösung woanders liegen. Wenn sie nicht teilnehmen können (wie meine NASes), ist dies möglicherweise Ihre Lösung.

Nun, ich habe diese Threads gefunden und es klingt wie eine fast identische Situation für mich:

Windows 10: Die Gruppenrichtlinie wird nicht direkt nach dem Start angewendet und ist später erfolgreich

Zugeordnete Windows 8.1 / 10-GPO-Laufwerke stellen keine Verbindung her

Anscheinend wird dieses Problem durch Microsoft verursacht, das standardmäßig die UNC-Härtung in Windows 10 aktiviert. Dies dient zur Behebung einer Sicherheitslücke, führt jedoch anscheinend dazu, dass zugeordnete Laufwerke unzuverlässig bereitgestellt werden. Es ist nicht überraschend, dass Microsoft diesen Fehler anscheinend noch nicht behoben hat (oder?)

Dies erklärt auch , warum ich keine Probleme , da alle Computer an Standort A aufwies , wurde es hatte unter Windows 8.1 Pro auf Windows 10 aktualisiert wurde, nehme ich an , dass die Einstellungen in Bezug auf UNC Härten von Windows - 8 übertragen und blieben weg , während die Computer mit dem frischen Bei der Installation von Windows 10 wurde die Standardeinstellung von UNC Hardening on verwendet .

Ich habe die Lösung noch nicht ausprobiert, aber es scheint zu perfekt für meine Symptome zu sein, um nicht relevant zu sein. Ich mache mir Sorgen um eine Lösung, die mein System für mehr Sicherheitsbedrohungen öffnet, und suche nach Alternativen. Die Idee, dies über Gruppenrichtlinien festzulegen, gefällt mir nicht und ich frage mich, ob es möglich ist, die UNC-Härtung nur durch manuelles Bearbeiten der Registrierung zu deaktivieren. Ich möchte zuerst an einigen Computern experimentieren, bevor ich mich entscheide, was als nächstes zu tun ist. Allerdings finde ich derzeit nur Schritte zum Ändern der Einstellung über GPO oder GPP ...

Irgendwelche Gedanken?

Ich möchte dies nur aktualisieren und sagen, dass irgendwann eines der wichtigsten Windows 10-Updates dieses Problem behoben hat. Dies ist eine alte Frage, aber ich lasse die Dinge nicht gerne hängen, nur für den Fall.

Nachdem ich alles durchgelesen habe, was Sie in dem Update Daniel bereitgestellt haben, würde ich tatsächlich vorschlagen, dass die UNC-Härtung, obwohl sie damit zusammenhängt, nicht die Hauptursache ist, und dass es sich möglicherweise tatsächlich um die "Fastboot" -Option handelt, die laut OP des 2. Posts sein Problem behoben hat . Alle diese Informationen zum UNC-Hardening beziehen sich auf die SYSVOL- und NETLOGON-Freigaben, die standardmäßig gehärtet werden. Während dieses Problem Ihre Clients daran hindern würde, GP-Updates zu erhalten, ist die Tatsache, dass das Drive Map-GPO bereits mindestens einmal auf die betreffenden Clients angewendet wurde und nicht nach jedem Neustart erneut angewendet werden muss (obwohl dies der Fall ist), um ausgeführt zu werden die Zuordnung.

Natürlich möchten Sie jede Option unabhängig von der anderen testen. Unabhängig davon, welche Option möglicherweise funktioniert oder nicht, scheint diese Argumentation nahe an der Hauptursache Ihres Problems zu liegen.