Windows CA: Zertifikatsregistrierungs-Webdienst lässt sich nah Migration nicht installieren (Configuration Failed 0x80070057 (WIN32: 87))

Veröffentlicht am von — Keine Kommentare ↓

Wenn man eine Windows CA erfolgreich migriert hat (Backup+Restore), kommt beim Versuch den CertSvc-Webdienst via ServerManger zu installieren die folgende Fehlermeldung:

Webregistrierung der Zertifizierungsstelle: Konfiguration fehlgeschlagen.
Die Einrichtung der Active Directory-Zertifikatdienste ist mit folgendem Fehler fehlgeschlagen: Der Parameter ist falsch. 0x80070057 (WIN32: 87)

Das passiert nach einer Migration und auch nur mit dem Webdienst – den man korrekterweise erst nach der CA „dazuinstalliert“. Natürlich ist das ein bekannter und bisher (Windows Server 2003-2022) ungepatchter Bug.

Lösung

Das Problem besteht darin, dass der Wert von SetupStatus in der Registry unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration noch den Wert „hat“Web ist installiert“ hat. Wenn das der Fall ist, scheitert der Windows ServerManager.

Der Hexadezimalwert 6003 sagt „ist schon installiert“
Der Hexadezimalwert 6001 sgat „ist frei“

Man ändere also mal eben den Wert von SetupStatus der Registrierung auf 6001 und dann läuft die Installation des „Zertifikatsregistrierungs-Webdienstes“ durch.

Update

Ich habe soeben herausgefunden, das das sogar an der Kommandozeile vie certutil möglich ist:

certutil -setreg config\setupstatus 0x6001

Es wird noch besser, es gibt sogar eine named procedure in certutil dazu, die ebenfalls genau das selbe tut:

certutil -setreg config\setupstatus - SETUP_CLIENT_FLAG

vmWare vSphere ESXi Host: „Das diesem Host zugewiesene Zertifikat ist abgelaufen. Sie müssen ein gültiges Zertifikat installieren.“

Veröffentlicht am von — Keine Kommentare ↓

Alle paar Jahre (alle 10 Jahre spätestens) läuft das selbsterstellt SSL-Zertifikat eines ESXi Hosts ab. Ein vCenter Server kümmert sich in „normalen“ Umgebungen automatisch um die Erneuerung, ein Standalone-Host alleine tut das aber nicht. Läuft das Zertifkat ab, erhält man die altbekannte Browser-Warnung und einen gelben Warnhinweis im ESXi vSphere Host-Client. Im Browser ist das nur halb so schlimm, weil man ja „trotzdem fortfahren“ kann.

Etwas perfide ist das, weil „plötzlich“ alle möglichen Remote-Aufgaben fehlschlagen. PowerShell, esxcli, Perl oder andere Scripts brechen überraschend mit einem „certificate verify failed“ Fehler ab.

Diese Anleitung ist unter ESXi 7.x entstanden, gilt im wesentlichen aber auch für ESXi 8.

Neues Self-Signed Zertifikat auf einem ESXi Host erstellen/aktivieren

  1. SSH auf dem ESXi starten (Verwalten > Dienste > TSM-SSH > starten)
  2. Als root via ssh auf den ESXi Host anmelden
  3. Ausführen:
    /sbin/generate-certificates
    ℹ️unter anderen Patch-Ständen hat das Script auch mal einen Unterstrich im Namen:
    /sbin/generate_certificates
  4. Wenn dabei kein Fehler passiert (passiert so gut wie nie), kann man danach den Hostclient (Host-Agent) einfach neu starten. Dazu auf der Shell ausführen:
    /etc/init.d/hostd restart

Das dauert je nach Hardware und Last einen Moment, führt aber zu keinen VM-Ausfällen. Ein ESXi Reboot ist nicht nötig. Wenn der Neustart der Hostdienste fertig ist, ist das neue Zertifikat sofort wieder online.

ACHTUNG: Das alte Browserfestern sollte man natürlich schliessen, denn dessen SSL-Verbindung ist ja nicht mehr gültig. Ja genau, hat einen Facepalm nach drei Minuten Kopfkratzen gekostet 🤦😅

