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

Überprüfung der Active Directory-Replikation und -Integrität mit „Repadmin“

Repadmin ist das zentrale Diagnosetool für die Active Directory-Replikation. Das Tool ist auf allen Domänencontrollern vorinstalliert oder via Remote Server Administration Tools (RSAT) nachinstallierbar.

Das hier sind häufig genutzten Parameter, damit man die nicht immer wieder einzeln googlen muss. Es gibt auch einen ganzen KB-Abschnitt darüber, aber die wichtigen Parameter gibt es dort auch nicht auf einer Seite.

Die wichtigsten Parameter von repadmin

  • repadmin /replsummary Zusammenfassung der ein- und ausgehenden Verbindungen (auch fehlgeschlagene)
  • repadmin /showrepl Status zwischen Domänencontrollern, pro Namenskontext
  • repadmin /queue Listet die eingehende Replikationswarteschlange auf
  • repadmin /syncall DOMAINCONTROLLER dc=EXAMPLE,dc=COM Synchronisiert den angegebenen Domänencontroller sofort
  • repadmin /syncall /AdeP Änderungen nach außen an alle Domänencontroller weiterleiten
    • A = Alle Partitionen
    • e = Enterprise (Meint: Cross Site Replikation eingeschlossen)
    • D = Server nach DN auflösen
    • P = Push (-Replikation)
  • repadmin /replicate Zeigt die eingehende Replikationswarteschlange an

Windows Update Fehler 0x80070643 bei KB5034441 oder KB5034439

Problem

Die aktuellen Windows Updates KB5034441 (Clients) und KB5034439 (Server) verursachen gerne mal den Fehler 0x80070643.

Der Fehlercode bedeutet im wesentlichen „zu wenig Speicherplatz“. Das bezieht sich in diesem Fall allerdings nicht auf die Platte bzw. Windows-Partition, sondern die Wiederherstellungspartition („WinRE“).

Auf Clients ist diese in der Regel zu klein wenn der Fehler auftritt, auf Servern kann es auch schonmal vorkommen, dass die Partition gar nicht existiert.

Sofern ganz sicher keine Recoveryumgebung benötigt wird, kann das Update im Prinzip einfach ignoriert werden (Zitat aus den MS KB-Artikeln: „HINWEIS: Wenn Ihr ausgeführter PC nicht über eine WinRE-Wiederherstellungspartition verfügt, benötigen Sie dieses Update nicht.“)

Sollte (sicherheitshalber) doch eine Recoverypartition erwünscht sein, hier die Kurzanleitung zum (Neu-)Erstellen und Vergrößern:

Lösung:

zunächst eine Konsole als Admin starten.

WinRE Status prüfen und ggfs. deaktivieren (wenn vorher „Enabled“):

C:\> reagentc /info
C:\> reagentc /disable

Ggfs. vorhandene Recoverypartition löschen und Windows-Partition verkleinern:

C:> diskpart
DISKPART> list disk
DISKPART> sel disk <OS Disk Nummer, i.d.R. 0>
DISKPART> list part
DISKPART> sel part <OS Partitionsnummer, i.d.R. 3>
DISKPART> shrink desired=250 minimum=250
DISKPART> sel part <WinRE Partitionsnummer, i.d.R. 4>
DISKPART> del part override

Neue Recoverypartition erstellen:

DISKPART> list disk
DISKPART> sel disk <OS Disk Nummer, i.d.R. 0>

# nur für GPT-Disks:
DISKPART> create partition primary id=de94bba4-06d1-4d40-a16a-bfd50179d6ac
DISKPART> gpt attributes =0x8000000000000001

# nur für MBR-Disks:
DISKPART> create partition primary id=27

# Partition formatieren:
DISKPART> format quick fs=ntfs label=”Windows RE tools”
DISKPART> exit

Sofern es vorher bereits eine Recoverypartition gab, kann diese nun einfach wieder aktiviert werden:

C:> reagentc /enable

Sofern es vorher keine aktive Recoverypartition gab, schlägt das fehl. Dann fehlt vermutlich auch das RE-Image in C:\Windows\System32\Recovery\WinRe.wim (reagentc /enable bzw. /disable verschiebt das Image zwischen der Partition und der Datei hin und her)

Dann muss man sich diese vom Installationsmedium (ISO) holen. Das geht am einfachsten per 7zip, das kann die ISO und die darin enthaltenen install.wim Files einfach öffnen. Aus dem Pfad \sources\install.wim\1\Windows\System32\Recovery\ im ISO kann die WinRe.wim dann nach C:\Windows\System32\Recovery\ kopiert werden.

Danach sollte sich das WinRE mittels reagentc /enable dann korrekt aktivieren lassen (WinRE.wim wird wieder aus System32\Recovery\ auf die Recoverypartition verschoben)

Danach sollte sich das Update dann problemlos installieren lassen.

PowerShell: Liste alle Dienste auf allen Servern auf, die als Benutzer (oder Administrator) starten

Bei einer Kennwortänderung in kleinen Domänen, also wenn das „Administrator“ Kennwort nach laaaanger Laufzeit geändert wird, müssen einige Dienste, die im Laufe der Zeit als solcher eingerichtet wurden, ebenfalls geändert werden. In den meisten Fällen ist im Laufe der Zeit auch die Anzahl der Server gewachsen.

Wie kommt der faule Administrator als nun an eine Liste der Server, wo die Anmeldedaten von Diensten angepasst werden müssen?

Lösung

Unter der Voraussetzung, dass PowerShell Remoting eingerichtet und funktionsfähig ist, hilft dieses kleine aber feine Script.

Zuerst wird eine Liste aller Server aus dem AD geholt und dann via WMIC eine gefilterte Liste der Dienste geholt, die nicht als „LocalSystem“ oder „NT Author%“ gestartet werden. Letzteres ist ein Trick, um sowohl „NT Authorität“ als auch „NT Authority“ auf Deutsch und Englisch zu erwischen.

Import-Module ActiveDirectory

$Servers = ( (Get-ADComputer -Filter 'operatingsystem -like "*server*" -and enabled -eq "true"').dnshostname )
$ServiceName =  @{ Name = 'ServiceName'; Expression = {$_.Name}}
$ServiceDisplayname = @{ Name = 'Service DisplayName';  Expression = {$_.Caption}}

foreach ($server in $servers) {
    Invoke-Command $server -ScriptBlock {
        Get-CimInstance -Class Win32_Service -filter "StartName != 'LocalSystem' AND NOT StartName LIKE 'NT Author%' " } | 
            Select-Object SystemName, $ServiceName, $ServiceDisplayname, StartMode, StartName, State | format-table -autosize
}