[English]Die Updates KB4480970 (Monthly Rollup) und KB4480960 (Security only) wurden am 8. Januar 2018 von Microsoft für Windows 7 SP1 und Windows Server 2008 R2 SP1 freigegeben. Die Updates scheinen bei einigen Leuten zu gravierenden Netzwerkproblemen zu führen. Es lassen sich keine Netzwerkfreigaben (Shares) mehr über SMBv2 erreichen.
Anzeige
Ich dachte, ich ziehe das Thema mal in einen separaten Blog-Beitrag. Vielleicht ergibt sich ja eine Lösung. Oder Microsoft bessert nach.
Was macht Update KB4480970?
Gestern Nacht hat Microsoft ja das Update KB4480970 (Monthly Quality Rollup for Windows 7 SP1 and Windows Server 2008 R2 SP1) freigegeben. Dieses schließt verschiedene Sicherheitslücken, unter anderem eine Remote Execution-Schwachstelle in der PowerShell. Weiterhin soll Windows gegen diverse Seitenkanalangriffe gehärtet werden.
Windows 7 SP1 und Windows Server 2008 R2 SP1 sollten also wegen der Schwachstellen (speziell PowerShell) zügig gepatcht werden. Ich habe das Update im Artikel Patchday: Updates für Windows 7/8.1/Server 8. Jan. 2019 behandelt.
Worum geht es beim KB4480970-Problem?
Im KB-Artikel KB4480970 steht erneut der Hinweis, dass das Update das seit vielen Monaten bekannt Problem hat, dass der NIC (network interface controller) wegen einer fehlenden Dritthersteller .inf-Datei nicht mehr funktioniert. Abhilfe schafft, den NIC über den Geräte-Manager neu installieren zu lassen. Microsoft hat Workarounds veröffentlicht.
Anzeige
- Entweder den Geräte-Manager in Windows aufrufen und dann nach neuer Hardware suchen lassen (geht über eine Schaltfläche im Programmfenster). Dann sollte der Netzwerkadapter gefunden werden.
- Oder im Geräte-Manager den Netzwerkadapter per Rechtsklick anwählen und Eigenschaften anklicken. Dann ggf. administrative Berechtigungen auf der Registerkarte Allgemein anfordern und den Gerätetreiber auf der Registerkarte Treiber aktualisieren lassen.
Der Bug zieht sich seit einem halben Jahr durch alle Updates. Die obigen Hinweise hatte ich im Mai 2018 im Blog-Beitrag Windows 7: Netzwerkprobleme bei Update KB4103718 gefixt gegeben.
Ist da mehr mit Netzwerkfreigaben im Argen?
In den Kommentaren zum Artikel Patchday: Updates für Windows 7/8.1/Server 8. Jan. 2019 haben sich jetzt einige Nutzer gemeldet, die über Probleme mit Netzwerkfreigaben nach Installation von KB4480970 berichten.
#1: Bei einem unserer Kunden die noch nicht im Patchmanagement teilnehmen ("kosten sparen") konnten mit der Installation des KB4480970 keine Netzwerkshares auf anderen Clients erreicht werden. War/ist das bei anderen auch der Fall?
#2: KB4480970 hat bei uns heute bei verschiedensten Kunden Kommunikationsprobleme mit SQL Servern verursacht (Seltsamerweise konnte sogar teilweise der Fileshare nicht erreicht werden, sofern dieser auf einem Server mit SQL Installation lag).
Deinstallation hat das Problem behoben.#3: Wir nutzen RDP um von unseren Thin-Clients auf RemotePC zuzugreifen, nach der Installation des Updates KB4480970 war dies nicht mehr möglich. Nur die Deinstallation hat geholfen.
Kann / Konnte noch Jemand das bei sich reproduzieren oder hat einen Weg gefunden den Fehler auszumerzen. Ein solches Sicherheitsupdate möchten wir nicht uninstalliert lassen.
Es scheint also ein Problem mit KB4480970 und Netzwerkverbindungen (Ergänzung: konkret Shares über SMBv2) zu geben. Man kann zwar das Update deinstallieren, dann ist das Problem erst einmal weg. Aber ein Sicherheitsupdate mit Remote Execution-Schwachstellenfix sollte man irgendwie installieren.
Was man testen könnte
Mir fallen da zwei Schnellschüsse ein, die ich Betroffenen ans Herz legen möchte. Der erste Versuch wäre, die Netzwerkverbindung über den NIC-Eintrag im Geräte-Manager zu löschen (ggf. auch die IPv4/v6-Verbindung in den Netzwerkeigenschaften) und dann das Gerät sowie das Netzwerkprotokoll neu aufbauen zu lassen.
Lässt sich das Problem damit nicht beheben? Es gibt ja das Update KB4480960 (Security-only update) für Windows 7 SP1 und Windows Server 2008 R2 SP1 zur Verfügung. Das Update adressiert die gleichen Punkte wie das Monthly Quality Rollup Update KB4480970. Dort schreibt Microsoft nichts über 'known issues'. Es wäre zumindest einen Versuch wert zu prüfen, ob mit diesem Update die gleichen Netzwerkprobleme auftreten.
Analyse: SMBv2-Problem und Workaround
Blog-Leser Andi hat, als ich den Beitrag noch verfasst habe, einen Kommentar mit einem Link auf diesen administrator.de-Thread gepostet (danke dafür). Er schreibt, dass die Updates KB4480960 und KB4480970 betroffen seien. Nach seiner Analyse kommt keine SMB2 Verbindung auf eine Windows 7/Server 2008 R2 SP2-Freigabe mehr zustande. Grund ist ein STATUS_INVALID_HANDLE-Fehler bei der Aushandlung der SMBv2-Verbindung. Damit sollten die obigen Tests wohl ins Leere laufen.
Inzwischen hat Andi auf administrator.de einen Workaround veröffentlicht. Er schreibt dazu:
Wenn der User der auf das W7 zugreift zufällig ein Administrator auf dem Remote-System ist sollte das hier auf dem W7 welches das Share hostet Abhilfe schaffen (elevated cmd):
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /fDanach zwingend ein Reboot durchführen!
Zum Registrierungseintrag, den Andi setzt, gibt es von Microsoft diesen und diesen Artikel, der Infos enthält. Wenn ich Andi richtig interpretiere, ist das Ganze etwas vertrackt: Es tritt nur auf, wenn der Nutzer, der auf eine Freigabe zugreift, auf dem System mit dem Share ein Administrator ist (siehe auch seine Erklärungen bei administrator.de). Vielleicht können Betroffene ja eine Rückmeldung geben, ob was geholfen hat.
Ergänzung: Microsoft hat das Problem im KB-Artikel bestätigt und schlägt als Workaround vor, den Nutzer aus der Gruppe der Administratoren herauszunehmen.
Ergänzung 2: Andi, der hier schon mal zum Thema kommentierte, hat inzwischen bei administrator.de mustergültig alle Lösungen zusammen gefasst. Das Netzwerkproblem betrifft auch SMBv1-Shares, die von Scannern oder Fax-Geräten genutzt werden.
Zudem hat es auch Nutzer gegeben, die mit der Neuinstallation des NICs wieder die Netzwerkfunktionen restaurieren konnten. War dann aber wohl eine andere Fehlerursache. Zudem verursachen die Updates KB4480960 und KB4480970 auch Aktivierungsprobleme (siehe Update KB971033/KB4480960/KB4480970 bricht Windows 7 Aktivierung (0xc004f200)).
Ergänzung 3: Microsoft hat am 12. Januar 2018 einen Fix herausgebracht, siehe meinen Blog-Beitrag Fix für das Windows 7-Netzwerkproblem mit Update KB4480970/KB4480960.
Ähnliche Artikel:
Microsoft Office Patchday (2. Januar 2019)
Microsoft Security Update Summary (08. Januar 2019)
Patchday: Updates für Windows 7/8.1/Server 8. Jan. 2019
Patchday Windows 10-Updates (8. Januar 2019)
Anzeige
Auf einen Server 2008R2 kam ich nach dem Monthly Rollup nach dem Reboot per RDP als Benutzer (in den Gruppen Administratoren, Remotedesktopbenutzer und WSUS-Administratoren) nicht mehr drauf. Es kommt "Authentifizierungsfehler. Die lokale Sicherheitsautorität (LSA) ist nicht erreichbar. Ursache könnte ein abgelaufenes Kennwort sein …". Komischerweise kann ich mich als Administrator-Account (umbenannt, heißt anders) aus der gleichen Situation erfolgreich anmelden. Kennwort des Benutzers als Administrator neu vergeben (nicht abgelaufen da Option "Kennwort läuft nie ab" aktiv) bringt auch nichts.
Nach Umstellung am Server2008R2 bei Computer – Eigenschaften – Remote – Remotedesktop von "Verbindungen nur von Computern zulassen, auf denen Remotedesktop mit Authentifizierung auf Netzwerkebene ausgeführt wird (höhere Sicherheit)" zu "Verbindungen von Computern zulassen, auf denen eiene beliebige Version von Remotedesktop ausgeführt wird (weniger Sicherheit)" kann sich auch der Benutzer mit Adminrechten wieder verbinden wie vorher.
Warum bei der sichereren Einstellung der Benutzer den Fehler bekommt, der Admin aber nicht kann ich mir nicht erklären.
Hat man vielleicht wieder eine neue Stufe der CredSSP-Verschärfung gezündet? Das sieht mir nämlich genau danach aus.
Da müsste es aber eigentlich heißen "Die angeforderte Funktion wird nicht unterstützt" statt des LSA-Fehlers. Und warum klappt es dann mit dem Administrator ohne Probleme?
Der Client von dem aus ich es per RDP versuchte ist übrigens ein Win7 SP1 x64, voll gepatcht inklusive bereits der Jan2019-Patches.
Wenn es mit dem lokalen Admin geht, dann riecht das ja mächtig nach UAC. Mal den LocalAccountTokenFilterPolicy-Regkey probiert?
Gerade probiert, damit klappt es, danke für den Tipp. Wobei auch der problematische Benutzer in der Gruppe der lokalen Administratoren war. Der Server dient nur als WSUS, ist nicht in eine Domäne eingebunden, es gibt nur 2 lokale Benutzer, den echten Administrator und meinen Benutzeraccount zur Wartung. Und beiden sind in den gleichen Gruppen.
Die Gruppen sind nicht der ausschlaggebende Punkt. Für den lokalen Administrator S-1-5-21-*-500 gilt keine UAC. Für alle anderen schon, wenn man es nicht explizit per Gruppenrichtlinie ausschaltet.
It is a nightmare. After KB4480970 installation all 50 workstations (Windons 7 SP1 64bit) are cut off from remote access through RDP (LSA error). Thanks Microsoft…
"After KB4480970 installation all 50 workstations"
Administrator prefers installing untested KB's so your complete Workstations ?
Administrator is applying new KB's on Patchday to all productive Workstations ?
"Thanks Adminstrator…you know your job"
Show me an Admin in a 50-100 User Workplace who has time to test each Windows Update. I do not have the time for and waiting 1-2 weeks with a update declared as important…
I also do not know an administrator who tests patches. but with such problems one begins to think.
Wir hatten nach dem Update exakt das beschriebene Problem und konnten es durch den Eintrag in die Registrierung lösen. Vielen Dank!
Für professionale Nutzer, hier Arztpraxis, eine Katastrophe. Diese ganzen Workarounds uns Lösungen sind doch nur was für Nerds, die stundenlang Zeit haben. Hat man aber nicht, wenn morgens die Patienten kommen und man die PC´s braucht. Selbst die Hersteller der Praxissoftware brauchten über eine Stunde, um dem Fehler auf die Spur zu kommen.
Vielen Dank Microsoft, Ihr seid die größten Penner. Wo ist da eine Qualitätssicherung ?
QA… Die wurde an den Kunden übertragen, so wie ich das bei vielen Softwarehersteller über die letzten Jahre festgestellt habe.
Was ich ABER nicht verstehe, warum werden die Updates immer sofort automatisch eingespielt. Da gibt es genug einfache Möglichkeiten, die einzelnen Workststions/Server mittels Service disable/Registry/firewall drops/WSUS daran zu hindern, am "After"-Patchday ein un/geplantes Debakel von MS zu erfahren.
Besonders, wenn es sich um win7 handelt, welches MS eh ein Dorn im Auge ist. (lässt sich nicht mehr "ver-SaaSen")
Was ich auch seit vielen Jahren festelle, die Methodik vom reaktiven Vorgehen, anstatt proaktives Vorgehen.
Ich stelle mal in den Raum: macht sich da mancher Admin die Arbeit etwas zu einfach?
=> Es kann natürliche auch aus Kostengründen sein, dann ist es aber _kein_ Problem, sondern vom Kunden gewünscht. :)
Ich schätze den Einsatz von Günter Born sehr (vielen Dank!), wie auch askwoody, r/sysadmin und dieser zeitliche Aufwand ist in meinen Services/SLAs einkalkuliert.
– Windows Update auf manuell umstellen, es gibt keinen Grund die monatlichen Updates sofort einzuspielen. Ein paar Tage warten und hier bei Günter mitlesen welche Probleme die Updates verursachen können
– Vor dem Windows-Update macht man ein Backup der Systempartition. Bei einer professionellen Nutzung von Computersystemen sollte man das sowieso regelmässig machen um bei Virenbefall oder Festplatten/SSD-Crash schnell reagieren zu können
– Wenn die Leute des Softwareherstellers eine Stunde brauchen um festzustellen dass dieser seit Monaten bekannte Bug das Problem ist dann frage ich mich von was diese Leute etwas verstehen, jeder interessierte Heimanwender hätte das sofort erkannt
Nach der Installation von KB4480970 funktioniert der RDP Zugriff auch auf Windows 7 VMs nicht mehr. ( W7Px64SP1 -> W7XPx64SP); Auf beiden Maschinen ist KB4480970 installiert. Entweder das "Sicherheitsqualitätsrollup" deinstallieren oder vorübergehend die RDP Verbindung auf "Verbindung von Computern zulassen auf denen eine beliebige Version von RDP ausgeführt wird"
Nach dem Tipp von riedenthied oben: Anlegen des Registryeintrags mit Wert 1 nach folgender Seite hilft hier auf einem Win2008R2 der ja Win7 SP1 entspricht. Danach konnte ich wieder auf höhere Sicherheit umstellen und es funktioniert auch nach Reboot des Servers noch:
https://support.microsoft.com/en-us/help/942817/how-to-change-the-remote-uac-localaccounttokenfilterpolicy-registry-se
Wie sieht das Ganze denn jetzt für "Otto Normalverbraucher" mit lediglich einem Heim-PC (Win 7 Home Premium 64 Bit inkl. SP1) aus?
Kann ich das KB4480970 bedenkenlos installieren?
Ich kann jetzt als "normaler User" aufgrund der obigen Angaben wie so oft schon gar nicht abschätzen, mit welchen "Einschränkungen" ich danach zu rechnen hätte.
Muss ich nun auch den angegebenen Eintrag in der Registry erstellen…?
Kurz gesagt: Nein, musst du nicht. Im beschriebenen Szenario spielt das keine Rolle.
Scyllo: Wenn Sie nur einen PC haben, sollte es keine Probleme geben. -Bei mir war nur die Verbindung zu anderen PCs im lokalen Netzwerk betroffen. Die Internetverbindung funktionierte ganz normal. -An Ihrer Stelle würde ich das Update installieren, da es ja einige Sicherheitslücken behebt.
Alle: Leider ist der Workaround mit dem Registry-Eintrag auch nicht DIE "Lösung". Zwar funktionierte der Zugriff auf die Shares wieder, jedoch wurde unter Netzwerk kein einziger PC mehr angezeigt. -Diese konnten nur durch die Eingabe von "\\PC-Name" wieder zum Vorschein gebracht werden. (Bei jedem Öffnen des Windows-Explorers erneut.)
Nach einigem Herumprobieren habe ich den Registry-Eintrag wieder gelöscht, und KB4480970 erstmal entfernt.
Da die entsprechenden Lücken offenbar seit Sept. 2018 bekannt waren, gehe ich davon aus, dass nichts passiert; und warte bis Microsoft – hoffentlich bald – "KB4480970+1" veröffentlicht!
MS: It's Your turn!
-Und wahlweise hätte ich gerne, entweder die drei Stunden zurück, die ich heute damit zugebracht habe, oder alternativ wären 6 Win10 Pro-Lizenzen ganz nett! *lol* :-D ;-)
Die 5 Doubletten des Kommentars habe ich gelöscht – neue Kommentare landen in der Moderation (siehe).
Bitte um Entschuldigung, hatte den Eindruck das Senden hätte nicht funktioniert, da der Beitrag (auch nach Neuladen der Seite) nicht im Tread erschienen ist, wie das normalerweise in Blogs der Fall ist. -War mein erster Beitrag hier.
Mit freundlichen Grüßen,
Kein Problem, Du bist jetzt bekannt und da kommen Beiträge ohne Links direkt. Ich muss hier einen SPAM Schutz mitlaufen lassen, sonst würden die Kommentare nur noch mit Mist geflutet.
"Diese konnten nur durch die Eingabe von "\\PC-Name" wieder zum Vorschein gebracht werden"
Dieser Fehler besteht in meinem (kleinen) Netzwerk schon seit vielen Monaten. Nach etwa der dritten Rückkehr des Problems hatte ich es aufgegeben zu versuchen dass der Explorer mir die \\PC-Namen ohne Probleme anzeigt.
Ich habe einfach keine Zeit um nach jeder Rückkehr des gleichen Problems (keine oder lückenhafte Anzeige der Dateiserver) nach Lösungen zu suchen. Ich habe zwar nur 8 Clients im kleinen Netz, aber auf jedem der Windows Maschinen gibt es andere Effekte zu bestaunen. Einige Windows zeigen bei jedem öffnen des Explorers einzelne Dateiserver an als würde das Betriebssystem Russisches Roulette spielen mit der Entscheidung ob denn nun ein Gerät angezeigt werden soll oder nicht.
Inzwischen habe ich zu allen externen Geräten einfache Links unter Windows Start gemacht.
Bisher hat das bei mir funktioniert, während das öffnen von "Netzwerke" im Explorer bei zwei Maschinen nur noch die Sanduhr anzeigt anstelle die gesuchten Geräte.
Auf drei Geräten werden die externen Geräte zwar als Medien-Server angezeigt wenn sie gleichzeitig frei gegebene Medien wie Videos enthalten, aber nicht als Datei Server.
Nach stundenlanger Fehlersuche haben wir endlich den Hinweis bei Administrator.de gefunden. Wir gingen relativ früh von den Updates aus und hatten sie auch deinstalliert, danach ging es aber trotzdem noch nicht. Aber der Registry-Key hat geholfen.
Ist einfach ärgerlich, so etwas. Das kann man keinem Kunden berechnen.
Selbiges Problem besteht auch z.B. bei Multifunktionsgeräten, die, z.B. mittels eines eingerichteten Adressbucheintrags, einen SMB-Scan auf einen Windows 7 Client/Windows Server 2008 R2 durchführen möchten. Nach Installation des Updates wird jeglicher Scan abgewiesen…
Dies nur als Hinweis für vielleicht etwas weniger versierte Nutzer, die auf dieses Problem stoßen.
https://support.microsoft.com/en-us/help/4480960
Update bei: "Known issues in this update"
"Local users who are part of the local "Administrators" group may not be able to remotely access shares on Windows Server 2008 R2 and Windows 7 machines after installing the January 8th, 2019 security updates. This does not affect domain accounts in the local "Administrators" group."
Habe genau das beschriebene Problem, das ich mich nicht mer via RDP als lokaler Admin anmelden konnte.
Der Registrierungseintrag war die Lösung.
Vielen Dank.
Hallo Herr Born, super BLOG. Hat mir schon mehrmals geholfen.
Bei mir war es genau umgekehrt: Konnte mich auf einem PC (Win7 64), auf dem das Update installiert war über RDP NUR noch als Admin, aber nicht mehr als User anmelden. -Nach Deinstallation von KB4480970 funktionierte wieder alles problemlos.
Ach ja, meine PCs sind in einer Workgroup mit Datei- und Druckerfreigabe. Auf allen PCs sind dieselben User-Accounts mit jeweils demselben PW angelegt.
Hallo,
ich bin mir aufgrund der Kommentare nicht sicher, ob meine PC-Kombination auch davon betroffen ist:
Ich habe einen Windows 7 PC, der auf meinen Windows 8.1. PC über Datei- und Druckerfreigaben (Workgroup) zugreift. Auch kann ich von dem Windows 8.1. PC auf den Windows 7 PC zugreifen, das mache ich aber sehr selten.
Wird es bei dieser Konstellation auch Probleme geben?
Danke für die Rückmeldung.
Du solltest in Deiner Konstellation nur dann Probleme haben, wenn Du über Deinen Windows 8.1 PC auf Deinen Windows 7 PC zugreifst.
Da Du aber geschrieben hast, dass Du den Zugriff so herum nur sehr selten benötigst, würde ich jetzt mal positiv denken und hoffen, dass das Problem durch Microsoft demnächst durch ein weiteres Update bzw. einen Patch gelöst wird und sich das Problem dann von selbst erledigt hat.
Auch ich möchte mich an dieser Stelle einmal bei Günter Born für seinen wirklich tollen Blog und seine Leidenschaft hierfür recht herzlich bedanken!
Da schließe ich mich sehr gerne an!
@F. Meyer: Danke für die Rückmeldung.
SMB Probleme hatte ich auch, bei einem Client verursachte die KB auch systemneustarts.
Nach deinstallation war alles wieder in ordnung
Hallo,
ich bin ein ganz 'normaler' User mit 3 Stk. Win7 PCs im einfachen Netzwerkverbund.
Der Reg-Eintrag hat das Netzwerkproblem beseitigt.
Hi,
ich hoffe, mir kann jemand helfen, bin schon am verzweifeln….
Ich habe ein ähnliches Problem wie Harald weiter oben, allerdings mit dem Unterschied, dass ich keinen physischen Zugriff auf den Server habe.
Bei Verbindungsversuch mittels RDP erscheint folgende Fehlermeldung seit dem Update: "Authentifizierungsfehler. Die lokale Sicherheitsautorität (LSA) ist nicht erreichbar. Ursache könnte ein abgelaufenes Kennwort sein …".
Sowohl Client als auch Server sind voll gepatchte Windows 7 SP1 x64 Installationen.
Da ich nur Zugang zum Client habe beschränken sich meine Lösungsversuche nur auf diesen. Patches deinstallieren hat nichts gebracht und auch die Sache mit dem Registrierungsschlüssel funktionierte nicht.
Der Account auf dem Server auf dem ich mich per RDP verbinde ist ein Admin Acoount.
Was kann ich von Client Seite aus tun um wieder auf meinen "Server" zu kommen?
Besten Dank vorab,
Ernst
@Ernst
Als normaler User wird man nichts ausrichten können, also kann man meiner bescheidenen Meinung nach gar nichts machen, außer hinfahren oder jemanden hinschicken, dem man dann zur Not die Schritte telefonisch diktiert. Nach genau so einer Erfahrung haben wir auf solchen Maschinen immer einen zweiten Zugang über Progamme wie Teamviewer, logmein usw. Ich weiß, dass das leider jetzt nicht tröstet…
Kannst du dich remote mit dem Regedit auf die andere Maschine verbinden? Oder ist die Remote-Shell eingerichtet?
@riedenthied: Eine Remote-Shell existiert leider nicht. Das ist bei diesem System nicht vorgesehen.
Die Nutzung des Servers ist nur privat für mich.
@Joe: Der Server steht in Kanada, wäre ein schöner Ausflug :-)
Nachdem die Updates installiert waren, wurde ein Neustart gefordert und dann begann das Drama. Ob mir Teamviewer in diesem Fall helfen würde, weiß ich nicht. Wird der Teamviewer-Dienst auch ohne Anmeldung gestartet?
Besten Dank für eure Antworten
Wie gesagt, über Remote-Zugriff auf die Registrierung (regedit.exe –> Mit Netzwerkregistrierung verbinden) könnte noch der Reg-Key gesetzt werden. Außerdem funktioniert nach wie vor noch DER lokale Administrator (S-1-5-21-*-500). Vielleicht ist das eine Möglichkeit, falls er aktiviert ist.
Ansonsten hilft wohl nur Abwarten, ob Microsoft da noch was fixt.
Kanada, ziemlich cool, aber weit…
Ja, Teamviewer und logmein funktionieren auch ohne Anmeldung, wenn Du verbunden bist, siehst Du den Anmeldebildschirm. Teamviewer kannst Du problemlos ausprobieren, einfach die passenden Dateien runterladen, für private Nutzung ist er sogar gratis.
Ich hatte auch keinen physischen Zugang auf den betroffenen Server, ok der wäre mit 40 km nicht ganz so weit weg. Der Server (=WSUS) ist nicht in einer Domäne und hat nur 2 lokale Benutzer, den echten "Administrator" der beim Server ja nicht ab Werk deaktiviert ist wie bei Win7 und meinen "Arbeits"-Benutzer der in der Gruppe der Administratoren ist.
Mein Benutzer meldete beim RDP-Versuch den LSA-Fehler, mit dem echten Administrator konnte ich mich aber per RDP anmelden. Und damit erst testweise die RDP-Einstellung auf nicht-so-sicher stellen und dann den Reg-Key setzen mit dem die RDP-Einstellung wieder zurückgestellt werden konnte. Danach ging auch der Benutzer wieder.
Ich konnte es also zum Glück ohne physischen Zugang und ohne TeamViewer lösen.
Ein großes Danke an euch für all die Antworten.
Ich habe den Server neu aufgesetzt. Der lokale Admin war nicht aktiviert und auf die Registrierung konnte ich auch nicht zugreifen. Da blieb mir nichts anderes übrig. Der Aufwand hielt sich in Grenzen, da nur ein Programm auf dem Server läuft.
Vor neuen Updates werde ich auf jeden Fall dieser Seite vorher einen Besuch abstatten.
Wünsche allen ein schönes Wochenende,
Viele Grüße
Hallo,
auch von hier ein nicht oft genug zu wiederholendes großes Dankeschön an Günter Born für seine Arbeit und dafür, dass hier sehr viel Kompetenz gesammelt und ausgetauscht wird.
Wir haben das Update von den ersten 20 Testmaschinen wieder entfernt, da sich die User über die nicht mehr funktionierenden Scanner in den Multifunktionsdruckern beschwert haben und hoffen nun, dass Microsoft doch noch in diesem Jahr eine Lösung anbietet.
Nur nebenbei, eines der Office Updates dieses Patchdays ist auch standardmäßig nicht aktiviert KB4461614.
Grüße
Joe Gerhard
Das mit den Scannern kann ich bestätigen … es betraf in unserem Kundenkreis Multifunktionsgeräte, an denen per "Scan to File" per SMB-Protokoll direkt am Gerät gescannt und eine Datei auf einer Verzeichnisfreigabe eines Windows-Rechners gescannt wird.
Mehr unter
https://compeff-blog.de/?p=1502
Und die Multifunktionsgeräte gehen auch mit Admin-Account auf den Share? Puh, da muss man ja eigentlich froh sein, dass Microsoft das nun so gebaut hat. :-)
Nein, die Netzwerkgeräte (Scanner) haben keine Adminrechte sondern nutzen die Anmeldeinformationen des jeweiligen Benutzers oder schreiben in ein spezielles für jedermann freigegebenes Verzeichnis. Warum es trotzdem nicht geht, wissen wir nicht. Wir haben auch nicht die Resourcen danach zu forschen, da kleiner Mittelständler.
Wie schon mehrfach erwähnt, hast Du momentan 3 Möglichkeiten:
Du schmeißt die Userkonten, die für die Scans verwendet werden, (temporär bis das gefixt wird) aus der Gruppe lokalen Administratoren raus, oder Du verwendest den Registrykey, oder aber Du deinstallierst das Update (vorerst) wieder.
Wenn z.B. der Adressbucheintrag, mit dem der SMB-Scan auf den Host durchgeführt wird, so konfiguriert ist, das hierfür Usercredentials verwendet werden, die auf dem Host lokale Adminrechte haben, dann greift das MFP natürlich mit Adminrechten auf die Freigabe zu.
In vielen kleineren Firmen, auf Homeoffice-Clients und vielen PCs und Notebooks (von Privatanwendern) ist es leider ziemlich verbreitet, dass hierauf in der Regel nur einen Adminkonto existiert, oder aber die User zur Gruppe der lokalen Administratoren hinzugefügt wurden…
Harald L. hat genau mein Problem, Andis Workaround ( Administrator.de) hat bei mir funktioniert, danke.
Hinweis für Betroffene. Die Datev hat gerade das Problem per E-Mail auch gemeldet und in ihrer Dok-Info-Datenbank mit Dok-nummer 1004764 eine Hilfe veröffentlicht.
Der Link ist hier:
https://www.datev.de/dnlexom/client/app/index.html#/document/1004764
Es wird dort auch eine Hilfe in der Regedit aufgezeigt.
Ich habe das Problem nicht, da kein solches Netzwerk. Vielleicht hilft es den einen oder anderen. Ich kann somit nicht sagen, ob es zielführend ist. Es bezieht sich vollständig auf Datev-Umgebungen im Netzbetrieb.
Grüße
Das ist ja der gleiche Workaround, der schon oben steht.
Es gibt nun einen Fix, auch wenn ich eigentlich der Meinung bin, dass man den bei korrekter Konfiguration nicht benötigt:
https://support.microsoft.com/en-us/help/4487345/
Danke – mache noch einen Kurzbeitrag dazu. Der Fix dürfte für die DATEV-Leute möglicherweise hilfreich sein – wenn die Zuordnung der Benutzer zu Standardbenutzergruppen ggf. nicht möglich ist.
Ich habe bisher auf meinem Windows 7-PC den Patch KB4480970 (Monthly Rollup) vom Januar noch nicht eingespielt, weil er Netzwerkprobleme verursacht. Hier gibt es ja mittlerweile einen Hotfix für. Dennoch würde ich gerne einen fehlerbereinigten Patch einspielen, sehe aber das der o.g. KB noch auf 4.1.19 steht. Wird hier Microsoft noch nachbessern?
Nur als Hinweis, auch das RDP Problem an W2k8 R2 lässt sich durch https://support.microsoft.com/en-us/help/4487345 beheben, nicht nur das SMB Problem wie bei MS angegeben: https://support.microsoft.com/en-us/help/4480970/windows-7-update-kb4480970#section-1
Habe dieses kb4480970 auf ein Win7 am Fr. den 12.04.19 installiert und konnte die folgenden Tage noch im Internet surfen. Seit Mittwoch den 17.04.19 geht das Internet – mit dieser Win7 Maschine – bei mir nicht mehr wirklich. Einen Ping auf Googles DNS-Server 8.8.8.8 gibt eine Antwort zurück, auch das Surfen mittels Tor geht, aber mit keinem anderen Browser! Im Geräte-Manager bei der Netzwerkkarte ist alles ok! Das Update lässt sich aber leider auch nicht deinstalieren. :-(
Danke für den Tipp!
Ein Samba-Zugriffsfehler "Pfad existiert nicht mehr" manifstierte sich auf meinem Win7-Laptop nach einem ASUS Router-Update RT-N18U (als Stichwort, falls mal einer wie ich danach googlen sollte ;)
Das Einspielen des KB4487345-Updates hat geholfen!