none
Script de logon ne démarre pas RRS feed

  • Question

  • Bonjour,

    J'ai réalisé un script de logon permettant de monter des disques (un bête fichier .bat avec des "net use") qui malheureusement ne parvient pas à être exécuté par les clients.

    Le serveurs est un Windows 2012 R2. Les clients vont du Windows 7 au Windows 10.

    J'ai déjà pas mal essayé de choses et j'arrive à la conclusion qu'il s'agit d'un problème de communication entre le serveur et les clients. Effectivement, un "GPUPDATE /Force" me donne une erreur côté client (cmd en mode administrateur), et à partir du serveur, un "Group Policy Update" me montre bien la liste des PC mais avec un message "RPC Server is unavailable" à côté de chacun...

    Le firewall est désactivé sur le serveur, "File and printer sharing", "Remote Management" et "WMI" sont autorisés côté client sur le firewall (en local et domaine)... J'ai également essayé en désactivant complètement le firewall sur les clients également... Même punition!

    Je ne configure pas des serveurs régulièrement mais en Windows 2008 R2, je ne me souviens pas avoir fait plus... Ma mémoire me joue peut-être des tours...

    Quelqu'un aurait-il une idée comment rendre disponible ce fameux "RPC Server" ?

    D'avance je vous remercie pour votre aide !

    Philippe

    jeudi 16 mars 2017 15:50

Réponses

  • Bonjour,

    Il semble qu'il s'agit un problème réseau.

    Utiliser l'outil PortQryUI pour vérifier l'ouverture des ports entra les machines et les DCs.

    sur les machines clients vérifier sur quel DC sont connecté via les commandes ci dessous :

    #lancer cette commande sur une machine cliente impactée:
    
    set logonserver
    
    


    Please don't forget to mark the correct answer, to help others who have the same issue. Thameur BOURBITA MCSE | MCSA My Blog : http://bourbitathameur.blogspot.fr/

    vendredi 17 mars 2017 00:02
    Modérateur
  • Bonjour,

    Il faut vérifier la liste des ports suivante:

    TCP135

    TCP 139
    TCP and UDP 389
    TCP 636
    TCP 3268
    TCP 3269
    TCP and UDP 88
    TCP and UDP 53
    TCP and UDP 445
    TCP and UDP 464
    UDP 123
    UDP 137
    UDP 138
    TCP & UDP 1024-5000

    TCP & UDP 49152-65535

    La GPO ne peut être appliquée que sur les les machines membres du domaine.

    la présence des poste WORKGROUP sur le même réseau  ne gène pas l'application des GPO sur les machines membres.


    Please don't forget to mark the correct answer, to help others who have the same issue. Thameur BOURBITA MCSE | MCSA My Blog : http://bourbitathameur.blogspot.fr/

    vendredi 17 mars 2017 09:33
    Modérateur

