none
Erreur 1202 AD - Dossiers partagés non joignable RRS feed

  • Question

  • Bonjour à tous, depuis mardi 03 octobre il m'est impossible de joindre mes dossiers partagés/lecteur réseau hébergés sur mon serveur distant, je n'ai fait aucune modification sur le serveur cette semaine là c'est arriver d'un coup.

    L'erreur apparaissant dans le registre depuis ce jour est la suivante :

    Cet ordinateur héberge désormais l’instance d’annuaire spécifiée, mais les services Web Active Directory n’ont pas pu la traiter. Les services Web Active Directory vont réessayer cette opération régulièrement.
     
     Instance de l’annuaire : NTDS
     Port LDAP de l’instance de l’annuaire : 389
     Port SSL de l’instance de l’annuaire : 636

    >Le ping serveur depuis un poste client est ok

    >La connection distante fonctionne

    > La connection à l'active directory fonctionne (les sessions AD etc).

    >Le serveur est à jour

    > Le pare feu ne bloque à prioris pas ces deux ports.

    > J'ai essayer de passer par plusieurs solutions donnée par le forum tel que des manipulations powershell, débloquer workstation dans le registre.

    Si quelqu'un a une idée je suis preneur, c'est assez urgent, merci!

    Cordialement,

    Lucas

    jeudi 5 octobre 2017 13:04

Réponses

  • Bonjour, en me rendant sur le site en question la solution du problème a été trouvé : Le tunnel vpn entre le serveur distant et le routeur sur site à été interrompu, tout est rentrer dans l'ordre. Merci pour votre aide
    • Marqué comme réponse Lucasboq mardi 10 octobre 2017 11:32
    mardi 10 octobre 2017 11:31

