ugg.li Schnelle Hilfe für schnelle Admins
Nicht immer schön, aber effektiv. Schnelle Hilfe für schnelle Admins.
Das Microsoft Windows Server 2012 R2 seit dem 10. Oktober diesen Jahres wirklich am Support-Ende angekommen ist, ist nicht neu. ESU natürlich ausgenommen, die Installationsbasis ist ja immer noch relativ groß.
Neu ist, zumindest für uns, aber die eindringliche „Sicherheitsempfehlung“ im Defender-Portal, das Betriebssystem schlicht zu deinstallieren 😂
Manchmal schlagen Firmware-Updates auf Alletra 5000 Storages (früher Nimble AF und HF) fehl. Die Fehlermeldung dazu lautet im GUI und an der Shell wenig hilfreich:
One of the HPE Nimble Storage services has become unreachable. If this occurred during a failover or planned outage, wait a minute and then refresh the GUI. This may also occur during security certificate update for group or array name changes or management ip and discovery ip changes. Wait a minute and then refresh the GUI. In some cases, you may also need to clear browser cache. If the service does not become reachable in a few minutes, contact HPE Nimble Storage Support.Es sieht so aus, als ob die Boot-Devices auf den aktiven (!) Controllern manchmal eine Zeitüberschreitung veraursachen. Das verursachte dann den Dienstfehler „Storage services has become unreachable“.
Dies kann man in den allermeisten Fällen durch einen Neustart des Controllers beheben – also durch einen einfachen Failover. Normalerweise kann man das im Web-GUI mit dem Button „Make active“ tun, was in diesem Fall aber ebenfalls nicht funktioniert.
Es hilft aber den Failover auf den anderen Controller an der SSH-Shell zu erzwingen:
failover --array <ARRAYNAME> --forceUnd nach wenigen Minuten ist der Failover fertig, der Controller frisch neu gebootet und das Update läuft ohne Probleme durch.
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.
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.
Ich habe soeben herausgefunden, das das sogar an der Kommandozeile vie certutil möglich ist:
certutil -setreg config\setupstatus 0x6001Es 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
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.
root via ssh auf den ESXi Host anmelden/sbin/generate-certificates/sbin/generate_certificates/etc/init.d/hostd restartDas 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 …
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.
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.aspx2. 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.