登录
 
主页技术资源库学习下载支持社区论坛
IT 专业人士的资源 >
> 
> 
Ouverture de session très longue (Problème Winlogon)

Discussion Ouverture de session très longue (Problème Winlogon)

  • 2012年7月26日 11:54
     
     
    登录进行投票
    0

    Bonjour,

    Je vous explique mon problème.
    Je viens d'ajouter 5 serveurs  sur un blade IBM (tous en Windows Server 2008 R2 SP1) sur un domaine de 2003 (****.local). J'ai fait toutes les MAJ en passant par le WSUS interne, j'ai installé IIS (+ ASP.net), framework 4, Forefront et Broadcom Nextreme pour le teaming de carte réseaux . J'ai mis une ip fixe, un masque /24, une GW et deux serveurs DNS. Ces serveurs seront des serveurs CITRIX.
    Lorsque je me connecte avec un compte administrateur (ou autre), cela met énormément de temps (entre 5 et 15 minutes) pour afficher le bureau Windows, je suis bloqué à "Applications des paramètres de l'utilisateurs..." puis "Veuillez attendre le client de stratégie de groupe"... Je tient à préciser qu'avant cela "Applications des paramètres de l'ordinateur..." mais aussi du temps (environ 3-4 minutes).
    Une fois la session démarré, je fais un "rsop.msc" afin de voir si les GPO sont appliqués et j'ai une petite croix sur le profil utilisateurs (donc elle ne s'applique pas), à ce moment là je fais un "gpupdate/force", la gpo se met en place? Je ferme la session puis je la re ouvre et le temps d'ouverture de session devient alors très rapide. Mais le lendemain ou quand je redémarre le serveur, l'ouverture de session redevient anormalement longue...

    Je consulte mon "event viewer" et je vois différentes erreurs:

    Le traitement de la stratégie de groupe a échoué. Windows a tenté en vain de lire le fichier \\******.local\SysVol\******.local\Policies\{D208409A-09BD-40B2-9D53-72D72A452911}\gpt.ini à partir d’un contrôleur de domaine. Il est possible que les paramètres de stratégie ne s’appliquent pas tant que cet événement n’est pas résolu. Cette erreur peut être temporaire et avoir une ou plusieurs des causes suivantes :
    a) Résolution de nom/connectivité réseau au contrôleur de domaine actif.
    b) Latence du service de réplication de fichiers (un fichier créé dans un autre contrôleur de domaine ne s’est pas répliqué sur le contrôleur de domaine actif).
    c) Le client du système de fichiers DFS (Distributed File System) a été désactivé.

    Le traitement de l’événement de notification (Logon) par l’abonné aux notifications Winlogon <GPClient> a duré 1620 secondes.

    Le traitement de l’événement de notification (Logon) par l’abonné aux notifications Winlogon <GPClient> dure longtemps.

    Voici les démarches que j'ai effectué:
    1 - J'ai déplacé mes serveurs dans une autres OU pour appliquer d'autres GPO et ça fait pareil.
    2 - J'ai sorti 1 serveur de l'AD puis je l'ai remis, toujours pareil.
    3 - J'ai fais différentes tests sur les serveurs, nslookup, ping du dns, ping de l'ad, tout est OK.

    Voilà, en espérant avoir une réponse :-)

    Romain.





     

