Comment savoir sur quel ordinateur un fichier est ouvert sur un partage réseau?

Environnement:

Windows XP sp3, serveur Windows 2003

Problème:

Nous avons plusieurs dizaines de machines de kiosque chacune avec le même nom de connexion qui occasionnellement et brièvement un fichier sur un partage. Le taux est de plusieurs verrous et libère une minute.

Récemment, nous avons vu l'un des clients verrouiller un fichier exclusivement, puis ne pas le libérer. 

Nous pouvons fermer le fichier lorsque cela se produit, mais plusieurs minutes ou plus s'écoulent, ce qui constitue une panne inacceptable.

Le problème de verrouillage inédit s'est produit plusieurs fois au cours du dernier mois. Je cherchais quel périphérique de kiosque est responsable du verrouillage et le détecte rapidement lorsqu'il se produit.

Il semble y avoir une lacune dans les informations que nous pouvons obtenir du serveur:

Nous pouvons voir à partir de divers outils:
-Quels fichiers sont ouverts et verrouillés. (de nombreuses façons)
-Quelle ouverture de session a un fichier spécifique ouvert ou verrouillé. (de nombreuses façons)
- Qu'un ordinateur particulier a généralement un fichier ouvert. (Dossiers partagés, sessions mmc)

Ce que nous ne pouvons pas voir, c'est qu'un ordinateur spécifique a un fichier spécifique ouvert et verrouillé.

Quelqu'un sait-il comment y arriver?

Merci -

Rob

Découvrez ce petit utilitaire gratuit ( ShareWatch ), je pense qu'il fera ce que vous cherchez.

L'une des fonctionnalités répertoriées: "Affiche les utilisateurs et les ordinateurs connectés à chaque partage, ainsi que les fichiers ouverts."

Entrez la ligne de commande (CMD),

puis tapez: openfiles / query ip of the networkshare

Et le nom d'utilisateur et le mot de passe peuvent être requis.

Vous pouvez obtenir plus d'informations sur les fichiers ouverts ici .

Je pense que vous allez vouloir vous référer au message de Sky100 car il a raison, non pas pour vous fournir ce que vous avez demandé, mais pour vous fournir ce dont vous avez besoin pour résoudre votre problème. Vous devrez référencer le numéro d'identification verrouillé via la commande "openfile / query / v" (verbose) car elle vous fournira les données dont vous avez besoin. Recherchez le nom de fichier dans la liste donnée, les données montreront quel élément la lecture et l'écriture sont activées et avec elles, elles fourniront un numéro d'identification spécifique. Non, vous ne pourrez peut-être pas trouver quel système spécifique le fichier est verrouillé, mais avec les outils fournis, vous pouvez déconnecter cet utilisateur du fichier. Voici une étape par étape pour simplifier mes divagations.

1) Sur le serveur de fichiers avec des droits d'administrateur, faites Démarrer> Exécuter> CMD [ENTER]

2) CD Desktop [ENTER] (Vous verrez pourquoi bientôt.)

3) openfiles / query / v> file.txt [ENTER] (Cela créera un fichier sur le bureau avec une liste de tous les fichiers ouverts sur le serveur.)

4) Ouvrez le fichier.txt et recherchez la ligne contenant à la fois votre nom de fichier et les autorisations de lecture + écriture.

5) Notez le numéro d'identification sur cette ligne et revenez à votre console de commande.

6) openfiles / déconnecter / ID [Mettre le numéro ID ici] [ENTER]

Tant que vous disposez de droits d'administration sur le serveur de fichiers, il déconnectera ce système du fichier et, en supposant que votre système est automatisé, devrait permettre aux choses de continuer à avancer selon les besoins.

Références: openfiles / query /? openfiles / déconnecter /?

Si vous avez besoin d'un script ou d'une application programmée adaptée à votre système, n'hésitez pas à commenter et je vous fournirai des informations de contact, un prix très bas ainsi que la technologie. support sur ma candidature.

Le problème que vous essayez de résoudre est-il celui que vous indiquez (c.-à-d. Mappez l'ordinateur client spécifique (pas l'utilisateur) au fichier verrouillé) ou est-ce qu'il y a un problème de verrouillage que vous devez résoudre?

Si ce dernier pouvait aider, il y aurait deux choses que je considérerais:

• Vérifiez l'AV qui est installé sur vos clients - J'ai vu plusieurs AV côté client provoquer un comportement de verrouillage anomole sérieusement désagréable sur les partages.

• Essayez de désactiver le verrouillage opportuniste en définissant la valeur de Registre EnableOpLocks sur 0.

  HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ LanmanServer \ Parameters EnableOplocks REG_DWORD 0 ou 1 Par défaut: 1 (activé)

Cela réduira quelque peu les performances mais ne devrait rien casser.

J'aimerais bien que quelqu'un réponde à votre question, c'est un problème intéressant.

Dans ma tentative de dépanner le problème de RobW et de fournir une solution alternative, je n'ai pas répondu à sa question.

Je crois que la solution que vous recherchez consistera à configurer des stratégies d'audit sur ce système, puis à configurer ce fichier pour auditer tout accès de cet utilisateur particulier. Les étapes pour effectuer cela peuvent varier en fonction de la configuration de votre réseau, je vais donc vous référer au lien technet de microsoft sur la façon de configurer différents systèmes à auditer.

http://technet.microsoft.com/en-us/library/cc787268(WS.10).aspx

Après avoir configuré cela, assurez-vous de poursuivre la configuration du fichier spécifique que vous souhaitez surveiller en attachant le compte d'utilisateur en tant qu'auditeur, vous devriez être prêt à partir.

