Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

problème de service de réplication: journal wrap error ; le merdier indescri ptible

1 réponse
Avatar
rantamplan
Message cross-posté sur
fr.comp.os.ms-windows.winnt, microsoft.public.fr.windows2000.
pas de fu2 positionné.

Bonjour,


Ca fait deux jours que je suis sur le problème, et que ni google, ni les
archives usenet, ni ce que j'ai pu trouver chez microsoft n'a pu résoudre.

Situation: Je suis le nouvel administrateur d'une boite où plus aucun
suivi régulier n'était effectué sur les serveurs depuis longtemps.
Deux contrôleurs AD Windows 2000 SP4 tout patchés de partout sur le
site: Net1 (le premier contrôleur de la forêt) et Net2.
Il y a quelques jours, j'ajoute un contrôleur AD Windows 2003 (compta);
forestprep, domainprep, toutça. Ca marche.
Hier. En regardant les logs je m'aperçois de vilaines erreurs au niveau
du service de réplication de fichiers, ces erreurs me disent que le
système ne fonctionne pas parce que mon serveur n'arrive pas à joindre
les autres contrôleurs du domaine (problème de DNS) ou qu'il y a un
problème de topologie, ou que le ntfrs (ce service, donc) n'est pas
démarré sur mes partenaires de réplication. Tant que mon service ne
fonctionnera pas, sysvol ne sera pas créé, partagé, et le serveur ne
participera pas à l'authentification sur le domaine.

Je vais voir sur net1 et net2, et effectivement, le ntfrs n'est pas
démarré. Je les démarre, confiant, tranquille et tout, et là, je me
retrouve avec une erreur hideuse qui dit (et j'élague):

Type de l'événement : Erreur
Source de l'événement : NtFrs
Le service de réplication de fichiers a détecté que le jeu de réplicas
"DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" est dans JRNL_WRAP_ERROR.

Nom du jeu de réplicas : "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)"
Chemin racine du réplica : "c:\winnt\sysvol\domain"
Volume racine du réplica : "\\.\C:"
Un jeu de réplicas va dans JRNL_WRAP_ERROR lorsque l'enregistrement
qu'il tente de lire dans le journal USN NTFS est introuvable. Ceci peut
avoir plusieurs causes.

[1] Le volume "\\.\C:" a été formaté.
[2] Le journal USN NTFS sur le volume "\\.\C:" a été effacé.
[3] Le journal USN NTFS sur le volume "\\.\C:" a été tronqué. Chkdsk
peut tronquer le journal s'il détecte des entrées endommagées à la fin
du journal.
[4] Le service de réplication de fichiers n'a pas été activé sur cet
ordinateur pendant une longue période.
[5] Le service de réplication de fichiers n'a pas pu suivre le débit
de transfert élevé des disques sur "\\.\C:".

Renseignements pris, la bonne raison est la 4. Le service a été
désactivé depuis super longtemps.

Le service a l'air correctement démarré, mais sur le serveur compta, ça
ne fonctionne pas plus, et à chaque redémarrage du service sur net1 et
net2, ça vautre

S'ensuit une proposition qui dit "Cliquez sur la clé :
"System\CurrentControlSet\Services\NtFrs\Parameters"
Double-cliquez sur la valeur portant le nom
"Enable Journal Wrap Automatic Restore" et mettez le valeur à 1"

Beaucoup de recherches sur google et microsoft on fini par m'indiquer
que cette solution n'était plus valide à partir du SP3. Je cherche
encore, et trouve que ça peut venir d'une taille trop faible du journal,
et que si les services n'ont pas été activés depuis longtemps, la
quantité de transactions à effectuer font péter le journal. Il faudrait
donc augmenter la taille avec la clé "Ntfs Journal size in MB". Je passe
donc tout ça à des valeurs bien conséquentes. J'essaie l'outil
ntfrsdiag, qui au départ me signale que "Enable Journal Wrap Automatic
Restore" n'est pas à utiliser dans ma situation, mais ne dit rien pour
ntfs journal size. Je supprime donc la première clé, et garde la
seconde, mais rien à faire.

Je trouve un message sur un forum où le gars a résolu sa situation en
virant tout ce qu'il y avait dans sysvol\policy, puis en récréant les
policies, mais ça ne fait rien, en dehors de générer plus de messages
d'erreur (mais pour cette personne, le problème était plus un problème
de réplication de policies non-uniforme)

Je trouve l'article qui me parle d'authoritative et non-autoritative
restore, http://support.microsoft.com/kb/290762/en-us#1 , mais cet
article sous entend qu'on a au moins un membre sur le domaine, pour
lequel la réplication est fonctionnelle, et qui peut servir de base pour
tout recréer sur les membres malades. Hors chez moi, les contrôleurs
historiques ne sont pas exploitable, et le contrôleur 2003 non plus. Je
ne pense donc pas pouvoir exploiter cette procédure.

En dehors de ça, la réplication d'AD fonctionne. Les utilisateurs sont
bien répliqués partout, tout roule.

Franchement, je n'ai plus d'idées.
Le ciel ne m'ayant guère aidé jusque là, j'espère beaucoup de
l'expérience de certains contributeurs ici, qui auraient pu rencontrer
ce problème. Les serveurs sont en prod, je veux bien désinstaller AD sur
net1 et net2, mais il faudrait que ça me laisse quelque chose
d'exploitable sur compta! Et là, je ne suis pas certain!

--
rantamplan

1 réponse

Avatar
rantamplan
rantamplan wrote:

Je trouve l'article qui me parle d'authoritative et non-autoritative
restore, http://support.microsoft.com/kb/290762/en-us#1 , mais cet
article sous entend qu'on a au moins un membre sur le domaine, pour
lequel la réplication est fonctionnelle, et qui peut servir de base pour
tout recréer sur les membres malades. Hors chez moi, les contrôleurs
historiques ne sont pas exploitable, et le contrôleur 2003 non plus. Je
ne pense donc pas pouvoir exploiter cette procédure.


Finalement, je l'ai tentée ce matin, parce que j'ai lu
http://minilien.com/?MtvS3b2mhD où ça dit que lorsqu'il n'y a qu'un
seul serveur, il faut faire D4 (lire l'article MS pour comprendre le D4)

J'ai donc fait un D4 sur net1, puis un D2 sur net2, et tout s'est
relancé nickel sur compta.

Il ne me reste plus qu'à aller constater s'il y a des pots cassés dans
policy et scripts.

--
rantamplan