• Betrifft: Kontextmenü beim Startmenü bzw. "Windows-Taste + X"
• System: Microsoft Windows 8.1, Windows Server 2012 R2
• Problem: Der Rechtsklick auf das Startmenü unter Windows 8.1 liefert kein Kontextmenü. Die Tastenkombination "Windows-Taste" + "X" zeigt kein Menü an. Also "Win" + "X" hat keine Auswirkungen. Bei den jeweiligen Benutzern kann es sich um Domänenbenutzer handeln.

Hintergrund

Es geht dabei um das linke untere Eck welches seit Windows 8 ein neues Kontextmenü anzeigt. Hier wird je nachdem was man mit der Maus macht eine Miniansicht vom Startmenü (= Modern Style UI / Metro) angezeigt oder bei einem anschließenden Rechtklick ein Kontextmenü mit durchaus nützlichen Funktionen angezeigt. Übrigens gelangt man mit der Tastenkombination "Windows-Taste" + "X" ebenso in das Kontextmenü. Daher wird es zeitweise als WinX Menü bezeichnet.

Nun kommt es primär bei Domänenbenutzern vor, dass diese beim anmelden auf einen Computer mit Windows 8.1 exakt dieses WinX Menü nicht öffnen können. Hier bewirkt ebenso die Tastaturkombination keine Reaktion. Bei diesen Computern (also Domänenmitglied) funktioniert bei einem lokalen Konto sehr wohl dieses Kontextmenü.

Zeitweise funktioniert aber auch bei einem lokalen Konto (kein Domänenmitglied) das Kontextmenü nicht. Und zwar wurden dann oft alte Profile (z.B. von Windows Vista, Windows 7 oder Windows 8) migriert.

Behebung

Eigentlich relativ leicht zu bewerkstelligen. Es fehlt im gerade verwendeten Benutzerprofil unter einem bestimmten Ordner nur einige wichtige Dateien.

1.) Dieser Ordner befindet sind unter folgenden Pfad:

Bei den Problemkonten fehlt unter dem oben angegebenen Pfad der zum Kontextmenü gehörende Ordner "WinX".

2.) Nun müssen einfach der notwendige Ordner mit den darin befindlichen Dateien erstellt werden.

• Das geht recht einfach wenn man Zugriff auf eine originale Benutzervorlage von Windows 8 hat. Vorsicht, wenn jemand angepasste Benutzervorlagen verwendet! Hier könnten die Dateien bereits fehlen.
• Alternativ gibt es die notwendigen Daten als ZIP-Archiv zum Download.

3.) Die notwendigen Dateien bzw. der Ordner "WinX" von der Vorlage befinden sich standardmäßig unter folgenden Pfad:

3.) Nun einfach den kompletten Ordner WinX (siehe 3. Punkt) in das Benutzerprofil (siehe 1. Punkt) kopieren. Alternativ die heruntergeladenen Dateien in das Benutzerprofil (siehe 1. Punkt) extrahieren.

Wie man sehen kann, so hat der Ordner "WinX" drei weitere Unterordner in denen sich wiederrum Verknüpfungen befinden. Exakt diese Dateien sind für die Anzeige notwendig.

4.) Nach dem Kopieren muss man sich mit dem Problemkonto einmal neu anmelden. Also entweder Neustart durchführen oder abmelden und wieder anmelden. Danach sollte das Kontextmenü wieder normal angezeigt werden.

Vielleicht hatte nun jemand die Idee das WinX Menü einfach mit eigenen Verknüpfungen zu erweitern. Nun, die Idee ist nicht schlecht, jedoch nicht so einfach möglich, da die Verknüpfungen speziell bearbeitet werden müssen. Dazu gibt es bereits mehrere Tools im Internet zu finden. Dazu vielleicht mal in einem anderen Artikel mehr Informationen…

weitere relevante Beiträge…

• Windows 8: Rechtklick auf Startmenü geht nicht
• KB2871690 UEFI Update scheitert mit Fehler 800f0922
• Automatische Anmeldung unter Microsoft Windows
• Saturday-Night-Cruising 2013: unterwegs im Weinviertel
• WordPress, Druckausgabe und QR-Code
• BlackSeals Network: QR-Code, Kurzlink und Download Portal

• Betrifft: IIS 7.0, IIS 7.5, IIS 8.0, IIS 8.5 mit aktivierten FTP-Zugang
• System: Microsoft Windows Server 2008 x64, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2
• Problem: Beim Zugriff von einem FTP-Client auf die FTP Funktion vom IIS erhält man einen Fehlermeldung. Der Server verwendet womöglich nur eine IP-Adresse und betreibt mehrere Webseiten.

Hintergrund

Beim Zugriff auf einen Microsoft FTP Service unter Windows Server erhält man eine eigenartige Fehlermeldung "530 Valid hostname is expected."

Nun kontrolliert man die Einstellungen und wird feststellen, dass man den Hostnamen (also den DNS-Namen des FTP-Server) richtig angegeben hat.

Am Beispiel von FileZilla findet man die entsprechenden Einstellungen im Servermanager unter Server. Die Daten scheinen vollständig zu sein. Hinweise auf diesen Fehler ist in der beigefügten Hilfe nicht zu finden.

Damit folgt je nach Möglichkeit ein Blick in die IIS-Manager zur Sitebindung. Dort findet man die IP-Adresse und den Hostnamen. Scheint also korrekt?

Behebung

Die Ganze Sache ist relativ einfach aufzuklären. Dies Fehlermeldung ist eine Eigenart vom Microsoft Internet Information Service (= IIS). Und zwar kann man einfach eine IP-Adresse für mehrere Webseiten benutzen. Das gleiche gilt somit ebenfalls für den FTP-Dienst – sonst ergibt es im Grunde keinen Sinn. Genauer wird nicht nur die IP-Adresse, sondern auch der Port mehrfach identisch genutzt. Bei Webseiten ist diese doppelte Nutzung für http bzw. https ohne Probleme machbar und seit langem für alle Webbrowser als Standard verankert.

Bei FTP-Server gibt es keinen solchen Standard und einige Leute reagieren auch sehr allergisch auf diese Möglichkeit. Man könnte natürlich unterschiedliche Ports nutzen – nur könnten die wieder gesperrt sein oder sonstige Probleme verursachen. Der TCP Port 21 ist nun mal für den FTP da und nicht ein x-beliebiger anderer. Wie auch immer, im Grunde hat man nicht immer eine Wahl und die Möglichkeit unterschiedliche IP-Adressen für Webseiten und dem zugehörigen FTP-Zugang zu nutzen.

Damit ergeben sich zwei Varianten:

1.) Eine weitere IP-Adressen für den Webdienst bzw. FTP-Dienst zuweisen und den Hostnamen im IIS-Manager unter Bindungen entfernen. Dies muss natürlich der Administrator des Servers erledigen. Aber darauf hat man nicht immer einen Zugriff.

2.) Gut, wie wäre es einfach mit der Nutzung dieser Funktion? Microsoft hat sich durchaus eine einfache Möglichkeit für diesen Fall überlegt. Am Beispiel vom FileZilla sieht es wie folgt aus:

Bei dem Benutzerfeld muss man den Hostnamen noch Mal angeben und nach dem Zeichen "|" den eigentlichen Benutzernamen angeben.

Hostname: webseite.at

Benutzer: webseite.at|Benutzer

weitere relevante Beiträge…

• GnuTLS Fehler beim Zugriff auf einen Microsoft FTP(S)-Server
• In FileZilla versteckte Dateien am Server anzeigen
• HTTP-Fehler 413, Anforderungseinheit zu groß
• HTTP-Fehler 500.19, zugehörige Konfigurationsdaten sind ungültig
• HTTP-Fehler 404.11, Escapesequenz werden abgelehnt im IIS
• Immer den vollen RSS-Feed erhalten

• Betrifft: automatische Anmeldung trotz Kennwort
• System: Microsoft Windows Vista, Windows 7, Windows 8, Windows 8.1 
• Problem: Unter Microsoft Windows soll trotz Kennwort die automatische Anmeldung beim Hochfahren aktiviert werden. Der Computer befindet sich in keiner Domäne.

Hintergrund

Einfachhalber soll der Computer direkt nach dem Hochfahren mit einem bestimmten Benutzer angemeldet werden. Der Benutzer soll aber trotzdem kennwortgeschützt sein.

Ich nutze dies gerne bei Testcomputer, egal ob physische oder virtuelle – nur hatte ich dies bislang noch nicht auf meinem Blog notiert…

Behebung

1.) Mithilfe der Tastenkombination "Windows-Taste" + "R" das "Ausführen"-Fenster öffnen.

2.) Entweder "netplwiz" oder "control userpasswords2" eingeben und mit "Ok" bestätigen.

(beides öffnet das selbe Fenster)