Vérifiez simplement vos journaux d'événements de sécurité à l'avenir et bien qu'il répertorie chaque système (car ils utilisent tous le même nom d'utilisateur), il ne devrait pas être difficile de trier et de localiser le système qui a actuellement un accès en lecture et en écriture au fichier.

Il peut être utile de configurer le journal de sécurité pour l'effacer tous les quelques jours.

Si cela ne fonctionne pas, vous devrez probablement configurer le système pour chaque nom d'hôte accédant au fichier, plutôt que le nom d'utilisateur. Je crois que cela est possible via la console de gestion Microsoft.

Encore une fois, si vous avez besoin de programmation, je ne suis pas un homme d'affaires intéressé à prendre beaucoup d'argent pour un petit programme. Je propose une programmation de qualité à un prix que même un individu ne reculerait pas. J'espère que cela vous aidera à résoudre votre problème.

J'affecterais également différents utilisateurs à différents kiosques si possible - cela pourrait vous aider à analyser d'autres journaux ...

Si ce n'est pas possible: Aperçu de la solution possible: Une solution pourrait être d'exécuter un outil comme sysinternals processmonitor avec un filtre approprié (vers le fichier en question) sur les kiosques (je ne sais pas si vous pouvez le masquer). Vous pouvez jouer avec certaines options de ligne de commande qui enregistrent les données capturées dans un fichier.

Collectez-les dans les différents kiosques, importez-les par exemple dans Excel et recherchez celui qui n'a pas été fermé ...

Qu'en est-il de l'utilisation de la commande netstat pour déterminer cela?

netstat -an | find ":445"

Cela devrait vous donner les adresses IP des machines connectées.

Si vous voulez les noms d'hôtes plutôt que les adresses IP, utilisez

netstat -a | find "microsoft-ds"

cependant, cela prendra plus de temps à s'exécuter, en particulier sur les serveurs de fichiers ou les contrôleurs de domaine occupés, car il y aura beaucoup de recherches d'hôtes à effectuer.

Gardez également à l'esprit que les résultats afficheront les ports d'écoute entrants, sortants et inactifs.

Les connexions entrantes afficheront le: 445 dans la colonne de gauche, le sortant le montrera dans la colonne de droite.

Vous pouvez ignorer en toute sécurité tous les résultats qui indiquent «LISTENING» ainsi que toutes les lignes qui affichent uniquement les adresses IP locales (par exemple, 0.0.0.0 ou 127.0.0.1) ou le nom d'hôte de l'ordinateur si vous n'utilisez pas l'option -n.

Par exemple:

Z:\>netstat -an | find ":445"
  TCP    0.0.0.0:445            0.0.0.0:0              LISTENING
  TCP    127.0.0.1:445          127.0.0.1:41764        ESTABLISHED
  TCP    127.0.0.1:445          127.0.0.1:41767        ESTABLISHED
  TCP    127.0.0.1:41764        127.0.0.1:445          ESTABLISHED
  TCP    127.0.0.1:41767        127.0.0.1:445          ESTABLISHED
  TCP    192.168.16.17:445      192.168.16.87:1098     ESTABLISHED
  TCP    192.168.16.17:18055    192.168.16.24:445      ESTABLISHED
  TCP    192.168.16.17:20678    192.168.16.24:445      ESTABLISHED
  UDP    0.0.0.0:445            *:*

Le seul hôte connecté ici est 192.168.16.87. Les connexions à 192.168.16.24 sont sortantes. Toutes les autres connexions sont des connexions locales.

Je me souviens qu'il y avait un outil graphique dans les fenêtres pour vérifier les partages utilisés et les fichiers verrouillés.

Il doit se trouver dans les "outils système" sous "Gestion de l'ordinateur" (~ traduit du français ...), sous le nom de "dossiers partagés".

Je sais que c'est très ancien, mais ADSI fournit l'interface WinNT: //, qui vous permet d'accéder au service LANMANSERVER et de rechercher des propriétés déjà exposées dans le composant logiciel enfichable mmc "Dossiers partagés". Je recherche actuellement un moyen de lier un hôte et un utilisateur à un fichier ouvert.

Si c'était moi et que j'avais accès à une machine Linux sur le même sous-réseau ... Je ferais un tcpdump sur le port de partage en question dans la boîte sur laquelle ils ouvrent le fichier.

Si vous n'avez pas unix, vous pouvez toujours utiliser tcpdump mais vous devez l'installer.

de linux ... Je ferais quelque chose comme ceci: tcpdump -ieth0 -s0 -X hostname port 1234 | grep -i "nomoffile"

Je sais que la plus grande partie de la charge utile est binaire ... Cependant, je parierais bien que l'en-tête initial pour négocier l'authentification pour l'accès au fichier soit en texte clair.

Cela vous montrera chaque hôte distant qui se connecte à cette boîte et où le nom de fichier se trouve dans leurs données de paquet (s'il n'est pas chiffré ou en binaire).

Bonne chance! Mais d'après mon expérience, les éléments suivants devraient être utilisés:

1) Les fichiers partagés sont une mauvaise idée! Surtout avec des systèmes distants qui pourraient laisser un fichier verrouillé s'ils perdent la connexion ou ont des connexions lentes.

2) L'accès au fichier partagé provoquera une condition de concurrence entre les clients. Perdre un temps de tick précieux.

3) Si vous DEVEZ utiliser un fichier partagé ... Créez des noms d'utilisateur différents pour chaque site distant afin de pouvoir déboguer correctement.

Meilleur scénario ... débarrassez-vous du fichier et fusionnez-le dans SQL ou créez un service Web qui permet aux clients d'accéder au fichier ou aux données.

++ Todd