Die Frage ist aber, ob der net send-Befehl beide Anmeldungen
findet - wenn das der Fall wäre, könnte man die selbe Technik
natürlich auch dazu verwenden, die Rechner zu identifizieren.
Nein, tut er nicht. Der gesuchte Messenger-Name Username ist per Definition Unique, d.h. dass nur ein einziger Computer ihn registrieren kann. Mit Subnetzen hat das nur insofern was zu tun als dass Computer in Subnetzen, die nicht mit einem WINS Server versehen wurden, den Namen fälschlicherweise doppelt registrieren können, weil der Check auf Doppelregistrierung an der Subnetzgrenze scheitert. Aber das ist ein Fehler im Netzaufbau, und nichts worauf man stolz ist. Sobald man die Subnetze korrekt per WINS verbindet wird die Doppelregistrierung verhindert.
Und es ist tatsächlich der Fall, nur taugt das von net send
verwendete Verfahren (Microsoft + Netzwerk - naja…)
allenfalls für Kleinstnetze.
So ist es. Es hat seine Wurzeln - wie übrigens der Netzwerkbrowser, der das „Inhaltsverzeichnis“ des Gesamtnetzes erstellen soll - im alten NETBIOS/NETBEUI Netz, das Microsoft seinerzeit von 3-Com eingekauft hat (3+ Open). Da NETBEUI nicht routingfähig war, gab es keine Probleme mit Subnetzen. Und eine Mehrfachanmeldung von Benutzern wurde als „seltener Sonderfall“ gar nicht erst berücksichtigt, angesichts der damaligen PC Preise eine durchaus richtige Annahme. Bis heute hat sich MS um dieses Problem, wie man am anderen Kollisionsfall „serverbasierte Profile“ deutlich sehen kann, nur halbherzig gekümmert. Jeder der mal versucht hat, ein Netz mit serverbasierten Profilen zu migrieren, in dem die Benutzer entweder PC+Terminal Server oder PC+Laptop (oder alle drei) mit dem selben Account gleichzeitig nützen, also zwangsweise doppelt angemeldet sind, kann ein leidvolles Liedchen darüber singen.
Es wird per Broadcast eine in TCP
verpackte netbios-Nameservice-Anfrage „Wer ist ‚Benutzer‘?
Bitte melden an…“ verschickt.
Fast ganz richtig. In einer subnetzgesegneten Umgebung fällt die Microsoft Broadcastauflösung auf die Nase, weshalb man seinerzeit mit dem Umstieg auf TCP flugs einen WINS Server erfunden hat. Sobald einer existiert wird per Unicast Paket im WINS gesucht. Broadcast wird nur noch als „Fallback“ mitgezogen für den Fall, dass der WINS Server mal ausfällt, man hat dann immerhin noch ein funktionierendes Subnetz, imemr noch besser als gar nnichts, dachte man sich wohl.
Das Messenger Problem hat damit aber nichts zu tun, Problemursache ist die „Unique“ Registrierung des Messenger-Namens. Nur ein einziger PC kann ihn besitzen, kommt ein zweiter, bekommt der eins auf die Finger, und geht der erste PC später aus dem Netz, bekommt der zweite das nicht mit, und verpennt dann seine Chance, den Namen, der jetzt eigentlich frei wäre, doch noch zu bekommen. Net Send versagt dann. Außer der Benutzer meldet sich neu an, aber wer tut das schon. Tut er es, entweder auf seinem zweiten Rechner oder woanders, kann der den Namen in Besitz nehmen, und net send geht wieder.
Ich bleibe dabei: man muss die Suche nach dem angemeldeten Benutzer, wenns funktionieren soll, selber programmieren. So schwer ist das Gott sei Dank auch nicht. Zwei simple Ansätze:
* Schleife über alle IP Adressen, und dann per WMI den angemeldeten Benutzer aus dem Rechner fischen. Bei C Netzen funktioniert das ganz prächtig, bei A und B Netzen durchaus auch noch, wenn man den Bereich er IP Adressen, die man abklappern will, einschränken kann, z.B. auf einen DHCP Range, der normalerweise viel kleiner ausfällt als alle Adressen. Unsicherheit: ich habe noch nie nachgesehen, ob die WMI Schnittstelle bei Rechnern, wo mehrere Benutzer angemeldet sind (Terminal-Server und Server mit Remote-Konsolen) auch brav eine Liste von Benutzern zurückgeben kann. Ich wage zu zweifeln, da Microsofties über die Sonderfälle des Lebens in der Regel lieber reden als sich darum zu kümmern.
* Wie schon angerissen: jeder anmeldende PC meldet sich auf einem Server, jeder abmeldende PC trägt sich brav wieder aus. Das klappt auch mit Terminal-Servern und Remote-Sessions wunderbar, benötigt aber irgendwo einen permanent laufenden Speicher wo man hinschreiben kann.
* Kombination aus Beiden: die serverstützte Liste enthält naturgemäß die anmeldenden Benutzer sehr zuverlässig, die abmeldenden dagegen nicht, wegen Abstürzen, Ruhezustand und Stecker-Raus Rüpelbenutzern. Also nimmt man die Liste der Computer, auf denen sich jemand angemeldet, aber nicht abgeleldet hat, als Eingabeliste für Lösung 1, statt alle IPs abzuklappern. Man bekommt dann eine subnetzübergreifende Liste aller Benutzer/Computer. Die Abfrageroutine muss dann nur noch damit rechnen, dass der eine oder andere Computer *doch* nicht mehr online sein könnte, damit die Suche nicht auf die Bretter geht wenn jemand den Stecker rauszieht. Eine Frage der Programmintelligenz und des Fehlerhandlings.
Ich habe solche Systeme schon erfolgreich implementiert. Normalerweise als programmierte Komponente in Support-Unterstützungssystemen, da die Supportler oft eine Möglichkeit suchen, schnell herauszufinden, wo ein bestimmter Benutzer angemeldet ist, weil sie ihre Remote-Help Konsole nur an den Rechnernamen, aber nicht an den Benutzernamen verbinden können.
Wers einfach aber funktionierend will und nicht gerade ein 10.000 User Netz verwaltet macht es über simple Serverdateien. Der Rest und Fans von Technik-Overkill bemühen dazu eine Datenbank.
…Armin