3.) Ein neues Fenster mit der Bezeichnung "Benutzerkonten" erscheint. Nun muss das Hakerl bei "Benutzer müssen Benutzernamen und Kennwort eingeben" deaktiviert werden.

4.) Sobald man dies mit "Übernehmen" bestätigen möchte, erscheint ein zusätzliches Fenster mit der Bezeichnung "Automatische Anmeldung".

Hier einfach den Benutzernamen und zwei Mal das Kennwort eingeben und mit "OK" bestätigen. Ab den nächsten Neustart wird nach dem Computerstart direkt dieser Benutzer geladen.

weitere relevante Beiträge…

• Gruppenrichtlinienverwaltung: Der Index war außerhalb des Arraybereichs
• Windows: Aufgabe bricht mit Fehler 2147942667 ab
• Nach Neustart kommt bei WinMgmt der Fehler 0×80041003
• Internet Explorer 10: Werbefilter
• VPN-Einwahl schlägt mit "Fehler 87 Falscher Parameter" fehl
• TeamSpeak Client: Portable Version

• Betrifft: UEFI Sicherheitsupdate via Windows Update.
• System: Microsoft Windows 8, Windows Server 2012
• Problem: Beim Installieren des Windows Updates KB2871690 erhält man die Fehlermeldung 800f0922. Das Betriebssystem Windows Server 2012 wird als Hyper-V Client. Als Hyper-V Host wird Windows Server 2012 R2 eingesetzt.

Hintergrund

Das Windows Update KB2871690 beinhaltet einen Widerruf von nicht konformer UEFI-Startlademodule. Demzufolge durchaus ein wichtiges Update für Windows 8 und Windows Server 2012.

Je nach Verteilungsmechanismus landet das Update früher oder später alleine oder mit weiteren Updates bei dem virtuellen System.

Die Installation startet normal, aber wird mit einem schweren Fehler unterbrochen: Code 800f0922 – Problem bei Windows Update. Zeitweise werden weitere Updates ebenso abgebrochen. Bitte diese extra installieren. Meist bleibt ein Update übrig, welches der wirkliche Grund ist. In unserem Fall KB2871690. Man könnte nun ausgehend von der Fehlermeldung an ein Problem mit dem Windows Update-Dienst oder dem Windows Server Update Services (= WSUS) denken. Gleich vorweg: ein manueller Download von Microsoft und anschließender Installation ergibt das selbe Problem.

Wie eingangs erwähnt wird Windows Server 2012 in einer virtuellen Umgebung betrieben. Der Hyper-V Server läuft unter Windows Server 2012 R2 und kennt zwei Hardware-Generationen. Die Generation 2 kann ab Windows 8 bzw. Windows Server 2012 eingesetzt werden und verwendet neuere virtuelle Hardware inkl. UEFI Unterstützung und kann viele neue Funktionen abbilden. Damit sollte der Zusammenhang zwischen Hyper-V Generation 2 und dem KB2871690 erkennbar sein.

Behebung

Die Behebung ist recht simpel. Ein System mit UEFI unterstützt den "Sicheren Start". Eine neue Schutzfunktion mit dem nicht autorisierter Code vor dem eigentlichen Start von Windows blockiert wird.

Diese Funktion behindert das einspielen des Updates. Dazu muss man einfach in den Einstellungen zum Hyper-V Client die Option "Sicheren Start aktivieren" deaktivieren. Wenn dies wie in meinem Screenshot ausgegraut ist, dann läuft die virtuelle Maschine und man muss diese zuerst herunterfahren. Damit folgendes VorgeheN:

1. Hyper-V Client herunterfahren.
2. Bei den Hyper-V Client Einstellungen bei Firmware den "Sicheren Start aktivieren" deaktivieren. Siehe Screenshot etwas weiter oben.
3. Hyper-V Client hochfahren und Update einspielen. Nach Abschluss einen Neustart durchführen. Manchmal wird beim Neustart weitere Anpassungen betreffend des Windows Updates durchgeführt.
4. Sobald der Hyper-V Client wieder hochgefahren ist, kann man die ordnungsgemäße Installation des Updates überprüfen. Nun den virtuellen Computer herunterfahren.
5. Nun kann die Option "Sicheren Start aktivieren" wieder aktiviert werden. Das geht wie bereits zuvor erwähnt nicht während des Betriebes.
6. Abschließend den Hyper-V Client wieder starten.

weitere relevante Beiträge…

• Hyper-V: Der virtuelle Computer konnte nicht gestartet werden
• Wie aktiviert man den Fernzugriff auf Hyper-V Servern
• Falschmeldung bzgl. notwendigen Neustart beheben
• Windows 8.1: Rechtklick auf Startmenü geht nicht
• Internet Explorer 10: Werbefilter
• VPN-Einwahl schlägt mit "Fehler 87 Falscher Parameter" fehl

• Betrifft: Update-Rollup der gesperrten nicht konformen UEFI-Module.
• System: Microsoft Windows 8.1, Windows Server 2012 R2
• Problem: Beim Installieren des Windows Updates KB2920189 erhält man die Fehlermeldung 800f0922. Das Betriebssystem Windows Server 2012 R2 wird als Hyper-V Client ausgeführt. Als Hyper-V Host wird Windows Server 2012 R2 eingesetzt.

Hintergrund

Das Windows Update KB2920189 beinhaltet einen Widerruf von nicht konformer UEFI-Startlademodule. Demzufolge durchaus ein wichtiges Update für Windows 8.1 und Windows Server 2012 R2.

Je nach Verteilungsmechanismus landet das Update früher oder später alleine oder mit weiteren Updates bei dem virtuellen System.

Die Installation startet normal, aber wird mit einem schweren Fehler unterbrochen: Code 800f0922 – Problem bei Windows Update. Zeitweise werden weitere Updates ebenso abgebrochen. Bitte diese extra installieren. Meist bleibt ein Update übrig, welches der wirkliche Grund ist. In unserem Fall KB2920189. Man könnte nun ausgehend von der Fehlermeldung an ein Problem mit dem Windows Update-Dienst oder dem Windows Server Update Services (= WSUS) denken. Gleich vorweg: ein manueller Download von Microsoft und anschließender Installation ergibt das selbe Problem.

Wie eingangs erwähnt wird Windows Server 2012 R2 in einer virtuellen Umgebung betrieben. Der Hyper-V Server läuft unter Windows Server 2012 R2 und kennt zwei Hardware-Generationen. Die Generation 2 kann ab Windows 8 bzw. Windows Server 2012 eingesetzt werden und verwendet neuere virtuelle Hardware inkl. UEFI Unterstützung und kann viele neue Funktionen abbilden. Damit sollte der Zusammenhang zwischen Hyper-V Generation 2 und dem KB2920189 erkennbar sein.

Behebung

Die Behebung ist recht simpel. Ein System mit UEFI unterstützt den "Sicheren Start". Eine neue Schutzfunktion mit dem nicht autorisierter Code vor dem eigentlichen Start von Windows blockiert wird.

Diese Funktion behindert das einspielen des Updates. Dazu muss man einfach in den Einstellungen zum Hyper-V Client die Option "Sicheren Start aktivieren" deaktivieren. Wenn dies ausgegraut ist, dann läuft die virtuelle Maschine und man muss diese zuerst herunterfahren. Damit folgendes Vorgehen:

1. Hyper-V Client herunterfahren.
2. Bei den Hyper-V Client Einstellungen bei Firmware den "Sicheren Start aktivieren" deaktivieren. Siehe Screenshot etwas weiter oben.
3. Hyper-V Client hochfahren und Update einspielen. Nach Abschluss einen Neustart durchführen. Manchmal wird beim Neustart weitere Anpassungen betreffend des Windows Updates durchgeführt.
4. Sobald der Hyper-V Client wieder hochgefahren ist, kann man die ordnungsgemäße Installation des Updates überprüfen. Nun den virtuellen Computer herunterfahren.
5. Nun kann die Option "Sicheren Start aktivieren" wieder aktiviert werden. Das geht wie bereits zuvor erwähnt nicht während des Betriebes.
6. Abschließend den Hyper-V Client wieder starten.

weitere relevante Beiträge…

• KB2871690 UEFI Update scheitert mit Fehler 800f0922
• Hyper-V: Der virtuelle Computer konnte nicht gestartet werden
• Wie aktiviert man den Fernzugriff auf Hyper-V Servern
• Falschmeldung bzgl. notwendigen Neustart beheben
• Windows 8.1: Rechtklick auf Startmenü geht nicht
• Internet Explorer 10: Werbefilter

• Betrifft: Sprungliste beim Windows Explorer
• System: Microsoft Windows 8, Windows 8.1
• Problem: bei der Sprungliste vom Windows Explorer lassen sich angeheftete Elemente nicht entfernen

Hintergrund

