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


21

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


1
Pas tout à fait ce que vous demandez, mais une autre approche serait de créer un compte distinct pour chaque système.
Bryan

Réponses:


10

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."

texte alternatif


1
Merci pour cela - j'ai essayé Sharewatch. Dans ma situation - plus d'une douzaine de clients avec les mêmes noms de connexion - il combine les fichiers ouverts et les postes de travail dans la même liste. Vous ne pouvez pas dire quel poste de travail l'a ouvert. En outre, la sélection des propriétés signale simplement qu'un poste de travail a ouvert x fichiers, et non leurs noms de fichier. La sélection des propriétés du fichier donne des informations similaires.
RobW

7

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 .


Merci. Openfiles donne en grande partie la même sortie que la session nette à partir de la console du serveur. Il ne donne pas le nom de l'ordinateur qui a ouvert le fichier. Je recherche une connexion fichier-> ordinateur, pas une connexion fichier-> utilisateur.
RobW

5

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.


Ha! Mon problème était de localiser l'ordinateur à partir duquel le fichier a été ouvert. Avez-vous des idées sur la façon de procéder? L'identification et la fermeture du fichier sont simples et il existe de nombreuses façons de concevoir ce résultat. J'apprécie la réponse, et votre offre commerciale m'a donné un petit rire tôt le matin ;-)
RobW

Mes excuses, je ne savais pas que le processus openfiles n'était pas la solution. D'après ce que vous avez décrit, il semble que cela aurait résolu votre besoin de jeter un œil au système car il ne ferme pas le fichier, mais supprime simplement ce paramètre verrouillé. En fait, j'ai construit l'application pour mon entreprise et elle peut être automatisée pour fonctionner chaque petit peu pour éviter de telles complications. Je suppose que c'est hors de propos, cependant. Pour répondre à votre question directe: Oui, il devrait y avoir un moyen de vérifier ces systèmes pour leur accès à ce fichier. Veuillez consulter mon prochain article pour plus de détails.
Thomas

En fait, revenir en arrière et relire votre message ... "Nous pouvons fermer le fichier lorsque cela se produit, mais plusieurs minutes ou plus s'écoulent, et c'est une panne inacceptable." La raison pour laquelle votre solution ne fonctionne pas est que vous fermez le fichier. Ma solution et partiellement celle de Sky100 fournie précédemment ne ferme pas le fichier, mais MODIFIE les droits d'accès en lecture seule. Encore une fois, je suis confus quant à la façon dont les fichiers ouverts NE SONT PAS la solution que vous recherchez. Essayez-le avant de l'écrire comme une non-solution. Si vous n'êtes pas intéressé par un programmeur, créez un fichier de commandes à exécuter toutes les quelques minutes.
Thomas

Je laisse ma solution à votre question ci-dessous pour ne pas perdre de temps au cas où ma compréhension de la situation ne serait pas approfondie.
Thomas

Mmmm. Toutes mes excuses, mais je ne pense pas que vous ayez répondu à ma question. J'avais besoin d'aide pour déterminer quel ordinateur gardait le fichier ouvert. Je suis vraiment intéressé à déterminer le nom de l'ordinateur. Tout le reste, bien qu'intéressant, ne me dit pas la chose finie que je recherche.
RobW

2

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.


Merci Helvick! La désactivation du verrouillage opportuniste est une approche intéressante. Serveur je suppose?
RobW

Oui, c'est sur le serveur - cela empêche les clients de demander un verrouillage opportuniste afin qu'ils puissent mettre en cache localement (des parties de) fichiers.
Helvick

Les performances affectées par la désactivation du verrouillage opportuniste seraient très probablement inacceptables pour nous. Nous devons examiner cela dans notre banc d'essai.
RobW

C'est certainement un risque avec cela - je serais intéressé par ce que vous trouvez.
Helvick

2

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.


Merci pour cela. J'ai défini l'audit sur ce répertoire peu de temps après le problème initial. Nous avons ~ 150 clients (et pas seulement des kiosques) actifs dans ce répertoire. Comme le problème est intermittent, le rapport signal / bruit était énorme et je n'ai pas vu de moyen clair de lier un ordinateur particulier à un événement de fichier. Je vais revoir ça. Nous avons déjà eu quelques réunions de conception à ce sujet. Plusieurs sujets sont sur la table, y compris les comptes d'ouverture de session. J'aimerais encore savoir quel ordinateur
contient

1

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é ...


0

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.


Hmmm, relisez simplement votre question, et cela ne résout pas tout à fait votre problème, car il ne vous dit pas quel fichier l'ordinateur a ouvert.
Bryan

Aucun problème. J'apprécie l'idée.
RobW

0

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".


0

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.


-1

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

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.