Mein Server WS-IPM läuft noch mit Windows Server 2012R2. Auf ihm laufen mein IPAM (IP Address Management), eine PRTG-Monitoring-Instanz und ein SYSLOG-Server für meine Firewall-Protokollierung. Im Rahmen meiner Migration auf Windows Server 2019 sollen die Services auf ein modernes Betriebssystem migriert werden.

Die IPAM-Instanz läuft seit 2013 nahezu durch und sammelt verschiedene, IP-basierte Informationen in einer Datenbank. Daraus können forensische Informationen abgeleitet werden. Zusätzlich hatte ich IPAM auch zur IP-Adressverwaltung verwendet. Die Idee war nicht schlecht. Aber mehrere Punkte stören mich:

• der Zugriff ist nur über den Servermanager möglich. Ein echtes Remoting ist sehr umständlich.
• Statische DNS-Einträge werden nicht erkannt. Man muss diese immer manuell einpflegen.
• Das Layout der Bereiche und Ranges ist nicht intuitiv.
• Es gibt außer einem Inplace-Upgrade keinen Migrationspfad für die Datenbank!

In der Folge habe ich den Service seit mehreren Monaten nicht mehr weiter gepflegt. Und wie vor einem Umzug in eine neue Wohnung stellt sich auch vor einer Migration die Frage: Brauche ich das wirklich noch? In meinem Fall lautet die Antwort nein.

So verbleiben nur noch 2 Services: Das PRTG-Monitoring und der SYSLOG-Server. Für beide gibt es ein Side-By-Side-Migrationsszenario. Ich kann also einen neuen Server erstellen und die Dienste übertragen. Da der IPAM nicht mitkommt, kann ich auch einen neuen Servernamen vergeben, der besser zum Anwendungsfall passt: WS-MON (Monitoring).

Zusätzlich werde ich noch einige Scriptaufgaben auf das neue System verschieben, die ich derzeit auf einem anderen Server bereitgestellt habe. Diese fallen in die Kategorie Monitoring und ergänzen das Angebot der Dienste.

Als Betriebssystem empfiehlt der Hersteller von PRTG (Paessler) Windows Server 2019. Leider wird eine Server-Core-Version nicht supportet. Daher installiere ich einen Windows Server 2019 mit Desktop-Experience.

Aktuell läuft die alte VM mit dem Server WS-IPM auf meinem alten WS-HV1 (Hyper-V-Host mit Windows Server 2016). Auf diesem habe ich weder freien RAM noch ausreichend freien Speicher auf der Festplatte. Daher erstelle ich die VM auf meinem neuen WS-HV3. Nach der Migration aller Services wird die VM dann auf den alten Server verschoben. Die VM-Version muss also mit Windows Server 2016 kompatibel sein. Daher erstelle ich die VM mit der PowerShell. Die Windows-Installation hatte ich bereits vor einigen Wochen als Basis-VHDX vorbereitet. Diese kann ich nun einfach reinkopieren:

New-VM -Name 'WS-MON' -Path 'V:\Hyper-V' -Version '8.0' -Generation 2 -SwitchName 'LAN-100' -NoVHD -MemoryStartupBytes 2GB

Set-VM -Name 'WS-MON' -ProcessorCount 4 -DynamicMemory -MemoryMaximumBytes 3GB -MemoryMinimumBytes 1GB

Set-VM -Name 'WS-MON' -AutomaticStartAction Start -AutomaticStartDelay 45

Get-VMIntegrationService -VMName 'WS-MON' | Enable-VMIntegrationService

New-Item -Path 'V:\Hyper-V\WS-MON\Virtual Hard Disks' -ItemType Directory | Out-Null

Copy-Item -Path 'V:\Base\Win2019-1908.vhdx' -Destination 'V:\Hyper-V\WS-MON\Virtual Hard Disks\HDD0-System.vhdx'

Add-VMHardDiskDrive -VMName 'WS-MON' -Path 'V:\Hyper-V\WS-MON\Virtual Hard Disks\HDD0-System.vhdx' -ControllerType SCSI

New-VHD -Path 'V:\Hyper-V\WS-MON\Virtual Hard Disks\HDD1-Monitor.vhdx' -Dynamic -SizeBytes 100GB

Add-VMHardDiskDrive -VMName 'WS-MON' -Path 'V:\Hyper-V\WS-MON\Virtual Hard Disks\HDD1-Monitor.vhdx' -ControllerType SCSI