Den technischen Grund lässt sich schwer ermitteln. Schon unter Windows 7 konnte ich dieses verhalten bemerken (siehe Artikel: angeheftete Ordner bei der Sprungliste lassen sich nicht löschen). Meist hat dies mit Netzwerklaufwerken auf Linux-Maschinen zu tun. Beim Windows Explorer können oft aufgerufene Ordner anheftet werden. Manchmal können diese Ordner aber nicht mehr entfernt werden.

Mit Windows 8 habe ich zwar kein solches Problem mehr gehabt, aber Anfragen hat es doch immer wieder gegeben. So zuletzt ein entsprechender Kommentar in dem alten Artikel. Aufgrund Änderungen in Windows 8 bzw. der anderen Verknüpfungsbezeichnung ist die alte Anleitung teilweise ungültig.

Die Frage ist nun: Wie kommt es dazu? Ich habe bemerkt, dass mehrere Faktoren notwendig sind. Wie erwähnt spielt Linux eine Rolle, welches meistens auf einen NAS zu finden ist. Mit reinen Windows-Freigaben hatte ich noch nie ein solches Phänomen.

Ich denke, dass es sich dabei um einen Bug mit speziellem Auslöser handelt. Dieser dürfte selten sein.

Behebung

Sehr einfach zu bewerkstelligen. Man muss einfach eine Datei löschen. Darin werden die angehefteten und häufig genutzten Ordner gespeichert. Beim Löschen verliert man aber leider alle angehefteten Ordner und die häufigen Ordner sind leer.

Im Windows-Explorer in der Adressleiste einfach folgenden Pfad eingeben:

Danach nach einer Datei mit folgender Bezeichnung suchen:

Der Ordnerinhalt sieht etwa so aus:

Diese Datei nun löschen. Man kann zur Sicherheit die Datei auch umbenennen. Dann kann man zur Not auf die alte Datei zurück gehen:

Es ist eigentlich kein Neustart erforderlich. Es müsste sofort gewirkt haben. Die Datei wird dann neu erstellt und man muss leider wieder alle gewünschten Ordner anheften.

weitere relevante Beiträge…

• Automatische Anmeldung unter Microsoft Windows
• Windows 8.1: Rechtklick auf Startmenü geht nicht
• Internet Explorer 10: Werbefilter
• Windows 8: Standardanmeldebild abändern
• VPN-Einwahl schlägt mit "Fehler 87 Falscher Parameter" fehl
• Gruppenrichtlinienverwaltung: Der Index war außerhalb des Arraybereichs

• Betrifft: Ereigniseintrag mit Remotedesktopdienste wurde unerwartet beendet.
• System: Microsoft Windows 7 und Windows Server 2008 R2, jeweils mit Servicepack 1
• Problem: Die entsprechende Fehlermeldung wird bei jedem Neustart in der Ereignisanzeige angezeigt. Dazu erscheinen meist davor vier weitere Fehlermeldungen betreffend Kryptografiedienst, DNS-Client, Arbeitsstationsdienst und NLA (Network Location Awareness). Die Übernahme von Gruppenrichtlinien ist gestört. Computer bzw. Server ist Mitglied einer Domäne.

Hintergrund

Bei jedem Neustart erhält man auf Windows 7 oder auf Windows Server 2008 R2 mit installierten Servicepack 1 fünf direkt nacheinander folgende Fehlermeldungen in der Ereignisanzeige. Dabei handelt sich um Abstürze von fünf verschiedenen Diensten: Kryptografiedienste, DNS-Client, Arbeitsstationsdienst, NLA (Network Location Awareness) und Remotedesktopdienste.

Bei der Kontrolle der Dienste wird man merken, dass diese meisten Dienste wieder normal laufen. Zeitweise ist der Remotedesktopdienst noch nicht gestartet. Dieser lässt sich aber normal starten.

Beim Startvorgang wird man vielleicht merken, dass die Zeitdauer bis der Anmeldebildschirm erscheint, etwas kürzer ist als für normal. Dabei könnte man ebenfalls merken, dass Gruppenrichtlinien nicht übernommen werden – aber das ist ein anderes Thema.

Der Grund ist dabei einfach. Beim Absturz aller Dienste geht die Netzwerkverbindung verloren. Daher können Gruppenrichtlinien oder Skripte nicht übernommen werden. Diese Abarbeitung bzw. Ausführung werden übersprungen.

Alle Dienste hängen direkt zusammen und die Ursache ist in diesem Fall der Remotedesktopdienst. Ist dieser deaktiviert, dann startet der Computer völlig normal. Daher sollte die Lösung als gesamtes betrachtet werden und nicht pro Fehlermeldung bzw. Dienst.

Im Internet steht bei den eher weniger passenden Beiträgen oft als Ursache für den Absturz des Kryptografiedienstes ein fehlerhaftes oder fehlendes Zertifikat – dies ist in diesem Zusammenhang aber falsch.

Genauso gibt es für die anderen Dienste die verschiedensten Lösungsmöglichkeiten. Sollte der jeweilige Dienst alleine in der Ereignisanzeige einen Fehlereintrag erzeugen, dann könnte die Möglichkeit passen – nicht aber im Zusammenhang mit anderen Einträgen.

Behebung

Die Behebung ist dabei einfach aber nicht ganz unproblematisch. Mit dem Servicepack 1 wurde das RDS 8.0 Protokoll hinzugefügt. RDS steht für Remote Desktop Services, also Remotedesktopdienst. Die neue Version kann dabei die vorherige Version (RDS 7.1) ersetzen und bietet einige neue Funktionen.

Mir ist dabei aufgefallen, dass der Fehler mit dieser Erweiterung zusammen hängt. Dazu gibt es ebenso eine Gruppenrichtlinie.

An sich sollte das Protokoll beim Remotezugriff auf Windows 8 oder Windows Server 2012 bzw. Windows 8.1 oder Windows Server 2012 R2 verwendet werden.

Verbindet sich ein anderes Gerät auf den Computer, dann wird in der Standardeinstellung nach wie vor das alte Protokoll genutzt. Produkte von Drittherstellern können dies abändern. Genauso die manuelle oder automatische Konfiguration über Gruppenrichtlinie.

Meine Empfehlung: die Gruppenlinien kontrollieren! Bei Domänenmitglied: "Gruppenrichtlinienverwaltung", bei Arbeitsgruppe: "Gruppenrichtlinie bearbeiten". Bei letzterem ist dies lokal in der Systemsteuerung zu finden.

Die entsprechende Einstellung ist unter "Computerkonfiguration" – "Administrative Vorlagen" – "Windows-Komponenten" – "Remotedesktopdienste" – "Remotedesktopsitzungs-Host" – "Umgebung für Remotesitzung" zu finden.

Selbst auf deutschen Systemen lautet bei mir die richtige Option: "Enable Remote Desktop Protocol 8.0". Diese einfach auf "Nicht konfiguriert" (=Empfehlung) oder "Deaktiviert" stellen. Danach benötigt man zwei Neustarts – also beim zweiten Neustart sollten die obigen Fehlermeldungen verschwunden sein.

weitere relevante Beiträge…

• Die Änderungen an den Softwareinstallationseinstellungen wurde nicht angewendet
• Internet Explorer 10: Werbefilter
• VPN-Einwahl schlägt mit "Fehler 87 Falscher Parameter" fehl
• Gruppenrichtlinienverwaltung: Der Index war außerhalb des Arraybereichs
• Windows: Aufgabe bricht mit Fehler 2147942667 ab
• Nach Neustart kommt bei WinMgmt der Fehler 0×80041003

• Betrifft: Softwareverteilung über Gruppenrichtlinie
• System: Microsoft Windows 7 (womöglich auch Windows Server 2008 R2)
• Problem: Eine Änderung bei den Softwareinstallationseinstellungen (Entfernung von Software, Hinzufügen von Software) über Gruppenrichtlinie wird nicht übernommen. Der Fehler laut Ereignisanzeige lautet %%2147944538.

Hintergrund

Man möchte per Gruppenrichtlinie Software verteilen. Wenn der Computer eine solche Richtlinie das erste Mal übernimmt, so wird die zugehörige Software (meistens) ohne Probleme installiert. Wird danach eine Änderung bei der Gruppenrichtlinie durchgeführt, wie z.B. neue Software hinzugefügt oder vorhandene Software entfernt, so wird dies beim nächsten Neustart nicht durchgeführt.

In der Ereignisanzeige des entsprechenden Computer erscheint eine Warnung und ein Fehler:

Die Warnung hilft nicht viel weiter, da eine eigenes Protokoll nicht vorhanden ist. Der Fehler ist ebenso wenig hilfreich. Bis zur Beitragserstellung konnte kein Hinweis gefunden werden, was der Fehler %%2147944538 bedeutet. Ich vermute, entweder kann der Fehlergrund nicht eruiert werden oder für den Fehlergrund gibt es keinen zugehörigen Text.

