Ausserdem steht ja deutlich "Brother PC-Fax" in der Beschreibung.
Und darüber steht dann (endlich) sogar irgendeine Modell-Bezeichnung ... nämlich Brother MFC-7360N. Schaut man sich jetzt dessen Netzwerk-Fähigkeiten beim Hersteller an, kann man den als Benutzer zweifellos immer noch so verkonfigurieren, daß die ganzen Mechanismen zur automatischen Erkennung, die dieser Drucker (der Website nach) bietet, nicht mehr wie gewohnt oder wie erwartet funktionieren.
Mich plagt hier nur die Frage, warum man das tun sollte ... mit den unterstützten Protokollen:
läßt das Gerät fast keine Wünsche offen, unterstützt "gängige Mechanismen" für mehrere Plattformen (damit sollten neben Windows auch MacOS-Systeme genauso klarkommen, wie Linux-OS) und eine Garantie, daß der kontrollwütige Besitzer das nicht am Ende tatsächlich so verrammelt, daß diese ganzen Mechanismen nicht mehr greifen, kann ohnehin niemand (mit hinreichender Sicherheit) geben.
Auch die Feststellung, daß für einen funktionierenden Netzwerk-Drucker nun mal drei Komponenten zusammenspielen müssen (Netzwerk, Drucker, Client), ist sicherlich keine wirklich neue Erkenntnis und hier ist für mich das Ansinnen, diese ganze Bandbreite (der Clients) auch noch abdecken zu wollen mit der "Vorhersagbarkeit", einigermaßen unverständlich. Wenn es nur um eine begrenzte Anzahl solcher Clients geht, fehlt wieder die entsprechende Angabe (und zwar im gesamten Threadverlauf bisher, sofern ich nichts Signifikantes überlesen habe).
Das Angebot, den Drucker gemeinsam zu benutzen und dessen (korrekte) Konfiguration für Plug&Play in einem Netzwerk und die Frage, ob die Clients mit dem dann auch arbeiten können, sind nun mal zwei Paar Stiefel ... zumal wir hier auf einmal von der Frage, wie Drucker und Netzwerk dafür zu konfigurieren wären, zum Thema irgendwelcher Druckertreiber für "muchtige" Windows-Versionen abgeglitten sind. Schon die Frage, wie man als "Verantwortlicher" (als der sich der TO ja offenbar sieht) verhindern will, daß da jemand an den Windows-Einstellungen dreht und es
deshalb nach dem Umstecken ebenso nicht mehr funktioniert, ist (mir zumindest) einigermaßen unklar.
Ein ordentlich konfigurierter Client (ich kenne Leute, bei denen ein Windows7-PC per se nicht in diese Kategorie fallen würde) sollte jedenfalls so einen Drucker auch dann noch im LAN finden, wenn der die Adresse gewechselt hat ... es kann höchstens passieren (unter älteren Windows-Versionen tatsächlich ein beliebtes Spiel und so ganz scheint das am TO auch nicht vorbeigegangen zu sein, wie man im Screenshot sehen kann), daß Windows hier eine weitere "Kopie" desselben Gerätes noch einmal erstellt (der vorhandene Treiber wird dann meist weiterverwendet) und dem (Drucker-)Port dafür dann die gerade aktuelle IP-Adresse zuweist - dagegen kann man sich dann tatsächlich "wehren", indem man den automatisch (falsch) eingerichteten Druckerport ordentlich von Hand konfiguriert (wie das
@koyaanisqatsi wohl getan hat). Damit findet Windows dann auch den passenden Port und über ihn den Drucker, solange sich der Gerätename nicht ebenfalls geändert hat.
Solche Geräte werden von ihren Herstellern meist in nennenswerten Stückzahlen verkauft (und zwar an Leute, die nicht mal wissen, was DHCP ist) und deren Software ist dann in aller Regel auch darauf ausgerichtet, sich automatisch einigermaßen in verschiedenen Umgebungen zurechtzufinden. Daher sieht man (zumindest in neueren Windows-Versionen) auch schon mal ein Gerät im Netzwerk, dessen lokalen Treiber man noch gar nicht von irgendeiner CD/DVD installiert hat ... genau dafür gibt es dann nämlich Seitenbeschreibungssprachen und Standard-Protokolle (sowohl für das Drucken selbst als auch für das Auffinden solcher Geräte im LAN oder für das Nachladen zusätzlicher Informationen/Programme/Treiber aus dem Internet) - die Geräte lassen sich normalerweise auch auf mehreren Wegen von einem Client "entlocken", was sie nun genau unterstützen, wenn sie es nicht ohnehin von sich aus in die Welt hinausschreien (wie z.B. beim mDNS).
Es ist mir auch egal, ob/wie das beim TO nun funktioniert oder nicht bzw. ob er immer noch nach einer alternativen Lösung (Warum eigentlich, wenn die Frage nach DHCP doch positiv zu beantworten wäre? Und nur die steht in #1 ...) sucht. Für spätere Leser, die im Verlauf der ersten Seite den Eindruck gewinnen konnten, das wäre eine sehr unsichere Sache und eine nur schwer zu konfigurierende Besonderheit, will ich noch einmal ganz explizit festhalten, daß die vernünftigste und in der deutlichen Mehrzahl der Fälle auch funktionierende Lösung hier immer noch die Verwendung von DHCP und aller anderen automatischen Protokolle ist, mit denen die Geräte im LAN normalerweise kommunizieren und mit denen sie (vermutlich in > 99% der Fälle) auch die richtigen Parameter aushandeln oder die korrekten Treiber in einem System installieren.
Erst dann, wenn man dabei wirklich Probleme hat (und nicht nur solche, die sich in der Theorie und in der Zukunft abspielen
könnten), dann sollte man sich (als Laie) da an irgendwelche zusätzlichen Einstellungen wagen.