Windows Update zerschiesst Netzwerkeinstellungen

[dr-borchert]

Das braucht wirklich keiner:
Wartezimmer schon gut gefüllt, nach Hochfahren der PCs ist kein Netzwerkzugriff möglich; Netzlaufwerke können alle nicht geöffnet werden, TM-Start damit nicht möglich. (Den Abend zuvor Windowsupdates gelaufen).
Neustart der Fritzbox und andere Maßnahmen ohne Erfolg; Lösung einige Adrenalinstöße später: Windows hat nach dem letzten Update die Dateifreigabe sowie auch die Einstellung "Netzwerkanmeldung ohne Kennwort" deaktiviert.
Nach entsprechender Anpassung der Netzwerkeinstellung funktioniert wieder alles ohne Probleme.
Ergo: Nicht nur TM-Updates sind ein Himmelfahrtskommando.
Dieser Thread nur für den Fall, dass jemand ähnliche Probleme hat.

Herzliche Grüße
W. Borchert

[SFeu]

Das Problem hatten wir vor 2 Jahren, als ein Windows-Update
die Heimnetzgruppe -stillschweigend- entfernte,
Nach Neueinrichten der Freigaben mit Passwort ging alles wieder.

[Johnny]

dr-Bochert schrieb:

Nach entsprechender Anpassung der Netzwerkeinstellung funktioniert wieder alles ohne Probleme

An alle Profi:
- Hätte auch eine Deinstallation des Updates geholfen?
- Oder eine Rücksetzen auf einen vorherigen Wiederherstellungspunkt?

Wie ist Eure Erfahrung - Meinung?

Grüsse aus Kiel
Johnny

[pdg]

Das braucht wirklich keiner:
Wartezimmer schon gut gefüllt, nach Hochfahren der PCs ist kein Netzwerkzugriff möglich; Netzlaufwerke können alle nicht geöffnet werden, TM-Start damit nicht möglich. (Den Abend zuvor Windowsupdates gelaufen).
Neustart der Fritzbox und andere Maßnahmen ohne Erfolg; Lösung einige Adrenalinstöße später: Windows hat nach dem letzten Update die Dateifreigabe sowie auch die Einstellung "Netzwerkanmeldung ohne Kennwort" deaktiviert.
Nach entsprechender Anpassung der Netzwerkeinstellung funktioniert wieder alles ohne Probleme.
Ergo: Nicht nur TM-Updates sind ein Himmelfahrtskommando.
Dieser Thread nur für den Fall, dass jemand ähnliche Probleme hat.

Herzliche Grüße
W. Borchert

und erneut ...!!!
Gestern W10 update auf Server (ich weiß schon, daß ...), zusätzlich auf W7 Workstation ( dto. !!!) - Folge heute morgen: nichts funktioniert mehr. Aktuelles W10 scheint keine NW Verbindung mit W7 Rechnern mehr zu machen.

Alles zurückgesetzt (nachdem mir klar wurde, wo es hakt), nun läuft es wieder (im übrigen wurde auch die Lizenz auf der WS nicht mehr erkannt und musste neu reinkopiert werden - eingestellt ist aber, zunächst auf dem Server danach zu suchen ...).

Sicher betrifft dies nur wenige Kollegen - ich höre zum 30.6. auf (!!!!), werde daher die Q2 TM erst zur Abrechnung einspielen. Aber es nervt und nervt, früher gab es das nicht !

An die jüngeren Kollegen: DURCHHALTEN und nicht verzeifeln ...

[nmndoc]

Hatten Sie auch so etwas wie "Netzwerkanmeldung ohne Kennwort" o.ä. genutzt?
Ich muss geseteh, so etwas kannte ich - glaube ich - bisher gar nicht... ist das so etwas in der Art wie Heimnetzgruppe? Jedenfalls klingt das nach nichts,was man verwenden sollte - nicht in einer Arztpraxis und auch sonst.
Gut möglich dass sich MS davon verabschiedet und im Zuge von "mehr Sichrheit" so etwas nicht funktioniert. Ist aber dann sicher auch bei den Updates dokumentiert - nur liest die wohl kaum Jemand durch.
Wir haben nur reguläre Freigaben und hatten das Problem bisher nicht - auch nicht in Kombination mit Windows 10 + 7.

[lcer]