Wie auch immer, die Ursachenforschung ist definitiv schwierig. Meine Empfehlung, andere Fehlereinträge suchen – selbst die, die nichts mit Softwareverteilung zu tun haben. Dazu gehört Netzwerk, Namensauflösung, Verschlüsselung und ähnlichem.

Behebung

In meinem Fall wurde dieses Phänomen unter Windows 7 entdeckt. Möglicherweise kann dies ebenso auf Windows Server 2008 R2 auftreten – nachstellen konnte ich dies nicht. Bei aktuelleren Systemen wie Windows 8 bzw. Windows Server 2012 und höher scheint dieser Fehler gar nicht auftreten zu können…

Jedenfalls wurde das Problem aufgrund dem Verlust der Netzwerkverbindung ausgelöst. Mir ist nicht ganz klar, ob %%2147944538 nun gleichbedeutet mit fehlendem Netzwerkzugriff ersetzt werden kann. Fakt ist aber das in meinem Fall mehrere Dienste beim Startvorgang abgestürzt sind. Darunter der Kryptografiedienste, DNS-Client, Arbeitsstationsdienst und NLA (Network Location Awareness). Diese wurden zwar wieder automatisch neu gestartet, jedoch zu spät verfügbar für die Gruppenrichtlinien. Damit kein Zugriff auf das Netzwerk.

Eine Lösungsmöglichkeit für diesen Fall habe ich im Artikel Remotedesktopdienste wurde unerwartet beendet dokumentiert. Zwar haben die Remotedesktopdienste weniger etwas mit der Softwareverteilung über Gruppenrichtlinien zu tun, aber beides hat definitiv etwas mit Initialisierung der Netzwerkverbindung zu tun und wenn aufgrund der Remotedesktopdienste die Netzwerkverbindung abbricht, dann kann keine neue Software installiert werden.

weitere relevante Beiträge…

• Gruppenrichtlinienverwaltung: Der Index war außerhalb des Arraybereichs
• Liste der installierten Programme per Powershell auslesen
• Remotedesktopdienste wurde unerwartet beendet
• Internet Explorer 10: Werbefilter
• VPN-Einwahl schlägt mit "Fehler 87 Falscher Parameter" fehl
• Windows: Aufgabe bricht mit Fehler 2147942667 ab

• Betrifft: Komponentenspeicher von Windows unter C:\Windows\WinSxS.
• System: Microsoft Windows 8.1 und Windows Server 2012 R2
• Problem: Unnötigen Speicherplatz aus dem Komponentenspeicher freigeben

Hintergrund

Unter Windows gibt es ab Windows XP einen speziellen Ordner mit der Bezeichnung WinSxS. Kurz als Erklärung, der Ordner dient unter Windows XP als Speicherplatz für gleichlautende *.dll Dateien mit unterschiedlichen Versionen. Beispielsweise system.dll mit Version 1.0 und Version 1.1. Der Hintergrund: ein Programm kann nicht in Probleme geraten, wenn diese für Version 1.1 entwickelt wurden, jedoch später für ein weiteres Programm die ältere Version installiert wird. Das ganze nennt sich Side-by-Side (SxS) Technologie.

Ab Windows Vista wurde die Nutzung des WinSxS Ordners erweitert. Aufgrund vergangener Einschränkungen betreffend modularer Aufbauweise konnten Systemfunktionalitäten nicht unabhängig installiert werden. So war Windows XP bzw. Windows Server 2003 ein nicht modulares System, wo Funktionalitäten stets auf andere aufgebaut haben. Mit Windows Vista wurden Funktionen in Pakete aufgeteilt. Diese Pakete geben an von welchen anderen Paketen sie abhängen und welche Dateien sie beinhalten. Ebenso sind darin Zielorte definiert und Registrierungswerte inkludiert. Bei der Installation werden die Zielorte gesetzt bzw. Registrierungswerte angelegt und bei der Deinstallation entfernt bzw. gelöscht. Um das Vorhalten des Installationsmedium für spätere Aktivierung von Funktionen bzw. Installation von Updates zu unterbinden, wurde entschieden alle Daten auf der Festplatte vorzuhalten. Bei den damals deutlich gesunkenen Preisen bzw. zur Verfügung stehenden Speicherplatzes eigentlich kein allzu großes Problem (klar bei SSD war es zu Anfang wieder etwas problematischer). Ein geeigneter Speicherort war mit dem WinSxS Ordner somit schnell gefunden.

Dabei wird man früher oder später über Dateien stoßen, die scheinbar doppelt vorhanden sind, wie z.B. explorer.exe (Windows Ordner und mindestens einmal im WinSxS Ordner). Diese Dateien sind in Wirklichkeit aber nur im WinSxS Ordner gespeichert und auf den eigentlichen Ordner per Hardlink verlinkt. Bei neueren Versionen einer Datei wird diese im WinSxS Ordner hinzugefügt und der Hardlink wird auf die neue Version gewechselt. Deshalb wächst der WinSxS Ordner vor allem nach der Installation von Windows Updates an – aber auch Programminstallation können den Ordner erweitern. Übriges kann der Windows Explorer Hardlinks nicht unterscheiden und zählt die Dateien mehrfach. Also erhält man eine falsche Ordnergröße.

Wie man sich vorstellen kann werden im Verlauf der Zeit im WinSxS Ordner Dateien unnötig, da diese ersetzt wurden und eine Deinstallation/Zurücksetzung nicht mehr in Frage kommt. Nun sollte man unter keinen Umständen im WinSxS Ordner willkürlich Daten löschen. Das wäre meistens die letzte Aktion bevor man den Computer formatiert und neu installiert.

Für die Bereinigung gibt es mit Windows 8.1 bzw. Windows Server 2012 R2 eine entsprechende Funktion zur Bereinigung von unnötig gewordenen Dateien. Dies ist speziell für Windows Server interessant wo die Datenträgerbereinigung nicht installiert wurden. Hinweis: bei Windows Clients ist die Datenträgerbereinigung vorzuziehen, da dies dort bei "Windows Update-Bereinigung" inkludiert ist. Die Datenträgerbereinigung muss dazu mit administrativen Rechen ausgeführt werden.

Behebung

Zuerst benötigt man eine Windows Kommandozeile mit administrativen Rechten ("cmd" ausführen als Administrator). Danach kann man mit folgendem Befehl überprüfen ob eine Bereinigung notwendig ist:

Sofern "Anzahl von Paketen, die freigegeben werden können" ungleich 0 ist, können Daten bereinigt werden. Dies geschieht mit folgendem Befehl:

weitere relevante Beiträge…

• Windows 8.1: Rechtklick auf Startmenü geht nicht
• VSS meldet Ereignis 8193 mit Fehler 0x80070005
• Kurios: Remotedesktop mag RAM zum Frühstück
• angeheftete Ordner unter Windows 8 lassen sich nicht löschen
• KB2920189 UEFI Update scheitert mit Fehler 800f0922
• KB2871690 UEFI Update scheitert mit Fehler 800f0922

• Betrifft: Volumeschattenkopie-Dienstfehler
• System: Microsoft Windows Server 2008, Windows Server 2008 R2, Windows Server 2012 und Windows Server 2012 R2
• Problem: Häufig wird wiederholt in der Ereignisanzeige unter System einen Fehler beim Volumenschattenkopiedienst mit Zugriff verweigert gemeldet. Auf dem Windows Server ist womöglich keine grafische Oberfläche eingerichtet. Der Server umfasst die Dienste für DNS Server, Active Directory und DHCP Server.

Hintergrund

Erstmals bemerkt habe ich das Phänomen ab Windows Server 2008 mit der Einführung der "Server Core" Rolle wo keine grafische Oberfläche bzw. kein GUI angezeigt wird. Meist in diesem Zusammenhang betrifft es Windows Server, die die DHCP-Server Rolle hinzubekommen haben. In manchen Fällen war die DHCP-Server Rolle bereits vorhanden, aber es hat eine Veränderung bei den Rollen stattgefunden. Beispielsweise die Deaktivierung der Benutzeroberfläche. Konkret empfindlich sind Domänencontroller mit DNS-Server, WINS-Server und DHCP-Server Rolle ohne grafischer Oberfläche.

Jedenfalls ist in der Ereignisanzeige wiederholt folgende Meldung zu finden:

Ein genauer Benutzer für das gemeldete Problem wird nicht angegeben. Manchmal kann man Zusammenhänge mit dem "Dhcp Jet Writer" finden.

