Serie „Migration zu Windows Server 2025“ – Migration eines Druck- und Scan-Servers

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 Beitrag zeige ich euch, wie ich Druck-Server von Windows Server 2019 auf Windows Server 2025 migriere.

Planung

IST-Situation

Ich habe einen Netzwerkdrucker, den ich über einen Windows Print-Server anspreche. Eigentlich ist das nicht notwendig. Aber der Druckserver stellt auch eine SMB-Freigabe ohne SMB3-Encryption bereit, die das Druckgerät als Scan-2-SMB-Ziel verwendet. Meine beiden File-Server sind mit SMB3-Encryption abgesichert und daher funktionierte das Scannen nicht. Daher muss ich den Server migrieren.

Der Drucker wird manuell auf den Clients bei Bedarf eingebunden.

SOLL-Situation

Ich benötige einen neuen Druck- und Scan-Server. Der Druckertreiber soll auf die neuste Version aktualisiert werden.

Migrationsszenario

Ich habe keine Verfügbarkeitsansprüche an das Drucken oder Scannen. Der Service kann also auch einmal eine Stunde nicht verfügbar sein.

Mit einem Verfügbarkeitsanspruch würde ich hier eine Side-By-Side-Migration vornehmen und einen neuen Druck-Serverneben dem alten aufbauen. Danach müsste nur auf allen Clients der Druckereintrag ausgetauscht werden. In meinem Fall genügt aber auch ein Wipe & Load, bei dem ich den Namen und die IP-Adresse mitnehmen kann: der neue Druck-Server kann weitestgehend vorbereitet werden und in der Migrationsphase wird der alte durch den neuen Server ersetzt.

In der produktiven Welt wird in diesem Fall eher auf Side-By-Side zurückgegriffen werden. Daher wähle ich für meine Migration dieses Szenario.

Vorbereitung

Berechtigungen

Ich benötige mehrere Berechtigungen für den Aufbau des neuen Servers:

• Rechte im Hyper-V zur Anlage der VM
• Rechte im Tier-1 im Scope „Standard“ – da wird der neue Printserver aufgenommen
• Rechte im File-Service, da die Scan-2-SMB-Freigabe im DFS-Namespace veröffentlich wird.
• Rechte zum Ausführen vom Drucker-Setup

Die Rechte konfiguriere ich an meine Tier-1-Kennung mit meiner PowerShell-PAM-GUI:

Review des alten Servers

Der aktuelle Druck-Server ist WS-PRINT1 mit der IPv4 192.168.100.14. Folgende Windows Features sind installiert:

Es sind keine zusätzlichen Anwendungen installiert:

Es ist ein einzelner Netzwerk-Drucker in der Drucker-Verwaltungskonsole sichtbar. Dieser wird über einen DNS-Namen angesprochen:

Er ist als Drucker-1 freigegeben und im Active Directory registriert:

Der Druckertreiber ist ein PCL-6:

Er ist ewig alt. Hier braucht es mal ein Update…

Bei mir darf jeder drucken. Die SID in der ACL sagt mir aktuell nichts:

Für das Scannen gibt es eine SMB-Freigabe. Diese zielt auf eine 2. Partition mit einer kleinen Verzeichnisstruktur. Die Berechtigungsgruppen sehen alle korrekt aus:

Es gibt keine besonderen, geplanten Aufgaben. Alle Tasks in der Konsole gehören entweder zu Windows oder sie kommen von meinen Richtlinien:

Mehr gibt es hier nicht zu finden.

Aufbau des neuen Servers

Der neue Server benötigt einen anderen Namen und eine freie IPv4-Adresse. Da ich keinen weiteren Print-Server plane werde ich den neuen Server einfach WS-PRINT nennen. Eine freie IP finde ich in meiner Netbox. Da sind alle meine Netz-Prefixe eingepflegt:

Die 192.168.100.23/24 ist in meinem Server-LAN noch frei:

