[Pas résolu en fait :)]Serveur plus accessible via partages réseaux

Répondre
Partager Rechercher
Hello,

Ptite galère au boulot dont je n'arrive pas à me sortir.

J'ai deux serveurs, appelons les A et B, qui ne communiquent plus l'un l'autre depuis Jeudi sans que j'arrive à comprendre pourquoi.

A doit déposer des fichiers sur B via un partage réseau mais A n'arrive plus à joindre B.

Quelques infos en vrac :
- A est un Windows Server 2008R2
- B est un Windows Server 2003
- les deux sont des VM (Hyper-V) qui sont sur le même serveur physique
- A peut joindre toutes les machines de la DMZ sauf B
- par contre B peut joindre A sans problème
- Les serveurs sont sur le même réseau 192.168.5.X, qui est une DMZ sur laquelle le parefeu matériel (Zyxel USG 200) n'intervient pas (vérifié, rien de bloqué, et rien de loggé concernant un éventuel rejet de paquets)
- le LAN peut communiquer avec la DMZ sans problème mais ne peut plus joindre B non plus
- les pings fonctionnement dans les deux sens
- les tracert idem
- les parefeux windows sont désactivés des deux côtés
- netbios est bien activé des deux côtés
- ca ne fonctionne ni via l'explorateur windows, ni en ligne de commande en essayant de monter un lecteur réseau par exemple
- ce sont des serveurs de production et mon équipe s'amuse à déposer les fichiers à la main pour ne pas bloquer les clients en attendant mais je sens bien que les tech commencent à être un peu soulés

Je sais plus trop où chercher, j'ai déjà pas mal épuré google mais sans résultat probant...
Il y aurait des utilitaires qui pourraient m'aider à comprendre ?
Je cherche du côté de Wireshark pour essayer de comprendre mais je sais pas trop analyser les paquets j'avoue

Help

Dernière modification par Saelian ; 13/07/2017 à 17h33.
Citation :
Publié par Whinette
Un bug smb ? Essaie de redémarrer le service ?
D'autres machines y ont accès ?
Non plus aucune machine n'accède à B en partage réseau, ce doit donc bien être elle qui déconne.

La machine a été reboot sans succès.
Au niveau des services, ils sont bien démarrés et ont été redémarrés aussi.

Edit pour en dessous : dernières maj effectuées fin mai

Dernière modification par Saelian ; 04/07/2017 à 14h35.
T'aurai pas eu le patch microsoft entre temps ?