Allgemein gesehen dient die Volumeschattenkopie (VSS) zur Sicherung von geöffneten Dateien. Dazu wird eine Schnittstelle zu dem jeweiligen Programm bzw. Dienst benötigt, der eben diese Datei zum Zeitpunkt der Sicherung geöffnet hat. Diese Schnittstellen hören auf die Bezeichnung "VSS Writer" und helfen bei der Datensicherung konsistente Zustände der Daten herzustellen. Ansonsten wäre die Leseoperationen auf die zu sichernden Daten blockiert und die Sicherung scheitert. Bei einem Windows System sind im Betrieb viele geöffnete Daten zu finden. Darunter z.B. die Registrierung oder ähnliche Datenbanken.

Deshalb werden von neuen Windows Rollen oder sonstigen Datenbankprogrammen die Schnittstelle um einen weiteren "VSS Writer" erweitert. Im Fall der DHCP-Server Rolle wird der "Dhcp Jet Writer" hinzugefügt. Und das ist in den meisten Fällen der Fehlergrund. Der DHCP-Server läuft mit dem Benutzer Netzwerkdienst und kann nicht auf den Registrierungspfad zugreifen.

Behebung

Die Behebung lässt sich recht einfach und schnell durchführen.

1.) Regstrierungseditor mit "regedit" als Administrator starten.

2.) Danach den Pfad "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS\Diag" aufrufen.

3.a) Nun mittels Rechtsklick in die Eigenschaften wechseln und den "Netzwerkdienst" den Vollzugriff auf den Ordner "Diag" geben.

3.b) Alternativ kann man die Berechtigung granularer vergeben. In diesem Fall muss man in den erweiterten Sicherheitseinstellungen dem "Netzwerkdienst" mehrere spezifische Berechtigungen auf "Dieser Schlüssel und Unterschlüssel" geben. Dies ist im nachfolgenden Bild detailliert ersichtlich.

4.) Nach Übernahme der Einstellungen alle Fenster schließen. Ein Neustart ist nicht notwendig. Die Fehlermeldung sollte nach der Änderung nicht mehr auftreten.

weitere relevante Beiträge…

• Active Directory-Zertifikatdienste: Zertifikate mit einer Gültigkeit von mehr als 2 Jahren
• VPN-Einwahl schlägt mit "Fehler 87 Falscher Parameter" fehl
• Liste der vertrauenswürdigen Stamm-Zertifizierungsstellen ist zu lang
• Gruppenrichtlinienverwaltung: Der Index war außerhalb des Arraybereichs
• Windows: Aufgabe bricht mit Fehler 2147942667 ab
• Nach Neustart kommt bei WinMgmt der Fehler 0x80041003

• Betrifft: Remotedesktopverbindung
• System: Microsoft Windows Server 2008, Windows Server 2008 R2, Windows Server 2012 und Windows Server 2012 R2
• Problem: Wie aktiviert man bei Windows Server Core die Remotedesktopverbindung? Wie kann ich die Aktivierung der Remotedesktopverbindung mit einem Skript aktivieren?

Hintergrund

Microsoft hat mit Windows Server 2008 die neue Funktion mit der Bezeichnung „Server Core“ eingeführt. Bei dieser speziellen Installationsart gibt es keine klassische grafische Benutzeroberfläche.

Mit wenigen Ausnahmen (wie z.B. Notepad oder Regedit) gibt es keine Programme. Direkt nach der Anmeldung erhält man nur eine Kommandozeilenfenster bzw. die Eingabeaufforderung. Der bekannte Weg zu den Systemeigenschaften ist nicht möglich.

Klarerweise kann seit Windows Server 2012 die grafische Oberfläche aktiviert werden, indem man z.B. via Server Manager via Remoteverwaltung auf dem entsprechendem Gerät die beiden Rollen „Tools und Infrastruktur für die grafische Verwaltung“ und vor allem „Grafische Shell für Server“ hinzufügt. Dies benötigt jedoch zumindest einen Neustart. Nebenbei kann danach die grafische Oberfläche wieder deaktiviert werden.

Bei den beiden älteren Betriebssystemen mit Windows Server 2008 und Windows Server 2008 R2 ist dies eine fixe Installationsart.

Dabei ist das Ganze viel einfacher mithilfe der Datei „scregedit.wsf“ im „System32″ Verzeichnis zu beheben.

Behebung mittels Befehl

In einem älteren Artikel Wie aktiviere ich Remotedesktop bei Windows Server Core habe ich dies bereits erklärt. Der Vollständigkeit nachfolgend ab Windows Server 2008 (NT 6.x) die möglichen Befehle. Für ältere Betriebssysteme siehe den älteren Artikel.

Den aktuellen Status der Variabel fDenyTSConnections auslesen:

• Remotedesktopverbindung ist aktiviert => fDenyTSConnections = 0
• Remotedesktopverbindung ist deaktiviert => fDenyTSConnections = 1 => ist die Standardeinstellung

Remotedesktopverbindung aktivieren:

Remotedesktopverbindung deaktivieren (= Standardeinstellung):

Nach dem Ausführen eines Befehles wird die Änderung ohne Neustart sofort übernommen.

Behebung mittels Richtlinie

Alternativ kann natürlich die Gruppenrichtlinie benutzen, sofern der Server bereits Mitglied einer Domäne ist. Dies ist so gesehen die saubere (und einfachere) Lösung, da dies dann automatisch übernommen wird.

Windows Server mit deutscher Sprache:

1. Der Pfad zur Einstellung lautet „Computerkonfiguration/Administrative Vorlagen/Windows-Komponenten/Remotedesktopdienste/Remotedesktopsitzungs-Host/Verbindungen“.
2. Die Richtlinie heißt „Remoteverbindung für Benutzer mithilfe der Remotedesktopdienste zulassen“ und muss aktiviert werden.

Windows Server mit englischer Sprache:

1. Der Pfad zur Einstellung lautet „Computer Configuration/Administrative Templates/Windows Components/Remote Desktop Services/Remote Desktop Session Host/Connections“.
2. Die Richtlinie heißt „Allow users to connect remotely using Remote Desktop Services“ und muss aktiviert werden.

weitere relevante Beiträge…

• Perflib meldet Ereignis 1008 oder 2003
• VSS meldet Ereignis 8193 mit Fehler 0x80070005
• Active Directory-Zertifikatdienste: Zertifikate mit einer Gültigkeit von mehr als 2 Jahren
• Wie aktiviere ich Remotedesktop bei Windows Server Core
• VPN-Einwahl schlägt mit "Fehler 87 Falscher Parameter" fehl
• Liste der vertrauenswürdigen Stamm-Zertifizierungsstellen ist zu lang

• Betrifft: Leistungsbibliothek
• System: Microsoft Windows Server 2008, Windows Server 2008 R2, Windows Server 2012 und Windows Server 2012 R2
• Problem: In der Ereignisanzeige kommen wiederholt Warnungen (Ereignis-ID 1008 oder 2003) betreffend der Leistungsbibliothek von verschiedenen Diensten.

Hintergrund

Die Leistungsindikatoren gibt es eigentlich schon seit Ewigkeiten und die meisten Administratoren werden den einen oder anderen mittel Leistungsüberwachung zumindest für einen bestimmten Zeitraum ausgelesen haben. Trotzdem gibt es zwei ärgerliche Fehler, die zum Teil sehr häufige Warnungen veranlassen.

Die erste Warnung habe ich vor allem bei den Leistungsindikatoren für „BITS“ und etwas weniger für „.NETFramework“ bemerkt.

Die zweite Warnung habe ich im Zusammenhang mit Microsoft SQL Server bemerkt.

Die Ursachen sind mir bei beiden nicht eindeutig klar. Man kann zwar viel im Internet finden, aber wirklich hilfreich ist nur ein Befehlszeilenprogramm gewesen: lodctr.

Mit dem nachfolgenden Befehl kann man den Status aller Leistungsindikatordienste anzeigen lassen.

Nur den Status einen bestimmten Leistungsindikatordienst anzeigen lassen:

Behebung Ereignis-ID 1008

Bislang konnte ich nur eine Lösung finden, die auch Abhilfe gebracht hat. Dies wäre mit dem Deaktivieren des jeweiligen Leistungsindikatordienstes.

Für den Leistungsindikatordienst „BITS“ wäre dies wie folgend:

Behebung Ereignis-ID 2003

Hier konnte ich zwei mögliche Lösungen finden. Die erste wäre mit dem kurzzeitigen Deaktivieren des Leistungsindikatordienstes um die Vertrauenswürdigkeit wiederherzustellen.

Damit Leistungsindikatordienst deaktivieren:

Leistungsindikatordienst als vertrauenswürdig festlegen:

Leistungsindikatordienst wieder aktivieren

Bei dem Befehl zur Wiederherstellung der Vertrauenswürdigkeit habe ich stellenweise eine Fehlermeldung bekommen. Es wird angemerkt, dass der Leistungsindikatordienst nicht gefunden werden kann. Sofern der eine Leistungsindikatordienst nicht direkt notwendig ist, so kann man diesen wie bei Ereignis-ID 1008 deaktiviert lassen.

