Serie „Migration zu Windows Server 2025“ – Migration der PKI

Dieser Eintrag gehört zu meiner Serie „Migration zu Windows Server 2025„. In dieser möchte ich euch die Aktualisierung meiner Server-Infrastruktur von 2019 auf 2025 dokumentieren. Es ist eine lebendige Welt von Systemen, die mir wichtig sind. Mit realen Anforderungen und Bedingungen werde ich alle Arbeitsschritte erläutern.

In diesem Abschnitt migriere ich meinen ersten Produktionsserver WS-CA1, der meine PKI bereitstellt.

Zielsetzung

IST-Situation

Meine PKI hatte ich im März 2021 auf Windows Server 2019 migriert. Die Arbeitsschritte für die Migration auf Windows Server 2025 werden nicht anders sein. Die PKI wird von einem Windows Server WS-CA1 bereitgestellt. Es handelt sich dabei um eine Active Directory integrierte Root-Zertifizierungsstelle.

Verschiedene Zertifikatvorlagen werden von meinen Systemen bei der automatischen Ausstellung von Zertifikaten genutzt. Die Zertifikate werden dabei nicht traditionell, sondern über CEP-CES ausgestellt (Certificate Enrollment Policy Service & Certificate Enrollment Web Service). Diese beiden zusätzlichen Services auf meiner Zertifizierungsstelle ermöglichen die Anfrage und die Ausstellung von Zertifikaten über HTTPS statt RPC-DCOM, was eine Platzierung der Zertifizierungsstelle hinter einer Firewall deutlich vereinfacht.

Der Server läuft im Tier-0. Das Zertifizierungsstellezertifikat läuft am 12.12.2025 ab und muss daher mit ausgetauscht werden.

SOLL-Situation

Ich habe verschiedene Anforderungen für die Migration definiert:

• Das Betriebssystem soll auf Windows Server 2025 umgestellt werden.
• CEP-CES soll weiter genutzt werden.
• Der Online Responder soll weiter genutzt werden.
• Das Sperrsystem soll weiter über das Internet erreichbar sein.
• Sperrlisten sollen nur über http erreichbar sein.
• Eine Bereinigung der bisher ausgestellten Zertifikate ist durchaus sinnvoll.
• Das Zertifizierungsstellen-Zertifikat muss erneuert werden.
• Der Server soll wieder mit einer grafischen Oberfläche bereitgestellt werden.

So sieht mein Service aus. Man erkennt auch die vorgelagerte Firewall – meine PFSense:

Migrationsszenario

Durch die Besonderheit des erforderlichen neuen Zertifizierungsstellen-Zertifikats muss die Migration über mehrere Schritte geführt werden:

• Cleanup: Zuerst werde ich die Bereinigung und die Erneuerung des Zertifizierungsstellen-Zertifikats auf der alten Windows CA durchführen.
• Migration: Dann werde ich mittels Wipe & Load den Service auf das neue Betriebssystem verschieben. So kann ich den Namen des Betriebssystems weiterführen und die IPv4-Adresse wiederverwenden und erspare mir verschiedene Anpassungen in Richtlinien und Firewall-Regeln.

Generell kann man an dieser Stelle auch über eine parallele, neue Zertifizierungsstelle sinnieren. Diese könnte frisch aufgesetzt und nach Wunsch konfiguriert zuerst ausgiebig getestet werden. Anschließend könnte man alle bisher ausgestellten und noch gültigen Zertifikate auf allen Systemen mit der neuen CA erneut ausstellen. Wenn keine Zertifikate der alten CA mehr in Verwendung sind, dann könnte diese einfach abgeschaltet werden. Durch das bereits ablaufende Zertifizierungsstellen-Zertifikat ist die Restlaufzeit einiger ausgestellter Zertifikate bereits reduziert (Eine Zertifizierungsstelle kann keine Zertifikate über ihre eigene Gültigkeit hinaus signieren). Die vielen Windows Systeme könnten bequem durch Gruppenrichtlinien automatisiert migriert werden. Aber in meinem Fall sind auch fast alle Nicht-Windows-Systeme mit Zertifikaten versorgt: Das sind z.B. alle Netzwerkgeräte. Und da würde mir eine Umstellung der Zertifikate mehr Arbeit bereiten als eine Bereinigung und Migration der alten CA, denn meine Zertifikate haben eine Laufzeit von einem Jahr – und so lange läuft mein Zertifizierungsstellenzertifikat noch.

