DTLcompare - Guide utilisateur

Objectif

DTLcompare ne lance pas le diagnostic lui-même. Il analyse deux fichiers JSON déjà produits par DTLknowsWhy :

• un snapshot pris depuis un poste où l'accès distant fonctionne ;
• un snapshot pris depuis un poste où le même accès distant échoue.

Le résultat attendu n'est pas seulement une différence brute. L'outil classe les causes probables, explique les preuves retenues, écarte les fausses pistes et propose une action suivante.

Principe en une minute

python comparative_analysis.py ok_depuis_SCCF-CZC025814B.json ko_depuis_PC-BEN-001.json

Si le port SMB 445 répond depuis les deux postes mais que les partages ne sont visibles que depuis le poste fonctionnel, l'outil orientera plutôt vers une cause d'identité, de droits ou d'identifiants Windows mémorisés que vers une panne réseau.

Préparer les fichiers

1. Lancer DTLknowsWhy depuis le poste où l'accès fonctionne.
2. Lancer DTLknowsWhy depuis le poste où l'accès échoue.
3. Utiliser strictement la même cible dans les deux diagnostics : même serveur, même IP, même partage si un partage est testé.
4. Copier les deux fichiers .json dans le dossier de DTLcompare ou noter leur chemin complet.
5. Renommer les fichiers si nécessaire pour ne pas se tromper entre le cas OK et le cas KO.

Exemple de rangement recommandé

C:\Users\Utilisateur\Documents\Secato\outils\DTLcompare\
  comparative_analysis.py
  ok_SCCF-CZC025814B_vers_SCCF-71SFS42.json
  ko_PC-BEN-001_vers_SCCF-71SFS42.json

Contrôle rapide avant analyse

Dans PowerShell, placez-vous dans le dossier DTLcompare et vérifiez que les deux fichiers sont bien visibles :

cd C:\Users\Utilisateur\Documents\Secato\outils\DTLcompare
dir *.json

Si les fichiers sont ailleurs ou si leur nom contient des espaces, utilisez des guillemets :

python comparative_analysis.py "C:\Temp\diagnostic OK.json" "C:\Temp\diagnostic KO.json"

Lancer l'analyse

La commande attend toujours les fichiers dans cet ordre :

1. working_snapshot : snapshot où l'accès fonctionne ;
2. failing_snapshot : snapshot où l'accès échoue.

python comparative_analysis.py working_snapshot.json failing_snapshot.json

Exemple avec les fichiers du dossier

python comparative_analysis.py 172.17.7.19_snapshot_20260610_151730.json 172.17.7.19_snapshot_20260610_152617.json

Exemple avec un nom de rapport choisi

mkdir rapports
python comparative_analysis.py `
  ok_SCCF-CZC025814B_vers_SCCF-71SFS42.json `
  ko_PC-BEN-001_vers_SCCF-71SFS42.json `
  --output-prefix rapports\comparaison_SCCF_vers_SCCF-71SFS42

Le caractère ` en fin de ligne permet seulement de couper une commande PowerShell sur plusieurs lignes. Vous pouvez aussi tout écrire sur une seule ligne.

Exemples de lecture

Rapports produits

Par défaut, DTLcompare écrit trois fichiers dans le dossier courant. Après une exécution réussie, la console affiche leurs chemins.

start .\comparative_analysis_SCCF-CZC025814B_vs_PC-BEN-001_20260610_160015.html

Lire l'analyse

Commencez par la conclusion, puis descendez vers les preuves. Ne vous arrêtez pas au premier message d'erreur Windows : DTLcompare cherche à savoir si ce message est cohérent avec le reste des tests.

• Causes probables : hypothèses classées avec preuves, confiance et score de pertinence.
• Causes éliminées : pistes que les données permettent d'écarter, par exemple serveur SMB muet ou port 445 bloqué.
• Preuves : faits extraits des snapshots, comme ping, TCP 445, partages visibles, type d'identité Windows ou message d'erreur.
• Remédiation : action conseillée lorsque l'analyse permet de proposer une suite logique.

Exemple concret de conclusion

Le serveur SCCF-71SFS42 fonctionne correctement.
Le problème semble spécifique au poste PC-BEN-001.

Preuves :
- SCCF-CZC025814B voit les partages.
- TCP 445 répond depuis les deux postes.
- PC-BEN-001 contient un indice d'échec d'identifiants.

Dans ce cas, il est inutile de commencer par redémarrer le serveur ou modifier le partage. La piste prioritaire est le poste en échec : session SMB, identifiants mémorisés, compte utilisé ou droits associés.

Actions après l'analyse

Quand l'analyse pointe vers une cause d'authentification SMB côté client, voici une procédure simple à exécuter sur le poste en échec.

whoami
whoami /upn
net use
cmdkey /list
net use * /delete /y

Ensuite, retestez l'accès avec un compte explicite. Adaptez le format du compte au contexte réel : domaine, compte local du serveur, compte AzureAD ou UPN.

net use \\SCCF-71SFS42\share /user:DOMAINE\utilisateur *
net use \\SCCF-71SFS42\share /user:utilisateur@domaine.example *

Si le retest fonctionne après nettoyage des sessions ou changement de compte, joignez au ticket le rapport HTML et indiquez le compte utilisé lors du test réussi.

Options utiles

--lang fr|en
--json
--output-prefix chemin\rapport
--no-files

Dépannage