Windows Server 2025 als Terminalserver einrichten – Schritt-für-Schritt-Anleitung

Ein Terminalserver ermöglicht mehreren Mitarbeitern, gleichzeitig auf einem zentralen Windows Server zu arbeiten.

Programme und Daten liegen dabei nicht auf jedem einzelnen Arbeitsplatz-PC, sondern werden zentral auf dem Server bereitgestellt.

Ein typisches Szenario:

Notebook / PC

↓

Remote Desktop

↓

Windows Server 2025

↓

Word, Excel, Outlook, ERP, Warenwirtschaft und weitere Anwendungen

Microsoft bezeichnet diese Technik offiziell als:

Remote Desktop Services – RDS

Der eigentliche Terminalserver wird dabei als:

Remote Desktop Session Host – RD Session Host

bezeichnet.

Windows Server 2025 eignet sich damit weiterhin für klassische Terminalserver- beziehungsweise RDS-Umgebungen.

In dieser Anleitung zeigen wir Schritt für Schritt, wie Sie Windows Server 2025 als Terminalserver einrichten, welche RDS-Rollen benötigt werden und was bei Active Directory, RDS-CALs, Microsoft 365, Benutzerprofilen, Sicherheit und externem Zugriff berücksichtigt werden sollte.

Was ist ein Windows Server 2025 Terminalserver?

Bei einem klassischen Arbeitsplatz läuft Windows lokal auf dem PC.

Bei einem Terminalserver läuft der eigentliche Arbeitsplatz dagegen zentral auf einem Server.

Mehrere Benutzer können gleichzeitig eigene Windows-Sitzungen verwenden.

Beispielsweise:

Benutzer A

→ eigene Sitzung

Benutzer B

→ eigene Sitzung

Benutzer C

→ eigene Sitzung

↓

Windows Server 2025

Die Benutzer teilen sich:

• CPU
• Arbeitsspeicher
• Storage
• Betriebssystem
• installierte Anwendungen

Ihre eigentlichen Sitzungen und Benutzerprofile bleiben voneinander getrennt.

Terminalserver oder Remote Desktop Services?

Der Begriff Terminalserver wird in Unternehmen weiterhin sehr häufig verwendet.

Microsoft spricht offiziell von:

Remote Desktop Services

beziehungsweise kurz:

RDS

Die zentrale Rolle lautet:

Remote Desktop Session Host

Für die Suchintention und den normalen Sprachgebrauch verwenden wir in dieser Anleitung trotzdem weiterhin den Begriff Terminalserver.

Wann lohnt sich ein Windows Server 2025 Terminalserver?

Ein Terminalserver ist besonders interessant, wenn mehrere Mitarbeiter dieselben zentralen Anwendungen verwenden.

Beispielsweise:

• Microsoft 365 Apps
• Outlook
• ERP
• Warenwirtschaft
• DATEV-nahe Anwendungen
• Branchensoftware
• Office-Anwendungen
• zentrale Dateiablage
• browserbasierte Anwendungen

Vorteile entstehen insbesondere bei:

• mehreren Standorten
• Homeoffice
• zentraler Administration
• einheitlichen Arbeitsplätzen
• geringer Bandbreite zu zentralen Anwendungen
• älteren Fachanwendungen

Statt zehn PCs einzeln zu pflegen, kann ein großer Teil der Arbeitsumgebung zentral bereitgestellt werden.

Welche RDS-Rollen gibt es bei Windows Server 2025?

Eine vollständige Remote-Desktop-Services-Umgebung kann aus mehreren Rollen bestehen.

RD Session Host

Der Remotedesktop-Sitzungshost stellt die eigentlichen Benutzerdesktops und Anwendungen bereit.

Hier arbeiten die Benutzer.

RD Connection Broker

Der Remotedesktop-Verbindungsbroker verwaltet Sitzungen und verteilt Benutzer auf vorhandene Session Hosts.

Er wird insbesondere bei größeren Umgebungen mit mehreren Terminalservern wichtig.

RD Web Access

RD Web Access stellt veröffentlichte Desktops und RemoteApps über eine Weboberfläche bereit.

RD Gateway

Das RD Gateway ermöglicht abgesicherte RDS-Verbindungen über das Internet, ohne den eigentlichen RDP-Port des Terminalservers direkt öffentlich bereitstellen zu müssen.

RD Licensing

Der RDS-Lizenzserver verwaltet die benötigten Remote Desktop Services CALs.

Braucht ein kleiner Terminalserver alle RDS-Rollen?

Nicht zwingend.

Bei einer kleinen internen Umgebung kann beispielsweise ein einzelner:

RD Session Host

mit:

RD Licensing

ausreichen.

Bei einer größeren beziehungsweise professionell bereitgestellten Umgebung können zusätzlich sinnvoll sein:

• Connection Broker
• RD Gateway
• RD Web Access
• mehrere Session Hosts

Die Architektur sollte vor der Installation festgelegt werden.

Beispiel: Kleiner Terminalserver

Ein Unternehmen besitzt:

• 8 Mitarbeiter
• einen Standort
• Active Directory
• einen Terminalserver
• VPN für Homeoffice

Möglicher Aufbau:

Domain Controller

DC01

↓

Terminalserver

RDS01

↓

8 Benutzer

Der Terminalserver stellt:

• Office
• Outlook
• Fachanwendungen

bereit.

Für einen solchen Aufbau muss nicht zwingend sofort eine komplexe RDS-Farm aufgebaut werden.

Beispiel: Größere RDS-Umgebung

Bei 40 oder 50 Benutzern kann die Architektur anders aussehen.

Beispielsweise:

DC01 / DC02

↓

Connection Broker

↓

RDS01

RDS02

↓

FSLogix Profile

↓

File Server

Zusätzlich:

RD Gateway

für externen Zugriff.

Damit können Benutzer auf mehrere Session Hosts verteilt werden.

Schritt 1: Windows Server 2025 installieren

Zunächst wird Windows Server 2025 installiert.

Für einen Terminalserver wird normalerweise:

Windows Server 2025 Standard

oder bei entsprechenden Virtualisierungsanforderungen:

Windows Server 2025 Datacenter

eingesetzt.

Welche Edition benötigt wird, hängt insbesondere von der gesamten Server- und Virtualisierungsarchitektur ab.

Desktop Experience verwenden

Für einen klassischen Terminalserver mit grafischen Anwendungen wird Windows Server 2025 normalerweise mit:

Desktop Experience

installiert.

Dadurch steht die bekannte grafische Windows-Oberfläche zur Verfügung.

Für einen normalen Office-Terminalserver wäre Server Core in der Regel nicht die praktische Wahl.

Schritt 2: Servernamen vergeben

Der Server sollte einen eindeutigen Namen erhalten.

Beispielsweise:

RDS01

oder:

TS01

Bei mehreren Session Hosts:

RDS01

RDS02

RDS03

Eine einheitliche Namenskonvention erleichtert später:

• DNS
• Monitoring
• Backup
• Gruppenrichtlinien
• Dokumentation
• Fehlersuche

Schritt 3: Feste IP-Adresse konfigurieren