Daher bleibe ich beim Szenario Wipe & Load.

Vorbereitung

Berechtigungen

Für den Zugriff auf meine PKI bzw. den Review sind mehrere Gruppenmitgliedschaften erforderlich. Diese delegiere ich mit meinem PAM-Script für 24 Stunden an meine Tier-0-Admin-Kennung:

Die Gruppe „GG-Admin-PKI“ ist in eine Gruppe „LD-Admin-PKI“ verschachtelt, welcher ich die administrativen Rechte in meiner PKI delegiert habe.

Review

Nun verbinde ich mich mit dem Server WS-CA1 und starte die Bestandsaufnahme. Zunächst sammle ich relevante Daten vom Server:

• Name: WS-CA1
• IPv4: 192.168.100.6/24
• Rollen und Features:
  
  
• Installierte Anwendungen: ElasticAgent, LAPS, sysmon

Ein Blick in die Konsole PKIVIEW.msc zeigt meine einfache, übersichtliche PKI. Diese besteht aus einer Online Enterprise RootCA. Und dieser geht es gut:

In der Konsole der Zertifizierungsstelle kontrolliere ich das Zertifizierungsstellenzertifikat. Abgesehen von der kurzen Restlaufzeit ist es passend konfiguriert:

Die Sperrlistenkonfiguration sieht auch wunschgemäß auf. Diese hatte ich ja bei der letzten Migration angepasst. LDAP wird nicht verwendet. Der Pfad c:\admin… in den Verteilungspunkten ist das Backend-Verzeichnis des lokalen Webservers. Hier legt die CA die Sperrliste ab. Über den mittleren Eintrag wird dann der Zugriff über http definiert:

Auch die AIA passen noch. Hier sieht man auch die URL des Online Responders:

Ich nutze keine Schlüsselarchivierung:

Der Service PKI wurde von mir mit einem vollständigen RBAC-Modell ausgestattet. Domain Admins oder Enterprise Admins haben hier keine Rechte mehr:

Ich nutze auch RegistrierungsAgents. Diese sind entsprechend konfiguriert:

Die auszustellenden Vorlagen sind übersichtlich und gepflegt. Diese kann ich einfach übernehmen:

Es gibt eine lokale, geplante Aufgabe für die Datensicherung der PKI-Datenbank. Dies nutze ich aber nur für das Abschneiden der Transaktionsprotokolle. Der Server wird mit Windows Server Backup gesichert. Alle anderen Aufgaben stammen von Gruppenrichtlinien. Die Aufgabe exportiere ich in ein Migrationsverzeichnis:

Im Dateisystem befinden sich alle relevanten Daten unter c:\admin:

Der Online Responder verarbeitet die Anfragen aus der Sperrlistendatei:

Das sollte für die Migration genügen.

Aufbau einer neuen VM

Dank meines Golden-Images ist die neue VM schnell aufgebaut. Die alte VM erhält vorher noch einen neuen Namen. Bei der neuen VM gibt es nicht viel zu beachten:

Die VHDX des Golden-Images kopiere ich in das Verzeichnis für die virtuellen Festplatten und benenne die Datei passend um:

Danach kann ich sie an die VM anfügen und weitere Optionen anpassen:

Danach gehe ich erneut in den Einstellungsdialog und ändere die Bootreihenfolge:

Jetzt schalte ich die VM ein und warte die Vorbereitung des Out-of-Box-Experience-Modus ab:

Das geht recht schnell. Ich vergebe noch ein initiales Adminkennwort und dann kann ich mich am Server anmelden:

Das neue Betriebssystem soll den gleichen Namen und die gleiche IP wie das alte erhalten. Also trenne das Netzwerk, benenne ich den Server um und gebe die IP-Konfiguration ein:

Jetzt füge ich noch die erforderlichen Windows Rollen und Features dazu. Das spart mir nachher beim Wipe&Load etwas Zeit:

Migration

Maintenance der PKI aktivieren

Ich muss verhindern, dass nach dem Backup der Zertifizierungsstelle noch Zertifikate ausgestellt werden. Das lässt sich einfach über das Entfernen der Zertifikatvorlagen erledigen. In meiner kleinen Umgebung könnte ich auf diesen Schritt verzichten. Aber in größeren Umgebungen wäre es fatal, wenn die wiederhergestellte Datenbank nicht alle Zertifikate enthält – besonders, wenn auch Private Key Archiving aktiv ist. Die Zertifikatvorlagen entferne ich über die Zertifizierungsstellenkonsole:

Ab jetzt kann meine PKI keine Zertifikate mehr signieren. Ich muss mich ab jetzt beeilen, um Störungen zu vermeiden!

Zusätzlich setze ich meine Überwachung im PRTG-Monitoring in die Wartung:

Backup der PKI

Das Migrationsszenario Wipe&Load setzt eine Datensicherung des Altsystems voraus, die auf dem Neusystem wiederhergestellt wird. In meiner alten CA erzeuge ich lokal die Sicherungsdateien, die ich in meinem Verzeichnis C:\Admin sammle. Ich beginne mit der Datenbank und den Private Keys:

Die alten Root-CA-Zertifikate sind eigentlich schon abgelaufen. Aber ich nehme sie dennoch immer gerne mit auf den nächsten Server. Daher exportiere ich sie manuell in das Verzeichnis:

Zum Abschluss kopiere ich alle Verzeichnisse in mein Migrationsverzeichnis auf dem Fileserver. Hier liegen auch schon die exportierten Aufgaben aus der Aufgabenplanung. Das Verzeichnis C:\Admin\PKI ist gleichzeitig mein Webserver-Verzeichnis. Hier liegen alle Sperrlisten, CA-Zertifikate und die Webseite zur Anzeige mit drin:

Jetzt sichere ich noch die Registry der Zertifizierungsstelle in mein Migrationsverzeichnis:

Zuletzt hole ich mir noch das aktuelle LAPS-Passwort des alten Servers ab. Sollte ich den reaktivieren müssen, dann brauche ich dieses für die lokale Anmeldung:

Austausch des Servers

Jetzt schalte ich den alten Server aus und nehme die Netzwerkkarte des neuen Server in das Servernetz:

Den neuen Server nehme ich nun in das Active Directory auf. Dafür benötige ich meine T3-Kennung, die für 15 Minuten als Domain Admin arbeiten kann. Meine T0-Kennung hat diese Rechte aktuell auch, sie ist aber auch Mitglied der Protected Users. Und diese Gruppenmitgliedschaft verhindert einen Domain Join:

Ein kleines Problem hält mich vom erforderlichen Domain Join ab: Die Rolle Zertifizierungsdienste ist installiert… Da hatte ich nicht dran gedacht! Also entferne ich diese Rolle und führe dann die Aufnahme in meine Domain durch:

Installation der Zertifizierungsstelle

Zuerst stelle ich mein Verzeichnis C:\Admin aus dem Migrationsverzeichnis vom Fileserver wieder her. Die Rolle der Zertifizierungsstelle installiere ich erneut. Dann starte ich den Post-Deployment-Wizzard:

Ich wähle die Rolle „Zertifizierungsstelle“ aus. Die Vergangenheit hat gezeigt, dass je Post-Deployment immer nur eine Funktion konfiguriert werden sollte:

Die weiteren Optionen entsprechen meiner bisherigen Konfiguration:

Bei der Nachfrage zum Private Key nehme ich die Wiederherstellungsoption:

Mit dem Importieren-Schalter kann ich die 3 vorherigen Zertifikate laden:

Dann wähle ich das letzte Zertifikat aus und klicke auf weiter:

Den Pfad zur Zertifikatdatenbank belasse ich beim Standard. Damit beende ich den Assistenten:

Ich kontrolliere nun schnell noch, ob sich ggf. die Standardzertifikatvorlagen in die auszustellenden Vorlagen verirrt haben. Das ist bei mir aber nicht der Fall. Wäre es so gewesen, dann hätte ich sie schnell entfernt:

Nun importiere ich noch die Registry-Einstellungen in meinen neuen Server und starte dann den CA-Service neu:

Meine Konfiguration ist damit wieder am Start:

Jetzt nehme ich noch die Zertifikatvorlagen in die auszustellenden Vorlagen wieder mit auf:

Spannenderweise werden mir meine Vorlagen nicht im Dialog angezeigt…

Mit dem Problem möchte ich mich aber aktuell nicht aufhalten. Daher trage ich die Namen der Zertifikatvorlagen in der ADSI-Konsole im Active Directory direkt ein:

Eine Aktualisierung in der Zertifizierungsstellenkonsole später sind diese dann auch hier sichtbar:

