problème Active Directory et build win 10 2004?

[darkjack]

Bonjour,

J'ai déployé la build 2004 par mon WSUS; vu que je ne force pas de reboot, la montée de version est progressive sur mon parc, je dois en être à 60% sur 250 pc.

Depuis, hasard, coïncidence, résultat d'une AD bancale sur laquelle travaille mon boss, je ne sais pas. En 2 semaines, j'ai eu 3 postes qui n’acquéraient plus leurs lecteurs réseaux montés par la fiche ADUC des utilisateurs ou GPO : barrés ou absent dans l'explorateur.

Premier réflexe, NTP? Y aurait pas un synchro à forcer pour se prévenir du méchant chien des enfers? déjà vu et résolu par une commande en cmd. Mais non.

Deuxième réflexe, sortir le poste d'AD, le joindre à nouveau au domaine. Déjà vu aussi. Mais non.

Mauvais DNS entré en manuel, flush du DNS. Non.

Je cherchai des caches en rapport avec AD à supprimer, pas trouvé. Bon, j'ai pas cherché longtemps, en ce moment, vu que mon collègue est parti à la retraite, j'essaye de me dupliquer mais je n'y arrive pas 🙂

Solution de bourrin, reset du poste par la fonction Win 10 avec conservation des données user. mais avec la lourdeur de réinstaller les softs, refaire des réglages, etc...

Du coup, cela me conforte dans mon idée, qu'il y aurait des foutus caches AD à vider sur ces machines pour éviter ce reset. Druides AD, une idée 🙂 ?

Avez vous ce type de comportement avec la build 2004?

Merci pour tout conseil amis Impacticiens!

 

 

 

 

 

[brice.wernet]

Dans l'évent viewer, tu vois un message d'erreur concernant ces reconnections?

Les problèmes de reçoit des shares sont parfois dûe à un problème de timing au démarrage session. On détecte ce problème de timing en démarrant le poste et e' ouvrant la session 1/2 minutes après démarrage.

Ça peut arriver aussi si tu as des changements de VLAN liés au login.

[CryoGen]

Alors une rapide recherche sur le net montre que malheureusement tu n'es pas le seul à avoir des soucis avec les lecteurs réseaux 😕 , par contre dans cette rapide recherche je n'ai pas trouvé de solution.

Sur l'un de mes PC (pas en domaine) je me suis rendu compte que \\nomserver ne marche plus alors que \\nomserver\path fonctionne

 

Serait-ce encore un magnifique bug de MS ? En tout cas j'en vois qui sont donc revenu en 1909 pour "remédier" au problème...

Il y a 11 heures, brice.wernet a écrit :

Ça peut arriver aussi si tu as des changements de VLAN liés au login.

What ? Comment ca serait possible ca ? Via une auth radius ?

[brice.wernet]

À l’instant, CryoGen a écrit :

What ? Comment ca serait possible ca ? Via une auth radius ?

Oui, à l'époque j'avais ça à gérer: auth radius sur une base cisco prime + AD. Login dans un VLAN neutre puis au login changement de VLAN. Ca pose parfois des problèmes. Notamment en session bureau à distance, où le changement de VLAN pouvait aussi se produire quand un informaticien se connectait sur un pote non info. Et aussi quand la stack réseau est lente à mourrir, avec des services, softs qui démarent mal tant que la nouvelle adresse n'a pas été récupérée ou qui tournent encore sur l'adresse précédente.

[CryoGen]

Ouais bah je vais rester sur les (machines des) utilisateurs réparties "à la main" dans les VLAN

 

[brice.wernet]

Ca offrait plus de possibilités de mobilité dans les bureaux sans risquer de compromettre la sécurité. Ca permettait aussi à un informaticien de passer dans le VLAN info pour les install, le diagnostic, ... Par ailleurs, il suffisait de mettre quelqu'un (ordi ou utilisateur) dans la bonne OU et ne pas se soucier des VLAN.

Mais ça restait globalement incompris par les dev et la hotline. Genre "magie noire".

[CryoGen]

On 17/07/2020 at 10:42, brice.wernet a écrit :

Ca offrait plus de possibilités de mobilité dans les bureaux sans risquer de compromettre la sécurité. Ca permettait aussi à un informaticien de passer dans le VLAN info pour les install, le diagnostic, ... Par ailleurs, il suffisait de mettre quelqu'un (ordi ou utilisateur) dans la bonne OU et ne pas se soucier des VLAN.

Mais ça restait globalement incompris par les dev et la hotline. Genre "magie noire".

C'est justement le coté "magie noire" que je vois poindre au loin juste en ayant imaginer comme l'implémenter chez mes clients XD

Déjà que les "admins réseaux" s'y perdent, alors j'imagine même pas le nombre de ticket d'assistance à la minute que ca pourrait générer 😛

[Fab'z]

Il me semble avoir déjà eu un truc qui y ressemble mais avec des postes sans AD. Pas spécialement en version 2004 mais a force de me loguer pour installer une app, ça s'est mis a merder complètement. Comme toi j'ai cherché un moyen de purger un cache, j'ai regardé du coté du SMB parce qu'on peu le faire sur Linux quand on a des soucis d'accès. Mais faut peu être creuser coté serveur plus que client...

C'est un peu moisi comme réponse parce que s'en est pas vraiment une ^^

En te loguant avec un profil tout neuf de l'AD ça passe ? une corruption du profil NTUSER peu être ?

[brice.wernet]

Question: ces partages qui n montent pas, cela donne quel message d'erreur quand on veut les monter via NET USE ?

Est-ce que des quota ont été mis?

Est-ce que la mise en cache a été activée sur les partages?

[Aloyse57]

J'ai eu le prob des lecteurs réseaux ; à part aller dans la Base de Registre, clé ''Computer\HKEY_CURRENT_USER\Network\'' et supprimer toutes les lettres des lecteurs mappés+reboot, je n'ai pas trouvé de solution fiable.

Une fois redémarré, je peux à nouveau faire les net use et là, plus de problème, même après reboot.

 

J'ai aussi altéré cette valeur, mais je ne crois pas que ça change quelque chose dans ce cas [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters] "AllowInsecureGuestAuth"=dword:1

 

La bonne nouvelle : 20H2 ne remet pas en cause les partages. Ils continuent de fonctionner.