Ein Terminalserver sollte eine dauerhaft bekannte IP-Adresse besitzen.

Beispielsweise:

192.168.20.20

DNS sollte auf die internen Domain Controller zeigen.

Beispielsweise:

Primärer DNS

192.168.20.10

Sekundärer DNS

192.168.20.11

wenn zwei Domain Controller vorhanden sind.

Öffentliche DNS-Server wie:

8.8.8.8

sollten auf einem Domain-Mitglied nicht einfach als primäre DNS-Server eingetragen werden, wenn Active Directory verwendet wird.

Schritt 4: Windows Updates installieren

Vor der Installation der produktiven Rollen sollte Windows Server vollständig aktualisiert werden.

Danach:

• Neustart durchführen
• erneut nach Updates suchen
• Treiber beziehungsweise Virtualisierungstools prüfen

Bei einer virtuellen Maschine sollten außerdem die zur Plattform gehörenden Gastwerkzeuge installiert werden.

Schritt 5: Server in Active Directory aufnehmen

Für eine professionelle RDS-Umgebung sollte der Terminalserver normalerweise Mitglied der Active-Directory-Domain sein.

Beispielsweise:

firma.intern

Danach:

RDS01

↓

Domain Join

↓

Active Directory

Nach dem Domain Join wird der Server neu gestartet.

Terminalserver nicht gleichzeitig als Domain Controller verwenden

Für sehr kleine Testumgebungen mag es technisch möglich erscheinen, möglichst viele Rollen auf einem einzigen Server zu kombinieren.

Für produktive Unternehmensumgebungen würde ich Domain Controller und Terminalserver jedoch trennen.

Besser:

DC01

→ Active Directory / DNS

RDS01

→ Terminalserver

Dadurch bleiben Rollen sauber getrennt.

Schritt 6: RDS-Bereitstellungsart auswählen

Im Server-Manager gibt es bei Remote Desktop Services eine eigene Bereitstellungsoption.

Für eine vollständige RDS-Bereitstellung kann gewählt werden:

Remote Desktop Services installation

Anschließend wird eine sitzungsbasierte Bereitstellung eingerichtet.

Für klassische Terminalserver lautet das Ziel:

Session-based desktop deployment

Damit wird eine Umgebung für mehrere gleichzeitige Benutzersitzungen aufgebaut.

Quick Start oder Standard Deployment?

Für Testumgebungen existieren vereinfachte Bereitstellungswege.

Für produktive Unternehmensumgebungen sollte die Rollenverteilung jedoch bewusst geplant werden.

Das gilt insbesondere dann, wenn später:

• mehrere Session Hosts
• Connection Broker
• RD Gateway
• RD Web Access

eingesetzt werden sollen.

Schritt 7: RD Session Host installieren

Die wichtigste Rolle des Terminalservers lautet:

Remote Desktop Session Host

Sie ermöglicht mehreren Benutzern, gleichzeitig Sitzungen auf dem Server zu verwenden.

Nach Installation der Rolle ist der Server grundsätzlich in der Lage, als RDS Session Host zu arbeiten.

Schritt 8: RD Licensing installieren

Für einen produktiven Terminalserver wird zusätzlich ein:

Remote Desktop Licensing Server

benötigt.

Dieser verwaltet die RDS-CALs.

Die Rolle kann je nach Architektur:

• auf demselben Server
• auf einem separaten Server

installiert werden.

Bei kleineren Umgebungen kann der Lizenzserver beispielsweise auf einem vorhandenen geeigneten Windows Server betrieben werden.

Schritt 9: RDS-Lizenzserver aktivieren

Nach der Installation der Rolle öffnen Sie:

Remote Desktop Licensing Manager

Der Lizenzserver muss anschließend bei Microsoft aktiviert werden.

Erst danach können die gekauften RDS-CALs installiert werden.

Schritt 10: RDS-CALs installieren

Nach Aktivierung des Lizenzservers werden die vorhandenen RDS-CALs eingespielt.

Dabei wird unter anderem festgelegt:

• Produktversion
• Lizenztyp
• Anzahl
• Lizenzprogramm

Für Windows Server 2025 sollte die verwendete CAL-Version zur eingesetzten Serverversion passen.

Windows Server CAL und RDS CAL nicht verwechseln

Das ist ein wichtiger Punkt.

Für RDS-Zugriffe existieren unterschiedliche Lizenzebenen.

Vereinfacht:

Windows Server CAL

für den Zugriff auf Windows-Serverdienste

und zusätzlich:

RDS CAL

für die Nutzung von Remote Desktop Services.

Eine normale Windows Server CAL ersetzt also nicht automatisch die RDS CAL.

Die konkrete Microsoft-Lizenzierung sollte immer anhand des tatsächlichen Szenarios geprüft werden.

RDS User CAL oder Device CAL?

Es gibt zwei grundlegende Lizenzierungsmodelle.

Per User

Die Lizenz wird einem Benutzer zugeordnet.

Das ist häufig sinnvoll, wenn ein Mitarbeiter mehrere Geräte verwendet.

Beispielsweise:

• Büro-PC
• Notebook
• privates Homeoffice-Gerät

Per Device

Die Lizenz wird einem Gerät zugeordnet.

Das kann interessant sein, wenn sich viele wechselnde Benutzer wenige Geräte teilen.

Beispielsweise:

• Schichtbetrieb
• Produktionsarbeitsplätze
• gemeinsame Terminals

Für klassische Büroarbeitsplätze wird häufig Per User verwendet.

Schritt 11: Lizenzierungsmodus festlegen

Der Session Host muss wissen:

• welchen Lizenzserver er verwenden soll
• welcher Lizenzierungsmodus gilt

Also beispielsweise:

Lizenzserver

DC01.firma.intern

Modus

Per User

In einer RDS-Bereitstellung mit Connection Broker kann dies über die Bereitstellung konfiguriert werden.

Bei einem einzelnen Session Host ohne Connection Broker können die entsprechenden Einstellungen beispielsweise über Gruppenrichtlinien festgelegt werden.

RDS-Lizenzdiagnose prüfen

Nach der Einrichtung sollte:

RD Licensing Diagnoser

kontrolliert werden.

Dort sollten keine Fehler mehr angezeigt werden.

Insbesondere prüfen:

• Lizenzserver erreichbar?
• richtige CAL-Version?
• richtiger Lizenzierungsmodus?
• genügend Lizenzen?
• Session Host korrekt konfiguriert?

Schritt 12: RDS-Benutzergruppe erstellen

Nicht jeder Domain-Benutzer sollte automatisch auf den Terminalserver zugreifen dürfen.

Erstellen Sie beispielsweise eine Active-Directory-Gruppe:

GRP-RDS-Benutzer

Darin befinden sich ausschließlich Mitarbeiter, die den Terminalserver verwenden dürfen.

Beispielsweise:

max.mustermann

anna.beispiel

thomas.muster

Diese Gruppe erhält anschließend die erforderlichen RDS-Anmelderechte.

Warum Gruppen statt einzelne Benutzer?

Berechtigungen sollten möglichst über Gruppen verwaltet werden.