Toutes les réponses

  • Bonjour,

    Dans les Services:

    1- Appel de procédure distantes

    2- Localisateur d'appel de procédure distantes

    jeudi 16 mars 2017 15:56
  • Bonjour,

    Effectivement, ils se trouvent bien dans les services:

    1. Appel de procédure distante -> Mode automatique et démarré à la fois sur le serveur ET sur le client
    2. Localisateur d'appel de procédures distantes -> était en manuel, je l'ai démarré manuellement, aucun changement... Je l'ai démarré sur le serveur ET sur le client.

    Même punition après ces diverses manip...

    Une chose qui pourrait peut-être provoquer un problème (mais en fait je n'en sais rien à vrai dire...je livre juste l'information) c'est que le serveur et tous les postes ont des IP fixes:

    • Serveur -> 192.168.1.10
    • Les clients -> 192.168.1.100, 101,...
    • La Box internet -> 192.168.1.1
    • Le serveur DNS est mis sur tous les postes sur 192.168.1.1
    • Il y a également un serveur DHCP sur cette box mais qui est réduit à une plage de 20 adresses (.20 à .39) pour des accès visiteur par exemple.

    D'un point de vue purement config serveur, j'ai créé un OU avec une GPO liées. Dans l'AD, j'ai deux sous-OU ("Utilisateurs" et "Ordis") qui contiennent respectivement les divers ordis et les utilisateurs concernés par le script de login...

    J'ai aussi testé le script manuellement à partir d'un poste client et il fonctionne nickel !

    J'ai l'impression que tout est cohérent...mais ça ne fonctionne toujours pas !

    D'autres idées ?

    Merci d'avance!

    Philippe

    jeudi 16 mars 2017 17:26
  • Bonjour,

    A défaut de paraitre un peu trop direct, on n'est plus sous windows 2000... Vous pouvez utiliser les préférence aujourd'hui pour monter les lecteur réseau. C'est un peu plus sympa à gérer en plus !Sinon, concernant votre problème je miserai sur la KB de juin 2016 qui est installé sur votre serveur ou poste de travail et donc le fonctionnement des GPO qui a été modifié.

    Au niveau du groupe de sécurité de votre GPO , qu'est ce que vous avez ? Si c'est utilisateur authentifié, alors le problème ne vient pas de la. Cependant, si c'est un groupe d'utilisateur, alors il vous faut alle dans l'onglet délégation, puis ajouter une autorisation en lecture sur le groupe utilisateur authentifié.

    Voici un tutoriel pour les lecteur mappé : http://www.supinfo.com/articles/single/984-gpo-mappage-lecteur-reseau-avec-windows-serveur-2012

    jeudi 16 mars 2017 18:18
  • Bonjour,

    Il faut vérifier que le script est placé dans le partage Netlogon , pour qu'il soit accessible à tous les ordinateurs du domaine?

    Il faut configurer les paramètres utilisateur ,pour lancer le script lors l'ouverture du session.

    Comme l'a proposé matteu31400, vous pouvez utiliser GPP au lieu du script pour mapper les lecteurs réseaux, cela permettra de simplifier l'administration des lecteurs mappés  et réduire la taille du sysvol.


    Please don't forget to mark the correct answer, to help others who have the same issue. Thameur BOURBITA MCSE | MCSA My Blog : http://bourbitathameur.blogspot.fr/

    jeudi 16 mars 2017 23:10
    Modérateur
  • Bonsoir,

    Au niveau du groupe de sécurité de ma GPO j'ai bien "Authenticated Users"...ce point semble donc ok.

    J'ai défini une GPP que espère avoir correctement définie...j'ai suivi le tuto du post précédent. Il ne semble pas y avoir de surprise...

    Le problème est identique : rien ne se monte côté client...

    J'ai essayé de faire un GPUPDATE /force (comme indiqué dans le tuto) et ce dernier me sort le message suivant :

      Mise à jour de la stratégie...

      La stratégie utilisateur n'a pas pu être mise à jour correctement. Les erreurs s
      uivantes ont été rencontrées :

      Échec du traitement de la stratégie de groupe en raison d'une absence de connect
      ivité réseau vers un contrôleur de domaine. Il peut s'agir d'un problème tempora
      ire. Un message de réussite est généré une fois que l'ordinateur est connecté au
      contrôleur de domaine et que la stratégie de groupe est correctement traitée. S
      i aucun message de réussite ne s'affiche pendant plusieurs heures, contactez vot
      re administrateur.


    En lisant une chose ou l'autre sur internet quelqu'un suggérait de vérifier une série de points dont notamment la commande dcdiag (qui chez moi donne tout ok) et de voir également nslookup et ce dernier me sort le message suivant :

      DNS request timed out.
          timeout was 2 seconds.
      Default Server:  UnKnown
      Address:  ::1

    nslookup est exécuté sans paramètre.

    Ne serait-ce pas un problème de DNS?

    Autre chose, lorsque dans le "Group Policy Management" je fait un "Group Policy Update" sur l'OU contenant ma GPO/GPP, j'ai un message indiquant : 

         

    Je commence à désespérer même si je pense ne pas être loin de la solution et vous remercie d'avance pour vos brillantes idées !

    Philippe

    jeudi 16 mars 2017 23:28
  • Bonjour,

    Il semble qu'il s'agit un problème réseau.

    Utiliser l'outil PortQryUI pour vérifier l'ouverture des ports entra les machines et les DCs.

    sur les machines clients vérifier sur quel DC sont connecté via les commandes ci dessous :

    #lancer cette commande sur une machine cliente impactée:
    
    set logonserver
    
    


    Please don't forget to mark the correct answer, to help others who have the same issue. Thameur BOURBITA MCSE | MCSA My Blog : http://bourbitathameur.blogspot.fr/

    vendredi 17 mars 2017 00:02
    Modérateur
  • Bonjour,

    SET LOGONSERVER me retourne parfaitement mon nom de serveur...

    Par contre, PortQryUI me sort une erreur. Il semble que RPC utilise les ports 80, 443, 593, 445 et 135 en TCP et UDP (selon https://technet.microsoft.com/en-us/library/cc738291%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396)

    Ne connaissant pas l'outil PortQryUI, pourriez-vous m'aider à interpréter ce message ?

    Si je désactive le firewall à la fois sur le client ET sur le serveur, cette erreur disparaît...mais, le GPUpdate /force me dit toujours que la stratégie utilisateur n'a pu être mise à jour correctement...

    Par contre au niveau de l'ouverture des ports (quand le firewall est actif), le Remote Procedure Call est bien ouvert...

    L'infrastructure est actuellement en migration : on passe d'un workgroup à un domaine. Certaines machines (la plupart en fait) sont toujours dans le workgroup... Est-ce que cela peut causer un problème ?  

    Merci encore pour tout !

    Philippe

    vendredi 17 mars 2017 09:00
  • Bonjour,

    Il faut vérifier la liste des ports suivante:

    TCP135

    TCP 139
    TCP and UDP 389
    TCP 636
    TCP 3268
    TCP 3269
    TCP and UDP 88
    TCP and UDP 53
    TCP and UDP 445
    TCP and UDP 464
    UDP 123
    UDP 137
    UDP 138
    TCP & UDP 1024-5000

    TCP & UDP 49152-65535

    La GPO ne peut être appliquée que sur les les machines membres du domaine.

    la présence des poste WORKGROUP sur le même réseau  ne gène pas l'application des GPO sur les machines membres.


    Please don't forget to mark the correct answer, to help others who have the same issue. Thameur BOURBITA MCSE | MCSA My Blog : http://bourbitathameur.blogspot.fr/

    vendredi 17 mars 2017 09:33
    Modérateur