Hallo,

Netzwerkanmeldung ohne Kennwort - ???? - für den Patientendatenserver ????

dümmer geht es wohl nicht. Da hätte man sich vor 10 Jahren schon drum kümmern müssen. Sicherheitstechnische jedenfalls ein NoGo. Engagement am PC in allen Ehren, aber sowas darf es heute nicht mehr geben. Also: entweder am Wochenende das Netzwerk absichern oder die IT Betreuung abgeben,

Grüße

lcer

[pdg]

[quote="lcer"]Hallo,

Netzwerkanmeldung ohne Kennwort - ???? - für den Patientendatenserver ????


Keine Sorge ... natürlich mit NW Kennwort, dennoch macht fast jedes Windows update Ärger

[nmndoc]

@pdg: wir haben/hatten damit m.E. keinerlei Probleme - egal ob Win10, Win10+7, Workgroup oder Domäne. Insofern wäre die Vermutung, dass es eher an Ihrer konkreten Umgebung / Konfiguration liegt. MÜsste man mehr Informationen zu Ihrer Konfiguration haben. zB auch erfolgt der Aufruf \\<server-ip>\turbomed\... oder \\server-name oder <gemapptes-Laufwerk>\... ? Sind die PCs normal immer an oder werden die abens runter gefahren (wir hatten manche, wo es locker 5-10 min gedauert hat, bis die Netzwerkverbindung da war, nach einem Neustart), wie erfolgt die Anmeldung am Client - zB User=Praxis + Passwort - gibs den auf dem Server auch oder sind andere Anmeldedaten zB für ein gemapptes Laufwerk hinterlegt usw.

[pdg]

@pdg: wir haben/hatten damit m.E. keinerlei Probleme - egal ob Win10, Win10+7, Workgroup oder Domäne. Insofern wäre die Vermutung, dass es eher an Ihrer konkreten Umgebung / Konfiguration liegt. MÜsste man mehr Informationen zu Ihrer Konfiguration haben. zB auch erfolgt der Aufruf \\<server-ip>\turbomed\... oder \\server-name oder <gemapptes-Laufwerk>\... ? Sind die PCs normal immer an oder werden die abens runter gefahren (wir hatten manche, wo es locker 5-10 min gedauert hat, bis die Netzwerkverbindung da war, nach einem Neustart), wie erfolgt die Anmeldung am Client - zB User=Praxis + Passwort - gibs den auf dem Server auch oder sind andere Anmeldedaten zB für ein gemapptes Laufwerk hinterlegt usw.

Ich schimpfe ja inzwischen gerne auf TM, in diesem Fall (siehe Titel des Artikels) ist jedoch nicht TM "schuld".
Bevor TM ins Spiel kommt muss erstmal das Netzwerk verbunden sein. Das macht ja wohl Windows (kaputt). Es war auf der workstation trotz Eingabe des korrekten NW Kennwortes nicht möglich sich mit dem NW zu verbinden. Nach Rückkehr zur letzten Windows 10 Version waren wieder alle WS spontan (und sofort) mit dem Server verbunden. Allerdings hatte auf einem WS Rechner TM keine Lizenz mehr und musste neu initialisiert werden.
Ich kann mir schon denken, daß als Antwort kommt, versuchs mal mit einem Server Betriebssystem auf dem Server ... Willl ich für den Rest meines Kassenarztlebens aber nicht mehr.

[nmndoc]

Es war auf der workstation trotz Eingabe des korrekten NW Kennwortes nicht möglich sich mit dem NW zu verbinden.

Alleine die Tatsache, dass Sie ein extra NW-Kennwort eingeben müsseb (dh ich verstehe es so - beim Zugriff auf die Freigabe?) zeigt, dass etwas an Ihrer Konfiguration nicht stimmt.

Ich gehe davon aus, dass Sie eine Arbeitsgruppe haben?

Beispielhaftes Szenario:

- 5 PCs, 1 Server

- An den Windows-PCs erfolgt die Windows(!)-Anmeldung mit Benutzer "praxis" und Kennwort praxis!1234
- Der Server verwendet für die Windows-Anmeldung zB benutzer admin + kennwort
- Auf dem Server MUSS der Windows-Benutzer "praxis" mit dem identischen Kennwort ebenfalls existieren

