Windows 11 bietet per Rechtsklick ein „neues“ Kontextmenü im Explorer an, das um alle wichtigen Funktionen beschnitten wurde. Wer das, wie wir Admins, ebefalls nicht mag, kann auch weiterhin das „alte“ Menü von Windows 10 nutzen.
Lösung
Im Explorer (und Desktop) kann man die Tastenkombination Shift+F10 nutzen, um das alte Kontextmenü sofort zu öffnen.
Ab Windows 11 Version 22572 reicht sogar das einfache drücken von Shift aus, um das gute alte Kontextmenü aufzurufen.
Wer nur das alte Kontextmenü nutzen möchte, kann mit einer schnellen Änderung in der Registry das Default-VErhanlten ändern.
Ein WSUS-Server mag keine Updates mehr ausliefern. Wir haben das bei „alten“ WSUS-Setups gesehen, aber auch bei nagelneu und ganz frisch installierten Server-Rollen.
Auf den (Windows 10) Clients gibt es nur die wenig hilfreichen Windows-Update Fehlermeldung 0x8024401f gegen die auch kein „Troubleshooting“ hilft:
Auf dem WSUS-Server hingegen sagt das Ereignisprotokoll unter „Anwendung“ mit dem Fehler 1309 zumindest etwas mehr aus, wenn auch sehr kryptisch:
Event code: 3005
Event message: Es ist eine unbehandelte Ausnahme aufgetreten.
Event sequence: 4
Event occurrence: 1
Event detail code: 0
Application information:
Application domain: /LM/W3SVC/2062417591/ROOT/ClientWebService-1-132949411067470524
Trust level: Full
Application Virtual Path: /ClientWebService
Application Path: C:\Program Files\Update Services\WebServices\ClientWebService\
Machine name: SRV-DC01
Process information:
Process ID: 10664
Process name: w3wp.exe
Account name: NT-AUTORITÄT\Netzwerkdienst
Exception information:
Exception type: InvalidCastException
Exception message: Das Objekt des Typs "System.Web.Compilation.BuildResultCustomString" kann nicht in Typ "System.Web.Compilation.BuildResultCompiledType" umgewandelt werden.
bei System.Web.UI.WebServiceParser.GetCompiledType(String inputFile, HttpContext context)
[...]
Lösung
Ab WSUS3 mit allen Updates und „einigen“ Clients, schlägt bei gleichzeitigen Anfragen eine Typkovertierung fehl. Das ist ein Bug im WSUS-Installer, der die Anwendung fälschlicherweise mit der klassischen (meint: Typenstrenger ISAPI) Pipeline konfiguriert.
Korrekt ist die „Managed ASP.NET“ Pipeline für diesen Applikationspool:
Den IIS-Manager auf dem WSUS-Server öffnen
Link unter SERVERNAME\Anwendungspools\WsusPool öffnen
Den „Verwalteter Pipelinemodus“ von „Klassisch“ auf „Integriert“ umstellen
„Anwendungspool sofort starten“ anhaken
Man muss den Server (oder den IIS) danach nicht neu starten, die Änderungen setzt sich sofort durch und die Updates fließen wieder fehlerfrei. Oder zumindest ohne diesen Fehler.
Die neue vSphere ESXi Version bringt viele Neuerungen mit. Einige gut, andere sind neuen Herausforderungen für vmWare Admins
NTP never was synchronized.
Wir sehen es öfter, das frisch aktualisierte vsphere ESXi Hosts keine aktuelle Uhrzeit mehr von NTP Servern unter Windows abholen wollen. Es ist nicht nur eine Windows Server Zeitquelle betroffen, aber hier ist der Effekt am einfachsten nachzuvollziehen (und ja auch schon hinlänglich dokumentiert).
Hosts zeigen nach einer Weile den roten Fehler „Zeitsynchronisierung des Hosts wurde unterbrochen“ an.
vSphere: Zeitsynchronisierung wurde unterbrochen
Im Testprotokoll (Hosts > Konfigurieren > Uhrzeitkonfiguration > Dienste testen) sieht man leider nur den wenig hilfreichen Hinweis „NTP is not synced“ und „NTP never was synchronized.„. Nach der nett übersetzten Angabe „Die Konfiguration funtioniert nicht normal“.
Lösung
Standardmäßig erlaubt Windows NTP Server eine Dispersion („Jitter“) von (großzügigen) 10 Sekunden und fügt diese auch in NTP-Antworten im DISP-Feld bei jedem Abfrageintervall hinzu. ESXi/ESX-Hosts ab 7.0.3 akzeptieren standardmäßig aber keine NTP-Antworten mit einer Root-Dispersion von mehr als 1,5 Sekunden.
Man könnte den Windows-NTP entsprechend anpassen, geht damit aber das Risiko fehlerhaft konfigurierter Domänenmitglieder ein. Oder man ermöglich dem NTP Client von vSphere ESXi einfach eine größere Dispersion. Letzteres machen wir hier.
Wichitg: Unter ESXi 7.0.3 kann man die /etc/ntp.conf nicht mehr manuell bearbeiten, denn sie wird durch das Webinterface (vSphere Client oder vCenter) überschrieben. Das hier ist die „richtige“ Lösung dazu.
Eine NTP-Konfigurationsvorlagendatei erstellen und diese via esxcli setzen
# config-Datei mit Inhalt erstellen
printf "server pool.ntp.org\ntos maxdist 30\n" > /tmp/ntphack.txt
# Datei als NTP-Config "anhängen"
esxcli system ntp set -f /tmp/ntphack.txt
# NTP Client neu starten
esxcli system ntp set -e 1
Ein paar Sekunden (~20 Sekunden) später hat sich der Fehler selbst behoben und der Hoststatus ist wieder Normal.
Beim hinzufügen von Dateien oder Ordner zu den „Favoriten“ („An Schnellzugriff anheften„) bricht Explorer manchmal mit der Fehlermeldung „Ein API-Aufruf wurde unnormal beendet“ ab. Es wird auch kein Favorit erstellt.
Lösung
Alle Dateien in dem „automaticdestinations“ Ordner löschen und von vorne beginnen:
del %appdata%\microsoft\windows\recent\automaticdestinations\*
Explorer neu starten (oder abmelden/anmeden). Danach lief es bei uns (…) sofort und fehlerfrei wieder.
Für einige Windows-Anwendungen wie den Internet Explorer oder den Editor werden im Startmenü und in der Taskleiste (rechte Maustaste) sogenannte Sprunglisten eingeblendet. Hierbei werden die zuletzt verwendeten Dateien aufgelistet. Diese persönlichen Sprunglisten scheinen „kaputtbar“ zu sein.
Darin kann man die Ordner sehen, sogar „unsichtbare“ Aufgaben entfernen, Berechtigunen korrigieren und nach Herzenslust gleich ganze Bäume mit Aufgaben und allen Inhalten entfernen.