Beim Onboarding:

Benutzer zur Gruppe hinzufügen

Beim Offboarding:

Benutzer aus Gruppe entfernen

Das ist übersichtlicher als individuelle Konfigurationen für jeden Mitarbeiter.

Schritt 13: Remotedesktopbenutzer konfigurieren

Benutzer, die sich auf dem Session Host anmelden sollen, benötigen die entsprechenden Remotedesktop-Anmelderechte.

Microsoft weist bei RDS ebenfalls darauf hin, dass Benutzer für die Remoteanmeldung Mitglied der entsprechenden Remotedesktopbenutzergruppe beziehungsweise entsprechend berechtigt sein müssen.

Normale Benutzer benötigen dabei keine lokalen Administratorrechte.

Benutzer niemals zu Administratoren machen

Ein Terminalserver-Benutzer sollte normalerweise:

Standardbenutzer

sein.

Nicht:

lokaler Administrator

Sonst könnte ein Benutzer unter Umständen:

• Software installieren
• Systemkonfiguration verändern
• Dienste beeinflussen
• Sicherheitsfunktionen deaktivieren

Auf einem Multiuser-System wäre das besonders problematisch.

Schritt 14: Sitzungssammlung erstellen

Bei einer vollständigen RDS-Bereitstellung wird anschließend eine:

Session Collection

erstellt.

Die Sammlung enthält die Session Hosts und definiert, welche Benutzer auf die bereitgestellten Desktops beziehungsweise Anwendungen zugreifen dürfen.

Beispielsweise:

Collection Name

Firma-Desktop

Session Host:

RDS01

Benutzergruppe:

GRP-RDS-Benutzer

Bei mehreren Hosts beispielsweise:

RDS01

RDS02

Was ist eine RDS Collection?

Eine Collection bündelt die Ressourcen, die Benutzern bereitgestellt werden.

Dazu können gehören:

• vollständiger Desktop
• RemoteApps

Bei mehreren Session Hosts können diese innerhalb einer Collection gemeinsam bereitgestellt werden.

Schritt 15: Vollständigen Desktop oder RemoteApps bereitstellen

Jetzt muss entschieden werden, was die Benutzer erhalten.

Vollständiger Desktop

Der Benutzer sieht einen kompletten Windows-Desktop.

Dort befinden sich beispielsweise:

• Outlook
• Word
• Excel
• ERP
• Browser
• Netzlaufwerke

RemoteApp

Nur eine bestimmte Anwendung wird veröffentlicht.

Beispielsweise:

ERP.exe

Die Anwendung erscheint auf dem Client nahezu wie eine lokale Anwendung, läuft tatsächlich aber auf dem RDS-Server.

Wann sind RemoteApps sinnvoll?

RemoteApps sind interessant, wenn Benutzer lediglich einzelne zentrale Anwendungen benötigen.

Beispielsweise:

• ERP
• Buchhaltungssoftware
• Warenwirtschaft
• Branchensoftware

Wenn Mitarbeiter dagegen ihren gesamten Arbeitsplatz auf dem Terminalserver verwenden sollen, ist ein vollständiger Desktop meist übersichtlicher.

Schritt 16: Anwendungen installieren

Jetzt werden die benötigten Anwendungen auf dem Session Host installiert.

Beispielsweise:

• Microsoft 365 Apps
• ERP
• PDF-Software
• Browser
• Warenwirtschaft
• Druckersoftware
• Fachanwendungen

Vorher sollte geprüft werden, ob die jeweilige Anwendung für:

Multiuser / RDS / Terminalserver

freigegeben und korrekt lizenziert ist.

Nicht jede normale Desktopsoftware darf oder kann automatisch auf einem Terminalserver eingesetzt werden.

Softwarehersteller vorher prüfen

Besonders bei:

• ERP
• Buchhaltung
• CAD
• Branchenanwendungen
• Datenbanken
• Lizenzservern

sollte vorher geprüft werden:

• Windows Server 2025 unterstützt?
• RDS unterstützt?
• Multiuserfähig?
• separate Terminalserverlizenz erforderlich?
• Datenbank lokal oder separat?
• Benutzerbezogene Lizenzierung?

Das verhindert spätere Überraschungen.

Schritt 17: Microsoft 365 Apps auf Windows Server 2025 installieren

Microsoft 365 Apps können in unterstützten RDS-Szenarien auf einem Session Host bereitgestellt werden.

Entscheidend ist jedoch die richtige Lizenzierung.

Für einen gemeinsam verwendeten RDS-Server benötigt Microsoft 365 Apps die:

Shared Computer Activation

beziehungsweise:

Aktivierung gemeinsam genutzter Computer

Die Installation sollte dafür über das:

Office Deployment Tool

mit entsprechender Konfiguration erfolgen.

Shared Computer Activation aktivieren

In der Office-Konfiguration wird unter anderem gesetzt:

SharedComputerLicensing = 1

Dadurch wird Microsoft 365 Apps für den Multiuser-Betrieb auf einem gemeinsam verwendeten Computer konfiguriert.

Jeder Benutzer meldet sich anschließend mit seinem eigenen Microsoft-365-Konto an.

Welche Microsoft-365-Lizenz funktioniert auf RDS?

Das ist besonders wichtig.

Nicht jede Lizenz, die Desktop-Office enthält, berechtigt automatisch zur Shared Computer Activation.

Microsoft nennt aktuell unter anderem:

Microsoft 365 Business Premium

als geeignete Business-Lizenz mit Shared Computer Activation.

Außerdem unterstützen entsprechende Microsoft-365-/Office-365-Pläne mit:

Microsoft 365 Apps for Enterprise

diesen Einsatz.

Ein Benutzer benötigt jeweils eine passende Lizenz.

Eine normale Microsoft 365 Business Standard-Lizenz sollte deshalb nicht einfach ungeprüft für einen klassischen RDS-Server eingeplant werden.

Business Premium und Terminalserver

Für kleine und mittelständische Unternehmen kann die Kombination:

Windows Server 2025 RDS

Microsoft 365 Business Premium

interessant sein.

Damit können Benutzer unter anderem Microsoft 365 Apps auf dem gemeinsamen RDS-Server mit Shared Computer Activation nutzen, sofern die übrigen Lizenzbedingungen erfüllt sind.

Schritt 18: Outlook auf dem Terminalserver konfigurieren

Outlook gehört häufig zu den wichtigsten Anwendungen eines Terminalservers.

Bei mehreren Benutzern entstehen jedoch zusätzliche Anforderungen an:

• Benutzerprofile
• OST-Dateien
• Suchindex
• Microsoft-365-Anmeldung
• Performance

Deshalb sollte die Profilstrategie bereits vor der produktiven Einführung geplant werden.

Schritt 19: Benutzerprofile planen

Windows erstellt für jeden Benutzer ein eigenes Profil.

Beispielsweise:

C:\Users\max.mustermann

Bei einem einzigen Terminalserver können lokale Profile grundsätzlich funktionieren.

Sobald jedoch mehrere Session Hosts verwendet werden, entsteht ein Problem:

Benutzer A meldet sich heute auf:

RDS01