Start-VM -Name 'WS-MON'

Ein OOBE später kann der Server in die Infrastruktur als WS-MON aufgenommen werden. Eine freie IPv4 habe ich auch herausgefunden: 192.168.100.18/24. Nach dem DomainJoin verschiebe ich noch das Computerkonto im AD in die richtige Organisationseinheit. Somit werden alle Gruppenrichtlinien angewendet:

Im alten WS-IPM hatte ich für die SYSLOG-Installation einfach einen Ordner auf Laufwerk c: erstellt. Dieser wurde im Laufe der Zeit immer größer und die Datensicherung der VM dauerte immer länger. Das soll auf dem neuen Server nicht passieren. Daher erstelle ich für die Protokolldateien ein eigenes Volume auf einer separaten VHDX. Das Volume ist schnell erstellt:

Damit die Logfiles der Monitoring-Partition nicht zu stark anwachsen, konfiguriere ich noch die Datendeduplizierung auf dem neuen Volume. Dazu ist aber auch die Rolle erforderlich:

Nun bekommt der Server noch alle genehmigten Windows Updates. Im WSUS verschiebe ich das Computerobjekt in den richtigen Container:

Nach dem Neustart ist das Basissystem einsatzbereit. Das Monitoring und das Backup konfiguriere ich im Schritt Nacharbeiten.

Von PRTG gibt es eine detaillierte Anleitung zur Migration einer bestehenden PRTG-Installation. Ich verwende derzeit die freie Edition und möchte das auch beibehalten.

Für die Kommunikation mit den Servern von Paessler ist eine Freischaltung in meiner Firewall (PFSense) erforderlich. Ich nehme die neue IPv4 in die Gruppe auf:

Der erste für mich relevante Schritt der Migrationsanleitung lautet „Step 1b: Install PRTG on the Target System“. Ich starte die Installation:

Die Installation läuft fehlerfrei durch.

Im nächsten Schritt „Step 2: Stop Core and Probe Services on Source and Target System“ muss ich alle Services auf beiden PRTG-Maschinen beenden. Das bedeutet also einen Ausfall im Monitoring:

Nun geht es an die Migration der alten Daten. Im Administrations-Tool (das findet man im Startmenü) kann der Datenpfad ausgelesen werden:

Nun kann ich die Daten einfach kopieren. Ich wähle aber auf dem Zielserver WS-MON einen neuen Pfad unter Laufwerk E: aus:

Teile der Konfiguration scheinen in der Registry zu liegen („Step 5: Export Settings of the Old Server and Local Probe from the Windows Registry to a File“). Also exportiere ich diese in eine reg-Datei:

Auf dem neuen Server erstelle ich auf die gleiche Weise noch ein Backup. Danach importiere ich die Einstellungen aus der Exportdatei des alten Servers:

Nun starte ich das PRTG-Administrationstool aus dem Startmenü und kontrolliere die Einstellungen. Der alte Server lief mit HTTPS. Das wurde jetzt übernommen. Aber der Datenpfad ist noch auf c: gerichtet. Das muss ich anpassen:

Vor dem Start exportiere ich noch das Zertifikat auf dem alten Server, da dieses bis 2020 gültig ist. Dieses installiere ich auf dem neuen Server:

Nun starte ich die Services. Das dauert einige Minuten:

Leider kommt diese Fehlermeldung:

Beim 2. Versuch sind die Services dann hochgefahren. Daher ignoriere ich die Meldung.

Es wird Zeit für einen Zugriffstest. Intern verwende ich für den den Service den FQDN prtg.ws.its. Dieser zeigt im DNS aber noch auf den alten Server:

Hier passe ich den Zeiger an auf den FQDN ws-mon.ws.its. Auf meinem Testrechner prüfe ich die Anpassung. Die IP-Adresse wird korrekt aufgelöst. Nur das ICMP-EchoRequest kommt nicht durch die Firewall:

Nun muss ich aber auch den Zugriff auf diese IP für HTTPS in meiner Firewall freischalten. Auch für diesen Servicezugriff habe ich eine Aliasgruppe erstellt. Da ändere ich die IP-Adresse und die Beschreibung vom alten Server (192.168.100.14) in die Daten des neuen Servers (192.168.100.18):

Auch die anderen Ausnahmen übertrage ich auf die neue IPv4. So muss die PRTG-Instanz auch Mails versenden können:

Die PRTG-Website sollte ich jetzt erreichen können. Aber anscheinend wurde mein Zertifikat nicht übernommen:

Ich bestätige die Sicherheitsausnahme und prüfe weiter. Jetzt kommt eine Lizenzierungsmeldung:

Klar. Der ProduktKey ist in der Registry gespeichert. Das System hat jetzt den alten Key installiert. Das erklärt auch das Problem beim Servicestart. Ich trage den neuen Key ein und führe die Aktivierung durch. Jetzt hat es funktioniert:

Das Monitoring läuft wieder an. Und alle meine Einstellungen sind noch vorhanden:

Es wird Zeit für das richtige Zertifikat. Im Webportal wird der Hinweis dazu gezeigt:

Ich lade das Tool herunter und starte es auf dem neuen Server. Mein zuvor manuell importiertes Zertifikat wird schon angezeigt:

Das Tool hat das Zertifikat aktiviert und den Webservice neu gestartet. Und was sagt der Browser dazu?

Auf zum nächsten Test: Funktionieren die Sensoren noch? Ich prüfe einige strichprobenhaft durch. Es sieht gut aus. Man erkennt deutlich die Lücke in der Überwachung:

Ein Sensor bleibt rot. Dieser soll einen meiner WLAN-AccessPoints auslesen:

Dir Ursache ist schnell gefunden: der Sensor verwendet SNMP. Und dafür muss auf dem Zielsystem eine Probe-IP eingetragen sein:

Eine Anpassung später wird der Sensor grün:

Das Monitoring habe ich auch nach extern freigegeben, damit ich Benachrichtigungen auf mein Handy gepusht bekomme. Diese Konfiguration basierte aber bereits auf dem Service-FQDN und muss daher nicht angepasst werden:

PRTG sollte damit erfolgreich umgezogen sein. Auf zum nächsten Service.

Mit SYSLOG biete ich meinen Firewalls einen zentralen Datenspeicher für ihre Logfiles an. Warum ich die Logs aufhebe? Natürlich für nachträgliche forensische Analysen! Diesen Service muss ich unbedingt mitnehmen. Am Liebsten ohne Datenverlust…

Zuerst installiere ich die gleiche Version des SYSLOG-Servers auf WS-MON. Beim Setup wird eine Voraussetzung angezeigt:

Also installiere ich .net-Framework 3.5. Wie in der Vorgängerversion ist das Feature nur auf der Installations-DVD enthalten. Eine Installation kann mit der PowerShell und dem ISO vorgenommen werden:

Nun lässt sich das Setup starten:

Ich benötige die Konfiguration. Diese kann in der alten Konsole exportiert und in der neuen importiert werden:

Auf dem neuen Server geht es ebenso einfach:

Eine kleine Anpassung ist noch erforderlich: Der Protokollpfad soll auf das neue Laufwerk zeigen:

Alle dazugehörigen Dateien kopiere ich auf den neuen Server:

Jetzt sind alle Komponenten einsatzbereit. In meiner PFSense trage ich die IPv4 zum neuen SYSLOG-Server ein:

Und schon geht’s rund. SYSLOG nimmt die Informationen der Firewall auf und speichert sie wie gewünscht auf der neuen Partition in je eine Textdatei pro Tag:

Auf dem alten Server kommen nun keine Datenpakete mehr an. Für die Datenmigration der bereits gesammelten Logfiles beende ich den alten SYSLOG-Service:

Als nächstes kopiere ich alle bisherigen Logfiles auf den neuen Server. Auf dem alten hatte ich nur die NTFS-Kompression zum Platzsparen aktiv. Auf dem Neuen wird das die Data-Deduplication übernehmen:

Nach wenigen Minuten hat die Deduplication (manuell gestartet) ganze Arbeit geleistet:

Zu dem SYSLOG-Service gehört noch ein ScriptTask von mir. Dieser wertet die Protokolle aus und schickt mir bei Bedarf Warnungen per Mail. Der Task ist einfach exportierbar:

Die XML-Datei importiere ich auf WS-MON:

Mein Script Snort-Monitor soll die gesammelten Logfiles untersuchen. Dazu muss es aber auch von dem neuen Pfad erfahren. Die Konfiguration passe ich in einer Variablen im Script selber an:

Ich starte das Script über den Task. Es dauert nicht lange bis zum nächsten Alarm. Damit ist auch diese Funktion getestet:

Weil ich gerade an den Aufgaben dran bin importiere ich auch die Aufgabe für meine Systemstate-Datensicherung. Mit dieser kann ich das System via BareMetalRecovery zuverlässig wiederherstellen. Das Script für die Sicherung muss unter einem gMSA-Account laufen. Diesen kann ich von meinem DomainController konfigurieren:

Damit sind alle Funktionen außer IPAM auf den neuen Server übertragen.

Zwei weitere Scripte, die ich für Auswertungen verwende, liegen noch auf einem anderen Server. Diese sind aber besser auf dem neuen WS-MON aufgehoben. Daher exportiere ich zunächst die dazugehörigen, geplanten Aufgaben auf dem aktuellen Server WS-RDS1:

Danach kopiere ich die Scriptdateien auf WS-MON:

Zuletzt importiere ich die Scriptaufgaben:

Der ausführende Account ist bei beiden Aufgaben ein spezieller Group Managed Service Account (gMSA). Von diesem kennt nur der DomainController das Passwort. Da die Aufgabenkonsole das Importieren ohne Passwort nicht erlaubt ändere ich den Account temporär:

Der Account admin-setup hat gar nicht die erforderlichen Rechte. Er ist aber auch nur ein Dummy, bis ich den richtigen Account mit meinem gMSA-Tool vom DomainController aus konfiguriere:

Und nun passt es auch in der Aufgabenverwaltung:

Beide Scripte benötigen das Feature RSAT-AD-PowerShell. Dieses installiere ich nach:

Dann noch ein kleiner Testlauf, ob alles passt. Dazu starte ich beide Aufgaben und warte auf die üblichen Mails. Die erste Mail kommt nach wenigen Minuten:

Und auch das andere Script arbeitet wie erwartet und sendet mir eine Mail. Fein. Auf dem alten Server WS-RDS1 deaktiviere ich die beiden Aufgaben. Ich möchte ja keine doppelten Mails haben:

Den alten Server WS-IPM schalte ich einfach aus. IPAM hatte einige GPOs im ActiveDirectory erstellt. Diese kann ich einfach löschen:

Im AD lösche ich das Computerkonto. In ein paar Tagen entferne ich auch die VM aus meinem alten Hyper-V-Host und verschiebe die neue VM zur Lastverteilung dorthin.

Meine Datensicherung basiert auf 2 Plattformen, damit unterschiedliche Anforderungen erfüllt werden. Eine Plattform ist meine SystemState-Sicherung. Diese basiert auf das Windows-Backup-Feature und wird von einem zentralen Script befeuert. Alle Server rufen dieses Script über eine geplante Aufgabe auf. In einer zentralen Konfigurationsdatei kann ich dann die Sicherungseinstellungen definieren. Das Script rendert daraus individuelle wbadmin-commands und die Server sichern ihren SystemState im Rotationsverfahren auf ein Netzlaufwerk.

In der Datensicherungskonfiguration (eine kleine Textdatei) tausche ich den Eintrag des alten Servers gegen den neuen aus:

Damit ist das Betriebssystem und die Installation sicher. Bisher genügte dies, denn alle Logfiles lagen ja auf Laufwerk C:. Jetzt verwende ich aber eine zusätzliche Partition für die Protokolle. Diese möchte ich mit meiner zweiten Plattform sichern: dem Data Protection Manager (DPM). Diesen verwende ich bevorzugt für Nutzdaten.

DPM benötigt einen lokal installierten Agent. Diesen kann ich über eine selber erstellte Freigabe herunterladen und installieren:

Nach dem Setup definiere ich den DPM-Server und stelle eine Verbindung zwischen beiden mit der DPM-Konsole her:

Die Sicherung selber definiere ich über eine neue Schutzgruppe. In einer Schutzgruppe werden Quelle, Ziel, Aufbewahrungsdauer, Sicherungszeiten, … erfasst:

Ich lasse die initiale Sicherung direkt starten:

So sind auch meine Logfiles vor einem Datenverlust geschützt.

Na das hat doch mal super funktioniert. Ein weiterer Server mit seinen Services läuft auf Windows Server 2019! Dazu habe ich Funktionen eines anderen Servers auf eine geeignetere Plattform verschoben. Und der IPAM war sehr einfach. Denn den gibt es nun nicht mehr.

Stay tuned!

Ach ja: Wie üblich gibt es hier diesen Beitrag auch als PDF.