Kategorie-Archiv: Allgemein

User Profile Service loggt Event ID 1534 („Fehler bei der Profilbenachrichtigung …“)

Veröffentlicht am von — Keine Kommentare ↓

Seit einem der letzten Updates von Windows 10/11 und Windows Server 2016/2019 und 2022 sehen wir auf vielen Windows-Systemen üpbermäßig viele Warnings mit der Event ID 1534 und der Quelle User Profile Service.

Fehler bei der Profilbenachrichtigung des Ereignisses Load für Komponente {B31118B2-1F49-48E5-B6F5-BC21CAEC56FB}. Fehlercode: See Tracelogging for error details.

In der Meldung wird immer die selbe Komponennte genannt: „{B31118B2-1F49-48E5-B6F5-BC21CAEC56FB}“. Das ist der „Kacheldaten-Modellserver“, der früher mal den Kachelserver zur Kachelaktualisierung für das Startmenü stellte. Den gibt es eigentlich nicht mehr – was wir als Grund für die Massen-Warnung vermuten.

Lösung

Um von den unnötigen Warnungen verschont zu werden, muss man einfach zwei Registry-Schlüssel komplett löschen.

Weil diese Key dem „TrustedInstaller“ gehören, muss man vorher den Besitz (einschliesslich untergeordneter Objekte) übernehmen.

Dann einfach entfernen:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileNotification\TLD

und

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion\ProfileNotification\TLD

Da es für die Besitzerübernahme von Reg-Keys kein (uns bekanntes) integriertes Kommandozeilentool gibt, ist hier leider etwas GUI-Klicken angesagt.

IIS SMTP stürzt nach einem in-place upgrade auf Windows Server 2022 ab (Fehler 7031 und Fehler 1000)

Veröffentlicht am von — 1 Kommentar ↓

Nach der Durchführung eines In-Place-Upgrades von Windows Server 2016 oder 2019 hat der gute alte IIS SMTP Dienst scheinbar ein ernstes Problem: Er stürzt mit einem Fehler ab wenn an eine E-Mail über diesen versenden will. In manchen Fällen erfolgt der Crash auch schon beim einfachen start des SMTPSVC.

Im Ereignisprotokoll (Anwendungsprotokoll) gibt es auch sofort den dazu passenden Fehler:

Name der fehlerhaften Anwendung: inetinfo.exe, Version: 10.0.20348.1, Zeitstempel: 0x20d57e42
Name des fehlerhaften Moduls: SMTPSVC.dll, Version: 10.0.20348.1, Zeitstempel: 0xba4e29ad
Ausnahmecode: 0xc0000005
Fehleroffset: 0x0000000000059abb
ID des fehlerhaften Prozesses: 0x850
Pfad der fehlerhaften Anwendung: C:\WINDOWS\system32\inetsrv\inetinfo.exe
Pfad des fehlerhaften Moduls: C:\WINDOWS\system32\inetsrv\SMTPSVC.dll
[...]

Wir wissen zwar das der IIS6 „deprecated“ ist, haben aber keine Erklärung für Microsofts offensiver „Your Problem“ Haltung zu dieser oftmals vitalen Windows-Komponente.

Es gibt schliesslich einen Haufen guter Gründe, weiterhin ein internes SMTP-Relay zu betreiben. ERP-Software muss in aller Regel Mails versenden, Scanner-Systeme, Alarmmelder und Maschineninformationen wollen Kontakt halten. Kaum eines dieser Systeme beerrscht die sichere Authentifizierung, noch weniger eines möchte man sowas für den Versand ins Internet lassen.

Lösung

Der Trick ist einfach: man muss einfach vor dem Upgrade ein Backup der IIS-Site machen und nach dem Upgrade widerherstellen. Dann läuft alles wie gewohnt und weiterhin geschmiert. Der Grund ist unsinniges Update-Gefummel in der IIS-Metabase, die sich aber erledigt hat wenn man seine alte (fehlerfreie) Version einfach weiterverwendet.

VOR dem Upgrade ein IIS Backup erstellen

Die CMD-Shell „Als Administrator“ öffnen

%windir%\system32\inetsrv\appcmd.exe ADD BACKUP %computername%