an.

Morgen landet derselbe Benutzer auf:

RDS02.

Ohne zentrale Profilverwaltung hätte er dort ein anderes Profil.

FSLogix für RDS verwenden

Eine moderne Möglichkeit zur zentralen Profilverwaltung ist:

FSLogix Profile Container

Das Benutzerprofil wird dabei in einer:

VHD beziehungsweise VHDX

gespeichert.

Beispielsweise:

\\FILE01\FSLogix\max.mustermann\Profile.vhdx

Bei der Anmeldung wird dieser Container eingebunden.

Der Benutzer erhält dadurch sein gewohntes Profil unabhängig vom verwendeten Session Host.

Was speichert FSLogix?

Ein Profile Container umfasst das Windows-Benutzerprofil und kann damit unter anderem Daten und Einstellungen enthalten für:

• Outlook
• Microsoft 365
• Teams
• Browser
• AppData
• Benutzereinstellungen

Microsoft empfiehlt bei aktuellen FSLogix-Konfigurationen den vollständigen Profile Container als zentrale Profilvariante.

FSLogix auch bei nur einem Terminalserver?

Bei nur einem einzigen RDS-Server ist FSLogix nicht zwingend erforderlich.

Es kann trotzdem sinnvoll sein, wenn:

• spätere Skalierung geplant ist
• Profile getrennt vom Session Host gespeichert werden sollen
• Wiederherstellung und Austausch des Hosts vereinfacht werden sollen

Für eine kleine Umgebung können lokale Profile aber ebenfalls ausreichend sein.

Schritt 20: FSLogix Storage bereitstellen

Für FSLogix wird typischerweise eine SMB-Freigabe verwendet.

Beispielsweise:

\\FILE01\FSLogix$

Wichtig sind:

• korrekte NTFS-Berechtigungen
• korrekte Freigabeberechtigungen
• ausreichend Performance
• ausreichend Kapazität
• zuverlässiger Storage

Die Profile liegen schließlich im direkten Anmeldepfad der Benutzer.

Langsamer Storage bedeutet:

langsame Anmeldung.

FSLogix Profile Container aktivieren

Typische Grundparameter sind:

Enabled

1

VHDLocations

\\FILE01\FSLogix$

Als Containerformat sollte in aktuellen Umgebungen üblicherweise:

VHDX

verwendet werden.

Die eigentliche Konfiguration kann zentral über Gruppenrichtlinien beziehungsweise entsprechende Registry-Einstellungen verteilt werden.

FSLogix und Antivirus

Ein wichtiger Punkt bei FSLogix:

Antiviren- und Sicherheitssysteme müssen korrekt auf die Profilcontainer abgestimmt werden.

Microsoft dokumentiert konkrete Ausschlüsse für:

• FSLogix-Dienste
• Treiber
• Programmverzeichnisse
• lokale Cachepfade
• VHD/VHDX-Dateien auf SMB-Freigaben

Falsch konfigurierte Echtzeitscans können zu:

• langsamen Anmeldungen
• gesperrten Profilen
• beschädigten Containern

führen.

Die Ausschlüsse sollten jedoch exakt nach Herstellervorgaben umgesetzt und nicht pauschal auf große Verzeichnisse ausgeweitet werden.

Windows Server 2025 und aktuelle FSLogix-Kerberos-Änderung

Bei aktuellen Windows-Server-2025-Systemen ist außerdem eine Änderung bei der Kerberos-Verschlüsselung relevant.

Microsoft weist für die Windows-Server-Updates 2026 darauf hin, dass ältere RC4-Konfigurationen bei SMB-Speichern für FSLogix zu Zugriffsproblemen führen können.

Bestehende FSLogix-Umgebungen sollten deshalb auf moderne unterstützte Kerberos-Verschlüsselung geprüft werden.

Gerade bei älteren File-Servern und langjährig bestehenden Active-Directory-Umgebungen sollte dieser Punkt nicht übersehen werden.

Schritt 21: Gruppenrichtlinien für Terminalserver erstellen

Ein professioneller Terminalserver sollte über:

Group Policies – GPOs

konfiguriert werden.

Dafür kann beispielsweise eine eigene Organisationseinheit erstellt werden:

OU=RDS-Server

Darin:

RDS01

RDS02

An diese OU werden anschließend die Terminalserver-GPOs gebunden.

Typische Terminalserver-GPOs

Je nach Unternehmen können beispielsweise geregelt werden:

• Sitzungszeitlimits
• getrennte Sitzungen
• Laufwerksumleitung
• Zwischenablage
• Druckerumleitung
• lokale Geräte
• Desktop
• Startmenü
• Windows Update
• OneDrive
• Microsoft 365
• Browser
• Sicherheit
• Benutzerprofile

Die Einstellungen sollten aber immer an den tatsächlichen Einsatzzweck angepasst werden.

Schritt 22: Sitzungszeitlimits konfigurieren

Ohne passende Richtlinien bleiben getrennte Sitzungen möglicherweise lange bestehen.

Beispielsweise:

Benutzer schließt einfach das RDP-Fenster.

Die Sitzung läuft weiter.

Das kann:

• RAM
• CPU
• Anwendungsressourcen

belegen.

Deshalb sollten Regeln definiert werden für:

• aktive Sitzungen
• inaktive Sitzungen
• getrennte Sitzungen

Abmelden statt nur trennen

Mitarbeiter sollten verstehen:

RDP-Fenster schließen

ist nicht dasselbe wie:

Abmelden

Beim Trennen bleibt die Sitzung bestehen.

Beim Abmelden werden Benutzerprozesse beendet und Ressourcen freigegeben.

Schritt 23: Zwischenablage kontrollieren

RDP kann die Zwischenablage zwischen:

lokalem PC

und:

Terminalserver

weiterleiten.

Das ist komfortabel.

Je nach Sicherheitsanforderungen kann es aber unerwünscht sein, dass Benutzer Daten einfach zwischen Unternehmensserver und privaten Geräten kopieren.

Die Clipboard-Redirection sollte deshalb bewusst konfiguriert werden.

Schritt 24: Laufwerksumleitung kontrollieren

RDP kann lokale Laufwerke in die Sitzung einbinden.

Beispielsweise:

C auf LAPTOP01

Damit kann ein Benutzer Dateien zwischen Terminalserver und lokalem PC übertragen.

Auch hier muss entschieden werden:

gewünscht

oder:

aus Sicherheitsgründen blockieren

Für besonders sensible Umgebungen wird die Laufwerksumleitung häufig eingeschränkt.

Schritt 25: Drucker einrichten

Drucker sind in RDS-Umgebungen häufig eine Fehlerquelle.

Es gibt unterschiedliche Möglichkeiten:

• zentral installierte Netzwerkdrucker
• Printserver
• RDP-Druckerumleitung
• Easy Print
• herstellerspezifische Treiber

Für mehrere Benutzer sind zentral verwaltete Netzwerkdrucker häufig stabiler als individuell installierte Drucker.

Druckertreiber sorgfältig auswählen

Nicht jeder Druckertreiber verhält sich auf einem Multiuser-Terminalserver problemlos.