Auf eine Testausstellung eines Zertifikates muss ich aktuell noch verzichten, denn ich nutze ja einen CEPCES, der mit einer Gruppenrichtlinie konfiguriert wurde. Und dieser ist noch nicht einsatzbereit.

Ausstellen des neuen Zertifizierungsstellenzertifikates

Vorher kümmere ich mich aber noch fix um das neue Zertifizierungsstellen-Zertifikat. Das aktuelle läuft ja in weniger als einem Jahr ab. Dieser Prozess ist recht einfach mit der Konsole zu erledigen:

Das neue Zertifizierungsstellenzertifikat ist nun einsatzbereit:

Ich kopiere den Public Key als der-kodierte und als BASE64-kodierte Datei in mein Verzeichnis C:\Admin\PKI, dass vom Webserver verwendet werden soll. Damit wird dann der Zugriffspunkt für die Authority Information Access bedient:

Dabei muss die Datei richtig benannt werden!

Der installierte Webserver muss nun dieses Verzeichnis veröffentlichen. Erst dann sind die Sperrlistendateien und die Root-CA-Zertifikate abrufbar. Dafür starte ich den IIS-Manager. Hier lege ich ein virtuelles Verzeichnis in der Root an:

Auf die gleiche Weise erzeuge ich ein virtuelles Verzeichnis crl, dass auf das gleiche Dateiverzeichnis verweist. Ich hatte bei meiner ersten Implementierung zwei unterschiedliche Verzeichnisse verwendet. Im Nachhinein betrachtet eigentlich unnötig.

Ein Aufruf der Website ist zwar nicht möglich, aber die Dateien darin können heruntergeladen werden. Das genügt für die Sperrprüfung.

Bereitstellung des Online Responders

Mit dem Webserver steht alles bereit, dass der Online Responder wieder aktiviert werden kann. Ich beginne mit dem Post-Deployment im Server Manager:

Es sind keine weiteren Fragen offen und die Funktion wird aktiviert:

Der Online Responder muss aber noch wissen, für welche Zertifizierungsstellen er Antworten ausstellen soll. Das wird in der Online Responder Verwaltungskonsole konfiguriert:

Hier lege ich eine Sperrlistenkonfiguration an:

Jede Sperrliste benötigt einen eigenen Namen:

Die Bindung an die CA kann mit der AD-Integration einfach erfolgen:

Auch das vorhandene Template für das Signaturzertifikat wird automatisch gefunden:

Der Sperrlistenanbieter sollte manuell nachgebessert werden, damit die Sperrliste häufiger aktualisiert wird:

Damit werden nun Anfragen für Zertifikate beantwortet, die mit dem neuen Zertifizierungsstellenzertifikat signiert wurden. Ich habe aber immer noch Zertifikate im Umlauf, die auf dem vorherigen Root-CA-Zertifikat beruhen. Für diese benötige ich eine weitere Sperrlistenkonfiguration. Damit ich beide auseinanderhalten kann, nehme ich das Jahr der Zertifikatsausstellung in den Namen mit auf:

Da das alte Zertifikat ab dem Ausstellen des neuen nicht mehr genutzt wird, kann ich es nur über den lokalen Zertifikatsspeicher finden:

Das Signaturzertifikat wähle ich wie vorher aus:

Und auch den Sperrlistenanbieter passe ich an. Hier erkennt man auch, dass diese Sperrlistenkonfiguration die Sperrliste vom Zertifikat (2) verwendet:

Jetzt habe ich 2 Sperrkonfigurationen online:

Und die Signaturzertifikate wurden auch schon ausgestellt:

Bereitstellung von CEPCES

Weiter geht es mit CEP und CES. Hier hatte ich auch schon einige Beiträge zu geschrieben. Diese beiden Komponenten können in einem Vorgang im Server Manager aktiviert werden:

Die Bindung des Certificate Enrollment Services ist immer 1:1 mit einer Issuing-CA. Sind beide Rollen auf dem gleichen Server verwendet, dann kann nur die lokale CA verwendet werden:

Ich möchte CES in der Vollautomatik verwenden und belasse es dafür bei der integrierten Anmeldung:

Weil alles auf einem Server läuft nutze ich die einfachere Option des integrierten Anwendungspools:

Auch für den CEP ist eine Anmeldung erforderlich. Diese muss gleich zu der vom CES sein:

CEP und CES laufen über https. Dieses Protokoll benötigt ein Webserverzertifikat. Das habe ich aktuell noch nicht:

Dieses Zertifikat erstelle ich mir fix mit meinem PowerShell-Script „Certificate Request Tool„, das ihr hier herunterladen könnt

Das Ergebnis installiere ich in den Zertifikatspeicher des Servers:

Zurück im Server Manager nutze ich den Schalter „Aktualisieren“ und wähle das neue Zertifikat aus:

Jetzt kann der Assistent beendet werden:

Auch hier kommt eine interessante Warnung als Ergebnis. Diese muss ich mir später auch noch ansehen:

Im IIS-Manager muss nun noch eine Kleinigkeit nachgetragen werden, da diese vom Setup nicht erledigt wird. Hier starte ich für die Anwendung CEP die Anwendungseinstellungen:

Im Feld „FriendlyName“ muss ein Anzeigename eingetragen werden. Dieser ist später in den Konsolen der Clients sichtbar:

CEPCES sollte damit funktionieren.

Testphase

Nach so vielen Konfigurationen kann ich nun alles zusammen prüfen. Ich beginne mit der manuellen Ausstellung eines Zertifikates auf einem anderen System:

Hier wird nun der FriendlyName des CEP angezeigt:

Der CEP analysiert, welche Vorlagen für den Anfrager zur Verfügung stehen. Ich nehme mal eine Computerzertifikatvorlage:

Nun wird mir ein (erwarteter) Fehler angezeigt:

Die Ursache ist eigentlich klar: Ich habe ein neues Zertifizierungsstellenzertifikat ausgestellt, das als ROOT-Zertifikat keinen Signierer hat. Dieses Zertifikat muss also im Speucher der „Vertauenswürdigen Stammzertifizierungsstellen“ stehen, bevor ihm vertraut wird. Und das ist hier noch nicht der Fall. Da stehen nur die alten Zertifikate drin:

Das liegt daran, dass Zertifikate von den Computern nur alle 8 Stunden von den Domain Controllern gezogen werden. Ein gpupdate /force überschreibt diesen Timer und sorgt für eine direkte Synchronisierung. Das ist einer der wenigen Fälle, bei denen der Force-Parameter sinnvoll ist:

Nun kommt der zweite Fehler dazu. Da habe ich beim Ausstellen des Webserver-Zertifikates nicht dran gedacht: Der FQDN muss mit in den Subject Alternative Names stehen:

Also stelle ich ein neues Webserver-Zertifikat mit diesem Parameter aus:

Das Zertifikat binde ich im IIS-Manager ein. Abschließend entferne ich das defekte Zertifikat

Jetzt klappt auch die Zertifikatanforderung:

Nun teste ich die Sperrkonfiguration. Dafür lasse ich mir ein altes und das neue Zertifikat auf meinem Testsystem als cer-Datei ohne Private Key raus:

Die Prüfungen führe ich mit certutil aus. Für beide Zertifikate prüfe ich, ob das Zertifizierungsstellenzertifikat heruntergeladen werden kann (AIA), ob die dazugehörige Sperrliste geladen werden kann (CDP) und ob der Online Responder korrekt funktioniert:

Hier erkennt man auch schön, dass die neue Sperrliste (3) verwendet wird:

Und auch OCSP funktioniert:

Die Tests sind auch für das alte Zertifikat erfolgreich. Hier erkennt man, dass für alte Zertifikate weiter die alte Sperrliste verwendet wird. Daher eben auch die beiden unterschiedlichen Online Responder Konfigurationen 😉

Zum Abschluss teste ich noch mit PKIVIEW.msc. Auch hier ist alles fein:

Meine PKI ist also wieder funktionstüchtig! Damit wird es Zeit für die Nacharbeiten.

Nacharbeiten

Konfiguration der Datensicherung

Der neue Server soll vollständig mit Windows Server Backup gesichert werden. Das übernimmt bei mir eine Sicherungsaufgabe, die ein Script auf meinem Backupserver aufruft. Diese Aufgabe muss ich importieren:

Die Aufgabe verwendet einem Group Managed Service Account. Dessen Passwort kenne ich nicht. Daher stelle ich die Option „nur ausführe, wenn der Benutzer angemeldet ist“ ein“:

Auf meinem Domain Controller starte ich nun mein Script „gMSA-Admin“ und korrigiere damit die importierte, geplante Aufgabe. Der Vorgang schlägt aber mit einer Fehlermeldung fehl…

