Ein gemeinnütziger Träger mit rund 160 Benutzern – davon bis zu 120 gleichzeitig angemeldet – arbeitet seit Jahren auf einer Terminalserver-Farm mit Windows Server 2019. Die Farm läuft stabil, aber das Betriebssystem nähert sich dem Support-Ende, die gewachsene Struktur ist schwer wartbar, und einige Design-Entscheidungen von damals würde heute niemand mehr so treffen. Zeit für einen Neuaufbau statt eines In-Place-Upgrades.
Die Ausgangslage
Die Bestandsfarm besteht aus getrennten Rollen-Servern (Connection Broker, Gateway, Web Access) und vier Session Hosts, verteilt auf zwei Sammlungen: ein allgemeiner Pool für alle Mitarbeiter und ein separater Pool nur für die Buchhaltung mit Finanzsoftware. Die Profile liegen bereits in FSLogix-Containern auf einem DFS-Namespace – ein Punkt, der den Umstieg erheblich vereinfacht.
Eine Bestandsaufnahme vor dem Neubau lohnt sich immer. In diesem Fall förderte sie unter anderem zutage: über 130 Gruppenrichtlinien, von denen ein Drittel nirgends mehr verknüpft war, uneinheitliche Software-Stände auf den Hosts und eine Sammlung, deren ursprünglicher Zweck (Smartcard-basiertes Banking) längst nicht mehr der Realität entsprach – die Buchhaltung arbeitete inzwischen mit Sicherheitsdateien statt Chipkarten.
Die wichtigsten Entscheidungen
Eine Sammlung statt zwei. Die historische Trennung in zwei Pools verursachte doppelten Pflegeaufwand bei minimalem Sicherheitsgewinn. In der neuen Farm gibt es eine Sammlung; der Zugriff auf die Finanzsoftware wird über AppLocker-Regeln und NTFS-Berechtigungen auf die Buchhaltungsgruppe beschränkt. Gleiche Wirkung, halber Betriebsaufwand.
Kein Weg nach draußen. Die alte Farm war über ein Remotedesktop-Gateway aus dem Internet erreichbar. Die neue Farm wird ausschließlich über VPN publiziert. Damit entfällt eine ganze Angriffsfläche – und die Zertifikate kommen von der internen CA statt von einem öffentlichen Anbieter.
Frische Profile statt Migration. Alle Benutzer starten auf der neuen Farm mit neu erzeugten FSLogix-Containern. Das klingt nach Zumutung, ist aber die einzige Gelegenheit, jahrelang gewachsenen Profilballast loszuwerden. Mit sauberer Kommunikation im Vorfeld ist der Aufwand für die Benutzer überschaubar.
Vorlagen-Prinzip beim Rollout. Ein Session Host dient als reine Vorlage, wird vollständig konfiguriert, per Sysprep generalisiert und dann für die produktiven Hosts geklont. Jeder Host ist damit identisch – kein „auf Host 3 fehlt Programm X“.
Namenskonventionen von Anfang an. Neue Gruppenrichtlinien folgen einem klaren Schema (getrennt nach Computer- und Benutzerrichtlinien, benannt nach Rolle), statt das gewachsene Bestandsschema fortzuschreiben. Die alte GPO-Landschaft bleibt unangetastet, bis die Altfarm abgeschaltet wird.
Was man daraus mitnehmen kann
Ein Farm-Neubau ist die beste Gelegenheit, Altlasten zu hinterfragen. Nicht jede Struktur, die seit Jahren existiert, hat noch einen Grund – und wer nur die alte Umgebung auf neuen Servern nachbaut, verschenkt den größten Teil des Projektwerts. Die Faustregel: Erst inventarisieren, dann jede Bestandsentscheidung einmal aktiv bestätigen oder verwerfen, dann bauen.
Sie betreiben selbst eine in die Jahre gekommene Terminalserver-Umgebung? Sprechen Sie mich an.