Nun kann ich die neue VM auf dem gleichen Hyper-V-Server erstellen. Ich nutze wie beim letzten Server ein PowerShell-Script für die Anlage der VM. Dieses erzeugt den Ordner der VM auf meiner GoldDisk #2 in der Partition X, kopiert meine Basefile mit dem Betriebssystem dort rein und erstellt daraus eine neue VM. Diese wird abschließend noch etwas modifiziert:

$VMName = "WS-PRINT"
$VMPath = "X:\Hyper-V\PROD"

New-Item -Path "$VMPath\$VMName\Virtual Hard Disks" -ItemType "Directory"

Copy-Item `
        -Path "V:\Base\win2025-2501.vhdx" `
        -Destination "$VMPath\$VMName\Virtual Hard Disks\HDD0-System.vhdx"

$NewVM = New-VM `
        -Name               "$VMName" `
        -MemoryStartupBytes 2GB `
        -SwitchName         "VLANs" `
        -Path               "$VMPath" `
        -Generation         2 `
        -VHDPath            "$VMPath\$VMName\Virtual Hard Disks\HDD0-System.vhdx"

$NewVM | Set-VM `
        -ProcessorCount 4 `
        -MemoryMinimumBytes 1GB `
        -MemoryMaximumBytes 3GB `
        -DynamicMemory `
        -AutomaticStartAction "Start" `
        -AutomaticStartDelay  30 `
        -AutomaticStopAction  "ShutDown"

$NewVM |
    Get-VMIntegrationService | 
        Enable-VMIntegrationService

Danach schalte ich die neue VM ein und beende den OOBE-Assistenten. Den neuen Server versehe ich mit der IP-Konfiguration, dem Namen und nehme ihn abschließend mit meiner Tier-3-Kennung in das Active Directory als Member auf. Vor dem Neustart verschiebe ich das neue AD-Computerkonto in die richtige Organisationseinheit. Damit wird der neue Server ein Tier-1-Standardserver und erhält die passenden Gruppenrichtlinien. Zusätzlich trage ich hier auch gleich die Beschreibung mit ein:

In meinem Jumpserver erstelle ich ein neues Verbindungsobjekt für den Server. Dann kann ich gleich per RDP darauf zugreifen:

Konfiguration des Druck-Services

Ich könnte den einen Drucker ohne Aufwand von Hand anlegen. In größeren Umgebungen werden hier aber vielleicht hunderte Drucker vorhanden sein. Da geht es leichter, die Konfigurationen auf dem alten Druckserver in eine Datei zu exportieren, die dann auf dem neuen Server importiert wird:

Es gibt keine Auswahlmöglichkeiten und der Vorgang ist damit sehr einfach:

Die Datei exportiere ich in mein Service-Verzeichnis auf meinem Fileserver:

Beim Speichern des WSD-Druckeranschlusses gab es eine Fehlermeldung. Das Ergebnis kann ich mir mit einem Klick in der Ereignisanzeige ansehen. Der betroffene Druckeranschluss wird von mir nicht benötigt und er wurde vom Assistenten übersprungen. Damit sollte das so passen:

Nun wechsle ich auf den neuen Druck-Server. Hier installiere ich zuerst das Windows Feature „Print-Server“ im Server-Manager:

Die Optionen lasse ich unverändert, denn auf dem alten Druck-Server war es nicht anders installiert:

Dann starte ich die Drucker-Verwaltungskonsole und importiere die Migrationsdatei:

Noch ist der Server nicht einsatzbereit, daher verzichte ich auf eine AD-Integration der Drucker:

Beim Import der Druckertreiber werden aber einige Fehler angezeigt:

TroubleShooting

Auch diese Fehler sind im Detail in der Ereignisanzeige zu finden:

Offenbar stört sich der Import-Assistent an der nicht erfolgreich angelegten Export-Datei auf dem alten Server. Stop! Mir fällt gerade der rote Pfeil an dem neuen Druck-Server in der Druckerverwaltungskonsole auf! Der Spooler-Service ist nicht gestartet!! In der Services-Konsole kann ich das bestätigen:

Die Ursache ist sehr schnell gefunden: Es ist eine Gruppenrichtlinie! Seit PrintNightmare deaktiviere ich den Spooler auf allen Systemen mit einer Standardrichtlinie. Dazu gibt es eine weitere Richtlinie für die Ausnahmen. Und hier muss ich den neuen Server aufnehmen:

Ein gpupdate und ein Neustart der Druckverwaltungskonsole später ist der rote Pfeil verschwunden:

Also probiere ich erneut einen Import der Migrationsdatei. Jetzt sieht es besser aus:

Bis zum Abschluss hat es aber mehrere Minuten gedauert. Fehler wurden nun keine mehr gemeldet:

Der Drucker-1 und die gesamte Konfiguration wird angezeigt. Der überzählige PDF-Drucker wird schnell entfernt:

Ich sende eine Testseite an den Drucker. Diese kommt wie erwartet an:

Konfiguration der Scan-Freigabe

Für das Scan-Target lege ich im Hyper-V eine zusätzliche Festplatte an der VM des Servers an, denn ich trenne gerne das Betriebssystem von den Nutzdaten. Die neue VHDX bekommt dynamische 15GB Speicher:

Danach nehme ich die Disk im Server-Manager online, initialisiere sie mit GPT und erstelle eine neue Partition, die dann noch mit NTFS formatiert wird:

Die gesamte Verzeichnisstruktur mit den gescannten Dokumenten und den ACL kopiere ich mit einem Einzeiler auf die neue Partition:

Nun fehlt nur noch die SMB-Freigabe. Diese erstelle ich einfach in der GUI:

Monitoring konfigurieren

Mein PRTG-Monitoring braucht eine Script-Integration auf dem neuen Print-Server. Diese ist schnell erledigt:

Nun kann ich im PRTG das neue Serverobjekt anlegen:

Für jeden Server nutze ich 2 selbst erstellte Sensoren, die im Hintergrund von der PowerShell-Implementierung von gerade eben ihre Daten beziehen:

Ich erstelle diese beiden Sensoren:

Kurz darauf werden die Daten im PRTG angezeigt. Der Base-Sensor steht auf Fehler, weil es noch keine Datensicherung des Servers gegeben hat:

Dafür laufen alle erforderlichen Dienste:

Konfiguration der Datensicherung

Dann wird es Zeit für die Datensicherung. Hier verwende ich eine Scriptlösung mit Windows Server Backup, die über eine geplante Aufgabe von einem Group Managed Service Account (gMSA) gestartet wird. Zuerst importiere ich die Aufgabe aus einer XML-Datei:

Dann melde ich mich an meinem Domain Controller als Tier-3-Admin an, den ich zuvor temporär mit Rechten im Tier-0 und im Tier-1 ausgestattet habe. Hier starte ich mein gMSA-Admin-Script und weise den gMSA der Aufgabe zu. Dafür delegiere ich das Recht zum Passwort-Abruf des gMSA-Kontos an das neue Computerkonto:

Jetzt setze ich den Account in der geplanten Aufgabe ein:

Danach melde ich mich als Tier-3-Admin vom DC ab und bereite meine Tier-0-Kennung für die Anpassung im Backupsystem vor:

Die Sicherungsaufgabe ruft ein Script mit einer Konfigurationsdatei auf meinem Backupserver auf. Hier muss ich für den neuen Server einen passenden Eintrag hinterlegen. Dafür ändere ich den bisherigen Eintrag des alten WS-PRINT1 ab. Die Sicherung wird 60 Minuten nach dem Aufgabenstart an den Wochentagen 2,4 und 6 ausgeführt und es werden 3 Versionen aufbewahrt. Gesichert wird C: in die Freigabe \\ws-dpm.ws.its\bmr-dpm$ in den Unterordner „Standard“:

Das schaut dann so aus:

Den alten Sicherungsordner WS-PRINT1 benenne ich in WS-PRINT um. Damit altern die Sicherungen vom bisherigen Druck-Server innerhalb der nächsten Woche raus.

Nun installiere ich noch das Windows Feature „Windows Server Backup“. Den verlangten Neustart spare ich mir hier, denn bei dem nächsten Schritt ist der eh fällig.

Später nach dem Neustart habe ich die erste Sicherung manuell gestartet. Dafür habe ich eine Verknüpfung auf jedem Desktop mit einer GPO angelegt. Diese startet den Sicherungstask, zeigt das GUI-Fenster an und startet eine PowerShell als Log-Viewer:

Updatekonfiguration

Durch die Gruppenrichtlinie wurde der neue Server angewiesen, sich bei meinem WSUS zu melden. Ich finde ihn wie erwartet im Containier „nicht zugewiesene Computer“. Er bekommt nun seine Gruppen zugewiesen. Damit steuere ich auch den Patchday:

Lokal auf dem Server kontrolliere ich den Updatestand. Er hat in der Nacht die neusten Updates eingespielt und wartet noch auf einen Neustart. Den führe ich aus:

Kontrolle der SIEM-Integration

Meine Gruppenrichtlinie sollte zwischenzeitlich den Elastic Agent registriert haben. Das kontrolliere ich in meinem Elastic SIEM. Das sieht gut aus:

Freischaltung in der internen Firewall

Ich nutze eine PFSense für die interne Netzwerksegmentierung. Verbindungen von den Clients zu den Servern müssen explizit erlaubt sein. Hier setze ich auf Alias-Definitionen. In der aktuellen ist nur der alte Druck-Server dabei:

Hier trage ich nun die Daten für den neuen Server ein. Für ein Side-By-Side-Szenario könnten auch beide Server gemeinsam eingetragen werden. Dann hat man mehr Zeit für die Umstellung 😉

Da der Druck-Server auch als Scan-Target SMB anbietet, muss ich auch hier die Ausnahme anpassen:

Damit sind alle Vorarbeiten abgeschlossen.

Migration

Maintenance aktivieren

Jetzt würde ich das Wartungsfenster für den Austausch abwarten. Der Austausch des Servers muss in meinem Fall in 2 Schritten erfolgen. Den alten Server nehme ich im PRTG in die Wartung:

Austausch des Scanner-Targets

Durch die Änderung des Servernamens muss ich in meinem HP-Druck-Kopier-Scanner die Scan-2-SMB-Targets anpassen. Diese sind hier als QuickSets organisiert:

Ich muss nur den Pfad anpassen:

Beim Testen kommt aber eine Fehlermeldung:

Die Ursache ist schnell im Eventlog Security gefunden. Dort suche ich nach dem Benutzernamen „service-Print1“ und finde einen Anmeldefehler:

Sucht man nach dem Fehlercode 0x80090302, dann findet man Hinweise auf eine NTLM-Blockierung. Ich habe NTLM vor vielen Jahren (2018) in meinem AD deaktiviert (WS IT-Solutions · Blog: Deaktivierung von NTLM). Das ging aber nicht ohne eine Ausnahmeliste. Da mein Drucker nicht zum AD gehört, kann er auch kein Kerberos nutzen und ist für das Scannen zu SMB auf NTLMv2 angewiesen. Also trage ich den Namen des neuen Druck-Servers in die Ausnahmeliste im Domain Controller ein:

Dann aktualisiere ich mit einem gpupdate meine beiden Domain Controller, denn diese lehnen die Anmeldung des Druckers ab. Jetzt ist auch der Testlauf erfolgreich:

Nun stelle ich auch die anderen Scan-Ziele um. Der letzte Schritt ist das Umbiegen im DFS-Namespace, denn ich greife als Benutzer nicht direkt auf das Share des Druck-Servers zu:

Den Link passe ich auf meinem File-Server in der DFS-Namespace-Konsole an. Hier lege ich ein neues Folder-Target an:

Eine Replikation benötige ich nicht:

Jetzt kann ich den Pfad zum alten Server löschen. Eine Deaktivierung wäre für einen Rollback ebenfalls denkbar:

Damit ist die Umstellung des Scanners abgeschlossen.

Testphase des Scanner-Targets

Ich lege eine Seite im Scanner ein und starte den Scan. Die pdf-Datei wird korrekt gespeichert:

Und auch im Explorer auf dem Client wird sie angezeigt:

Maintenance beenden

Die Wartung kann ich nun beenden, denn alle Scanjobs laufen nun über den neuen Druck-Server. Das Drucken kann ich Side-By-Side umstellen, denn beide Server können den Drucker erreichen.

Austausch der Druckerverbindungen

Den Austausch erledige ich bei mir mit einem Anmeldescript und einer Gruppenrichtlinie. Der Code ist denkbar einfach. Auch die Konfiguration des Standarddruckers wird dabei übertragen. Ein manueller Lauf zeigt danach den neuen Drucker an:

Das ist der Code:

$OldPrinter = '\\ws-print1\Drucker-1'
$NewPrinter = '\\ws-print\Drucker-1'

if (Get-Printer | Where-Object { $_.Name -eq $OldPrinter }) {
    $DefaultPrinter = Get-CimInstance -class "win32_printer" | Where-Object {$_.Default -eq $true}
    
    Remove-Printer -Name $OldPrinter
    Add-Printer -ConnectionName $NewPrinter
    
    if ($DefaultPrinter.name -eq $OldPrinter) {
        $Printer = Get-CimInstance -Class "Win32_Printer" | Where-Object{ $_.name -eq $NewPrinter }
        Invoke-CimMethod -InputObject $Printer -MethodName SetDefaultPrinter 
    }
}

Das ist meine neue GPO:

Testlauf der Druckerverbindung

Ich sende einen Druckauftrag an meinen Standarddrucker. Dieser kommt wenige Sekunden später aus dem Drucker raus. Das Drucken funktioniert.

Nacharbeiten

Bereinigungen

Die Abschlussarbeiten sind übersichtlich und schnell erledigt:

• Im PRTG lösche ich den alten Eintrag zum WS-PRINT1
• Da der alte Druck-Server nun nicht mehr benötigt wird, schalte ich ihn aus. Die VM und deren VHDX-Files lösche ich im Hyper-V-Server.
• Im Elastic lösche ich ebenfalls den Agent.
• In der PFSense sind bereits alle Einträge korrigiert.
• In meiner Netbox entferne ich den alten Eintrag.
• Nach einigen Tagen kann ich auch meine Migrations-GPO entfernen.
• Das alte Computerkonto lösche ich im Active Directory.
• Ebenso nehme ich den Eintrag aus der Gruppenrichtlinie für den Spooler-Start raus.
• In meinem gMSA-Admin-Script entferne ich den alten Server aus der Liste der Computer für den gMSA der Datensicherung.
• Im WSUS entferne ich den alten Computer-Eintrag.

Abschluss

Damit habe ich einen weiteren Server auf Windows Server 2025 migriert. Man erkennt deutlich, dass das Szenario Side-By-Side mehr Vorarbeiten erlaubt, die für produktive Systeme sehr wichtig sein können (Backup, Monitoring, …). Aber durch die Koexistenz des alten und neuen Servers sind auch viele zusätzliche Arbeiten und Bereinigungen erforderlich. Hat man genug Zeit für eine Service-Downtime, dann ist Wipe&Load mit Übernahme der IP-Adresse und des Namens deutlich einfacher.

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

Stay tuned.