Problematische Treiber können:

• Druckwarteschlange beeinträchtigen
• hohe CPU-Last verursachen
• Anwendungen zum Absturz bringen

Deshalb sollten nur tatsächlich benötigte und für die Umgebung geeignete Treiber installiert werden.

Schritt 26: Netzlaufwerke bereitstellen

Unternehmensdaten können beispielsweise über einen zentralen File Server bereitgestellt werden.

Beispiel:

\\FILE01\Daten

und anschließend als:

S:\

eingebunden werden.

Die Verteilung kann über Gruppenrichtlinien erfolgen.

Beispielsweise:

GRP-Buchhaltung

→ B:\Buchhaltung

GRP-Vertrieb

→ V:\Vertrieb

Damit erhalten Benutzer automatisch die benötigten Laufwerke.

Daten nicht unnötig lokal auf RDS01 speichern

Der Session Host sollte möglichst austauschbar bleiben.

Deshalb würde ich zentrale Unternehmensdaten nicht unnötig auf:

C:\

des Terminalservers ablegen.

Besser:

• File Server
• NAS
• geeigneter zentraler Storage

Dadurch lässt sich der Session Host bei Problemen einfacher ersetzen.

Schritt 27: CPU und RAM richtig dimensionieren

Die benötigten Ressourcen hängen stark von den verwendeten Anwendungen ab.

Ein Benutzer mit:

• Outlook
• Word
• Browser

benötigt deutlich weniger Ressourcen als ein Benutzer mit:

• CAD
• großen Excel-Dateien
• ERP
• datenintensiven Anwendungen

Deshalb gibt es keine seriöse allgemeine Aussage wie:

Ein Terminalserver benötigt exakt 2 GB RAM pro Benutzer.

Die Dimensionierung sollte anhand des tatsächlichen Workloads erfolgen.

Beispiel für 5 bis 10 Benutzer

Für einen normalen Office-Workload könnte ein Ausgangspunkt beispielsweise sein:

• mehrere moderne CPU-Kerne
• 16–32 GB RAM
• schneller SSD-/NVMe-Storage

Das ist ausdrücklich keine universelle Vorgabe.

Je nach Anwendungen können deutlich mehr Ressourcen erforderlich sein.

Beispiel für 20 bis 30 Benutzer

Bei höheren Benutzerzahlen sollte geprüft werden, ob:

ein großer Session Host

oder:

mehrere Session Hosts

sinnvoller sind.

Mehrere Hosts bieten Vorteile bei:

• Wartung
• Skalierung
• Ausfällen
• Lastverteilung

Ein einzelner extrem großer Terminalserver erzeugt dagegen einen entsprechend großen Single Point of Failure.

Schritt 28: Storage-Performance berücksichtigen

RDS erzeugt viele parallele Zugriffe.

Beispielsweise:

20 Benutzer öffnen gleichzeitig:

• Outlook
• Browser
• Office
• ERP

Zusätzlich:

• Profile
• Windows
• Antivirus
• Updates

Langsamer Storage kann deshalb die gesamte Benutzererfahrung beeinträchtigen.

Für produktive RDS-Systeme sind schnelle SSD- beziehungsweise NVMe-basierte Storage-Systeme häufig sinnvoll.

Schritt 29: Windows Defender beziehungsweise Endpoint Security konfigurieren

Auch ein Terminalserver benötigt Endpoint Protection.

Je nach Umgebung beispielsweise:

• Microsoft Defender
• EDR-Lösung
• zentral verwalteter Virenschutz

Dabei muss die Lösung ausdrücklich für:

Windows Server

und:

Multiuser-Umgebungen

geeignet sein.

Antivirus-Ausnahmen nicht blind übernehmen

Im Internet finden sich häufig lange Listen mit angeblich notwendigen Ausnahmen.

Diese sollten nicht einfach kopiert werden.

Jede Ausnahme reduziert den überwachten Bereich.

Deshalb nur:

• dokumentierte Herstellerempfehlungen
• tatsächlich notwendige Ausnahmen
• regelmäßig überprüfte Ausnahmen

verwenden.

Schritt 30: Windows Firewall aktiviert lassen

Die Windows Defender Firewall sollte nicht einfach deaktiviert werden.

Stattdessen sollten nur die tatsächlich benötigten Verbindungen erlaubt werden.

Beispielsweise:

• RDS
• Domain-Kommunikation
• Monitoring
• Backup
• benötigte Anwendungen

Das Prinzip lautet:

so wenig wie möglich, so viel wie notwendig.

Schritt 31: RDP nicht direkt ins Internet freigeben

Einer der wichtigsten Sicherheitspunkte:

TCP 3389 sollte nicht einfach aus dem Internet auf den Terminalserver weitergeleitet werden.

Also nicht:

Internet

↓

Port 3389

↓

RDS01

Ein öffentlich erreichbarer RDP-Dienst erhöht die Angriffsfläche erheblich.

Sicherer externer Zugriff über VPN

Eine Möglichkeit:

Homeoffice-PC

↓

VPN

↓

Unternehmensnetz

↓

RDS01

Damit ist der Terminalserver selbst nicht direkt öffentlich erreichbar.

Sicherer externer Zugriff über RD Gateway

Alternativ kann:

Remote Desktop Gateway

verwendet werden.

Das RD Gateway stellt abgesicherte verschlüsselte Verbindungen zu internen RDS-Ressourcen bereit.

Damit können Benutzer von extern auf RDS zugreifen, ohne den Session Host direkt über RDP im Internet bereitzustellen.

RD Gateway oder VPN?

Beides kann sinnvoll sein.

VPN

gut, wenn Mitarbeiter ohnehin Zugriff auf mehrere interne Ressourcen benötigen.

RD Gateway

gut für gezielten RDS-Zugriff ohne vollständigen VPN-Zugang.

Welche Architektur besser passt, hängt vom Unternehmen ab.

Schritt 32: Network Level Authentication aktivieren

Für RDP sollte:

Network Level Authentication – NLA

verwendet werden.

Dabei authentifiziert sich der Benutzer bereits vor dem vollständigen Aufbau der Remotedesktop-Sitzung.

Das reduziert die Angriffsfläche des Session Hosts.

Schritt 33: MFA für externen Zugriff planen

Bei extern erreichbaren Unternehmensdiensten sollte eine zusätzliche Authentifizierungsebene vorgesehen werden.

Nur:

Benutzername + Passwort

ist für einen kritischen Remotezugang keine ideale Sicherheitsarchitektur.

Je nach Gateway-, VPN- und Identity-Lösung sollte deshalb MFA integriert werden.

Schritt 34: Netzwerk segmentieren

Ein Terminalserver sollte nicht in einem völlig flachen Netzwerk stehen.

Beispielsweise:

VLAN 10 – Clients

VLAN 20 – Server

VLAN 30 – Management

VLAN 40 – Backup

Der RDS-Server befindet sich im Servernetz.

Firewallregeln erlauben anschließend nur die tatsächlich benötigte Kommunikation.

Schritt 35: Zugriff des Terminalservers begrenzen