weitere relevante Beiträge…

• Remotedesktopverbindung für Windows Server Core aktivieren (lassen)
• VSS meldet Ereignis 8193 mit Fehler 0x80070005
• Active Directory-Zertifikatdienste: Zertifikate mit einer Gültigkeit von mehr als 2 Jahren
• VPN-Einwahl schlägt mit "Fehler 87 Falscher Parameter" fehl
• Liste der vertrauenswürdigen Stamm-Zertifizierungsstellen ist zu lang
• Gruppenrichtlinienverwaltung: Der Index war außerhalb des Arraybereichs

• Betrifft: Netzwerkeigenschaften festlegen
• System: Microsoft Windows 8, Windows 8.1
• Problem: Den Netzwerknamen unter „Netzwerk- und Freigabecenter“ bearbeiten oder abändern. Das eigene Netzwerk einen passenden und wiedererkennbaren Namen geben. Das Netzwerkprofil nach eigenem Wunsch abändern.

Hintergrund

Bis Windows 7 war die Abänderung von Netzwerknamen ohne Probleme machbar. Im Netzwerk- und Freigabecenter werden aktive Netzwerke angezeigt.

Bei einem linken Mausklick auf das Symbol (im Bild ein Haus) kommt ein neues Fenster mit „Netzwerkeigenschaften festlegen“.

Dort konnte man neben dem Netzwerksymbol ebenfalls den Netzwerknamen abändern. Einfach und für jeden recht simpel machbar – zumindest sobald man davon wusste.

Tja und nun das „Netzwerk- und Freigabecenter“ unter Windows 8.1… – wo es kein Netzwerksymbol mehr gibt.

Damit ist ein Aufruf des alten Dialogfeldes nicht mehr möglich. Ebenfalls in den PC-Einstellungen, ist eine Änderung des Netzwerknamens nicht berücksichtigt worden. Man kann zwar den Adapternamen abändern (unter Adaptereinstellungen ändern), aber dies ist überhaupt nicht das selbe. Wird aber im Internet manchmal so behauptet.

Behebung

Es gibt damit kein Dialogfeld mehr und so führt der Weg, wie womöglich bereits vermutet, über den Registrierungs-Editor. Der Wert wird 1:1 noch genauso wie im vorherigen Betriebssystem gespeichert, verwaltet und wieder ausgelesen.

1.) Über „Windows-Taste“ + „R“ das „Ausführen“ Fenster öffnen. Darin „regedit“ eingeben und mit „Ok“ bestätigen.

Es sollte anschließend die Benutzerkontensteuerung erscheinen, da dieser Vorgang administrative Rechte voraussetzt. Sollte dies nicht kommen, dann bitte auf einen entsprechenden Benutzer (Administrator) wechseln.

2.) Es erscheint der Registrierungs-Editor.

3.) Nun muss der richtige Pfad aufgerufen werden. Dieser lautet wie folgt:

Jetzt wird es etwas komplizierter, da beim erweitern von „Profiles“ ein oder mehrere Unterordner vorhanden sein können. Dies hängt davon ab, wie viele Netzwerke bereits besucht wurden bzw. aktuell aktiv sind. Für jedes Netzwerkprofil wird ein eigener Unterordner mit eigener ID angelegt. Diese ist von Computer zu Computer unterschiedlich.

4.) Um das korrekte Netzwerkprofil bzw. den richtigen Unterordner zu finden, einfach einen Unterordner nach der Reihe durchschauen und den Wert „ProfileName“ mit der Angabe unter „Netzwerk- und Freigabecenter“ vergleichen. Sobald der gleiche Profilname gefunden wurde, kann es mit der Änderung losgehen.

Einfach den Wert von „ProfilName“ nach eigenem Wunsch abändern. Dies geht mittels Doppelklick auf „ProfilName“. Abschließend mit „OK“ das Fenster schließen.

5.) Nach der Abänderung kann der Registrierungs-Editor und das „Netzwerk- und Freigabecenter“ geschlossen werden.

Ein Neustart ist nicht unbedingt notwendig. Wenn das „Netzwerk- und Freigabecenter“ neu geöffnet wird, dann wird bereits der neue Netzwerkname angezeigt. Dies gilt für alle Bereiche – jedoch werden manche Fenster bzw. Anzeigen nur bei der Anmeldung eingelesen. Damit kann bis zur nächsten Anmeldung bzw. bis zum nächsten Neustart an manchen Stellen noch der alte Netzwerkname noch aufscheinen. Ist damit kein großes Problem und behebt sich spätestens mit dem nächsten Neustart.

weitere relevante Beiträge…

• Netzwerknamen unter Windows 10 bearbeiten
• angeheftete Ordner unter Windows 8 lassen sich nicht löschen
• Automatische Anmeldung unter Microsoft Windows
• ständiges anmelden mit einem temporären Benutzerprofil
• Windows Komponentenspeicher SxS bereinigen
• Kurios: Remotedesktop mag RAM zum Frühstück

• Betrifft: Netzwerkeigenschaften festlegen
• System: Microsoft Windows 10
• Problem: Den Netzwerknamen unter „Netzwerk- und Freigabecenter“ bearbeiten oder abändern. Das eigene Netzwerk einen passenden und wiedererkennbaren Namen geben. Das Netzwerkprofil nach eigenem Wunsch abändern.

Hintergrund

Bis Windows 7 war die Abänderung von Netzwerknamen ohne Probleme machbar. Im Netzwerk- und Freigabecenter werden aktive Netzwerke angezeigt.

Bei einem linken Mausklick auf das Symbol (im Bild ein Haus) kommt ein neues Fenster mit „Netzwerkeigenschaften festlegen“.

Dort konnte man neben dem Netzwerksymbol ebenfalls den Netzwerknamen abändern. Einfach und für jeden recht simpel machbar – zumindest sobald man davon wusste.

Tja und nun ein Blick in die PC-Einstellungen nach „Netzwerk und Internet“ bzw. „Netzwerk- und Freigabecenter“ unter Windows 10… – wo es weiterhin keine Möglichkeit zur Abänderung gibt.

Damit ist ein Aufruf des alten Dialogfeldes nicht mehr möglich. Zwar wurden unter Windows 10 die PC-Einstellungen enorm erweitert. Diese Funktion ist aber weiterhin nicht enthalten. Man kann zwar den Adapternamen abändern (unter Adaptereinstellungen ändern), aber dies ist überhaupt nicht das selbe. Wird aber im Internet manchmal so behauptet.

Behebung

Es gibt damit kein Dialogfeld und so führt der Weg, wie womöglich bereits vermutet, über den Registrierungs-Editor. Der Wert wird 1:1 noch genauso wie im vorherigen Betriebssystem gespeichert, verwaltet und wieder ausgelesen.

1.) Über „Windows-Taste“ + „R“ das „Ausführen“ Fenster öffnen. Darin „regedit“ eingeben und mit „Ok“ bestätigen.

Es sollte anschließend die Benutzerkontensteuerung erscheinen, da dieser Vorgang administrative Rechte voraussetzt. Sollte dies nicht kommen, dann bitte auf einen entsprechenden Benutzer (Administrator) wechseln.

2.) Es erscheint der Registrierungs-Editor.

3.) Nun muss der richtige Pfad aufgerufen werden. Dieser lautet wie folgt:

Jetzt wird es etwas komplizierter, da beim erweitern von „Profiles“ ein oder mehrere Unterordner vorhanden sein können. Dies hängt davon ab, wie viele Netzwerke bereits besucht wurden bzw. aktuell aktiv sind. Für jedes Netzwerkprofil wird ein eigener Unterordner mit eigener ID angelegt. Diese ist von Computer zu Computer unterschiedlich.

4.) Um das korrekte Netzwerkprofil bzw. den richtigen Unterordner zu finden, einfach einen Unterordner nach der Reihe durchschauen und den Wert „ProfileName“ mit der Angabe unter „Netzwerk- und Freigabecenter“ bzw. „Netzwerk und Internet“ vergleichen. Sobald der gleiche Profilname gefunden wurde, kann es mit der Änderung losgehen.

Einfach den Wert von „ProfilName“ nach eigenem Wunsch abändern. Dies geht mittels Doppelklick auf „ProfilName“. Abschließend mit „OK“ das Fenster schließen.

5.) Nach der Abänderung kann der Registrierungs-Editor, die PC-Einstellungen und das „Netzwerk- und Freigabecenter“ geschlossen werden.

Ein Neustart ist nicht notwendig. Wenn das „Netzwerk- und Freigabecenter“ neu geöffnet wird, dann wird bereits der neue Netzwerkname angezeigt. Dies gilt ebenfalls für die PC-Einstellungen. Ebenfalls alle weiteren Bereiche wurden in meinem Fall sofort aktualisiert.

weitere relevante Beiträge…