ACHTUNG: Wenn man Veeam als Host-Sicherung im Einsatz hat, muss man da nach einem Host-Rescan das Zertifika auch „neu“ akzeptieren. Sonst läuft die sicherung nicht durch …

Veeam für Office365 Warning: Processing site […] finished with warning: Cannot change web part export mode to ‘All’, because custom scripting is disabled for site

Veröffentlicht am von — Keine Kommentare ↓

Microsoft SharePoint in Microsoft 365 nutzt „Webparts“. Das sind diese „Dokumentenblöcke“ die man in Sites einfügen kann, zum Beispiel die Office Blöcke (Promimentes Beispiel: der Excel-Table-Block). In diesen ist „Scripting“ normalerweise aus Sicherheitsgründen abgeschaltet (Office-Macros und so).

Den Effekt hatten wir hier zwar schon, aber aufgrund einer Nachfrage nach mehr Details, hier praktisch das selbe nochmal, nur kleinschrittiger 🙂

Wenn man nun die „moderne Authentifizierung“ für Veeam nutzt, also die Anmeldung als App-Only-Authentifizierung mit dem Zertifikat, muss man für Veeam die Eigenschaft „Exportmodus“ des/der Webparts ändern. Standardmäßig ist Scripting auf „Keine“ festgelegt, aber Veeam benötigt „Alle“. Wenn die Scriptingeigenschaft auf „keine“ festgelegt ist, kann man Webparts nicht via Graph API exportieren. Das gilt auch nicht nur für Veeam.

Da seit Anfang des Jahres 2023 die Änderung der Site-Eigenschaft durch einen SharePoint-Administrator verboten ist, muss man das Globaler Admin selber übernehmen.

Lösung

1. Zuerst die notwendigen Rechte prüfen oder notfalls vergeben. Dazu öffnet man das klassische (!) SharePoint AdminCenter als „Globaler Admin“ und die Einstellungen-Seite zu SharePoint:

https://SITENAME-admin.sharepoint.com/_layouts/15/online/TenantSettings.aspx

2. Im Abschnitt „Benutzerdefiniertes Skript“ stellt man die (Radio-)Auswahl auf:
„Benutzern das Ausführen benutzerdefinierter Skripts auf persönlichen Websites gestatten„
UND
„Benutzern das Ausführen benutzerdefinierter Skripts auf Self-Service Creation-Websites gestatten„

3. Dann braucht man eine SharePoint PowerShell-Verbindung:

# Prüfen obd as SharePoint Modul installiert ist
Get-Module -Name Microsoft.Online.SharePoint.PowerShell -ListAvailable

# Wenn nicht, SharePoint Modul installieren ("Als Admin")
Install-Module -Name Microsoft.Online.SharePoint.PowerShell

# Wenn doch, Update machen (sicher ist sicher)
Update-Module -Name Microsoft.Online.SharePoint.PowerShell

# Mit der SPO-Site Verbinden 
Connect-SPOService -Url https://SITENAME-admin.sharepoint.com

4. In dieser verbundenen Shell führt man dann aus:

Set-SPOSite https://SITENAME.sharepoint.com -DenyAddAndCustomizePages 0

Die Änderung dauert dann gerne mal 1-2 Tage, also am besten nicht sofort wieder versuchen sondern eine Weile warten.

Exchange EventID 1006 (MSExchangeDiagnostics) „Event Dispatchers Catching Up“

Veröffentlicht am von — Keine Kommentare ↓

Auf Exchange Servern seit 2010 wird gerne mal dieses Ereignis alle paar Minuten in das Anwendungsprotokoll geschrieben:

The performance counter '\\EXCHANGESERVER\MSExchange Assistants - Per Database(msexchangemailboxassistants-DATABASE)\Quarantined Assistant Count Total' sustained a value of '6.015,00', for the '10' minute(s) interval starting at '10.10.2020 12:00:00'. Threshold breached since '10.10.2020 21:12'. None Trigger Name:AssistantsQuarantinedTrigger. Instance:msexchangemailboxassistants-DATABASE

Oder auch mit etwas längerem Intervall:

The performance counter ‚\\EXCHANGESERVER\MSExchange Assistants – Per Database(msexchangemailboxassistants-DATABASE)\Event Dispatchers Catching Up‘ sustained a value of ‚2.730,00‘, for the ’30‘ minute(s) interval starting at ‚10.10.2020 19:39:00‘. Threshold breached since ‚10.10.2020 20:10‘. None Trigger Name:EventDispatchersCatchupQueueTrigger. Instance:msexchangemailboxassistants-DATABASE

Lösung

Das ist ein Fehler, den es in vielen Setup auch schon unter Exchange 2013 gab (Exchange 2016 hat das genauso). Es gibt für beide einen Workaround um die nervigen Fehler-Einträge loszuwerden.

Im Verzeichnis Microsoft\Exchange\Vxxx\BIN (Powershell: $exinstall\bin) findet sich die Datei Microsoft.Exchange.Diagnostics.Service.exe mit der zugehörigen *.config Datei:

Microsoft.Exchange.Diagnostics.Service.exe.config

Diese „als Admin“ bearbeiten. Darin muss nur ein Trigger auf „false“ geändert werden, und zwar diese Zeile:

<add Name="Microsoft.Exchange.Diagnostics.Service.ExchangeJobs.Triggers.EventDispatchersCatchupQueueTrigger" Assembly="Microsoft.Exchange.Diagnostics.Service.ExchangeJobs.dll" Enabled="True" Role="Mailbox" />

in diese:

<add Name="Microsoft.Exchange.Diagnostics.Service.ExchangeJobs.Triggers.EventDispatchersCatchupQueueTrigger" Assembly="Microsoft.Exchange.Diagnostics.Service.ExchangeJobs.dll" Enabled="False" Role="Mailbox" />

Das ist in der Regel so um die Zeile 1440 herum. Danach startet man den MSExchangeDiagnostics Dienst neu und ist die Meldung los.

sc restart MSExchangeDiagnostics

Das leider Admins – hier die Top 5 aus dem echten Leben

Veröffentlicht am von — Keine Kommentare ↓

Admins, wie wir ja auch sind, möchten ja das Infrastrukturen funktionieren. Wir wollen Benutzern helfen. Wir geben einiges damit „das Netzwerk“ funktioniert. Aber trotzdem gibt es universell bekannte „Sollbruchstellen“ über die wir oft nicht hinweghelfen können.

Das hier ist die Liste der „Top 5“ der ständigen Leiden von Admins. Das seufzen aus dem Nebenbüro oder der Technik auf den Punkt gebracht. Die häufigsten Sprüche die man bei uns hören kann.

  • „Ich hasse Drucker“ (Dauergast in der Top 5 seit 1994)
  • „Ich hasse VoIP“ (Meint Telefonanlagen, Cloudfonie und vor allem das prinzipielle Problem, das menschliche Sprache Echtkommunikation bedeutet, aber TCP/IP [das Intenet] by Design das exakte Gegenteil davon umsetzt. Daher kommt es ständig zu zahlreichen, aber prakisch nie reproduzierbaren oder findbaren Fehlern)
  • „Wer (zum|zur|…) (Hölle|Geier|…) hat das hier gebaut?“ (… und sich DABEI gedacht? Wurde ÜBERAHAUPT dabei gedacht? Aus welchem Jahrtausend ist DAS denn noch?)
  • „Können Sie mal eben“ oder „Wo sie schonmal da sind“. (Die weltweit standartisierte Formulierung für überraschende Admin-Überstunden, absurde IT-Rätsel und von der Meinung her diametral gegenüberstehend zu einem kurzen und/oder planbaren Zeitraum)
  • „Die E-Mail habe ich (nicht|nie|aufkeinenFall|sichernicht) bekommen“ (Das System E-Mail versagt besonders oft bei angekündigten Wartungsarbeiten, Systemumstellungen oder wichtigen Informationen, die zwar nur mittelbar das Tätigkeitsfeld eines Benutzers tangieren aber [angekündigterweise] zu umittelbaren Fehlern oder Ausfällen führen).

Wenn wir etwas offensichtliches vergessen haben, freuen wir uns über einen Kommentar. Ansonsten sind wir jetzt schon gespannt auf 2024. Mal sehen wie viele der Dazergäste sich weiterhin halten 😂