Ein kompromittierter Terminalserver darf nicht automatisch uneingeschränkten Zugriff auf die gesamte Infrastruktur ermöglichen.

Deshalb sollte geprüft werden, welche Verbindungen wirklich erforderlich sind.

Beispielsweise:

RDS01 →

Domain Controller

erlaubt

RDS01 →

File Server

erlaubt

RDS01 →

Datenbankserver

falls benötigt

RDS01 →

Managementnetz

normalerweise stark eingeschränkt

Schritt 36: Backup einrichten

Der Terminalserver muss in die Backupstrategie aufgenommen werden.

Gesichert werden sollten je nach Architektur:

• System
• Konfiguration
• Anwendungen
• relevante lokale Daten
• gegebenenfalls Benutzerprofile
• FSLogix-Storage
• Datenbanken

Bei virtuellen Maschinen kann zusätzlich ein VM-basiertes Backup verwendet werden.

Profile separat sichern

Wenn FSLogix-Profile auf:

FILE01

liegen, reicht ein Backup von:

RDS01

nicht aus.

Der Profilstorage benötigt eine eigene Sicherung.

Das Gleiche gilt für:

• File Server
• Datenbank
• Lizenzserver
• Domain Controller

Die gesamte RDS-Umgebung muss betrachtet werden.

Schritt 37: Wiederherstellung testen

Ein vorhandener Backupjob bedeutet nicht automatisch, dass der Terminalserver schnell wiederhergestellt werden kann.

Testen sollte man beispielsweise:

• einzelne Datei
• Benutzerprofil
• komplette VM
• Applikationsdaten
• Konfiguration

Zusätzlich sollte dokumentiert sein, in welcher Reihenfolge Systeme wiederhergestellt werden.

Schritt 38: Monitoring einrichten

Ein produktiver Terminalserver sollte überwacht werden.

Mindestens:

• CPU
• RAM
• Storage
• freier Speicher
• Windows-Dienste
• Event Logs
• RDS-Dienste
• Backup
• Antivirus/EDR
• Windows Updates

Zusätzlich kann die Anzahl aktiver Sitzungen überwacht werden.

Schritt 39: Benutzererfahrung testen

Vor dem produktiven Rollout sollte ein normaler Testbenutzer verwendet werden.

Nicht nur der Administrator.

Testen:

• Anmeldung
• Profil
• Outlook
• Microsoft 365
• Fachanwendung
• Netzlaufwerke
• Drucker
• Zwischenablage
• Abmelden
• erneute Anmeldung
• RDP von extern
• Performance

Nur so fallen Berechtigungs- und Profilprobleme auf.

Schritt 40: Dokumentation erstellen

Dokumentiert werden sollten mindestens:

• Servernamen
• IP-Adressen
• Rollen
• RDS-Lizenzserver
• Lizenzierungsmodus
• Anzahl RDS-CALs
• Collections
• Benutzergruppen
• GPOs
• installierte Anwendungen
• FSLogix-Konfiguration
• Storage
• Backup
• Firewallregeln
• externer Zugriff
• Zertifikate
• Monitoring

Eine Terminalserverumgebung sollte nicht nur deshalb funktionieren, weil ein einzelner Administrator alle Einstellungen auswendig kennt.

Terminalserver virtualisieren oder physisch installieren?

In vielen Unternehmen würde ich Windows Server 2025 RDS heute virtualisiert betreiben.

Beispielsweise auf:

• Hyper-V
• Proxmox
• VMware

Die Virtualisierung bietet Vorteile bei:

• Backup
• Hardwarewechsel
• Ressourcenanpassung
• Migration
• Wiederherstellung

Die jeweilige Windows-Server-Lizenzierung muss dabei selbstverständlich berücksichtigt werden.

Windows Server 2025 Terminalserver auf Proxmox

Windows Server 2025 kann beispielsweise als virtuelle Maschine auf Proxmox VE betrieben werden.

Möglicher Aufbau:

Proxmox Host

↓

DC01

Windows Server

↓

RDS01

Windows Server 2025

↓

FILE01

File Server / FSLogix

↓

PBS

Proxmox Backup Server

Damit bleiben die einzelnen Serverrollen logisch getrennt.

Terminalserver und Domain Controller auf einer VM?

Für produktive Umgebungen würde ich das vermeiden.

Besser:

VM 1

Domain Controller

VM 2

Terminalserver

Auch wenn dadurch eine zusätzliche Windows-Server-VM entsteht, ist die Rollenverteilung deutlich sauberer.

Terminalserver und SQL Server trennen

Auch Datenbanken sollten bei anspruchsvolleren Anwendungen nicht automatisch auf demselben Session Host installiert werden.

Beispielsweise:

RDS01

Anwendung

↓

SQL01

Datenbank

Das erleichtert:

• Wartung
• Performanceanalyse
• Backup
• Skalierung

Ob eine Trennung notwendig ist, hängt allerdings von der jeweiligen Anwendung ab.

Ein Terminalserver oder mehrere Session Hosts?

Ein Session Host

Vorteile:

• einfacher
• weniger Infrastruktur
• günstiger im Betrieb

Nachteile:

• Ausfall betrifft alle Benutzer
• Wartung betrifft alle Benutzer
• begrenzte Skalierbarkeit

Mehrere Session Hosts

Vorteile:

• bessere Skalierung
• Wartungsmöglichkeiten
• Lastverteilung
• höhere Verfügbarkeit

Nachteile:

• komplexere Infrastruktur
• zentrale Profile notwendig
• Connection Broker erforderlich
• höhere Kosten

Für kleine Unternehmen kann ein einzelner Server völlig ausreichend sein.

Terminalserver für 5 Benutzer

Ein mögliches Konzept:

DC01

Active Directory

↓

RDS01

Windows Server 2025

↓

5 RDS User CALs

↓

Microsoft 365 Business Premium

↓

Office / Outlook / Fachanwendung

↓

VPN

↓

Backup

Für fünf Benutzer kann diese Architektur bereits ausreichend sein.

Terminalserver für 10 bis 20 Benutzer

Mögliche Struktur:

DC01 / DC02

↓

RDS01

↓

FILE01

↓

FSLogix

↓

RDS Licensing

↓

VPN oder RD Gateway

↓

Backup

Je nach Workload kann ein leistungsfähiger Session Host noch ausreichen.

Die tatsächliche Auslastung sollte überwacht werden.

Terminalserver für 30 bis 50 Benutzer

Bei höheren Benutzerzahlen sollte geprüft werden:

Connection Broker

↓

RDS01

RDS02

↓

zentraler FSLogix Storage

↓

File Server

↓

RD Gateway

↓

Backup

Dadurch wird die Umgebung besser skalierbar.

Windows Server 2025 RDS Best Practices

1. Domain Controller und Terminalserver trennen

Serverrollen sauber aufteilen.

2. Benutzer als Standardbenutzer betreiben

Keine lokalen Administratorrechte für normale RDS-Benutzer.

3. RDS-Zugriff über AD-Gruppen steuern

Benutzer nicht einzeln konfigurieren.

4. RDS-CALs korrekt lizenzieren

