Bonsoir à tous,
 
Je me tourne vers vous avec une grosse inquiétude.
J'administre les serveurs d'un lycée. Aujourd'hui un de nos 2 serveurs a lâché (alim certainement, je n'ai pas eu le temps de vérifier) se mettant en cours circuit et provoquant la coupure du disjoncteur.
Sauf que ce serveur gérait le logiciel des onduleurs sur les 2 serveurs (je sais aujourd'hui que c'était une très mauvaise idée et qu'elle manquait de réflexion, mais bon passons ...).
Le 2e serveur du coup s'est éteint quand la batterie de son onduleur s'est retrouvée vide.
Les rôles principaux sont sur ce 2e serveur (DNS, DHCP, etc ...).
Je l'ai redémarré, mais depuis, il est impossible aux utilisateurs de se connecter sur leur session.
J'ai effectué 2/3 tests : sur un PC, quand je fais un ping vers le serveur par adresse ip, il y a bien réponse de celui-ci. Mais impossible par exemple d'y accéder quand je lance l'explorateur en entrant son adresse ip et le nom d'un dossier partagé (mais par contre j'y accède en passant par le voisinage réseau).
Là je bloque vraiment.
 
Je me retrouve avec un serveur HS, et le 2e qui dysfonctionne. Tous est paralysé dans le lycée, je vous dis pas le stress !!!
Sans parler de solution (ce qui serait merveilleux), quelles pistes me conseillez-vous d'explorer pour diagnostiquer le pb ?
Le serveur est en 2003 R2.
 
Merci d'avance pour tout conseil ...

probleme de dns, que faisait le serveur HS hormis la gestion des onduleurs ?

 
C'est ce que je me suis dit, mais comme le serveur HS n'était pas serveur DNS ...
Il était également contrôleur de domaine avec le 2e serveur.
J'y avais mis aussi un système DFS entre lui et le 2e serveur
 
Auparavant, il était serveur DNS et DHCP, mais j'ai transféré ces rôles sur le 2e serveur, ce qui avait réussi.
J'avais d'ailleurs déjà déconnecté ce serveur une fois, pour une intervention, et le 2e serveur avait montré qu'il assumait bien ces 2 rôles.
 

Le pb a évolué quelque peu.
Après plusieurs interventions : suppression du serveur HS sur le domaine et dans AD. Transfert des rôles FSMO, utilisation de ntdsutil ...
Les ordinateurs peuvent se connecter mais l'ouverture de session est d'une lenteur .... !
(environ 10mn pour se connecter !)

A tout hasard, ton 2ème serveur il n'a pas un RAID ?
Quel est son état ?

Taux d'utilisation CPU et charge réseau ?

Le DHCP distribue quoi comme serveur DNS aux clients ?
L'IP du bon serveur en DNS primaire ?

 
Il n'y a pas de RAID sur le 2e serveur.
Le CPU est peu utilisé, pas de saturation anormale.
Par contre, pour la charge réseau, je ne sais pas comment vérifier.
Petite remarque, même le soir, sans personne au lycée donc sans surcharge réseau, l'ouverture de session est lente.

 
Le DHCP distribue le bon serveur, celui du serveur 'opérationnel', avec sa bonne adresse IP.

est ce que les cripts d'ouverture de sessions ne font pas appel a des composants qui étaient sur le serveur 2? (du genre le fond-ecran.bmp ou autre petits paths appliqués par scripts?)

 
bonne remarque, je vérifie ...

Que donne un "dcdiag" (Outil de diagnostic du contrôleur de domaine) ?

Disponible ici

Services Windows KO ?

des news sur la situation?

Ca y est !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
 
Pb enfin résolu !
 
Désolé de ne pas être revenu plus tôt. J'ai bossé super dur dessus.
 
Un grand merci à tous, pour vos conseils.
Après toute la batterie de tests et de changements que j’ai réalisé, c’est également en faisant le ménage dans la base de registre que le pb a disparu.
Bon, le pb c’est qu’il faut le faire pour chaque PC, et qu’il y en a 250 ………..
(si quelqu’un voit une façon d’automatiser la tâche je suis preneur ).
 
En tout cas, grand merci, à ceux qui m'ont aidé.
 
Avec les conseils de classe qui doivent démarrer la semaine prochaine, on se sent un peu plus léger ...

Résolu à moitié...

 
 
 
c'etait quoi dans la bdr ?

 
Pourquoi dis-tu çà, ça m'intéresse ...

 
Toutes les références à l'ancien serveur sous son nom où par son ip sur les postes XP.
Franchement, je ne pensais que les PC chercheraient encore l'ancien serveur alors que celui actuel leur envoie l'info qu'il est le seul serveur DNS ...
(Surtout que l'obtention des adresses IP et du serveur DNS est automatique sur les postes).

VBScript pour manipuler la base de registre et script d'ouverture de session, comme ça dis le prochain redémarrage hop nettoyé.

 
Merci pour l'info.
Bon, il reste plus que je me mette aux scripts ...

Bah "bateau" c'est :

 
Pour les scripts d'ouverture de session, je te renvoie vers Microsoft, quand à la création d'une GPO, je pense que tu sais faire non ?

Sans Vbscript, juste des .reg que tu lances en silencieux dans un .bat
 
Sinon, quelles sont ces clés mystérieuses qui ralentissaient l'ouverture de sessions ?
 
Car si le poste client a les bons DNS et lance à l'ouverture de session que des scripts/programmes accessibles, je ne vois pas ce qui pourrait ralentir ?

Et bonne chance pour lancer des regwrite/regedelete sur HKLM avec un script d'ouverture de session (sauf si tous tes users sont admins).
 
Soit un startup script, soit des GPP

Le .reg/bat ça sera la même limitation

 
Tu n'avais pas précisé, ce qui ralentissait l'ouverture de session...
 

 
Toutes les références à l'ancien serveur sous son nom où par son ip sur les postes XP.
 

C'est  pas pour rien qu'on implémente du dfs pour gérer les shares ça évite de devoir modifier les gpo ou quoique ce soit lorsqu'un serveur tombe en rade, il suffit simplement de supprimez la référence du serveur HS.
 
Sinon pour ton cas il faut effectivement transférer les rôles avec ntdsutil (transfer role seize) http://support.microsoft.com/kb/255504/fr, nettoyez les métadonnées ntdsutil metadata cleanup, vérifier qu'il ya tjs un catalogue global sur ton serveur ,et surtout supprimez les références DNS vers le serveur HS , si ceux-ci y sont encore tu risques d'avoir des clients qui essaieront de l'interroger et seront soumis au problèmes de logon impossible (a cause du round robin dns ) etc...
 
Vérifier que tu as pas des bails dhcp trop qui contiennent encore la référence à l'ancien serveur sur tes clients . Modifier tes logons script si tu en utilises .
 
Tester ton serveur avec netdom fsmo roles pour voir si il possède bien tous les rôles .
DCDIAG /fix  
DCDIAG /v > dcdiag.txt ---> regarder si plus d'erreur
 
Tester tes clients avec nltest  
/DSGETDC:<NomDomaine> - appelle DsGetDcName /PDC /DS /DSP /GC /KDC pour vérifier que ton serveur restant a bien le flag PDC
/DCLIST: <NomDomaine> - obtient la liste des contrôleurs de domaine pour <NomDomaine>
/DNSGETDC:<NomDomaine> voir si ton serveur est bien le seul à répondre au requete dns .
 
 

Merci à tous pour vos nombreux messages.
 
Bon j'ai pris le temps de répondre parce que je voulais être sûr de vous envoyer les bonnes infos.
 
Pour ceux qui se demandent quelle clé de la BdR pose pb, c'est celle-ci :
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient
Et dans cette clé, il était fait référence à mon serveur HS.
Ce qui m'étonne, comme je disais, c'est que la valeur soit stockée dans la BdR alors que je fais de l'ip et du DNS automatique.
(Peut-être est-ce parce que, quand j'ai repris le réseau l'an dernier, tout était en adressage statique. Peut-être ces valeurs sont-elles restées ... ?)
 
Il y a d'autres références au serveur qui est HS en HKEY_LOCAL_MACHINE et en HKEY_USERS, mais après tests, elles ne semblent pas affecter la vitesse d'ouverture de session. Enfin, çà je le dis entre parenthèses. ...
 
Sinon, je partage l'avis de statoon54, tout en DFS ...
Sauf que quand j'ai repris le réseau, tout n'était pas comme çà, et je n'avais pas modifié toutes les GPO. Bien mal m'en a pris ...
(Au fait, merci statoon54 pour toutes ces remarques, je vais prendre çà en compte).
 
Pour bardiel, ShonGail et Je@nb, ou tout autre qui veut répondre ..., vous ne pensez pas que si j'exécute un script en GPO (oui, je connais les GPO ...   ), non pas à l'ouverture de session, mais au démarrage de l'ordinateur, je résous les pbs de droits et que ces clés seront effacées ...?  
 
Encore merci pour vos remarques ...

Oui ça marchera.
 
Après si c'est cette clé je pense que si tu configures la GPO adequat en disabled elle disparait

c'est pas sûr que ca marchera puisque tes pc ont un dns qui n'existe pas ils risquent de ne pas pouvoir exécuter les gpo (ils ne trouvent meme pas le domaine en fait)
J'ai déjà vu le meme cas il y a quelques années (une GPO qui inscrivait en dur les dns en la bdr puis une suppression de DC), on a dû remonter un DC avec l'ancienne IP le temps d'appliquer la GPO qui les efface. D'ailleurs est ce que tes pc aujourd'hui arrivent à appliquer les GPO  ? Pas sur du tout a mon avis
 
Sinon oui en appliquant une GPO machine les problemes de droits sont résolus.

Si le problème, c'est l'exécution d'un script sur les machines, il peut y avoir aussi la solution du psexec avec script copié en local sur chaque machine ou exécuté à partir d'un chemin UNC.

ah oui c'est pas faux Si les GPO s'appliquent pas, ça va pas marcher.
Tu peux toujours mettre une ip supplémentaire au DC le temps de l'opération.

 
Je confirme après essai, on résout effectivement les pbs de droits mais pas ceux de GPO, elles ne s'exécutent pas ...
Du coup, j'ai crée un fichier reg, je passe sur chaque machine, je le lance. Petit redémarrage, et les machines repartent du bon pied !
Bon, ça prendra plus de temps mais en 3 jours c'est fait. Cool l'informatique ...
 
Pour info, je sais maintenant pourquoi mes ordis ont gardé cette clé dans la BdR. Mon prédécesseur avait préféré les IP et le DNS en statique sur chaque PC.
J'avais tout basculé en automatique, sauf que j'avais pas vu que dans une GPO il indiquait l'adresse du DNS (double sécurité ... ?). Sachant que la GPO est prioritaire sur les infos du serveur DNS ou du DHCP.
Quoi qu'il en soit, quand le serveur est mort, les PC le cherchaient puisque c'est ce qu'ils avaient dans la base de registre, et qu'après, même si je changeais la GPO, de toute les façons elle ne pouvait plus s'appliquer, puisqu'inaccessible pour les PC ...
 
Pas toujours évident de reprendre après les méthodes d'un autre ...

clair mais tu aurais pu tenter la méthode de Je@nb, une seconde IP sur ton DC et ca aurait pu marcher (s'ils sont sur le meme vlan).

 
Je comprends l'idée, enfin je crois, mais je ne vois pas ce que ça aurait changé, puisque les PC n'y auraient pas accédé ... ?

Pourquoi ?

 
Bonsoir Je@nb,
 
Si je ne m'abuse, le but est que les postes communiquent avec le serveur en utilisant une autre adresse IP.
Comment peuvent-ils la connaître s'il n'arrive déjà plus à communiquer avec lui.
Ou alors quelque chose m'échappe, ce qui est fort possible ...

Si ton DC a l'ip 10.0.0.2
Que la GPO forçait l'utilisation du DNS sur 10.0.0.1
Rien ne t'empeche de rajouter sur le DC, l'ip 10.0.0.1.
Comme ça les postes arrivent à noueau à communiquer avec le DC. Tu configures ta GPO, scripts ou quoi, une fois que tous les PC ont récup la bonne config, tu enlèves l'ip supplémentaire

 
CQFD ...
Là oui, en effet, j'avais pas compris ...
 
Merci Je@nb,
Je ferais çà pour les PC restant