Dieser Fehler ergibt keinen Sinn. Verschiedene Tests zeigen, dass Windows Server 2025 offenbar mit meinen gMSA nicht umgehen kann. Ich löse dieses Problem separat. Für jetzt installiere ich nur noch das Windows Feature Windows Server Backup:

Nun fehlt noch die Aufgabe für die Datenbanksicherung. Diese importiere ich ebenfalls in die Aufgabenplanung:

Monitoring

Mein PRTG nutzt lokal abgelegte PowerShell-Scripte auf meinen Servern, die über Just-Enough-Administration angesprochen werden. Damit benötigt der Account im PRTG keine Adminrechte auf den Zielsystemen. Die Scripte dazu und der JEA-Endpunkt müssen einmalig eingerichtet werden. Das übernimmt mein JEA-Setupscript:

Nun beende ich die Maintenance im PRTG. Bis auf das noch nie erfolgte Backup sind alle Werte wieder normal:

Zur Überwachung gehört aber auch die Integration ins Elastic SIEM. Hier prüfe ich, ob der Agent automatisch bereitgestellt wurde und ob er Daten liefert. Das sieht schon mal gut aus:

Und auch die Logs kommen gut rein:

Updatekonfiguration

Durch die Computerobjektübernahme muss ich im WSUS nichts konfigurieren. Das Computerobject hat immer noch seine Update-Gruppen zugewiesen, wird nun aber mit Windows Server 2025 angezeigt:

CRL-Prestaging

Nun fehlt noch eine letzte Sache: das CRL-Prestaging. Wer schon einmal einen CA-Server verloren hat und die Wiederherstellung dabei nicht erfolgreich war, der weiß, dass der Verlust der Sperrlisten massive Probleme in der gesamten Infrastruktur verursachen kann. Denn ohne gültige Sperrlisten können Clients und Server die Zertifikate nicht mehr validieren. Im besten Fall wird das einfach vom Service ignoriert. Im schlimmsten Fall werden die Zertifikate als ungültig abgelehnt!

Damit mir so etwas nicht passiert, lege ich Sperrlisten mit einem Datum in der Zukunft an. Das erledige ich mit meinem PowerShell-Script. Die Parameter passen auf meine 6 Wochen gültigen Sperrlisten, die bereits nach 3 Wochen erneuert werden. Das ergibt 42 Tage Laufzeit:

$PathPrestaged = "C:\Admin\Prestaged"
$PathCRL = "C:\Admin\PKI\WS-ITS-Zertifizierungsstelle-CA1(2).crl"

Get-ChildItem -Path $PathPrestaged -Filter "*.crl" | Remove-Item

1..10 | ForEach-Object {
    $StartDate = (get-date).AddDays($_ * 42) 

    $DateCU   = get-date -date $StartDate -Format 'dd.MM.yyyy'
    $DateFile = get-date -date $StartDate -Format 'yyyy-MM-dd'

    $BaseFile = Split-Path -Path $PathCRL -Leaf

    certutil -f -sign $PathCRL "$PathPrestaged\$DateFile-$BaseFile" $DateCU+42:00
}

Jede Ausstellung muss dabei manuell bestätigt werden:

Und das ist das Ergebnis für beide gültigen Zertifizierungsstellenzertifikate. Diese Dateien liegen auf meinem Fileserver. Fällt meine CA also einmal unwiederbringlich aus, dann nutze ich diese Sperrlisten für die bestehenden Zertifikate und baue mir in Ruhe eine neue Zertifizierungsstelle auf:

Bereinigung im Hyper-V

Die alte VM entferne ich noch im Hyper-V:

Und ebenso die alte Festplattendatei:

Abschluss

Meine erste Migration ist damit abgeschlossen. Eine PKI ist vielleicht nicht immer die beste Wahl für ein solches Vorhaben. Aber bei mir hatte das Zertifizierungsstellenzertifikat nur noch eine vergleichsweise kurze Restlaufzeit. Da hat sich das einfach mal angeboten.

Da es doch einige Probleme und ungewöhnliche Fehlermeldungen gab, bin ich gespannt, wie sich dieser neue Server im Alltag beweisen wird.

Stay tuned.

Die Übersichtsseite zum meinem Migrationsprojekt findet ihr hier: Migration zu Windows Server 2025