[English]Bei Windows 10 April Update (V1803) gibt es wohl diverse Probleme im Bereich des Netzwerks und bei RDP-Verbindungen. So können keine Adapter-Bindungen im Netzwerk per GUI deinstalliert werden. Zudem macht RDP bzw. die Datei mstscax.dll Probleme. Microsoft hat diese zwei Probleme wohl in KB-Artikeln beschrieben und liefert auch Workarounds. Allerdings ist der RDP-KB-Beitrag schon wieder verschwunden.
Ich bin bei den Kollegen von Deskmoder hier auf das Thema aufmerksam geworden und versuche das nachfolgend etwas aufzubereiten.
Fehler 0x80071779 beim Entfernen des Netzwerk-Clients
Der erste Fehler ist etwas exotisch und dürfte den wenigsten Nutzern begegnen. Der Fehlercode 0x80071779 steht für ERROR_FILE_READ_ONLY (Die angegebene Datei ist schreibgeschützt) und tritt auf, wenn man in den Eigenschaften eines Netzwerkadapters versucht, den Client für Microsoft Netzwerke zu deinstallieren.
In welchem Szenario gibt es den Fehler?
Um den Fehler angezeigt zu bekommen, muss man als Administrator versuchen, den Client für Microsoft Netzwerke über die Eigenschaften einer Netzwerkverbindung zu deinstallieren. Dazu kann man folgende Schritte verwenden.
1. Das geht z.B. indem man die Systemsteuerung über die Suche der Taskleiste aufruft und dann zu Netzwerk- und Freigabecenter – Adaptereinstellungen navigiert.
2. Dann wählt man eine der angezeigten Netzwerkverbindungen per Rechtsklick an und klickt auf Eigenschaften (obiges Bild). Das erfordert administrative Berechtigungen.
3. Im Eigenschaftenfenster Netzwerk wählt man Client für Microsoft-Netzwerke an und klick auf Deinstallieren.
Das ist eine Schrittfolge, die wohl die wenigsten Windows 10-Nutzer benötigen, da dann der Client für die Microsoft-Netzwerke entfernt wird. Es funktioniert dann kein Netzwerkzugriff mehr. Unter Windows 10 V1803 wird dieser Schritt aber nicht ausgeführt, sondern mit einer Fehlermeldung „Das Feature Client für Microsoft-Netzwerke konnte nicht entfernt werden.“ konnte nicht deinstalliert werden.“ (Error 0x80071779) abgelehnt.
An dieser Stelle allerdings mein Hinweis, dass das Entfernen anderer Einträge in den Eigenschaften einer Netzwerkverbindung den gleichen Fehler liefert. Bei MS Answers findet sich dieser Eintrag, wo der Link-Layer Responder deinstalliert werden sollte und der Vorgang den Fehler auslöst. In diesem Technet-Forenbeitrag wird der Fehler beim Versuch, den QoS Packet Scheduler zu deinstallieren, angezeigt. Dort gibt es den Hinweis, dass dies ‘by design’ sei.
Blocking uninstallation of inbox drivers is by design, however. We do not support using this UI to remove built-in drivers. We don’t test in that configuration, and we know that uninstalling drivers breaks things.
As you’ve probably already noticed, uninstalling a driver from this UI was never permanent. E.g., if you uninstalled a driver from Windows 7, then upgraded to Windows 8, it would get reinstalled. Maybe more disconcertingly, a monthly security update that affected that particular driver could reinstall it. The reason is that the OS’s servicing stack isn’t really aware of this UI, and doesn’t realize when this UI is removing drivers. The OS’s servicing stack will reinstall the driver any time the driver is serviced.
Klingt logisch. Im KB-Artikel Error 0x80071779 when removing network components in Windows 10, version 1803 hat Microsoft jetzt aber den obigen Fehler dokumentiert. Dort wird erneut bestätigt, dass dies Absicht sei. Weder in der Systemsteuerung (GUI) noch mit netcfg wird das Deinstallieren von Protokollen oder der Build-in Treiber unterstützt.
Ein Workaround per PowerShell
Man kann aber das PowerShell cmdlet Disable-NetAdapterBinding zum Entfernen des Protokolls verwenden. Die Kollegen bei deskmodder.de haben die folgenden Schritte angegeben:
1. Windows+X drücken und dann die PowerShell Eingabeaufforderung starten.
2. Den Befehl Get-NetAdapterBinding eingeben und mittels der Eingabetaste absenden.
Der Befehl listet alle Adapter-Bindungen auf. Mit ms_msclient wird der Microsoft Client angesprochen, während ms_pacer den QoS-Paketplaner adressiert. Dann lässt sich folgender Befehl zum Löschen des Protokolls verwenden:
Disable-NetAdapterBinding -Name „Ethernet0“ -ComponentID ms_msclient
Anstelle des Platzhalters Ethernet0 ist der Netzwerkname anzugeben (in meinem Szenario wäre der Name WLAN). Dann sollte die betreffende Bindung entfernt werden.
Das Problem mit mstscax.dll
Bei der Verwendung des Remote Desktop Protokolls (RDP) für Remote-Verbindungen kann die Fehlermeldung mstscax.dll file version does not match error when using RDP client in Windows 10 angezeigt werden. Ursache: Die Dateiversion von mstscax.dll stimmt nicht mit der von Windows 10 erwarteten Version überein.
Sucht man nach diesem Fehler, wird man mehrere Fundstellen finden, die sich nicht nur auf Windows 10 beziehen. Hier ist ein Fall mit Windows 7 beschrieben.
Der Fehler kann ggf. nach Installation eines Updates wie z.B. KB4284835 (siehe Patchday: Windows 10-Updates 12. Juni 2018) auftreten. Microsoft hat dazu am 25. Juni 2018 den KB-Artikel 4340846 (mstscax.dll file version does not match error when using RDP client in Windows 10) veröffentlicht. Der betreffende Link ist aber inzwischen gebrochen – ich habe den nachfolgenden Text aus Google Cache-Version (hier (Link entfernt)) herausgezogen.
mstscax.dll file version does not match error when using RDP client in Windows 10
Applies to: Windows 10
Symptom
After you install an update on a Windows 10-based computer, you can’t use a Remote Desktop Protocol (RDP) client. Additionally, you receive the following error message:Remote Desktop Connection
The Remote Desktop Services ActiveX control (mstscax.dll) does not match the version of the client shell.Cause
This issue occurs on computers where mstsc.exe and mstxcax.dll files were replaced with a previous version of these files. Replacing files from earlier versions of the operating system is not supported and can lead to unexpected behavior. As a result, when future updates such as KB4284835 are installed, file mismatch errors occur.For example: On a Windows 10, version 1803-based computer, say you replaced mstsc.exe and mstscax.dll with files from Windows 10, version 1709. After update KB 4284835 is installed, the issue occurs because update KB 4284835 updates mstsc.exe and does not update mstscax.dll.
Resolution
Replacing binaries from a previous version is unsupported. These steps may help but should only be used on client computers that had mstsc.exe and mstscax.dll replaced with older versions.To resolve this issue, go back to original file versions, and then install KB 4284835. To do this, follow these steps:
- Take ownership and give full control permission for mstsc.exe and mstscax.dll.
- Uninstall the update that caused the issue.
- Restore the original Windows 10, version 1803 files (mstsc.exe and mstscax.dll) to the %windir%\system32 folder.
- Restart the computer.
- Reinstall the update.
- Restart the computer.
Microsoft schreibt, dass dieses Problem auf Computern auftritt, auf denen die Dateien mstsc.exe und mstxcax.dll durch eine frühere Version dieser Dateien ersetzt wurden. Das Ersetzen von Dateien aus früheren Versionen des Betriebssystems wird nicht unterstützt und kann zu unerwartetem Verhalten führen. Dies hat zur Folge, dass bei der Installation zukünftiger Updates, wie z.B. KB4284835, Fehler bei der Dateianpassung auftreten. RDP kann nicht mehr benutzt werden. Der Workaround besteht darin, die Original-Dateien aus Windows 10 V1803 gemäß obiger Anweisung manuell zu ersetzen.
Ähnliche Artikel:
Patchday: Windows 10-Updates 12. Juni 2018
Windows 10 V1803: Update KB4284835 Installationsprobleme
Windows 10 V1803: Update KB4284835-Schleife fixen
Puh, zum Glück nur bei 1803. Wollte gerade die WSUS Verteilung in der Domäne stoppen. Sind noch bei 1709 ;-)
Danke für den Hinweis!
ob ich derzeit am programm zur verbesserung der benutzerfreundlichkeit teilnehmen möchte, fragen mich die security essentials von microstop. ich könne das jederzeit beenden, sagen sie. ein klick auf weitere informationen führt wie erwartet in die unendliche weite des ms404-omniversums. nach prüfung der wie erwartet ignorierten einstellungen schaue ich nochmal in den taskscheduler und stelle fest, dass alle tasks unter ceip nach wie vor deaktiviert sind. ich freue mich dass die extramühe bei der neuinstallation eines win7 sich lohnt und werde dem kunden raten keine updates mehr zu installieren nach 12.17, da seit dem nur noch schrott ohne ausnahme kommt. schrott..
nebenbei erstelle ich ein schrottimage für die schnelle installation von schrott10 mit integriertem kumulativen schrott, ich glaub weil die bedienung „dieser“ 1607 vm auf ssd, schneller als jeder consumer pc, einfach spaß macht.
für mich ist windows tot, gut so! ein paar zombies (7-12.17, 1607.1670/2156, 1803.48/83) werd ich hegen und pflegen, einfach den guten zeiten des langen weges, welchen mich dieses os begleitet hat wegen. ich rate absolut niemandem irgendetwas neueres auf seine teure hardware zu lassen und bin einfach in der position das in bestimmten maß umzusetzen.
wufuc lässt grüßen! ;-)
1803 ist für mich nach wie vor kein Thema. Ich bleibe bei 1709, so lange es geht.
Auf meinen Zweitrechner, auf dem ich eine Zeit lang mit dem 1803 herumgefrickelt hatte, kommt jetzt auch wieder 1709 drauf. Das ist mir alles zu doof und ich habe keine Lust mehr, meine wertvolle (Lebens)Zeit mit diesem Mist zu verschwenden.
Mich überzeugen diese halbgaren Fixes von Microsoft nicht und ich überlege ernsthaft, mittelfristig auf Mac und Linux zu setzen.
Diesen Heinis sollte man die Lichtschalter in der Wohnung totlegen, und Ihnen sagen, das Licht über Schalter ein oder auszuschalten, wird nicht mehr supportet!