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

MISE À JOUR: pas résolu …

La question persiste, j'ai également essayé l'approche de chemins UNC renforcée , toujours pas de chance. Je vais continuer à mettre à jour ce sujet si je rencontre quelque chose de nouveau.

MISE À JOUR et résolu (j'espère)

On dirait que le problème a été déclenché par l'option "démarrage rapide" dans Windows 10 (et 8.1). Il existe même un article TechNet décrivant quelque chose comme ça. Je suis allé et désactivé un démarrage rapide pour tous les clients via un GPO de registre ( HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Power\HiberbootEnabled, REG_DWORD 0x0 (0) )

En ce moment, les partages réseau sont mappés lors du démarrage et du redémarrage. J'espère que ça restera comme ça.


Dans mon environnement (domaine Server 2012 R2 avec trois DC, tous les GC), il existe des problèmes avec les lecteurs mappés via les GPP, mais uniquement avec les clients Windows 8.1 et Windows 10 (toutes les mises à jour sont installées).

Les GPP mappent 7 lecteurs, 4 d'entre eux sont sur le DC principal et le serveur de fichiers, les 3 autres sur les partages DFS.

Si les clients Win8.1 / Win10 se connectent, parfois les lecteurs apparaissent, mais la plupart du temps ils ne le font pas. Si je lance un gpupdate /force par ligne de commande, tous se connectent. Lorsque après un certain temps inactif, l'utilisateur veut parcourir un partage (peu importe si DFS ou serveur de fichiers), une erreur apparaît:

Erreur 0x80090006: signature invalide

Mais s'ils cliquent sur le lecteur à nouveau, tout va bien. J'ai essayé toutes les réparations possibles que je peux imaginer, configurant les GPP pour attendre le réseau avant le démarrage, en définissant le temps de déconnexion automatique sur les serveurs à l'infini via net config server /autodisconnect:-1 , en supprimant les GPP et en commençant à partir de zéro, en vérifiant et en vérifiant le système Les autorisations, mais tout en rien.

Les clients affichent également parfois une erreur dans le journal des événements auquel aucun DC ne peut être consulté, ce qui est absurde car tous les autres GPO et GPP (imprimantes, par exemple) sont traités à chaque fois, seuls les lecteurs mappés sont défectueux.

Est-ce que quelqu'un a rencontré quelque chose comme ça aussi? Tout conseil sera très apprécié.

METTRE À JOUR

Dès le démarrage du client, parfois cette erreur apparaît dans les événements (sur le client) aussi:

ID d'événement 1058, GroupPolicy (Microsoft-Windows-GroupPolicy)

Le traitement de la stratégie de groupe a échoué. Windows a essayé de lire le fichier \ domain.local \ SysVol \ domain.local \ Policies {5898270F-33D0-41E8-A516-56B3E6D2DBAB} \ gpt.ini à partir d'un contrôleur de domaine et n'a pas réussi. Les paramètres de stratégie de groupe peuvent ne pas être appliqués tant que cet événement n'a pas été résolu. Ce problème peut être transitoire et pourrait être causé par un ou plusieurs des éléments suivants: a) Résolution de nom / Connexion réseau au contrôleur de domaine actuel. B) Latence du service de réplication de fichier (un fichier créé sur un autre contrôleur de domaine n'a pas été répliqué sur le contrôleur de domaine actuel). C) Le client DFS (Distributed File System) a été désactivé.

Je vais essayer de regarder cela.

Après avoir testé et attendu les commentaires de l'utilisateur, j'ai essayé l' approche UNC endurcée ci-dessus, mais cette fois-ci pas via GPO lui-même, mais via un GPP pour définir les entrées de registre appropriées ( HKLM\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths\\\*\NETLOGON || SYSVOL - RequireMutualAuthentication=0, RequireIntegrity=0 ) directement. Et voilà! Cela fonctionne … Je ne sais pas pourquoi les options de GPO mises en place ne le sont cependant pas. Peut-être que j'ai fait quelque chose de mal, mais à ce moment-là, je m'en fous, tant qu'il fonctionne. Microsoft publiera probablement un (nouveau) correctif rapidement de toute façon.

EDIT: Rappelez-vous que les chemins UNC renforcés ont été implémentés pour résoudre un problème de sécurité «critique» de Windows , qui peut être daté de l'an 2000. En désactivant les chemins UNC sécurisés, vous ouvrez activement ce trou, si cela vaut, cela dépend de Votre topologie et / ou la sécurité de votre infrastructure nécessaire.

Ce problème dans mon environnement se manifeste uniquement avec les cartes DFS et apparaît parfois jusqu'à 8 et 8.1 mais dans 10 Anniversaire est systématique.

C'est ma solution de contournement personnelle: dans GPO, je crée une tâche planifiée qui s'exécute chaque fois qu'une ouverture de session d'utilisateur lance le script d'ouverture de session

Cela fonctionne comme un charme …

Essayez de désactiver UAC sur le client, cela nous a aidé.