Windows Server CAL und RDS CAL unterscheiden.

5. Lizenzserver konfigurieren

Nicht nur Rolle installieren, sondern Lizenzserver aktivieren und Session Host zuweisen.

6. Microsoft 365 korrekt für RDS lizenzieren

Shared Computer Activation und unterstützten Microsoft-365-Plan verwenden.

7. Profile planen

Bei mehreren Session Hosts beispielsweise FSLogix einsetzen.

8. GPOs verwenden

Terminalserver zentral und reproduzierbar konfigurieren.

9. RDP nicht direkt veröffentlichen

Kein ungeschütztes TCP 3389 aus dem Internet.

10. VPN oder RD Gateway verwenden

Externen Zugriff kontrolliert bereitstellen.

11. MFA einplanen

Remotezugriff nicht ausschließlich mit Passwort absichern.

12. Windows Firewall aktiviert lassen

Nur notwendige Kommunikation freigeben.

13. Netzwerk segmentieren

Server-, Client-, Management- und Backupnetze trennen.

14. Schnellen Storage verwenden

RDS reagiert empfindlich auf langsame I/O.

15. Backup einrichten

Nicht nur den Session Host, sondern die gesamte Infrastruktur sichern.

16. Monitoring verwenden

Performance und Fehler erkennen, bevor Benutzer sie melden.

17. Restore testen

Backup ohne getestete Wiederherstellung ist kein vollständiges Backupkonzept.

Häufige Fehler bei Windows Server 2025 als Terminalserver

RDS-Rolle installieren und Lizenzierung vergessen

Nach der Einrichtung fehlen die benötigten RDS-CALs beziehungsweise der korrekt konfigurierte Lizenzserver.

Windows Server CAL mit RDS CAL verwechseln

Beides erfüllt unterschiedliche Lizenzanforderungen.

Business Standard für Microsoft 365 Apps auf RDS einplanen

Shared Computer Activation ist nicht einfach Bestandteil jeder Business-Lizenz mit Desktop-Apps.

Office normal per Klick installieren

Für eine professionelle RDS-Bereitstellung sollte Microsoft 365 Apps mit passender Shared-Computer-Konfiguration bereitgestellt werden.

Terminalserver direkt per Port 3389 ins Internet stellen

Unnötig hohe Angriffsfläche.

Alle Benutzer zu Administratoren machen

Besonders auf einem Multiuser-System problematisch.

Domain Controller und RDS auf demselben Server betreiben

Unnötige Vermischung kritischer Rollen.

Profile nicht planen

Spätestens beim zweiten Session Host entstehen Probleme.

FSLogix auf langsamen Storage legen

Anmeldungen und Anwendungen werden langsam.

Antivirus scannt FSLogix-VHDX ungeeignet

Kann zu Performance- und Containerproblemen führen.

Keine Sitzungslimits konfigurieren

Getrennte Sitzungen laufen tagelang weiter.

Alle RDP-Umleitungen erlauben

Lokale Laufwerke und Zwischenablage werden ungeprüft zwischen privaten und geschäftlichen Systemen verwendet.

Anwendungshersteller nicht prüfen

Die Fachsoftware unterstützt Windows Server 2025 oder Multiuser-RDS möglicherweise nicht.

Kein Monitoring

Ressourcenengpässe werden erst bemerkt, wenn Mitarbeiter sich beschweren.

Checkliste: Windows Server 2025 Terminalserver einrichten

Grundinstallation

• Windows Server 2025 installieren
• Desktop Experience
• Servernamen vergeben
• feste IP-Adresse
• DNS konfigurieren
• Windows Updates
• Domain Join

RDS

• RD Session Host
• RD Licensing
• gegebenenfalls Connection Broker
• gegebenenfalls RD Web Access
• gegebenenfalls RD Gateway
• Session Collection

Lizenzierung

• Windows Server Lizenzierung
• Windows Server CALs
• RDS CALs
• Per User oder Per Device
• Lizenzserver aktivieren
• CALs installieren
• Lizenzierungsmodus konfigurieren
• Licensing Diagnoser prüfen

Benutzer

• RDS-Benutzergruppe
• Standardbenutzer
• Remotedesktoprechte
• keine unnötigen Adminrechte

Anwendungen

• RDS-Kompatibilität prüfen
• Fachanwendungen
• Microsoft 365 Apps
• Shared Computer Activation
• Outlook
• Browser
• PDF-Software

Profile

• lokale Profile oder FSLogix
• zentraler Storage
• Berechtigungen
• VHDX
• Backup
• AV-Ausnahmen nach Herstellervorgaben

Gruppenrichtlinien

• Sitzungslimits
• Laufwerksumleitung
• Zwischenablage
• Drucker
• OneDrive
• Office
• Sicherheit
• Desktop

Netzwerk

• Server-VLAN
• Firewall
• benötigte Ports
• kein öffentliches RDP
• VPN oder RD Gateway
• NLA
• MFA für externen Zugriff

Betrieb

• Backup
• Monitoring
• Updates
• EDR/Antivirus
• Dokumentation
• Wiederherstellungstest

Fazit: Windows Server 2025 als Terminalserver richtig einrichten

Windows Server 2025 bietet mit Remote Desktop Services weiterhin eine leistungsfähige Plattform für zentral bereitgestellte Unternehmensarbeitsplätze.

Die eigentliche Installation der Rolle:

Remote Desktop Session Host

ist dabei nur ein kleiner Teil des Projekts.

Eine professionelle Terminalserverumgebung besteht aus:

Active Directory

↓

RD Session Host

↓

RDS-Lizenzierung

↓

Benutzer und Gruppen

↓

Anwendungen

↓

Benutzerprofile

↓

Gruppenrichtlinien

↓

Sicherheit

↓

Backup und Monitoring

Bei kleinen Unternehmen kann ein einzelner Session Host ausreichen.

Bei größeren Umgebungen können:

• mehrere Session Hosts
• Connection Broker
• FSLogix
• RD Gateway
• zentraler Storage

ergänzt werden.

Besonders wichtig sind außerdem die korrekte RDS-Lizenzierung und die Lizenzierung von Microsoft 365 Apps.

Wer Microsoft 365 Apps auf einem gemeinsam genutzten RDS-Server einsetzen möchte, benötigt einen dafür geeigneten Microsoft-365-Plan und muss Shared Computer Activation korrekt konfigurieren.

Damit kann Windows Server 2025 auch für moderne kleine und mittelständische Unternehmen weiterhin eine sinnvolle Plattform für zentrale Windows-Arbeitsplätze sein.

Windows Server 2025 Terminalserver einrichten lassen

Sie möchten einen neuen Windows Server 2025 Terminalserver einrichten, einen bestehenden RDS-Server modernisieren oder Ihre Terminalserverumgebung in ein Rechenzentrum beziehungsweise auf eine Virtualisierungsplattform migrieren?

Unetifi unterstützt kleine und mittelständische Unternehmen bei der Planung, Einrichtung und laufenden Betreuung von Windows Terminalserver- und RDS-Umgebungen.

Dazu können unter anderem gehören:

• Windows Server 2025
• Remote Desktop Services
• RD Session Host
• RDS Licensing
• RDS CALs
• Connection Broker
• RD Gateway
• RemoteApps
• Active Directory
• Gruppenrichtlinien
• FSLogix
• Microsoft 365 Apps
• Shared Computer Activation
• Exchange Online
• Drucker
• Netzlaufwerke
• VPN
• Firewall
• Servervirtualisierung
• Proxmox
• Backup
• Monitoring
• Patchmanagement
• laufende Wartung

Dabei wird nicht nur der Terminalserver installiert, sondern die komplette Umgebung aus Server, Benutzern, Anwendungen, Profilen, Sicherheit und Backup betrachtet.

So entsteht eine zentral verwaltete Arbeitsumgebung, die sich an die Anforderungen des Unternehmens anpassen und später erweitern lässt.

Häufig gestellte Fragen zu Windows Server 2025 als Terminalserver

Kann Windows Server 2025 als Terminalserver verwendet werden?

Ja. Windows Server 2025 unterstützt Remote Desktop Services und kann als RD Session Host für mehrere gleichzeitige Benutzersitzungen eingesetzt werden.

Welche Rolle benötige ich für einen Windows Server 2025 Terminalserver?

Die zentrale Rolle ist Remote Desktop Session Host. Für den produktiven Betrieb wird außerdem eine korrekte RDS-Lizenzierung benötigt. Bei größeren Umgebungen können Connection Broker, RD Gateway und RD Web Access hinzukommen.

Brauche ich RDS CALs für Windows Server 2025?

Ja. Für Benutzer beziehungsweise Geräte, die auf einen Windows Server RD Session Host zugreifen, werden entsprechende RDS-CALs benötigt. Diese kommen zusätzlich zur allgemeinen Windows-Server-Lizenzierung beziehungsweise den entsprechenden Zugriffsrechten hinzu.

Was ist der Unterschied zwischen RDS User CAL und Device CAL?

Eine User CAL wird einem Benutzer zugeordnet und eignet sich besonders, wenn dieser mehrere Geräte verwendet. Eine Device CAL wird einem Gerät zugeordnet und kann bei gemeinsam genutzten Arbeitsplätzen sinnvoll sein.

Brauche ich einen RDS-Lizenzserver?

Ja, für eine regulär lizenzierte produktive RDS-Umgebung wird ein aktivierter Remote Desktop Licensing Server benötigt, auf dem die entsprechenden CALs installiert sind.

Kann ich Microsoft 365 auf Windows Server 2025 RDS installieren?

Microsoft 365 Apps können in einem unterstützten RDS-Szenario eingesetzt werden. Für einen gemeinsam verwendeten Session Host ist Shared Computer Activation erforderlich und jeder Benutzer benötigt eine dafür geeignete Microsoft-365-Lizenz.

Funktioniert Microsoft 365 Business Standard auf einem Terminalserver?

Business Standard sollte nicht einfach als RDS-Lizenz eingeplant werden. Microsoft weist darauf hin, dass Shared Computer Activation bei den Business-Plänen eine Berechtigung von Microsoft 365 Business Premium ist und nicht generell von Microsoft 365 Apps for Business. Alternativ kommen entsprechende Pläne mit Microsoft 365 Apps for Enterprise infrage.

Funktioniert Microsoft 365 Business Premium auf RDS?

Ja, Microsoft nennt Business Premium ausdrücklich als unterstützten Plan für Microsoft 365 Apps mit Shared Computer Activation auf einem gemeinsam verwendeten RDS-System.

Was ist Shared Computer Activation?

Shared Computer Activation ermöglicht mehreren jeweils korrekt lizenzierten Microsoft-365-Benutzern, Microsoft 365 Apps auf einem gemeinsam genutzten Computer wie einem RDS Session Host zu aktivieren und zu verwenden.

Brauche ich FSLogix für einen Terminalserver?

Nicht zwingend. Bei einem einzelnen kleinen Terminalserver können lokale Benutzerprofile ausreichen. Bei mehreren Session Hosts beziehungsweise höheren Anforderungen ist FSLogix häufig eine sinnvollere zentrale Profillösung.

Was macht FSLogix?

FSLogix kann das vollständige Windows-Benutzerprofil in einem VHD- beziehungsweise VHDX-Container speichern. Dieser wird bei der Anmeldung eingebunden, sodass der Benutzer auf unterschiedlichen Session Hosts dasselbe Profil verwenden kann.

Kann ich Windows Server 2025 RDS auf Proxmox betreiben?

Ja, Windows Server 2025 kann als virtuelle Maschine auf Proxmox VE betrieben werden. Windows- und RDS-Lizenzierung müssen dabei passend zur tatsächlichen Virtualisierungs- und Benutzerumgebung geplant werden.

Sollte der Terminalserver gleichzeitig Domain Controller sein?

Für eine produktive Unternehmensumgebung würde ich die Rollen trennen. Domain Controller und RDS Session Host sollten nach Möglichkeit auf getrennten Servern beziehungsweise virtuellen Maschinen betrieben werden.

Kann ich RDP-Port 3389 ins Internet freigeben?

Technisch ist eine Portweiterleitung möglich, für einen Unternehmens-Terminalserver sollte RDP jedoch nicht einfach direkt öffentlich bereitgestellt werden. Für externen Zugriff sind beispielsweise VPN oder RD Gateway die deutlich sinnvolleren Architekturen.

Was ist ein RD Gateway?

Ein Remote Desktop Gateway ermöglicht abgesicherte und verschlüsselte Verbindungen von externen Geräten zu internen RDS-Ressourcen, ohne den eigentlichen Session Host direkt per RDP im Internet bereitzustellen.

Wie viel RAM braucht ein Windows Server 2025 Terminalserver?

Das hängt stark von Benutzerzahl und Anwendungen ab. Office, Browser und Outlook haben andere Anforderungen als CAD oder umfangreiche ERP-Anwendungen. Die Dimensionierung sollte deshalb anhand des tatsächlichen Workloads erfolgen und anschließend durch Monitoring überprüft werden.

Wie viele Benutzer können auf einem Terminalserver arbeiten?

Es gibt keine sinnvolle pauschale Zahl. Entscheidend sind CPU, RAM, Storage, Anwendungen und das Benutzerverhalten. Bei steigender Benutzerzahl kann es sinnvoller sein, mehrere Session Hosts einzusetzen, anstatt einen einzelnen Server immer größer zu dimensionieren.

Kann ich mehrere Windows Server 2025 Session Hosts verwenden?

Ja. Mehrere RD Session Hosts können in einer RDS-Bereitstellung und Collection zusammengefasst werden. Für eine solche Umgebung werden unter anderem Connection Broker und eine geeignete zentrale Profilstrategie relevant.

Wie sichere ich einen Windows Terminalserver?

Wichtig sind unter anderem aktuelle Updates, Endpoint Protection, Windows Firewall, Standardbenutzer statt lokaler Administratoren, Netzwerksegmentierung, kontrollierter Remotezugriff, MFA, Backup, Monitoring und eine sichere RDS-Gateway- beziehungsweise VPN-Architektur.