Die Backup-Dateien landen sofort in diesem Pfad:

%windir%\system32\inetsrv\backup\%computername%

NACH dem Upgrade das Backup widerherstellen

Die Backup-Dateien gehen wärend des Upgrades zwar nicht verloren (aber paranoide Admins wie wir kopieren den Inhalt des Verzeichnisses natürlich an einen sicheren Ort).

Auch nach dem Update wird die CMD-Shell „Als Administrator“ benötigt:

%windir%\system32\inetsrv\appcmd.exe RESTORE BACKUP %computername%

Außerdem stellt das Setup den IIS SMTP Dienst auf den manuellen Start um, was nach Server-Neustarts zu Kopfkratzen führen könnte. Der Dienst sollte also möglichst wieder automatisch starten:

sc config smtpsvc start=auto
sc start smtpsvc

Und schon funktioniert der SMTP-Server auch unter Windows Server 2022 wieder.

Aufgaben „XblGameSaveTask“ und „XblGameSaveTaskLogon“ von Windows Server entfernen

Veröffentlicht am von — Keine Kommentare ↓

Es ist zwar irgendwie nett zu wissen, das man mit den aktuellen Windows Updates nun endlich auch auf seinem Windows Server (und auf Windows Server Core) vernünftig mit seinem X-Box Live Account spielen kann, aber notwendig ist das für den Unternehmensbetrieb eher nicht.

Windows Server brauchte DRINGEND unterstützung für XBox-Games

Wir wissen nicht was Microsoft dazu bewegt hat die Xbox „GameSaveTasks“ aus Server zu verteilen, zumal der Konzern selbst eher das genaue Gegenteil empfielt.

Lösung

Zum Glück kann man die entsprechenden Tasks schnell mit der PowerShell entfernen.

Hier ist die Copypasta:

Unregister-ScheduledTask -TaskName XblGameSaveTask -Confirm:$false
Unregister-ScheduledTask -TaskName XblGameSaveTaskLogon -Confirm:$false

PowerShell Connect-SPOService Fehler „Current site is not a tenant administration site.“

Veröffentlicht am von — 1 Kommentar ↓

Beim Verbinden mit einer SPO (SharePointOnline) Site gibt die PowerShell unerwartet diesen Fehler zurück:

PS C:\> Connect-SPOService -Url https://<MYTENANT>.sharepoint.com
Connect-SPOService : Current site is not a tenant administration site.

Lösung

Man muss die Fehlermeldung nur genau lesen, dann merkt man das die URL zur admin Site tatsächlich so nicht stimmt …

PS C:\> Connect-SPOService -Url https://<MYTENANT>-admin.sharepoint.com

Und ja, ich habe grade auch viel zu lange gesucht … 😶‍🌫️

Kalender einer Ressource zeigt keinen Betreff an, sondern den Namen des Organisators

Veröffentlicht am von — Keine Kommentare ↓

Ein Ressourcenpostfach (z.B. Shared Mailbox) ist in Exchange Online mit „AutoAccept“ (automatische Zusagen, AutomateProcessing) konfiguriert, damit der Kalender Besprechungsanfragen bestätigt.

Die Besprechungsanfragen werden auch korrekt automatisch angenommen. Der Besprechungsbetreff wird im Postfach des Organisators auch angezeigt.

Aber alle anderen Benutzer (mit Berechtigungen auf dem Postfach) sehen statt des Besprechungsbetreffs nur den Namen des Organisators.

Lösung

Dies ist das Standardverhalten von Exchange Online (und Exchange seit 2010) und seither irritierend. Das passiert immer dann, wenn AddOrganizerToSubject und/oder DeleteSubject auf True festgelegt sind.

Aktuelle Einstellung anzeigen:

Get-CalendarProcessing -Identity <RESSOURCE> | fl *subject*

Einstellungen ändern:

Set-CalendarProcessing -Identity <RESSOURCE> -DeleteSubject $false -AddOrganizerToSubject $false

DeleteSubject: Soll der Betreff entfernt werden? (true=ja)

AddOrganizerToSubject: Soll der Name des Organisierenden den Betreff ersetzen? (true=ja)