Archiv des Autors: weed

vmWare vCenter „Die STS-Signaturzertifikate laufen demnächst ab“

Veröffentlicht am von — Keine Kommentare ↓

In der vCenter Server Appliance (VCSA) und/oder dem vSphere GUI wird diese Fehlermeldung angezeigt:

Die STS-Signaturzertifikate laufen demnächst ab

Wenn man die VSCA rebootet, wird der Dienst vmware-vpxd nicht mehr gestartet. Jede erneute Anmeldung am vSphere-Client funktioniert mit diesem Fehler nicht mehr:

HTTP-Status 400 – Bad Request Message BadRequest
Signaturzertifikat ist ungültig

In /var/log/vmware/vpxd-svcs/vpxd-svcs.log gibt es Einträge wie diesen:

com.vmware.vim.sso.client.impl.SecurityTokenServiceImpl$RequestResponseProcessor opId=] Server rejected the provided time range. Cause:ns0:InvalidTimeRange: The token authority rejected an issue request for TimePeriod

Lösung

Dieses Problem tritt auf, wenn das Security Token Service (STS)-Zertifikat abgelaufen ist. Das führt dazu, dass interne Dienste keine gültigen Tokens mehr erwerben können und nicht mehr funktionieren. Wenn das STS-Zertifikat abläuft, geschieht das auch gerne mal ohne Vorwarnung (8.0.2.400+ fixt das wohl).

Es gibt von vmware einen guten Fix, der leider aktuell in der Broadcom-Umstellung nicht erreichbar ist. Hier ist der Mirror 🙂

  1. fixsts.sh (Hier als ZIP) herunterladen
  2. Auf der VCSA als root anmelden. Wenn das nicht mehr funktionieren sollte (Timeout und/oder Verbindungsabbruch), einfach als „[email protected]“ anmelden, die shell mit shell.set --enabled true einschalten und eine rootshell via sudo /bin/bash starten.
  3. Das Script fixsts.sh in /tmp ablegen und ausführbar machen:
    chmod +x /tmp/fixsts.sh
  4. Das Script ausführen:
    /tmp/fixsts.sh
  5. Das Script generiert neue STS-Zertifikate und tauscht diese aus. Der Vergang braucht nicht lange. Danach muss man nur noch die vCenter Dienste neu starten:
    service-control --stop --all && service-control --start --all

SSD und HDD Modellnummern und Seriennummern unter Windows auslesen

Veröffentlicht am von — 1 Kommentar ↓

Per Zufall grade gefunden: Man kann unter Windows schnell mal eben die Seriennummer(n) der angeschlossenen Festplatte(n) und SSDs herausfinden.

Der Windows Gerätemanager zeigt solche Gerätedaten (irritierenderweise) nicht an, aber zum Glück kann WMI das und die PowerShells spricht ja bekanntlich auch WMI.

Lösung

PowerShell

Get-PhysicalDisk | Select-Object FriendlyName,SerialNumber

CMD

wmic diskdrive get model,serialNumber,size

Umgang mit PDFs langsam, Acrobat Reader druckt langsam

Veröffentlicht am von — Keine Kommentare ↓

Bei fast allen PDF-Dateien Dateien druckt der Adobe Reader (PCL6-Drucker) auf einmal ungewohnt langsam. Der Umgang mit PDFs, wie verschieben, Drag & Drop, Vorschau im Explorer und ähnliches sind ebenfalls langsam.

Lösung

Es gibt einen schnellen Registry-Fix, der dieses Problem mit „irritierenden“ (für den Adobe reader irritieren 🙂 Feature-States im schnell löst:

HKLM\SOFTWARE\Adobe\Acrobat Reader\DC\FeatureState
"FeatureState" (DWORD) auf "4033257" setzen (oder erstellen)

In 32bit-Installationen lautet der Pfad zu dem Schlüssel folgerichtig:

HKLM\SOFTWARE\Wow6432Node\Adobe\Acrobat Reader\DC\FeatureState

Nach einem Neustart des Readers, ist der Umgang mit PDF Dateien sofort wieder schnell. Der Explorer benötigt manchmal jedoch einen zusätzlichen Windows-Neustart.

Microsoft Office 365 Apps auf RDS (RD-Sessionhosts) oder VDI Fehler „Da hat etwas nicht geklappt, [1001]“

Veröffentlicht am von — Keine Kommentare ↓

Auf RDS oder in VDI-Umgebungen, auch mit FSLogix, sehen wir schon mal diesen Fehler, wenn ein Benutzer sein Office (meit Outlook) öffnen möchte:

Fehler: Es ist ein Fehler aufgetreten. [1001]

oder auch

Fehler: Da hat etwas nicht geklappt. [1001]

Der Effekt ist nicht wirklich persistent und scheint nicht immer aufzutreten. Manchmal geht es auch „Vormittags“ und „Nachmittags“ aber nicht mehr.

Lösung

Es gibt ein paar Pfade, die eigentlich nicht roamingfähig sind, aber in Szenarien mit FSLogix-Profilcontainern trotzdem unfreiwillig umgezogen werden. Die Ordner (und Registry-Schlüssel) werden somit zwischen RDS oder VDI Hosts „geroamt“ge-roamed“. Das macht die Schlüssel und Host-Zertifikate aber ungültig.

Am einfachsten ist es, die betreffenden Pfade und Registry-Schlüssel einfach zu löschen. Nach einem ab- und wieder anmelden tritt der Fehler dann nicht mehr auf, bis es wieder zu einem Hostwechsel kommt. Dann kann das Script aber einfach wieder ausgeführt werden.

@echo off
REM /*
REM	Office (Outlook) Fehler "1001" beheben
REM	https://support.microsoft.com/en-us/office/6f63238d-d83c-437c-a929-de72fe819793
REM	10.04.2024 Admins auf ugg.li
REM */

if exist "%localappdata%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy" rd /s /q "%localappdata%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy"
if exist "%localappdata%\Packages\Microsoft.Windows.CloudExperienceHost_cw5n1h2txyewy" rd /s /q "%localappdata%\Packages\Microsoft.Windows.CloudExperienceHost_cw5n1h2txyewy"

for /d %%i in ("%localappdata%\Packages\*") do (
	if exist %%i\AC\TokenBroker echo rd /s /q %%i\AC\TokenBroker
)

reg delete "HKEY_CURRENT_USER\SOFTWARE\Microsoft\IdentityCRL" /f
reg delete "HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\AAD" /f
reg delete "HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WorkplaceJoin" /f

Die „richtige“ Lösung wäre eine Anpassung von FSLogix, oder einfach ein Fix von Microsoft das roamed-certificates einfach einbezieht …