• Netzwerknamen unter Windows 8 bearbeiten
• Automatische Anmeldung unter Microsoft Windows

• Betrifft: Löschen von Ordnern, die im Namen mit einem Punkt enden
• System: Microsoft Windows Vista, Windows 7, Windows 8, Windows 8.1, Windows 10
• Problem: Unter Microsoft Windows lässt sich ein Ordner nicht löschen. Das System kann die angegebene Datei nicht finden. Die Bezeichnung des Ordners endet mit einem Punkt – also dem Trennzeichen von Dateien.

Hintergrund

Es ist eine ärgerliche Tatsache. Ein Ordner darf bei der Bezeichnung nicht mit einem Punkt enden. Der Punkt ist nur für Dateien gültig, wo der Punkt die Bezeichnung von der Dateityperkennung.

Trotzdem kann die Situation vorkommen und zwar laut meinen Recherchen unlängst, wenn man ein komprimierte Datei (ZIP-Archiv, RAR-Archiv, 7z-Archiv) in einem neuen Ordner extrahieren möchte. Wenn der neue Ordner automatisch aus den Dateinamen generiert wird, dann kann es vorkommen, dass ein doppelter Punkt in der ZIP-Datei diese Situation verursachen kann. So kann „Karin%20N..zip“ einen Ordner mit „Karin%20N.“ generieren.

Im Windows Explorer kann der Ordner weder betreten, noch gelöscht werden. Man bekommt die Fehlermeldungen „Element wurde nicht gefunden“ bzw. „Das System kann die angegebene Datei nicht finden“.

Wie man sich vorstellen kann wird es eine Lösung geben, da die Erstellung ja auch einmal funktioniert hat. Im Windows Explorer wird übrigens bei der Bezeichnung eines Ordners ein Punkt am Schluss automatisch entfernt.

Behebung

Für die Behebung muss man in der Windows Eingabeaufforderung den Löschbefehl mit der Syntax „\\?\“ durchführen. Das sieht in etwa wie folgt aus:

• *Laufwerk* kann C, D, E sein
• *Pfad* der zum Ordner führt
• *Ordner.* Der Ordner mit dem Punkt

1.) Mithilfe der Tastenkombination „Windows-Taste“ + „R“ das „Ausführen“-Fenster öffnen.

2.) Nun „cmd“  eingeben und mit „Ok“ bestätigen. Damit sollte sich die Windows Eingabeaufforderung öffnen.

3.) Danach gibt man laut oberen Beispiel den passenden Befehl ein und nach einer Bestätigung sollte der Ordner gelöscht sein.

weitere relevante Beiträge…

• Automatische Anmeldung unter Microsoft Windows
• ständiges anmelden mit einem temporären Benutzerprofil
• Gruppenrichtlinienverwaltung: Der Index war außerhalb des Arraybereichs
• Windows: Aufgabe bricht mit Fehler 2147942667 ab
• Nach Neustart kommt bei WinMgmt der Fehler 0x80041003
• Netzwerknamen unter Windows 8 bearbeiten

• Betrifft: Entfernen von zusätzlichen Registrierungseinstellungen in der Gruppenrichtlinienverwaltung
• System: Microsoft Windows 8, Windows 8.1, Windows 10, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016
• Problem: Nach dem Löschen oder Aktualisieren von administrativen Vorlagedateien für die Gruppenrichtlinie sind zusätzliche Registrierungseinstellungen vorhanden. Diese sollen entfernt werden, aber die administrative Vorlage steht nicht mehr zur Verfügung bzw. ist unbekannt.

Hintergrund

In einer Microsoft Active Directory Umgebung kommen Gruppenrichtlinien sehr häufig vor. Mit der Zeit können sich je nach Umgebung hunderte bis tausende Einstellungen darin ansammeln. Dazu wird klassisch die Gruppenrichtlinienverwaltung verwendet.

Dabei kann es durchaus passieren, dass veraltete administrative Vorlagen entfernt oder aufgrund neuer Windows Versionen aktualisiert werden. Letztere gilt besonders wenn man einen zentralen Gruppenrichtlinienordner (Group Policy Central Store) verwendet. Damit können bereits getätigte Einstellungen ungültig werden bzw. anders konfiguriert werden. Das bedeutet zwar nicht, dass diese Einstellungen nicht mehr verteilt und womöglich von einem Computer übernommen werden. Man kann diese jeweilige Einstellungen nur nicht mehr anpassen bzw. entfernen.

Egal warum, in der Gruppenrichtlinienverwaltung werden bei der jeweiligen Gruppenrichtlinie unter dem Register „Einstellungen“ entsprechend im Feld „Zusätzl. Reg.-einst.“ einer oder mehrere Werte aufgeführt. Ohne der eigentlichen administrative Vorlage scheint es keine Möglichkeit zu geben, diese Einstellung zu entfernen…

Behebung

Zum Glück gibt es mittlerweile Windows Powershell. Dort gibt es sobald die Gruppenrichtlinienverwaltung als MMC-Snap-In installiert wurde, die Funktion „Remove-GPRegistryValue“. Damit können veraltete Einstellungen aus der Gruppenrichtlinie entfernt werden. Und das ohne der Notwendigkeit die alten administrative Vorlagen mit den Endungen *.admx oder gar noch *.adm finden zu müssen.

Das Schema für den Befehl lautet:

• *Gruppenrichtline* = Name der Gruppenrichtlinie
• *Registrierungspfad* = Ist der Pfad zur jeweiligen Richtlinie ohne der letzten Passage, da das der Registrierungswert ist.
• *Registrierungswert* = Ist der letzte Teil der Angabe aus der Gruppenrichtlinie. Also der Name nach dem letzten „\“.

In meinem Beispiel lautet der richtige Befehl:

weitere relevante Beiträge…

• Entfernen von Ordnern mit Punkt
• Automatische Anmeldung unter Microsoft Windows
• Gruppenrichtlinienverwaltung: Der Index war außerhalb des Arraybereichs
• Netzwerknamen unter Windows 8 bearbeiten
• Perflib meldet Ereignis 1008 oder 2003
• Remotedesktopverbindung für Windows Server Core aktivieren (lassen)

• Betrifft: DistributedCOM unter Windows für APPID {9CA88EE3-ACB7-47C8-AFC4-AB702511C276}
• System: Microsoft Windows 8.1, Windows 10, Windows Server 2012 R2, Windows Server 2016
• Problem: In der Ereignisanzeige ist häufig von fehlender Berechtigung vom Typ „Lokale Aktivierung“ für die COM-Serveranwendung mit der CLSID {D63B10C5-BB46-4990-A94F-E40B9D520160} lesbar.

Hintergrund

In der Ereignisanzeige wird ein Fehler bei der Quell DistributedCOM gemeldet. In den meisten Fällen wird der Fehler mehrfach pro Tag gemeldet.

Die Ursache ist mir unklar. Hinter den kryptischen Nummern versteckt sich der RuntimeBroker. Manchmal kommt der Fehler sofort am ersten Tag einer Neuinstallation. Dann wiederum gar nicht oder erst nach einem Monat. Den Fehler kenne ich bestimmt schon seit Windows 8 – also doch einige Jahre. Persönlich dokumentiert habe ich es unter Windows 8.1 bzw. Windows Server 2012 R2 mit entsprechender Lösung. Die Angelegenheit tritt jedoch selbst unter Windows Server 2016 und ebenso bei frisch installiertem Windows 10 1709 weiterhin auf.

Behebung

In vielen Fällen werden doch recht komplexe Schritte zur Behebung angeführt. Grundlegend funktionieren diese. Haben teilweise aber Nebenerscheinungen, wie z.B. die automatische Entfernung von Standardvorgaben beim RuntimeBroker durch den Komponentendienst.

Kürzlich habe ich wieder einige Fälle gelöst. In diesem Fall mit einer neuen und wirklich einfachen Variante ohne Nebenerscheinungen. Es müssen keine Rechte oder Besitzer (TrustedInstaller) in der Windows-Registrierung geändert werden. Also weit weniger komplex und nicht fehleranfällig.

Die Behebung geht via PowerShell mit DCOMPermissions.psm1 aus der Technet Galerie. Nach dem Download muss PowerShell als Administrator im gleichen Pfad gestartet werden.  Danach folgen die beiden Befehle:

Es ist kein Neustart notwendig.

weitere relevante Beiträge…

• Veraltete Einstellungen aus der Gruppenrichtlinienverwaltung entfernen
• CAPI2 meldet 513 Zugriff verweigert
• Fehler bei Suche nach Updates: 0x8024401c
• Entfernen von Ordnern mit Punkt
• Windows Komponentenspeicher SxS bereinigen
• Automatische Anmeldung unter Microsoft Windows

