Remote Desktop Services aufbauen: Session Host, Verbindungsbroker, Gateway und Lizenzserver
Welche Rollendienste zusammengehören, wie du sie auf Server verteilst und warum die Lizenzierung von Anfang an in die Planung gehört.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Vier Monate später melden sich alle Clients gleichzeitig ab
Der Aufbau einer RDS-Umgebung ist im Assistenten in wenigen Schritten erledigt, und genau das ist die Falle. Server Manager fragt nach dem Verbindungsbroker, dem Web Access und dem Session Host, verteilt die Rollendienste, startet die Server neu, und danach funktionieren Anmeldungen. Der Lizenzserver ist in diesem Ablauf ein optionaler Nachtrag, den man später hinzufügen kann. Weil alles läuft, wird aus später oft gar nicht.
Microsoft dokumentiert dazu eine klare Zahl: Es gibt eine Karenzzeit für die Lizenzierung von 120 Tagen, in der kein Lizenzserver erforderlich ist. Danach müssen die Clients eine gültige, von einem Lizenzserver ausgegebene Zugriffslizenz besitzen, bevor sie sich an einer Remotesitzung anmelden können. Der Übergang ist also kein sanftes Nachlassen, sondern ein Stichtag. Er fällt regelmäßig in eine Woche, in der niemand mit einem RDS-Problem rechnet, weil die Umgebung seit Monaten unauffällig läuft.
Die zweite Überraschung kommt beim Versionswechsel. Zugriffslizenzen müssen zur Version des Session Hosts passen, und zwar in eine Richtung: Neuere Lizenzen erlauben den Zugriff auf ältere Server, ältere aber nicht auf neuere. Wer einen Session Host auf Windows Server 2025 hebt und mit Lizenzen aus der Generation 2022 arbeitet, hat danach eine Umgebung, die technisch bereitsteht und an der sich niemand anmelden kann. Dieselbe Regel gilt für den Lizenzserver selbst: Er muss mindestens so neu sein wie die Lizenzen, die er ausgeben soll.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der Weg einer Verbindung durch die Rollendienste
Die folgende Kette beschreibt, welche Stationen eine Verbindung von außen durchläuft, bis eine Sitzung steht. Jede Station hat eine eigene Aufgabe, eigene Anforderungen an Namen und Zertifikate und einen eigenen typischen Fehler.
Der Aufbau
Client → RD Gateway (TCP 443) → RD Web Access → RD Connection Broker → RD Session Host → RD Licensing (RDS-CAL) - 01 Der Eintritt von außen, ohne RDP nach innen zu öffnen
RD Gateway (TCP 443)Das Gateway kapselt RDP in HTTPS und nimmt Verbindungen über TCP 443 entgegen. Damit muss kein RDP-Port aus dem Internet in euer Netz zeigen, und ihr könnt zusätzliche Bedingungen an die Verbindung knüpfen, etwa eine zweite Authentifizierungsstufe. Das Zertifikat des Gateways trägt den von außen erreichbaren vollständigen Namen, und dieser Name muss auch in der öffentlichen Namensauflösung stehen.
- 02 Das Portal und die Verzeichnisse mit den freigegebenen Ressourcen
RD Web AccessDas Web Access liefert die Weboberfläche und die Verzeichnisse, über die Nutzer sehen, welche Desktops und Anwendungen für sie freigegeben sind. In den Standardarchitekturen liegt es zusammen mit dem Gateway auf denselben Servern, weil beide nach außen zeigen und dasselbe Zertifikat nutzen können. Es ist der Ort, an dem Nutzer den Unterschied zwischen einem vollständigen Desktop und einer einzelnen veröffentlichten Anwendung überhaupt bemerken.
- 03 Die Stelle, die Sitzungen zusammenhält
RD Connection BrokerDer Verbindungsbroker verwaltet die Sitzungen, verteilt neue Verbindungen auf die vorhandenen Session Hosts und führt Nutzer zu einer bestehenden, abgetrennten Sitzung zurück, statt eine zweite zu eröffnen. Er verwaltet außerdem die Sammlungen. Er braucht zwei eigene Zertifikate, eines für die einmalige Anmeldung und eines für die Veröffentlichung, beide auf den internen vollständigen Namen. Für einen Verbund mehrerer Broker kommt eine gemeinsame Datenbank dazu.
- 04 Der Ort, an dem die Sitzungen tatsächlich laufen
RD Session HostDer Session Host führt die Sitzungen der Nutzer und die veröffentlichten Anwendungen aus, mehrere Sitzungen gleichzeitig auf demselben Server. Hier entscheidet sich, wie viele Nutzer ein Server trägt, und hier fallen auch die Überraschungen an: Anwendungen, die feste Pfade oder Registrierungsschlüssel je Rechner erwarten, vertragen sich mit dem Mehrsitzungsbetrieb nicht immer. Diese Eignung solltest du früh prüfen und nicht erst beim Ausrollen.
- 05 Der Dienst, der nach 120 Tagen unverzichtbar wird
RD Licensing (RDS-CAL)Der Lizenzserver installiert, gibt aus und verwaltet die Zugriffslizenzen. Fordert ein Session Host eine Lizenz an und ist eine passende verfügbar, wird sie dem Client zugeteilt und die Sitzung kommt zustande. Ohne aktivierten Lizenzserver funktioniert die Umgebung während der Karenzzeit von 120 Tagen, danach müssen die Clients eine gültige Lizenz besitzen. Die Lizenzen müssen zur Version des Session Hosts passen, und der Lizenzserver muss mindestens so neu sein wie die Lizenzen.
Wenn es nicht funktioniert
Das siehst du
Die Umgebung läuft seit Monaten unauffällig, und dann können sich innerhalb weniger Tage immer mehr Clients nicht mehr anmelden. Eine Änderung hat es nicht gegeben.
Warum
Die Karenzzeit für die Lizenzierung von 120 Tagen ist abgelaufen. Bis dahin kommen Sitzungen ohne Lizenzserver zustande, danach verlangt der Session Host eine gültige, von einem Lizenzserver ausgegebene Zugriffslizenz. Weil die Karenzzeit je Bereitstellung läuft und nicht je Client, trifft es nicht alle gleichzeitig, sondern gestaffelt, was die Deutung des Fehlerbildes zusätzlich erschwert.
Was hilft
Das siehst du
Ein neu aufgesetzter Session Host auf einer neueren Windows-Server-Version weist alle Anmeldungen ab, obwohl auf dem Lizenzserver ausreichend Zugriffslizenzen installiert sind.
Warum
Die Zugriffslizenzen müssen zur Version des Servers passen, mit dem sich der Nutzer verbindet. Neuere Lizenzen erlauben den Zugriff auf ältere Serverversionen, ältere Lizenzen aber nicht auf neuere. Lizenzen aus der Generation Windows Server 2022 erlauben also Verbindungen zu Session Hosts bis einschließlich 2022, aber nicht zu einem Session Host unter Windows Server 2025.
Was hilft
Das siehst du
Die Bereitstellung arbeitet mit Lizenzen pro Benutzer, die Zahl der tatsächlich verbundenen Personen ist aber deutlich höher als die Zahl der beschafften Lizenzen. Beschwert hat sich nie jemand.
Warum
Im Modus pro Benutzer wird die Lizenzierung nicht erzwungen. Der Lizenzserver gibt eine Lizenz aus dem verfügbaren Bestand aus oder, wenn der erschöpft ist, aus dem Bestand der überbelegten Lizenzen. Technisch funktioniert alles weiter, vertraglich ist das ein Verstoß gegen die Lizenzbedingungen. Es liegt ausdrücklich in der Verantwortung der Administration, dafür zu sorgen, dass alle Nutzer gültige Lizenzen haben.
Was hilft
Das siehst du
Im Schichtbetrieb mit gemeinsam genutzten Geräten funktionieren neue Geräte zunächst und werden nach einiger Zeit abgewiesen.
Warum
Im Modus pro Gerät bekommt ein Gerät bei der ersten Verbindung eine temporäre Zugriffslizenz, die 90 Tage gültig ist. Bei der nächsten Verbindung wird sie zu einer dauerhaften Lizenz aufgewertet, sofern der Lizenzserver aktiviert ist und Lizenzen verfügbar sind. Sind keine verfügbar, läuft das Gerät weiter auf der temporären Lizenz, und wenn deren 90 Tage ablaufen, ist Schluss. Der Bestand war also von Anfang an zu klein, aber der Effekt zeigt sich erst mit Verzögerung.
Was hilft
Das siehst du
Der Verbindungsbroker oder der Virtualisierungshost lässt sich auf dem vorgesehenen Server nicht installieren, obwohl die Rolle in der Liste steht.
Warum
Seit Windows Server 2019 stehen diese beiden Rollendienste auf einer Server-Core-Installation nicht mehr zur Verfügung. Microsoft hat sie an den Session Host angeglichen, der ohnehin die Variante mit Desktopdarstellung verlangt. Wenn eure Vorlage für neue Server standardmäßig Core ist, fällt das erst beim Installieren auf.
Was hilft
Das siehst du
Ein zweiter Verbindungsbroker soll dazukommen, die vorhandene Bereitstellung lässt sich aber nicht in einen Verbund überführen.
Warum
Ein Verbund aus mehreren Verbindungsbrokern braucht eine gemeinsame Datenbank für Konfiguration und Sitzungsdaten. Eine Einzelinstallation legt diese Daten lokal ab. Wer für die Datenbank die interne Windows-Datenbank vorgesehen hat, steht zusätzlich vor dem Problem, dass Microsoft sie als abgekündigt kennzeichnet und ausdrücklich empfiehlt, für die betroffenen Rollen eine kostenfreie oder vollständige Ausgabe von SQL Server einzusetzen.
Was hilft
Sechs Festlegungen vor dem ersten Session Host
- 01 Welche Rollendienste liegen auf welchem Server, und welche werden zusammengelegt?
- 02 Pro Gerät oder pro Benutzer? Die Entscheidung wirkt auf Beschaffung und Nachweis.
- 03 Steht der Lizenzserver, ist er aktiviert und in der Bereitstellung eingetragen?
- 04 Wie lauten der externe und der interne vollständige Name, und woher kommen die Zertifikate?
- 05 Braucht ihr mehrere Verbindungsbroker? Dann braucht ihr auch eine gemeinsame Datenbank.
- 06 Passen die Zugriffslizenzen zur Version der Session Hosts, und ist der Lizenzserver mindestens so neu?
Was vor dem ersten Session Host feststehen muss
Der Aufbau selbst ist gut dokumentiert und lässt sich abarbeiten. Die Entscheidungen davor sind es, die später schwer zu ändern sind, und sie betreffen fast alle die Lizenzierung, die Namen und die Zertifikate.
Die Rollendienste einmal in ihrer Aufgabe trennen
Der Session Host führt die Sitzungen und die veröffentlichten Anwendungen aus. Der Verbindungsbroker hält die Sitzungen zusammen, verteilt neue Verbindungen und führt Nutzer zu ihrer bestehenden Sitzung zurück. Das Web Access liefert das Portal und die Verzeichnisse mit den freigegebenen Ressourcen. Das Gateway bringt Verbindungen über HTTPS auf Port 443 von außen herein, ohne dass ihr RDP nach innen öffnen müsst. Der Lizenzserver gibt die Zugriffslizenzen aus und führt Buch darüber.
Pro Gerät oder pro Benutzer vorab entscheiden
Die Zuordnung pro Gerät passt, wenn sich mehrere Schichten dieselben Rechner teilen, die Zuordnung pro Benutzer, wenn jede Person ihre eigenen Geräte hat. Der Unterschied ist nicht nur kaufmännisch: Bei der Zuordnung pro Gerät verwaltet der Lizenzserver den Bestand hart, bei der Zuordnung pro Benutzer wird die Lizenzierung nicht erzwungen, und eine Überbelegung ist technisch möglich, aber ein Verstoß gegen die Lizenzbedingungen.
Den Lizenzserver aktivieren und eintragen, bevor er gebraucht wird
Ein installierter Lizenzserver reicht nicht. Er muss über den Assistenten aktiviert und in der Bereitstellung als zuständiger Server eingetragen werden, und die Zugriffslizenzen müssen dort installiert sein. Erledigt das direkt beim Aufbau, denn nach 120 Tagen ist es kein Wartungsvorgang mehr, sondern ein Ausfall.
Die Namen vor den Zertifikaten festlegen
Für das Gateway und das Web Access braucht ihr den von außen erreichbaren vollständigen Namen, für die beiden Zertifikate des Verbindungsbrokers den internen. Diese Namen bestimmen, was in den Zertifikaten steht, und sie lassen sich später nur mit neuen Zertifikaten ändern. Legt sie deshalb fest, bevor ihr das erste Zertifikat beantragt.
Zertifikate aus einer vertrauenswürdigen Quelle einplanen
Der Aufbau lässt sich mit selbst ausgestellten Zertifikaten durchspielen, und für ein Labor ist das in Ordnung. Im Betrieb braucht das nach außen gerichtete Zertifikat eine öffentliche Zertifizierungsstelle, und die internen Zertifikate für den Verbindungsbroker gehören in eure eigene interne Zertifikatsinfrastruktur, damit alle Clients ihnen ohne Zusatzarbeit vertrauen.
Für Hochverfügbarkeit die Datenbank mitplanen
Ein einzelner Verbindungsbroker ist ein einzelner Ausfallpunkt. Mehrere Broker im Verbund brauchen eine gemeinsame Datenbank für die Konfiguration und die Sitzungsdaten. Die interne Windows-Datenbank ist dafür nicht der richtige Weg, denn sie ist bei Microsoft als abgekündigt gekennzeichnet, mit dem ausdrücklichen Hinweis, für die betroffenen Rollen eine kostenfreie oder vollständige Ausgabe von SQL Server zu erwägen.
Die Betriebssystemvariante der Server prüfen
Seit Windows Server 2019 lassen sich der Verbindungsbroker und der Virtualisierungshost nicht mehr auf einer Server-Core-Installation betreiben, sie verlangen die Variante mit Desktopdarstellung. Wenn eure Standardvorlage für neue Server Core ist, fällt das erst beim Installieren auf, und dann ist der Server schon in Betrieb.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Wie sich die Rollendienste auf Server verteilen
Microsoft beschreibt zwei Standardarchitekturen. Die einfache Bereitstellung enthält die minimale Zahl an Servern für eine voll funktionsfähige Umgebung, allerdings ohne jede Redundanz. Die hochverfügbare Bereitstellung enthält alle Bestandteile, die für eine möglichst hohe Verfügbarkeit nötig sind. Beide folgen derselben Aufteilung, die hochverfügbare Variante hat lediglich mehrere Instanzen jeder Rolle.
Die Zusammenlegung folgt dabei einem einfachen Muster: Was nach außen zeigt, liegt zusammen, und was nach innen zeigt, liegt zusammen. Gateway und Web Access teilen sich einen Server, weil beide von außen erreichbar sein müssen und dasselbe Zertifikat nutzen können. Verbindungsbroker und Lizenzserver teilen sich einen anderen, weil beide nur intern gebraucht werden. Die Session Hosts stehen für sich, weil sie die Last tragen und getrennt skaliert werden sollen. Dazu kommen zwei Bestandteile, die nicht zu RDS gehören, aber vorausgesetzt werden: ein Domain Controller und ein Dateiserver für die Profile.
Der Aufbau selbst beginnt damit, alle beteiligten Server im Server Manager zu erfassen. Danach führt der Assistent über die Standardbereitstellung mit sitzungsbasierten Desktops und fragt nach den Servern für Verbindungsbroker, Web Access und Session Host. Erst danach kommen Lizenzserver und Gateway als eigene Schritte dazu, gefolgt von den Zertifikaten und der ersten Sammlung. Diese Reihenfolge ist im Assistenten so vorgegeben, und sie ist der Grund dafür, dass die Lizenzierung als Nachtrag erscheint, obwohl sie es nicht ist.
Lizenzierung: der Teil, der nicht nachträglich dazukommt
Jeder Nutzer und jedes Gerät, das sich mit einem Session Host unter Windows Server verbindet, braucht eine Zugriffslizenz für Remote Desktop Services. Es gibt zwei Arten, pro Gerät und pro Benutzer, und sie unterscheiden sich nicht nur in der Zuordnung. Lizenzen pro Gerät sind einem Gerät fest zugeordnet und lassen sich auch außerhalb einer Domäne nachhalten. Lizenzen pro Benutzer sind einem Konto in Active Directory zugeordnet und lassen sich in einer Arbeitsgruppe nicht nachhalten. Der Lizenzserver führt in beiden Fällen Buch.
Der entscheidende Unterschied für den Betrieb liegt in der Durchsetzung. Bei Lizenzen pro Gerät ist eine Überbelegung technisch nicht möglich, dafür sind bis zu 20 Prozent der Lizenzen widerrufbar, etwa für ausgemusterte Geräte. Bei Lizenzen pro Benutzer wird die Lizenzierung nicht erzwungen, eine Überbelegung ist also möglich und stellt einen Verstoß gegen die Lizenzbedingungen dar, dafür lässt sich keine Lizenz widerrufen. Welcher Modus passt, ergibt sich aus der Arbeitsweise: mehrere Schichten an denselben Rechnern sprechen für die Zuordnung pro Gerät, eigene Geräte je Person für die Zuordnung pro Benutzer.
Die Versionsregel ist die dritte Sache, die man kennen muss. Zugriffslizenzen müssen zu der Windows-Server-Version passen, mit der sich Nutzer verbinden. Neuere Lizenzen erlauben den Zugriff auf ältere Server, umgekehrt nicht. Dieselbe Richtung gilt für den Lizenzserver: Er kann Lizenzen seiner eigenen Version und älterer Versionen aufnehmen, aber keine neueren. In gemischten Umgebungen ergibt sich daraus eine klare Reihenfolge für Aktualisierungen. Zuerst der Lizenzserver, dann die Lizenzen, dann die Session Hosts.
Zertifikate und der Weg von außen
In einer RDS-Umgebung stehen vier Zertifikatsfunktionen nebeneinander, und sie verlangen unterschiedliche Namen. Das Gateway braucht ein Zertifikat auf den von außen erreichbaren vollständigen Namen, unter dem eure Nutzer die Umgebung ansprechen. Das Web Access nutzt in der Regel dasselbe Zertifikat, weil es unter demselben Namen erreichbar ist. Der Verbindungsbroker braucht zwei eigene Zertifikate, eines für die einmalige Anmeldung und eines für die Veröffentlichung, und beide auf den internen vollständigen Namen des Brokers.
Diese Aufteilung ist der Grund, warum die Namensplanung vor die Zertifikatsbeschaffung gehört. Ein Zertifikat lässt sich nicht auf einen anderen Namen umschreiben, und ein Wechsel des externen Namens nach dem produktiven Start bedeutet, dass alle bereits verteilten Verbindungsdateien und Verzeichnisse angepasst werden müssen. Legt den externen Namen deshalb so fest, dass er einen Standortwechsel oder einen Providerwechsel übersteht.
Selbst ausgestellte Zertifikate sind für den Aufbau in einer Testumgebung ein gangbarer Weg, und der Assistent unterstützt sie ausdrücklich, samt der Möglichkeit, sie auf den Zielrechnern in den Speicher der vertrauenswürdigen Stammzertifizierungsstellen aufnehmen zu lassen. Im Betrieb ist das keine tragfähige Lösung, weil jedes Clientgerät diese Zertifikate mitbekommen müsste. Der übliche Aufbau ist deshalb zweigeteilt: ein Zertifikat von einer öffentlichen Zertifizierungsstelle für alles, was nach außen zeigt, und Zertifikate aus der eigenen internen Zertifikatsinfrastruktur für die internen Namen.
Wo Hochverfügbarkeit tatsächlich beginnt
Ein zweiter Session Host ist der einfachste Schritt in Richtung Verfügbarkeit und der, der am meisten bringt: Fällt ein Host aus, verteilt der Verbindungsbroker die Sitzungen auf die verbliebenen. Deshalb ist er auch der erste Ausbauschritt, den Microsoft nach dem Grundaufbau nennt. Er hilft allerdings nur gegen den Ausfall eines Session Hosts. Der Verbindungsbroker selbst bleibt in dieser Ausbaustufe ein einzelner Punkt, an dem alles hängt.
Der Verbund mehrerer Verbindungsbroker ist der zweite Schritt, und er ist der aufwendigere, weil er eine gemeinsame Datenbank verlangt. Genau an dieser Stelle unterscheiden sich die beiden Referenzarchitekturen von Microsoft: Die hochverfügbare Variante ersetzt die lokale Ablage durch eine eigenständige Datenbank, in einer Bereitstellung in Azure durch einen verwalteten Datenbankdienst, der Sicherung und Verfügbarkeit selbst übernimmt. Für eine Umgebung im eigenen Haus bedeutet das einen SQL Server, den ihr betreibt und dessen Verfügbarkeit ihr wiederum sicherstellen müsst.
Der dritte Bereich wird oft übersehen und fällt im Ernstfall genauso ins Gewicht: die unterstützenden Bestandteile. Ein Dateiserver für die Benutzerprofile, ein Domain Controller für die Anmeldung, eine funktionierende Namensauflösung und eine Zertifikatsinfrastruktur für die Erneuerung. Keine dieser Komponenten gehört zu RDS, und der Ausfall jeder einzelnen legt die Umgebung lahm. Wenn ihr also Verfügbarkeit plant, gehört diese Liste mit auf das Blatt, sonst habt ihr drei redundante Session Hosts hinter einem einzelnen Dateiserver.
Dazu passende Kurse
Wenn bei euch Anwendungen zentral bereitgestellt statt auf jedem Gerät installiert werden sollen, führen Kurse zu Terminaldiensten und zentraler Anwendungsbereitstellung den Aufbau einmal vollständig durch.
Für die Datenbank hinter einem Broker-Verbund und die übrigen Serverdienste findet ihr in Trainings rund um Anwendungsserver im Microsoft-Umfeld den passenden Unterbau.
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Danke an Trainer Sven, welcher ein sehr detailliertes und fachliches KnowHow besitzt.
Ich beziehe mich hier nur auf die Nachschlung durch Herrn Marco Jachmann. Herr Jachmann ist überaus kompetent und hat alle Inhalte professionell vermittelt.
Sehr sehr gut aufbereitete Nachschulung mit genau dem notwendigen Engagement und der erforderlichen Vorbereitung innerhalb von 48 Stunden.
Häufige Fragen
Wie lange läuft RDS ohne Lizenzserver?
Pro Gerät oder pro Benutzer, was ist der Unterschied im Betrieb?
Können wir Zugriffslizenzen aus einer älteren Generation weiternutzen?
Brauchen wir zwingend ein Gateway?
Warum lässt sich der Verbindungsbroker nicht auf Server Core installieren?
Was brauchen wir für mehrere Verbindungsbroker?
Quellen
- Microsoft Learn, Remote Desktop Services mit Zugriffslizenzen lizenzieren
- Microsoft Learn, Überblick über Remote Desktop Services
- Microsoft Learn, Remote-Desktop-Umgebung bereitstellen
- Microsoft Learn, RDS-Architektur und Bereitstellungsmuster
- Microsoft Learn, entfernte und abgekündigte Funktionen in Windows Server
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Windows Server-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Remote Desktop Services einmal komplett aufbauen statt zusammenstückeln
Im RDS-Kurs bei cmt baust du die Rollendienste selbst auf, richtest Zertifikate und Lizenzserver ein und siehst an einer laufenden Umgebung, was passiert, wenn eines der Teile fehlt.
Passt dazu
- Eigene Zertifizierungsstelle aufbauen: Zertifikate für interne Dienste ausstellen
- Windows Server lizenzieren: Kerne, CALs und die Wahl zwischen Standard und Datacenter
- Gruppenrichtlinie greift nicht: die Verarbeitung Schritt für Schritt nachvollziehen
- Hyper-V oder VMware vSphere: was für welchen Serverraum passt