- Auf dem Server sind die NTFS-Berechtigungen (Verzeichnis/Dateirechte; Explorer rechtsklick > Eigenschaften > Sicherheit) für den Turbomed-Ordner so gesetzt, dass zB "benutzer" Vollzugriff haben (schlechter) oder besser: "Benutzer" (dh die Gruppe) (oder explizit der Benutzer "praxis") die Berechtigung "ändern" auf dem Ordner und Unterordner hat.
- Der Ordner wird freigegeben (erweiterte Freigabe) und die Berechtigungen auf "Jeder Vollzugriff" gesetzt (nein das ist kein Problem, weil im Nachgang die Ordner/Dateirechte geprüft werden und so die effektive Berechtigung entsteht)

Wenn Sie jetzt vom Client aus auf \\sever\turbomed zugreifen, müssen Sie *kein* Kennwort eingeben.

Noch ein Hinweis am Rande, da beliebte Fehlerquelle:

a) würde ich von der Verwendung gemappter Laufwerke also zB "N:" = \\server\turbomed generell abraten - aber - wenn man diese verwendet und hat sie zB als o.g Benutzer "praxis" verbunden - und man startet zB wegen das Updates Turbomed als Administrator, dann wird das im Zweifelsfall fehlschlagen, da in diesem Userkontext das Laufwerk nicht bekannt ist/nicht existiert.

[pdg]

Es war auf der workstation trotz Eingabe des korrekten NW Kennwortes nicht möglich sich mit dem NW zu verbinden.

Alleine die Tatsache, dass Sie ein extra NW-Kennwort eingeben müsseb (dh ich verstehe es so - beim Zugriff auf die Freigabe?) zeigt, dass etwas an Ihrer Konfiguration nicht stimmt.

Ich gehe davon aus, dass Sie eine Arbeitsgruppe haben?

Beispielhaftes Szenario:

- 5 PCs, 1 Server

- An den Windows-PCs erfolgt die Windows(!)-Anmeldung mit Benutzer "praxis" und Kennwort praxis!1234
- Der Server verwendet für die Windows-Anmeldung zB benutzer admin + kennwort
- Auf dem Server MUSS der Windows-Benutzer "praxis" mit dem identischen Kennwort ebenfalls existieren

- Auf dem Server sind die NTFS-Berechtigungen (Verzeichnis/Dateirechte; Explorer rechtsklick > Eigenschaften > Sicherheit) für den Turbomed-Ordner so gesetzt, dass zB "benutzer" Vollzugriff haben (schlechter) oder besser: "Benutzer" (dh die Gruppe) (oder explizit der Benutzer "praxis") die Berechtigung "ändern" auf dem Ordner und Unterordner hat.
- Der Ordner wird freigegeben (erweiterte Freigabe) und die Berechtigungen auf "Jeder Vollzugriff" gesetzt (nein das ist kein Problem, weil im Nachgang die Ordner/Dateirechte geprüft werden und so die effektive Berechtigung entsteht)

Wenn Sie jetzt vom Client aus auf \\sever\turbomed zugreifen, müssen Sie *kein* Kennwort eingeben.

Noch ein Hinweis am Rande, da beliebte Fehlerquelle:

a) würde ich von der Verwendung gemappter Laufwerke also zB "N:" = \\server\turbomed generell abraten - aber - wenn man diese verwendet und hat sie zB als o.g Benutzer "praxis" verbunden - und man startet zB wegen das Updates Turbomed als Administrator, dann wird das im Zweifelsfall fehlschlagen, da in diesem Userkontext das Laufwerk nicht bekannt ist/nicht existiert.

Danke für Ihre Mühe, vermutlich habe ich mich unklar ausgedrückt ..., Natürlich gebe ich nicht jeden Tag ein NW Kennwort ein, etc.
Was ich meine war: Bevor TM im Mehrplatzbetrieb läuft muss erstmal das Windows Netzwerk konfiguriert sein. Hier war der Fehler !
Nach dem Update bestand das zuvor laufende NW nicht mehr, die Wiederanmeldung der clients an den Server war trotz richtigem Kennwort nicht möglich.
NAch Rücksetzen auf die vorherige W10 Version waren alle client Rechner sofort wieder automatisch mit dem Server verbunden. Damit ist ja eindeutig, daß es am W10 update gelegen haben muss !