SSD und HDD Modellnummern und Seriennummern unter Windows auslesen

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

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

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 …

Veeam für Office 365 sichert nicht mehr richtig „Failed to get folder properties. Not allowed to access Non IPM folder“

Seit einer Weile™️ schlagen Veeam für Office 365 Sichrungsjobs fehl. Nach und nach sind immer mehr Unternehmen betroffen. Ein Job sichert dann praktisch keine Mailbox mehr, oder zumindest erweckt die Meldung den Anschein.

Die neue Fehlermeldung lautet:

Failed to get folder properties. Not allowed to access Non IPM folder

Lösung

Die Ursache: Microsoft rollt changes aus. Es geht um die Neuigkeit „Microsoft will restrict access via EWS to Teams message data starting on January 31, 2023„.

Das bedeutet natürlich nicht, das alle Tenants der ganzen Welt das „Update“ gleichzeitig bekommen. Mein Fall für heute ist auch genau von heute. Also vom 9.4.2024 (!). Wenn sich also jemand wundert, wie lange Updates manchmal zum ausrollen brauchen 😎

Der Fix ist zum Glück einfach

  1. Veeam-Config Datei %programdata%\Veeam\backup365\config.xml „Als Administrator“ bearbeiten
  2. In der Sektion <Archiver> diesen Tag hinzufügen:
    <Proxy SkipTeamsMessagesDataFolders="True" />
  3. Veeam Dienste neu starten, zum Beispiel an der PowerShell:
Restart-Service -Name "Veeam.Archiver.Service"

SQL Server Datenbank-Kompatibilitäts-Level upgraden (Aktualisieren des Datenbank-Kompatibilitätsgrads)

Wenn Microsoft eine neue Version des SQL Servers released, bleiben neue Funktionen in der Regel der neuesten „Kompatibilitätsstufe“ vorbehalten. Beispielsweise ist die „Parameter Sensitive Plan Optimization (PSPO)“ aus dem SQL Server 2022 nur in Datenbanken verfügbar, die unter der Kompatibilitätsstufe („Level“) SQL Server 2022 ausgeführt werden.

Datenbanken behalten ihr Kompatibilitätslevel auch bei einem Upgrade des Servers, jeder SQL kann Datenbanken jeder älteren Version ausführen. Grundsätzlich eine gute Idee. Das bedeutet aber, ein [DB]Admin muss je nach Software ab und zu die Datenbanken aktualisieren. Manchmal wegen der neuen Features, manchmal weil Software das benötigt.

SQL Server Kompatibilitätsgrad / Kompatibilitätslevel

Wichtig: Die Versionsnummern für SQL Server und Azure SQL-Datenbank sind nicht so richtig miteinander vergleichbar. Azure SQL basiert zwar auf dem gleichen Code, aber die SQL Engine in Azure ist „immer“ die neueste. Zum Beispiel ist v12 von Azure SQL „neuer“ als v15 von einem lokalen SQL Server.

80SQL Server 2000
90SQL Server 2005
100SQL Server 2008
110SQL Server 2012
120SQL Server 2014
130SQL Server 2016
140SQL Server 2017
150SQL Server 2019 (+Azure SQL)
160SQL Server 2022

Lösung

Es gibt zwei Möglichkeiten, das Upgrade für eine Datenbank auszuführen.

Microsoft SQL Management Studio

Im SMSS geht das in der grafischen Oberfläche sehr komfortabel:

  1. SMSS „Als Administrator“ starten
  2. Mit dem SQL Server verbinden
  3. Rechte MT auf die Datenbank > Eigenschaften
  4. Links in der Liste auf „Optionen“ > Rechts das „Kompatibilitäts Level“ auswählen

SQL Kommando

An einer SQL Shell, einer beliebigen – solange mit DBO-Rechten verbunden, kann man das mit diesem Einzeiler erledigen:

ALTER DATABASE <DB-NAME>
SET COMPATIBILITY_LEVEL = 150

Windows CA: SAN (oder DN) fehlt in Zertifikaten aus dem Template „Webserver“

Google unterstützt in Chrome seit Version 58 (von 2017!) Feld „Common Name“ in SSL/TLS-Zertifikaten nicht mehr. Gleiche gilt für Firefox seit Version 98 und mittlerweile auch alle anderen Browser.

Firefox und Chrome melden: SSL_ERROR_BAD_CERT_DOMAIN

Die Windows Zertifizierungsstelle (Windows CA) mit dem Template „Webserver“ füllt dieses Feld allerdings nicht automatisch. Daher muss man bei Zertifikatsanforderungen das Attribut manuell hinzufügen und die CA dafür konfiguriert haben.

Warum? Das CN-Feld wird verwendet, um den Domänennamen anzuzeigen, für den das Zertifikat gültig ist. Der reine CN als Identifikationsmerkmal wurde allerdings vor fast zwei Jahrzehnten per RFC abgeschafft, das Feld ist viel zu unflexibel (keine Wildcards, keine Multidomains …). Die heute genutzten Felder sind „DN=“ und „SAN=“ (DNS-Domain) – warum die noch immer nicht in Microsoft’s Standard-Templates enthalten sind ist ein Geheimnis.

Lösung

Man muss der CA zuerst beibringen, den „Subject Alternate Name“ (SAN) überhaupt nachträglich zur Anforderung hinzuzufügen. An einer Administrator-CMD-Shell geht das so:

certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc
net start certsvc

Ab dann kann (=muss) man den Anforderungen den SAN als „san:“ Attribute bei der Beantragung mitgeben.

Lösung (Web Zertifizierungsstelle)

Im Feld „Zusätzliche Attribute“ können einer oder mehrere SANs mit „&“ getrennt angegeben werden:

san:dns=SERVERNAME.EXAMPLE.COM&dns=SERVERNAME2.EXAMPLE.COM

Lösung (Kommandozeile)

An der Kommandozeile sollte im Auftrag (*.inf) das Attribut einfach bereits unter „[RequestAttributes]“ enthalten sein:

[RequestAttributes]
CertificateTemplate = Webserver
SAN="dns=SERVERNAME.EXAMPLE.COM"

Dann kann man das Zertifikat ganz normale Requeste werden:

certreq -submit -attrib "CertificateTemplate:Webserver" CSRDATEINAME.req ZERTIFIKATAUSGABEDATEI.cer