• Betrifft: Microsoft-Windows-CAPI2 mit Fehler 513
• System: Microsoft Windows 8.1, Windows 10, Windows Server 2012 R2, Windows Server 2016
• Problem: Bei jedem Sicherungsvorgang werden mehrfach Fehler vom Kryptografiedienst gemeldet. Darin ist von fehlenden Zugriffsrechten zu lesen. Es wird ein externer VSS-Agent für die Sicherung verwendet.

Hintergrund

In der Ereignisanzeige werden während einer Sicherung mehrfach von der Quelle Microsoft-Windows-CAPI2 eine Fehlermeldung gemeldet.

Der Fehler wurde von mir erst kürzlich unter Windows Server 2016 entdeckt. Mittlerweile wurde das auf einem zweiten frisch installierten Server ebenfalls erkannt. Grundsätzlich scheint der Fehler ebenfalls in älteren Versionen auftreten zu können, wie im Microsoft Forum unter „Cryptographic Services failed while processing the OnIdentity() call“ nachgelesen werden kann. Da war der Fehler unter Windows 8.1 aufgetreten.

Nachtrag: Es gibt mittlerweile sogar einen Microsoft Support Eintrag: Event ID 513 when running VSS in Windows Server 2016 and Windows Server Version 1709

Grundsätzlich scheint es um fehlende Rechte zu gehen. Eine Ursache ist mir nicht bekannt. Vermute jedoch Zusammenhänge mit Drittherstellerprodukten, die zur Sicherung einen eigenen Agent auf dem System installieren. Dazu zählt z.B. Quest Rapid Recovery oder Veeam Endpoint Protection.

Behebung

Im oben verlinkten Artikel steht es ausführlich. Damit nur wirklich kurz die notwendigen Schritte. Es geht um die Systemdatei „Microsoft Link-Layer Discovery Protocol“ unter „C:\Windows\system32\DRIVERS\mslldp.sys“. Nachfolgende Befehle müssen via Windows Eingabeaufforderung ausgeführt werden.

Aktuelle Berechtigung für mslldp.sys anzeigen:

Berechtigung der mslldp.sys erweitern. Dazu muss der obige Ausgabewert um „(A;;CCLCSWLOCRRC;;;SU)“ – was für „NT AUTHORITY\SERVICE“ steht – erweitert werden. Dies sieht dann folgendermaßen aus:

Ein Neustart ist nicht notwendig. Bei der nächsten Sicherung sollten die Fehler in der Ereignisanzeige nicht mehr erscheinen.

weitere relevante Beiträge…

• DistributedCOM meldet 10016 für RuntimeBroker
• Veraltete Einstellungen aus der Gruppenrichtlinienverwaltung entfernen
• Fehler bei Suche nach Updates: 0x8024401c
• Entfernen von Ordnern mit Punkt
• Windows Komponentenspeicher SxS bereinigen
• Automatische Anmeldung unter Microsoft Windows

• Betrifft: Active Directory Federation Service 4.0 (und womöglich älter)
• System: Microsoft Windows Server 2012 R2, Windows Server 2016
• Problem: Nach einem Änderungsvorgang über Powershell (Set-AdfsProperties) können keine Abfragen (Get-AdfsProperties) gestellt werden. In den Rückmeldungen erhält man eine Fehlermeldung, jedoch keine Werte. Der zugehörige Windowsdienst kann nicht gestartet werden, sofern dieser beendet wurde. Es wird für die ADFS-Datenbank ein eigenständiger SQL Server verwendet.

Hintergrund

Im Verlauf der Zeit wird man immer wieder Änderungsvorgänge entweder via Powershell oder via AD FS-Verwaltung durchführen müssen. Man wird dabei vielleicht merken, dass der Änderungsvorgang länger als gewöhnlich dauert.

Bei der Kontrolle ob die Änderung erfolgt wurde, erhält man direkt eine Fehlermeldung:

In der Ereignisanzeige treten nach dem Ausführen des Änderungsbefehls (nicht ab der Eigenschaftenabfrage) wiederholte Fehlermeldungen auf.  Diese sehen wie folgt aus:

Wenn nun versucht wird, den ADFS-Dienst neu zu starten, dann wird der Startvorgang mit folgender Fehlermeldung scheitern:

Es scheint einen Zusammenhang mit dem KB4019472 (Sicherheitsupdate 2017-05) vom 5. Mai 2017 für Windows Server 2016 zu geben. Das konnte ich nicht direkt verifizieren, da schon recht lange her. Womöglich schlummert der Fehler seit dem Update in vielen Installationen und erst die nächste Konfigurationsänderung löst das Problem aus.

Behebung

Die Angelegenheit ist simpel, aber verlangt nach einer gültigen Datenbanksicherung bevor die Behebung durchgeführt wird. Wer keine Sicherung hat, der kann direkt die Behebung probieren und mit Glück geht es wieder.

Zumindest in meinem Fall hatte ich die Datenbank aus der Sicherung wiederhergestellt, da in die Datenbank (laut Ereignisanzeige) ungültige Daten geschrieben wurden. Erst anschließend wurde die notwendige Behebung durchgeführt. Grundlegend könnte der ADFS-Dienst nach der Wiederherstellung gestartet werden und würde wieder normal laufen, jedoch eine erneute Konfigurationsänderung liefert wieder das obige Problem…

Die Ursache hat mit den Anmeldungseigenschaften des ADFS-Dienstes auf die SQL-Datenbank zu tun. Dazu benötigt man eine aktive Verbindung zum SQL Server via SQL Server Management Studio. Der ADFS-Dienst sollte beendet sein.

Während der Erstinstallation wurde bei der Standardsprache „German“ eingestellt. Die Sprache des Betriebssystem scheint unabhängig zu sein. Jedenfalls arbeitet der ADFS-Dienst mit Englisch und erwartet ebenfalls die gleiche Anmeldesprache am SQL-Server.

Somit muss im SQL Server Management Studio der ADFS-Dienstbenutzer aufgerufen und entsprechend abgeändert werden. Danach den ADFS-Dienst starten und jede zukünftige Änderung wird schneller und ohne Problem erfolgen.

weitere relevante Beiträge…

• CAPI2 meldet 513 Zugriff verweigert
• DistributedCOM meldet 10016 für RuntimeBroker
• Fehler bei Suche nach Updates: 0x8024401c
• Veraltete Einstellungen aus der Gruppenrichtlinienverwaltung entfernen
• Hyper-V: Der virtuelle Computer konnte nicht gestartet werden
• Kerberos Authentifizierung während der Migration Exchange 2013 auf 2016

• Betrifft: Löschen von Ordnern, die im Namen mit einem Punkt enden
• System: Microsoft Windows Vista, Windows 7, Windows 8, Windows 8.1, Windows 10
• Problem: Unter Microsoft Windows lässt sich ein Ordner nicht löschen. Das System kann die angegebene Datei nicht finden. Die Bezeichnung des Ordners endet mit einem Punkt – also dem Trennzeichen von Dateien.

Hintergrund

Es ist eine ärgerliche Tatsache. Ein Ordner darf bei der Bezeichnung nicht mit einem Punkt enden. Der Punkt ist nur für Dateien gültig, wo der Punkt die Bezeichnung von der Dateityperkennung.

Trotzdem kann die Situation vorkommen und zwar laut meinen Recherchen unlängst, wenn man ein komprimierte Datei (ZIP-Archiv, RAR-Archiv, 7z-Archiv) in einem neuen Ordner extrahieren möchte. Wenn der neue Ordner automatisch aus den Dateinamen generiert wird, dann kann es vorkommen, dass ein doppelter Punkt in der ZIP-Datei diese Situation verursachen kann. So kann „Karin%20N..zip“ einen Ordner mit „Karin%20N.“ generieren.

Im Windows Explorer kann der Ordner weder betreten, noch gelöscht werden. Man bekommt die Fehlermeldungen „Element wurde nicht gefunden“ bzw. „Das System kann die angegebene Datei nicht finden“.

Wie man sich vorstellen kann wird es eine Lösung geben, da die Erstellung ja auch einmal funktioniert hat. Im Windows Explorer wird übrigens bei der Bezeichnung eines Ordners ein Punkt am Schluss automatisch entfernt.

Behebung

Für die Behebung muss man in der Windows Eingabeaufforderung den Löschbefehl mit der Syntax „\\?\“ durchführen. Das sieht in etwa wie folgt aus:

• *Laufwerk* kann C, D, E sein
• *Pfad* der zum Ordner führt
• *Ordner.* Der Ordner mit dem Punkt

1.) Mithilfe der Tastenkombination „Windows-Taste“ + „R“ das „Ausführen“-Fenster öffnen.

2.) Nun „cmd“  eingeben und mit „Ok“ bestätigen. Damit sollte sich die Windows Eingabeaufforderung öffnen.

3.) Danach gibt man laut oberen Beispiel den passenden Befehl ein und nach einer Bestätigung sollte der Ordner gelöscht sein.