Archiv der Kategorie: Microsoft

WSUS liefer keine Updates aus, Event 1309 tritt auf, Windows Update zeigt Fehler 0x8024401f

Veröffentlicht am von — Keine Kommentare ↓

Problem

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:

Windows Update Fehler 0x8024401f

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:

WSUS "Error Code 3005" beheben
  1. Den IIS-Manager auf dem WSUS-Server öffnen
  2. Link unter SERVERNAME\Anwendungspools\WsusPool öffnen
  3. Den „Verwalteter Pipelinemodus“ von „Klassisch“ auf „Integriert“ umstellen
  4. „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.

Outlook „Offline Adressbuch kann nicht heruntergeladen werden“ Fehler 0x8004010F

Veröffentlicht am von — Keine Kommentare ↓

Outlook versucht im Cache Modus immer das Offline Adressbuch (OAB) zu synchronisieren. Der Prozess bricht aber gerne mal mit dem wenig hilfreichen Fehler 0x8004010F ab.

Das Problem tritt gerne nach Migrationen auf, wenn ein Exchange Server auf ein anderes System (oder neue VErsion) migriert wurde. Dabei wird nämlich ein neues OfflineAddressBook (OAB) generiert, welches auch die Verteilung der Adresslisten übernimmt.

Die Adressliste auf den Clients ist dann meist auch nicht mehr richtig (veraltete Inhalte), allerdigns ist im OWA alles korrekt und aktuell.

Lösung

Zuerst: An der EMS prüfen ob das Adressbuch als „Default“ markiert ist:

Get-OfflineAddressBook | select Name, IsDefault

Hier sollte ein IsDefault: True zurückkommen.

Dann kann man mit prüfen, ob das OAB auch korrekt via Autodiscover verbreitet wird:

Get-OfflineAddressBook | select Name, VirtualDirectories, *web*

Und hier passiert gerne der Fehler. Exchange kennt zwei verschiedene Varianten, um dem Client den Zugriff auf das OAB zu wemöglichen:

  1. Man gibt an welche (IIS-) Virtual Directories vom Client abgefragt werden können um das OAB herunterzuladen
  2. Man erlaubt allen Virtual Directories den Download anzubieten

Microsoft (und wir) raten natürlich zur Variante Nummer 2:

Set-OfflineAddressBook "Standard-Offlineadressbuch" -GlobalWebDistributionEnabled $true

Der Name „Standart-Offlineadressbuch“ ist hier exemplarisch, alle existierenden Offline-Adressbücher listet man mit Get-OfflineAddressBook auf.

Windows 11 Taskleiste verkleinern („Kleine Symbole auf der Taskleiste verwenden“)

Veröffentlicht am von — 8 Kommentare ↓

Aus uns unerfindlichen Gründen hat Microsoft in Windows 11 (2022) die meisten praktischen und sinnvollen Funktionen der Taskleiste entfernt.

Nicht nur das man auf breiten Bildschirmen die Taskleiste nicht mehr an den Rand verschieben kann, sondern stattdessen nun noch mehr kostbaren (und knappen) vertikalen Platz verschenken muss, sondern die Taskliste ist nun auch erzwungenermaßen Rriesengroß.

Glücklicherweise lässt sich die unvernünftige Größe der Startleiste noch in der Registry schnell bändigen. Das geht sogar pro Benutzer.

Taskliste kleiner machen

Diese Registry-Einstellung skaliert die Taskbar:

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced]

"TaskbarSi"=dword:00000000

Der DWORD 0 steht für „klein“, die 1 für Standard und 2 für groß.

REG-Downlaod für den schnellen Admin:

win11-taskleiste-kleinHerunterladen

Veeam Backup and Replication Logfile Pfade

Veröffentlicht am von — 4 Kommentare ↓

Veeam B&R schreibt äußerst großzügige Logfiles, die die Fehlersuche in den allermeisten Fällen wesentlich vereinfachen. Das ist großartige – bitte bitte Veeam, ändert das niemals 😉

Früher(TM) war nicht nur alles besser, sondern man konnte über das Hilfe-Menü den Logfile-Ort schnell und komfortabel aufrufen; doch das war eine sinnvolle und hilfreiche Funktion und musste daher selbstverständlich ersatzlos gestrichen werden.

Naja, nicht ganz ersatzlos, denn dafür gibt es jetzt den freundlichen „Support-Assistenten“, der erst (wortwörtlich) Gigabyteweise Diag-Files zusammenkopiert, diese über alle CPU-Kerne verteilt einpackt und dem Informationensuchenden Admin schon nach einigen Minuten (!) ein wieder neu zu entpackendes .zip mit ALLEN logs darin präsentiert. In vielen Fällen eher sinnfrei, wenn Ihr mich fragt.

Lösung: Für das schnelle debuggen sind die Logfiles hier versteckt:

  • Windows Server XP/2003: 
    %allusersprofile%\Application Data\VeeamBackup
  • Windows Server 2008/2008R2/7: 
    %allusersprofile%\VeeamBackup
  • Windows Server 2026/2019/2022 und Windows 10: (thx Dezibel)
    %allusersprofile%\Veeam
  • Linux: 
    /var/log/VeeamBackup/

vSphere (7/) NTP funktioniert nicht „Zeitsynchronisierung des Hosts wurde unterbrochen“ und „NTP is not synced“ (NTP never was synchronized.)

Veröffentlicht am von — Keine Kommentare ↓

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“.

Die Konfiguration funktioniert 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.

NTP-Client auf ESXi-Hosts anpassen

  1. SSH auf Host aktivieren (Konfigurieren > Dienste > SSH > starten)
  2. Via SSH zum Host Verbinden und anmelden
  3. 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.