Essaye de supprimer le dernier patch installé (qui dois dater de moins d'une semaine) voir si c'est ca ?
Plus d'infos :

- j'ai forcé sur le parefeu matériel une règle qui autorise A vers B pour tous les protocoles en IP privée > pas mieux
- un netstat -ano sur le serveur B montre bien les ports 139/445 utilisés par NB/SMB comme ouverts et en écoute mais pour autant, un telnet sur ces ports depuis A n'aboutit pas (aboutit correctement sur les autres services type http 80 de B)

pas mieux :'(
Oui, sur le même domaine que les autres serveurs.
Je vois rien d'anormal dans AD mais c'est pas trop mon domaine (notre admin nous à laché il y a deux mois et il ne sera pas remplacé avant un moment, budget toussa...). Il est possible qu'un paramétrage bloque cet accès dans AD ? Ca m'étonne, vu que B>A fonctionne

J'ai essayé de le virer du domaine pour le rattacher de nouveau, idem
J'ai mis à jour les composants invités Hyper-V qui m'annonçaient une 'alerte', idem
J'ai créé un nouveau commutateur virtuel dans Hyper-V > idem

je commence à sécher

Je vais temporairement bricoler un script pour que B vienne chercher les flux sur A plutôt que ce soit A qui les pousse mais ça ne peut qu'être temporaire et je vais envisager de procéder à la migration du serveur 2003 en 2016 plus tôt que prévu (c'était prévu pour l'an prochain) mais j'avais autre chose à faire en ce moment
Tu as dis que le port 80 répondait et comme c'est une DMZ je suppose que c'est un serveur web.

Coté DNS tu as testé les accès réseau en IP plutôt qu'en nom d'hôte ?

Se qui est étonnant c'est que tu as réussi a rejoindre ton domaine, donc tu as plus que le ping qui passe.

Tu as un serveur NTP ? la synchronisation du temps entre tes VM et l’hôte voir le domaine peut empêcher les accès aux partages.

Va falloir fouiller les évents log et remonter tout se que tu vois.
Oui on a une sauvegarde mais comme on l'a jamais fait (sans admin), on est pas jouasse à l'idée de restaurer une machine de prod comme ça

On va creuser cette piste

Edit pour au dessus : oui il y a un IIS sur ce serveur avec certains ports ouverts.
Non fonctionnel en accès IP autant qu'en nom d'hôte.
Non pas de serveur NTP chez nous.

Honnêtement, tout fonctionne sur cette machine (IIS Web, FTP ainsi que d'autres protocoles spécifiques sur des ports particuliers) sauf ce p**** de partage réseau depuis d'autres machines du réseau...

On tente la restau de VM à Mercredi soir (le pb est survenu Jeudi dans la journée)

Dernière modification par Saelian ; 05/07/2017 à 12h53.
essaie de passer cette cmd sur B: net time /domain /set

En faite quel est le message d'erreur affiché, as tu un événement de créé sur B ?

es que tu arrives a te connecter au gestionnaire de serveur de B depuis A ?
Citation :
Publié par Saelian
Oui on a une sauvegarde mais comme on l'a jamais fait (sans admin), on est pas jouasse à l'idée de restaurer une machine de prod comme ça
Comment ça sans admin ? '
La VM restaurée ne remplace pas forcément la VM de prod, vous pouvez la tester sur un autre environnement.
Si ça résout le problème (durablement, i.e. après mises à jours et applications des gpo de prod pour éviter que ça se reproduise), tu fais faire la restau sur la prod par les admins.
Citation :
Publié par Eyce Karmina
Comment ça sans admin ? '
La VM restaurée ne remplace pas forcément la VM de prod, vous pouvez la tester sur un autre environnement.
Si ça résout le problème (durablement, i.e. après mises à jours et applications des gpo de prod pour éviter que ça se reproduise), tu fais faire la restau sur la prod par les admins.
Notre admin système nous a quitté y a pas longtemps donc il me reste que mon technicien et moi-même, et on est pas aussi calé que l'était l'admin (qui ne sera remplacé que fin d'année vu que le poste n'était pas budgété...)

On est en train de backup la VM actuelle pour assurer le coup et on va tenter la restau sur une autre VM, je savais pas qu'on pouvait faire ça en effet.

Pour les questions de Zaebos, la machine est en cours de copie, je peux plus intervenir dessus pour l'instant mais la seule chose qui ne fonctionne pas c'est d'accéder à la machine depuis un autre serveur via \\monServeur\monPartage (ou \\192.168.5.X\monPartage)
Oui j'ai accès au gestionnaire de serveur de B depuis A
J'ai pas précisé que ce n'était pas un problème de droit, peu importe les droits on passe pas (même admin du domaine)
Bon, en restaurant la VM à la date de Mercredi soir, je récupère mon partage réseau, j'ai au moins pu débloquer tous les flux de production bloqués mais... la VM tape maintenant des BSOD de manière aléatoire.

Je repars googliser un peu
C'est ce que j'aurai fait depuis longtemps si c'était possible mais c'est un vieux serveur qui a été mal géré dans le temps et on a plus certaines licences qui sont liées directement aux composants système donc très compliqué.

Enfin ca n'a pas planté depuis 2h après un coup de CCCleaner et après avoir rajouté certains hotfix préconisés par MS, je croise les doigts.

Merci à tous pour votre aide en tout cas, je pense qu'on peut clore le topic
Bon en fait c'est pas résolu du tout, la machine reperd son réseau régulièrement, parfois au bout de quelques heures parfois très rapidement.
On a fait un snap de la VM et on la restaure dès que ca crash le temps de trouver la solution.

La différence c'est que j'ai maintenant des logs dans l'observateur et, comme le suggérait Zaebos, ca parle bien de problème de NTP/W32Time qui crash et/ou qui n'arrive pas à joindre le serveur.

Les écrans bleus continuent également mais je les provoque lorsque que je /net time

Je creuse google mais j'avoue que je ne connais pas du tout cette partie d'active directory donc pour l'instant j'avance pas des masses, si vous avez des idées, je suis toujours preneur
Deux choses:

Tu dois avoir une synchronisation liée a l’hôte de virtualisation possible.

Tu dois déjà savoir si la machine synchronise sur l’hôte ou pas et en fonction voir si cela peut résoudre le problème.


Cas 1 toutes les VM sont Synchronisées avec l’hôte sauf celle-ci, tu changes sa config pour la rajouter.

Cas 2 L’hôte en question n'est pas synchronisé avec le reste du domaine, dans ce cas tu ne synchronise plus ta VM avec l’hôte et tu force le temps du système sur le domaine. Ceci n'est pas pérenne, c'est une synchronisation a un moment donné et cela peut donc se perdre.

Pour stabiliser ceci tu dois installer un serveur NTP sur le domaine, si plusieurs contrôleurs sur celui qui détient le rôle FSMO: PDC

https://support.microsoft.com/fr-fr/...windows-server

Un serveur de temps doit y être configuré via le registre. Si tu as un DHCP dans ton réseau a coté de ça celui-ci peut diffuser le serveur NTP ainsi configuré pour les machines en IP fixes elles vont naturellement interroger le DC avec le rôle émulateur PDC

Pour en revenir a tes crash c'est complètement anormale que tu es ceci quand tu veux changer le temps de ton système, je continue de penser que ta VM est dans état de stabilité inquiétant pour la suite.

Dernière modification par Zaebos ; 18/07/2017 à 15h31.
Citation :
Publié par Saelian
Oui on a une sauvegarde mais comme on l'a jamais fait (sans admin), on est pas jouasse à l'idée de restaurer une machine de prod comme ça
Vous ne testez pas vos backups ? En pratique, ca veut dire que vous n'avez aucun backup. Des que vous faites un backup, validez que vous pouvez restore une autre VM avec.
Répondre

Connectés sur ce fil

 
1 connecté (0 membre et 1 invité) Afficher la liste détaillée des connectés