Stratégie de groupe: les lecteurs mappés ne se chargent pas, Windows Server 2012 Active Directory et Windows Pro 10

Réseau:

• Domaine multi-sites.
• Chaque site dispose de 2 contrôleurs de domaine Windows Server 2012 R2 locaux (sur site, même sous-réseau).
• Les sites sont correctement définis dans les sites et services Windows.
• Les enregistrements DNS pour chaque site ont UNIQUEMENT les deux serveurs DNS locaux définis.
• TOUS les clients sont Windows 10 Pro 64 bits avec toutes les mises à jour.
• Les deux réseaux fonctionnent entièrement en gigabit sur des commutateurs Cisco avec un câblage CAT6 certifié.
• Chaque site dispose d'un serveur de stockage Synology local (sur site, même sous-réseau).
• Dans le cadre de la stratégie de groupe, deux lecteurs réseau sont mappés sur des partages sur le serveur Synology.

Diagnostics de connectivité:

• dcdiag /test:dns /v /c /erapports PASSpour TOUS les serveurs et TOUS les tests
• echo %logonserver% renvoie toujours un DC local
• nltest /dsgetdc affiche toujours un DC local et une IP locale correcte
• Sur le site A, les deux lecteurs réseau s'affichent, avec peut-être un risque d'échec de 0,5% (j'ai rencontré quelques démarrages où les lecteurs ne s'affichent pas correctement).

Problème:

Sur le site B, les lecteurs réseau ne s'affichent peut-être pas 30% du temps. Parfois, ce sont les deux lecteurs, parfois c'est l'un ou l'autre. Le problème est principalement aléatoire et ne semble suivre aucun utilisateur ou poste de travail particulier.

Symptômes:

Sur les 30% du temps où un problème se présente:

• 5% du temps a gpupdateou gpupdate /forcerésoudra le problème et les lecteurs apparaîtront immédiatement. Si le gpupdatene fonctionne pas à la première tentative, il ne fonctionnera pratiquement plus après (pour ce démarrage)
• 5% du temps un gpupdateou gpupdate /forcefera apparaître un seul lecteur
• 20% du temps, un gpupdatene résoudra pas le problème, mais le prochain démarrage se passera bien
• 50% du temps, un gpupdatene résoudra pas le problème, mais après un démarrage et un autre gpupdate , les lecteurs apparaîtront

• 20% du temps, il faudra plusieurs redémarrages (et gpupdatepour chaque démarrage) avant que les disques n'apparaissent. Parfois, il s'agit de 2 démarrages, mais j'ai dû rarement redémarrer un ordinateur parfois 6 ou 7 fois avant que les disques n'apparaissent.

  • Pour ces derniers 20% du temps, je reçois parfois des erreurs du processus 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.
    

  • Cette erreur est en fait, généralement mais pas toujours, un bon signe car généralement après avoir reçu cette erreur, le prochain «gpupdate» ou le prochain démarrage et «gpupdate» fera réapparaître les lecteurs.

Diagnostics de la carte de lecteur:

1. gpresult /h gpresult.html spectacles:

   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. J'ai activé la journalisation du débogage de l'environnement de stratégie de groupe (par http://social.technet.microsoft.com/wiki/contents/articles/4506.group-policy-debug-log-settings.aspx créé une entrée de registre [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics] "GPSvcDebugLevel"=dword:00030002). Le fichier journal c:\Windows\debug\UserMode\gpsvc.logne m'a pas montré d'erreurs claires et je n'ai pas pu trouver beaucoup d'aide via Google. Voici quelques messages intéressants que j'ai reçus:

   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. J'ai activé le débogage des préférences de stratégie de groupe pour Drive Maps (selon http://blogs.technet.com/b/askds/archive/2008/07/18/enabling-group-policy-preferences-debug-logging-using-the -rsat.aspx défini Drive Map Policy Processingsur Enabledet activé Event Loggingdans les propriétés de \Computer Configuration\Policies\Administrative Templates\System\Group Policy\Logging and tracing). Le fichier journal dans C:\ProgramData\GroupPolicy\Preference\Trace\User.logn'a renvoyé aucune erreur.

   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. J'ai également plusieurs captures netmon d'une connexion avec des lecteurs qui ne se chargent pas, mais la capture contient tellement d'informations que je ne sais pas par où commencer.

5. Si, après une connexion échouée, j'essaie de naviguer directement vers \\SynologyServer\ShareName\, le partage se charge toujours immédiatement sans aucune erreur. Il n'y a aucun signe de problème de connexion ou d'autorisation.

Question:

Pourquoi ce problème se produit-il si fréquemment sur un site, mais presque jamais sur l'autre site, lorsque les deux sont sur le même domaine, ont la même stratégie et exécutent le même logiciel?

La seule différence de logiciel à laquelle je peux penser est que sur le site A, tous les ordinateurs exécutaient Windows 8.1 Pro et étaient mis à niveau vers Windows 10 Pro, tandis que sur le site B, tous les ordinateurs ont de nouvelles installations de Windows 10 Pro.

Comme je n'ai presque pas de représentant, je ne peux pas encore poser de questions, donc j'essaierai de poser une question tout en affichant une réponse et j'espère que je ne serai pas en conserve. ;)

Je vais supposer que vous avez assuré que la partie GPO de cette affaire n'est pas un problème, en testant ce GPO par rapport à un partage UNC "traditionnel" sur un autre système Windows. À mon avis, les informations importantes manquantes sont de savoir si les appareils Synology sont joints ou non au domaine. De nombreuses unités NAS basées sur Linux telles que Synology, QNAP, et al, ont des composants logiciels intégrés qui leur permettent de participer aux domaines Active Directory. Que cet appareil participe ou non au domaine affecte la solution.

Cela étant dit, j'ai des installations distantes dans mon réseau interconnectées avec des circuits T1. Nous exigeons l'utilisation de sauvegardes d'imagerie Acronis sur tous les systèmes en raison des exigences du système. Ainsi, la sauvegarde à distance d'images de plusieurs Go de postes de travail Windows sur T1 est un non-démarrage. Nous avons donc placé des unités Drobo NAS sur chaque segment local pour surmonter cela et nous donner un peu de tolérance aux pannes. Ces Drobos particuliers n'ont pas la possibilité de participer au domaine AD.

Pour activer les partages UNC tels que configurés, nous avons dû configurer deux choses principales. Tout d'abord, nous avons créé des entrées DNS statiques sur les serveurs DNS pour permettre une résolution correcte des noms. Et deuxièmement, nous avons dû "assouplir" deux politiques que DISA recommande normalement à la plupart des membres du domaine. Nous avons uniquement assoupli ces politiques sur le serveur de sauvegarde et les postes de travail ont été sauvegardés sur des sites "à liaison lente", car ce sont les seuls systèmes qui ont besoin d'accéder aux partages respectifs:

• Configuration ordinateur \ Paramètres Windows \ Paramètres de sécurité \ Options de sécurité:
  • Client réseau Microsoft: communications signées numériquement (toujours) = désactivé
  • Client réseau Microsoft: envoyer un mot de passe non crypté à des serveurs SMB tiers = activé
  • Serveur réseau Microsoft: communications signées numériquement (toujours) = désactivé

Les objets de stratégie de groupe pour «Signer numériquement les communications en cas de négociation» sont toujours définis sur Activé, ce qui atténue un peu le risque de sécurité impliqué. Une fois que nous avons activé ces modifications, les partages étaient immédiatement accessibles via le chemin UNC, alors qu'auparavant c'était impossible.

C'est pourquoi j'ai dit plus tôt que selon que vos NAS peuvent participer ou non au domaine, cela détermine le chemin de la solution. S'ils peuvent participer, alors les stratégies de groupe DNS et "SMB" ne devraient pas vous poser de problème, et la solution se trouverait donc ailleurs. S'ils NE PEUVENT PAS participer (comme mes NAS), alors cela peut être votre solution.

Eh bien, j'ai trouvé ces fils, et cela ressemble à une situation presque identique à la mienne:

Windows 10: la stratégie de groupe ne s'applique pas directement après le démarrage, réussit plus tard

Les lecteurs mappés GPO Windows 8.1 / 10 ne se connecteront pas

Apparemment, ce problème est dû au fait que Microsoft active le renforcement UNC dans Windows 10 par défaut. Il s'agit de corriger une faille de sécurité, mais, apparemment, involontairement, les lecteurs mappés se montent de manière non fiable. Sans surprise, il semble que Microsoft n'ait pas encore corrigé ce bogue (ou l'ont-ils?)

Cela explique également pourquoi je n'ai eu aucun problème sur le site A. Étant donné que tous les ordinateurs ont été mis à niveau de Windows 8.1 Pro vers Windows 10, je suppose que les paramètres concernant UNC Hardening ont été transférés de Windows 8 et sont restés éteints , tandis que les ordinateurs avec la nouvelle l'installation de Windows 10 a utilisé la valeur par défaut UNC Hardening sur .

Je n'ai pas encore essayé la solution, mais elle semble trop parfaite pour s'adapter à mes symptômes pour ne pas être pertinente. Je m'inquiète d'une solution qui ouvre mon système à davantage de menaces de sécurité, donc je cherche des alternatives. Je n'aime pas l'idée de définir cela via une stratégie de groupe, et je me demande s'il est possible de désactiver le renforcement UNC via l'édition manuelle du registre uniquement. Je veux d'abord expérimenter sur quelques ordinateurs avant de décider quoi faire ensuite. Cependant, je ne peux trouver que les étapes pour changer le paramètre via GPO ou GPP actuellement ...

Des pensées?

Je veux simplement mettre à jour cela et dire qu'à un moment donné, l'une des principales mises à jour de Windows 10 a résolu ce problème. C'est une vieille question mais je n'aime pas laisser les choses en suspens, juste au cas où.

Après avoir lu tout ce que vous avez fourni dans la mise à jour Daniel, je suggère en fait que le durcissement UNC, bien que lié, n'est pas la cause principale ici, et qu'il peut en fait s'agir de l'option "fastboot" que l'OP du deuxième message a dit avoir résolu son problème. . Toutes ces informations sur le durcissement UNC faisaient référence aux partages SYSVOL et NETLOGON durcis par défaut. Bien que ce problème empêche vos clients de recevoir des mises à jour de GP, le fait est que le GPO Drive Map a déjà appliqué au moins une fois aux clients en question et n'a pas besoin de réappliquer après chaque redémarrage (même s'il le fait) pour s'exécuter. la cartographie.

De toute évidence, vous voudrez tester chaque option indépendamment de l'autre, mais quelle que soit l'option qui fonctionne ou non, ce raisonnement semble être proche de la cause première de votre problème.