Toutes les réponses

  • Vérifier le port SMB : Telnet MonServeur 445

    ensuite, faite le test d'accès classique : \\IPduServeur\C$, \\Nom.FQDN.Du.Serveur\c$ et \\NomCourt\C$. donnez-nous ensuite les résultats.

    Note : vous n'auriez pas installer le serveur de fichier sur le contrôleur de domaine, par hasard ?

    jeudi 5 octobre 2017 13:12
  • Pouvez vous faire un dcdiag sur le serveur et un repadmin /showrepl .

    jeudi 5 octobre 2017 13:23
    Modérateur
  • Bonjour,

    @Loïc Veirman :

    Aucun de ces tests d'accès ne fonctionnent, oui le serveur de fichier est bien le contrôleur de domaine, ça pourrais poser un problème ?

    La commande telnet ne marche pas dans mon cmd, je n'ai jamais eu à l'utilisé je vais regarder comment faire.

    @Philippe Barth :  sur le dcdiag tout les tests sont réussis, il y a seulement un avertissement d'erreur sur le systemlog qui indique qu'un périphérique de pointage à signalée une plage angulaire erronée, mais le test a quand même été reussi. (id 0x80000102, 0x8000010 et 0x8000009)

    Sur le repadmin ceci s'affiche : https://image.noelshack.com/fichiers/2017/40/4/1507210665-truc-admin-ergege.png

    Edit: La commande telnet me charge une page noir avec le port 445, echec lors de la connexion sur le port 23
    • Modifié Lucasboq jeudi 5 octobre 2017 13:49
    jeudi 5 octobre 2017 13:38
  • ça pourrais poser un problème ?

    Avec Philippe on pourrait vous en dire et même en débattre (souvenir :)) mais, en gros, oui ca peut poser des problèmes tel que celui que vous rencontrez. Pour le diagnostique, c'était important de le savoir. 

    Est-ce que vous pouvez accéder à \\FQDN.DU.DOMAINE\SYSVOL et \\FQDN.DU.DOMAINE\NETLOGON ?

    jeudi 5 octobre 2017 13:50
  • +

    C'est un serveur distant mais c'est le seul DC du domaine ?

    si tu fais un net share sur le serveur ?

    Si  tu fais \\monserveur\c$ directement sur le serveur tu vois les partages ?

    jeudi 5 octobre 2017 13:59
    Modérateur
  • Ah d'accord, c'est la première fois que je rencontre un problème avec ce serveur mais il serais peut être bien d'ajouter des Vms pour déléguer la tâche en effet..

    J'ai bien accès à ces deux dossiers, par contre, il n'y a rien dans le dossier netlogon (ou alors les fichiers sont cachées).

    Edit : \\monserveur\c$ fonctionne bien et tout mes partages y sont

    net share monIP et net share monserveur m'indique que cette ressource partagée n'existe pas.

    Je rajoute que les postes clients ce connecte pour accéder aux ressources sur l'ip xx.xxx.xx.46 (ou le nom du serveur au choix )précedemment pour le partage des fichiers, pareil pour le dns, alors que le serveur lui a besoin de ce connecter à cette même ip mais en .45 pour accéder au partage fichier, qui est l'ip du serveur, ça me parait étrange

    • Modifié Lucasboq jeudi 5 octobre 2017 14:28
    jeudi 5 octobre 2017 14:00
  • Le dossier NetLogon peut etre vide. Pas le sysvol en revanche.Comme proposé par philippe, si vous vous placez sur le serveur et que vous exécutez "net share", vous affiche-t-il bien les partages souhaité ?
    jeudi 5 octobre 2017 14:20
  • Non, le net share m'affiche que cette ressource partagée n'existe pas

    ps : j'ai fait un edit sur mon message précedent sur un point qui pourrais être un problème?

    • Modifié Lucasboq jeudi 5 octobre 2017 14:33
    jeudi 5 octobre 2017 14:32
  • donc il y a eu un changement d'état ? Je vous ai faire le test au tout début et cela ne fonctionnait pas (ou alors, nous ne nous sommes pas compris :)).

    Le NET SHARE doit obligatoirement vous retourner quelque-chose (sinon pas de c$ ou de netlogon) :

    jeudi 5 octobre 2017 14:39
  • Oups, j'avais juste rentré quelque chose après net share,ça me donne ça :

    http://hpics.li/577bab1


    • Modifié Lucasboq jeudi 5 octobre 2017 14:46
    jeudi 5 octobre 2017 14:44
  • Excellent. Votre serveur ne présente à priori pas de soucis pour le partage de ressources. Essayez maintenant la commande suivante :

    net use z: \\serveur\scan 

    Dites-nous si vous réussissez à vous y connecter (essayez également de parcourir son contenu avec un petit dir z: par exemple)

    jeudi 5 octobre 2017 14:51
  • le net use \\serveur\scansce termine correctement

    le net use c:\\serveur\scan ou z:\\serveur\scan non par contre.

    Le problème n'as rien à voir avec les adresses ip que je vous ai données?


    • Modifié Lucasboq jeudi 5 octobre 2017 15:27
    jeudi 5 octobre 2017 14:58
  • JE pense qu'il y a des erreurs de typo dans votre réponse, je la retranscrit ici pour être sur qu'on est en phase :

    le net use \\serveur\scan se termine correctement

    le net use c: \\serveur\scan ou z: \\serveur\scan non par contre.

    C'est normalement impossible : vous réalisez la même commande (la première en authentification sans montage, la seconde en mappant le disque C puis le disque Z) : je pense que la première commande n'a tout simplement pas affiché d'erreur. Je vais donc vous demander de refaire l'opération depuis le poste client  et cette fois-ci de nous fournir une capture d'écran contenant les messages d'erreurs retourné.

    jeudi 5 octobre 2017 15:32
  • C'est bien ça,

    Voici ce que le net use me donne sur un poste client : https://www.hostingpics.net/viewer.php?id=499201Capturenetuse.png

    jeudi 5 octobre 2017 15:56
  • Votre problème est lié à la résolution de nom.

    Le poste client est dans le même sous réseau que le serveur, sinon le nom court du serveur ne sera pas résolu ?

    Le poste client est membre du domaine ?

    Le poste client utilise le DC comme DNS primaire ?

    l m'est impossible de joindre mes dossiers partagés/lecteur réseau hébergés sur mon serveur distant, 

    Je n'ai toujours pas compris si le serveur distant est le seul DC du domaine, je suppose que oui.

    Qaund vous faites un net use z:\\serveur\partage il y a une erreur et c'est normal car il manque un espace entre z: et le reste. La commande crée normalement une lettre Z:  sur le poste ou elle est exécuté. La lettre z; affiche le contenu du partage \\serveur\partage dans la mesure ou l'utilisateur dispose des droits sur le partage et des permissions NTFS.

    jeudi 5 octobre 2017 16:36
    Modérateur
  • @Phil: "J'ai bien accès à ces deux dossiers, par contre, il n'y a rien dans le dossier netlogon (ou alors les fichiers sont cachées). Edit : \\monserveur\c$ fonctionne bien et tout mes partages y sont" :)

    C'est vrai qu'on ne s'y retrouve plus, je suis tout aussi perdu !

    jeudi 5 octobre 2017 16:43
  • Le poste client est dans le même sous réseau que le serveur, sinon le nom court du serveur ne sera pas résolu ? : Non, le serveur est un serveur dédié hebergé chez OVH, son ip local est la même que l'ip public et commence par 51, alors que les postes sont en 192.168.1.x , mais cette configuration fonctionnait avant.

    Le/Les postes clients sont bien membres du domaine et log sous des comptes AD (ad installé sur ce même serveur).

    Les postes clients utilise le DC comme DNS secondaire.

    En mettant l'espace sur le poste client, le chemin réseau n'as toujours pas été trouvé.

    @Loïc : Pardon si c'est pas clair, le \\monserveur\c$ fonctionne sur le serveur * pas sur les postes clients. Le netlogon fonctionne aussi quand je fais la manip sur le serveur, la recherche du dossier netlogon était à faire sur le poste client?

    • Modifié Lucasboq jeudi 5 octobre 2017 16:53
    jeudi 5 octobre 2017 16:50
  • Les postes clients utilise le DC comme DNS secondaire.

    S'ils sont membre du domaine ils  doivent utiliser le DC comme DNS primaire (sauf s'il utilisent un autre serveur DNS qui détient la zone du domaine si le DNS n'est pas géré par le DC).

    Pour faciliter la résolution de nom il est possible de configurer des suffixes DNS sur la carte réseaux si le suffixe du domaine n'est pas présent.

    Voir : 

    http://pbarth.fr/node/37

    En mettant l'espace sur le poste client, le chemin réseau n'as toujours pas été trouvé.

    Le problème d'espace est un problème de syntaxe et n'a rien a voir avec le problème de résolution de nom qu'il faut également traiter.

    jeudi 5 octobre 2017 17:01
    Modérateur
  • J'ai quitté le bureau, je vous tiens au jus demain matin pour la suite.

    Merci beaucoup pour votre aide en tout cas!

    jeudi 5 octobre 2017 17:10
  • Le poste client est dans le même sous réseau que le serveur, sinon le nom court du serveur ne sera pas résolu ? : Non, le serveur est un serveur dédié hebergé chez OVH, son ip local est la même que l'ip public et commence par 51, alors que les postes sont en 192.168.1.x , mais cette configuration fonctionnait avant.

    Le/Les postes clients sont bien membres du domaine et log sous des comptes AD (ad installé sur ce même serveur).

    Les postes clients utilise le DC comme DNS secondaire.

    En mettant l'espace sur le poste client, le chemin réseau n'as toujours pas été trouvé.

    @Loïc : Pardon si c'est pas clair, le \\monserveur\c$ fonctionne sur le serveur * pas sur les postes clients. Le netlogon fonctionne aussi quand je fais la manip sur le serveur, la recherche du dossier netlogon était à faire sur le poste client?


    Le DC est sur une adresse public et accessible depuis internet ou bien vous êtes sur une offre PaaS et vous exploitez un tenant ? 
    jeudi 5 octobre 2017 17:30
  • Oulah, je suis un peu largué sur la définition de PaaS mais en gros c'est un serveur dédié, hebergé chez OVH dans leurs locaux et moi j'y ai accés en tse/teamviewer, le dc à juste une ip non "commune" en 51.xxx.xxx.xx
    jeudi 5 octobre 2017 18:13
  • Paas c'est une façon un peu plus fun et commercial pour dire que tu loue un service dans le cloud pour ton environnement matériel.

    @Loïc : Pardon si c'est pas clair, le \\monserveur\c$ fonctionne sur le serveur * pas sur les postes clients. Le netlogon fonctionne aussi quand je fais la manip sur le serveur, la recherche du dossier netlogon était à faire sur le poste client?

    Oui le serveur n'a pas de problème pour résoudre son nom court alors que les postes clients qui sont situés à l'extérieur du réseau ne le trouve pas.

    Si tu ajoutes sur le poste client dans le fichier "host" sous C:\Windows\System32\drivers\etc le nom et l'ip de ton serveur, celui ci devrait pouvoir résoudre le nom du serveur. Meme si ca fonctionne la méthode n'est pas recommandable. Il est préférable d'utiliser un nom complet qui soit résolue par les DNS comme par exemple : monserveur.monAD.mondomaine.fr

    Les clients doivent pouvoir résoudre l'ensemble des services proposé par ton serveur et les services sont des enregistrements dans les DNS c'est pour cela que le poste client doit utiliser le serveur DNS qui contient les informations de ton domaine AD. L'AD est TRES DEPENDANT de la résolution de nom DNS.

    MAintenant si tu fais juste du partage de fichier les offres comme Azure AD, Office365 qui te fournit de l'espace de stockage son plus simple de mise en oeuvre vu que tu n'a plus à gérer la partie configuration du système (la c'est plutôt Iaas  que PaaS).

    vendredi 6 octobre 2017 04:37
    Modérateur
  • tout pareil que Philippe :)
    vendredi 6 octobre 2017 07:02
  • Bonjour,

    J'ai donc regardé du côté du DNS sur vos conseils, voici ou j'en suis :

    https://www.hostingpics.net/viewer.php?id=391198problemeaenvoyer.png

    (Le fe80 affiché est l'IPV6 du serveur, je ne peut pas la desactiver dans les paramètres de la carte car ça me couperais l'accés internet via ovh).

    (Gauche poste client, droite serveur).

    Le poste client ne ping pas le nom du serveur, le nom.domaine.xxx du serveur, il ping par contre l'IP du serveur et le domaine (domaine.xxx) sur la bonne ip.


    • Modifié Lucasboq vendredi 6 octobre 2017 08:29
    vendredi 6 octobre 2017 08:27
  • Le poste client ne ping pas le nom du serveur, le nom.domaine.xxx du serveur, il ping par contre l'IP du serveur et le domaine (domaine.xxx) sur la bonne ip.

    Pour qu'il puisse faire un ping il faudrait qu'il utilise un serveur DNS qui gère la zone en tant que DNS primaire.

    S'il utilise un autre DNS primaire qui ne connait pas les zones du domaines AD il ne trouvera pas le nom.

    vendredi 6 octobre 2017 09:00
    Modérateur
  • C'est bien le serveur DNS qui est référencé en IP sur les postes clients : https://www.hostingpics.net/viewer.php?id=682146problemeaenvoyer.png
    vendredi 6 octobre 2017 09:06
  • Et il n'arrive pas a résoudre le nom complet de l'ordinateur ?

    Avant de tester fait un ipconfig /flushdns sur le poste client, pour vider le cache DNS

    vendredi 6 octobre 2017 09:41
    Modérateur
  • En faisant le flushdns, il ping maintenant bien le nom court (juste le nom de la machine) et le nom complet, la résolution se fait aussi sans problème. C'est déjà un problème en moins.

    Par contre toujours aucun accès aux dossiers partagés..

    vendredi 6 octobre 2017 10:05
  • S'il ping le nom court c'est qu'il a sans doute le suffixe DNS du domaine de configurer du coup il ajoute automatiquement le nom du domaine...

    Quel erreur pour l'accès au partage ?

    Maintenant si c'est uniquement pour faire du partage, ce n'est pas forcément la meilleur méthode.

    Avez-vous également tenu compte des performances des connexion réseau car ouvrir par le net des partages et gérer des documents comme office peut s'avérer être une expérience pas très rapide .

    vendredi 6 octobre 2017 11:12
    Modérateur
  • Le poste client m'indique que le chemin réseau n'a pas été trouvé.

    C'est pour faire du partage de fichiers classique (image, documents,scan..), cette solution me paraissait rapide (comme sur un réseau local), quand ça fonctionnait encore.


    Edit : et maintenant je ne peux plus ping le serveur même avec un flush dns sans n'avoir rien touché, c'est super aléatoire..

    • Modifié Lucasboq vendredi 6 octobre 2017 12:36
    vendredi 6 octobre 2017 12:29
  • Le poste client m'indique que le chemin réseau n'a pas été trouvé.

    Donc toujours problème de résolution de nom ...

    On va dire que ce n'est pas la méthode la plus conventionnelle pour déployer un AD.

    vendredi 6 octobre 2017 12:47
    Modérateur
  • Je peux ping le nom alors qu'il y a dix minutes je pouvais pas, c'est quand il veux..

    Message d'erreur pour l’accès aux fichiers maintenant : "Vérifiez l’orthographe du nom. Autrement, il y a peut être un problème au niveau de votre réseau. Pour tenter [...] cliquez sur diagnostiquer"

    Je me doute :/


    • Modifié Lucasboq vendredi 6 octobre 2017 12:53
    vendredi 6 octobre 2017 12:51
  • En cliquant sur diagnostiquer, "ressource de partage de fichier et d'impression (monip) est en ligne mais ne répond pas aux tentatives de connexions" En détail sur le port 445

    • Modifié Lucasboq vendredi 6 octobre 2017 12:55
    vendredi 6 octobre 2017 12:54
  • Bonjour, en me rendant sur le site en question la solution du problème a été trouvé : Le tunnel vpn entre le serveur distant et le routeur sur site à été interrompu, tout est rentrer dans l'ordre. Merci pour votre aide
    • Marqué comme réponse Lucasboq mardi 10 octobre 2017 11:32
    mardi 10 octobre 2017 11:31