全部回复

  • 2012年7月26日 14:46
     
     
    登录进行投票
    1

    Bonjour,

    Une simple question, avez vous votre pile IPv6 d'activé sur vos serveurs ?

    Si cela est le cas pouvez vous desactiver l'ipv6 avec le procedure suivante :

    Lien TechNet

    DisabledComponents = ffffffff

    Autres pistes

    - vous pouvez aussi verifier que ce ne soit pas l'IPv6 qui soit le protocole preferé de vos cartes réseaux via (ipconfig).

    - Casser votre teaming Broadcom, utiliser une seul carte avec IPv4 Fix et valider le fonctionnement.

    L'ensemble des ces tests sont je penses necessaires vue que vous avez verifié les DNS et autres acces.

    Merci de votre retour

    Cordialement, Yann Biez http://www.adminsysteme.fr


     
  • 2012年7月26日 15:20
     
     
    登录进行投票
    0

    Bonjour,

    J'avais désactivé manuellement dans ma carte "teaming" ipv6 (en décochant l'option), je vais essayer en le désactivant complètement en modifiant la cléde registre. Si cela ne marche pas je testerai de casser mon teaming.

     
  • 2012年7月27日 8:12
     
     
    登录进行投票
    0
    Merci de votre retour, tenez nous au courant.

    Cordialement, Yann Biez http://www.adminsysteme.fr

     
  • 2012年7月27日 12:10
     
     
    登录进行投票
    0
    Merci de votre retour, tenez nous au courant.

    Cordialement, Yann Biez http://www.adminsysteme.fr

    Alors j'ai effectué tous les tests et cela n'a rien changé.
    Par contre j'ai du nouveau... quand je veux me connecter au partage de l'AD avec le FQDN --> \\ad.****.local\SYSVOL pour allez voir le dossier SYSVOL c'est très rapide. En revanche quand je met le nom de domaine \\****.local\SYSVOL (toujours pour allez voir le dossier SYSVOL) cela met énormément de temps... Avez-vous une idée?
     
  • 2012年7月27日 12:23
     
     
    登录进行投票
    1

    Pouvez-vous effectuer un nslookup depuis votre serveur qui presente le probleme, afin de verifier les IP repondu.

    Attention si vous avez plusieurs sites verifier que la reponse de votre DNS presente en premiers les IP locals de vos DCs.

    Relancer plusieurs fois votre nslookup afin de valider le RoundRobin.

    Il semble que votre probleme soit bien lier au DNS.

    Cordialement.

    Cordialement, Yann Biez http://www.adminsysteme.fr

     
  • 2012年7月27日 12:55
     
     
    登录进行投票
    0

    Pouvez-vous effectuer un nslookup depuis votre serveur qui presente le probleme, afin de verifier les IP repondu.

    Attention si vous avez plusieurs sites verifier que la reponse de votre DNS presente en premiers les IP locals de vos DCs.

    Relancer plusieurs fois votre nslookup afin de valider le RoundRobin.

    Il semble que votre probleme soit bien lier au DNS.

    Cordialement.

    Cordialement, Yann Biez http://www.adminsysteme.fr

    J'avais déjà fait le test du NSLookup et il me remonte bien le DC local (sinon oui j'ai plusieurs sites).
     
  • 2012年7月27日 14:45
     
     
    登录进行投票
    1

    il faudrais investiger un peux plus...

    Avez vous des warning ou erreurs dans vos journaux d'evenements ?

    Pouvez vous essayer d'ajouter temporairement dans le fichier Host de votre serveur le nom Domaine.local = IP, puis tester de nouveau l'acces ?

    Cordialement,

    Cordialement, Yann Biez http://www.adminsysteme.fr

     
  • 2012年7月31日 8:48
     
     
    登录进行投票
    1

    Bonjour,

    Pouvez vous nous faire un point sur l'avancement du probleme svp?

    Cordialement,

    Cordialement, Yann Biez http://www.adminsysteme.fr

     
  • 2012年9月10日 14:44
     
     
    登录进行投票
    0

    Bonjour,

    Pouvez vous nous faire un point sur l'avancement du probleme svp?

    Cordialement,

    Cordialement, Yann Biez http://www.adminsysteme.fr

    Bonjour,

    je me permets de réitérer la demande d'Esteban_135 car le sujet n'est pas très vieux et nous rencontrons les mêmes symptômes sans trouver la moindre piste pour résoudre ce problème. Avez-vous réglé le vôtre, si oui comment ?

    La piste d'une mauvaise config dns est plausible mais comment le vérifier et corriger ?

    La piste d'une gpo qui ne s'appliquerait pas correctement est-elle envisageable, par exemple le déploiement d'une imprimante qui ne se ferait pas ?

    Merci d'avance pour votre retour.

     
  • 2012年9月11日 14:25
     
     
    登录进行投票
    0

    je me réponds à moi-même au cas où cela puisse aider quelqu'un : dans notre cas, nous avions plusieurs cartes réseaux installées sur le serveur et apparamment, sans teaming, ce n'est pas supporté. Bref en désactivant les connexions réseaux des cartes qui n'avaient pas de fonction particulière, tout est revenu dans l'ordre pour ce qui est du démarrage et de l'ouverture de session. En revanche, la fermeture de session reste très longue à distance.

    Espérant que cela puisse aider...