RDS-CALs: Lizenzen für den Remotezugriff

Auf dem alten Server startet die ERP-Anwendung über eine RDP-Datei. Die Mitarbeiter können sich problemlos verbinden, doch der Lizenzmanager zeigt weniger zugewiesene Lizenzen als Personen, die die Anwendung nutzen. Beim Umzug auf Windows Server 2025 stellen sich zwei getrennte Fragen: Nimmt der neue Server die Verbindungen an, und ist die tatsächliche Nutzung ausreichend lizenziert?

RDS User CALs zählen nach den zugriffsberechtigten Personen, nicht nach gleichzeitigen Sitzungen. RDS Device CALs zählen nach den zugreifenden Geräten. Eine erfolgreiche Anmeldung belegt keine ausreichende Lizenzierung. Für eine korrekte Bestellung müssen außerdem CAL-Typ, Version des Sitzungshosts, Version des Lizenzservers und Domänen- beziehungsweise Arbeitsgruppenumgebung zusammenpassen.

Dieser Leitfaden behandelt internes betriebliches RDS auf Windows Server in der kommerziellen Lizenzierung. Für Hosting, externe Kunden, SPLA oder Azure Virtual Desktop gelten zusätzliche Bedingungen. Die vertraglichen Beispiele beruhen auf den aktuellen Product Terms für MCA, geprüft am 14. Oktober 2026. Wählen Sie für andere Vertragsprogramme die entsprechenden Bedingungen.

Zuerst die drei Lizenzebenen trennen

Windows Server benötigt eine Lizenzierung der Serversoftware selbst. Für interne Zugriffe prüfen Sie zusätzlich die grundlegende Windows Server CAL oder ein entsprechendes gleichwertiges Recht. Für die grafische Remote-Arbeitsumgebung kommt eine RDS CAL beziehungsweise passende RDS User SL hinzu. Die Product Terms führen RDS als zusätzliches Zugriffsrecht auf; eine Base CAL ersetzt es nicht.

Einige Microsoft-365-Unternehmenspakete enthalten grundlegende Serverzugriffsrechte. Prüfen Sie die konkrete Zeile in der Tabelle der CAL-Äquivalenzen. Dass Microsoft 365 E3 die Windows Server Base CAL abdeckt, bedeutet keine enthaltene RDS CAL. Diese Verwechslung kann das Ergebnis der gesamten Bestandsprüfung verändern.

Für Office in einer Sitzung gelten eigene Anwendungs- und Aktivierungsregeln. Einzelheiten erklärt der Leitfaden zur gemeinsamen Office-Aktivierung. Der Kauf von RDS CALs behebt keine fehlenden Rechte für Microsoft 365 Apps.

RemoteApp und zwei administrative Sitzungen

Ob eine Person den vollständigen Desktop oder nur das ERP-Fenster sieht, ist nicht ausschlaggebend. Die Product Terms verlangen das zusätzliche RDS-Recht auch, wenn Windows Server eine grafische Benutzeroberfläche über andere Technologien bereitstellt. Der Clientname, eine RDP-Datei oder ein anderes Remoteprotokoll rechtfertigen für sich genommen keine fehlende RDS-Lizenzierung.

Die allgemeinen Softwarebedingungen erlauben zwei Benutzern Zugriff ohne CALs ausschließlich für administrative Zwecke. Das sind keine zwei kostenlosen Arbeitsplätze für Buchhaltung oder Vertrieb. Auch eine Verbindung mit /admin macht aus ERP-Nutzung keine Serveradministration.

Erfassen Sie deshalb den Zweck jedes Zugriffs. Ein Administrator, der Updates und Servereinstellungen konfiguriert, ist ein anderer Fall als jemand, der auf demselben Server Rechnungen bearbeitet. Bei gemischten Tätigkeiten ist die administrative Ausnahme keine pauschale Lizenzierung des Kontos.

User, Device und tatsächliche Zugriffe

Die RDS-CAL-Übersicht weist ausdrücklich darauf hin, dass Per User technisch überbelegt werden kann. Lizenzen können also fehlen, obwohl niemand eine Fehlermeldung erhält. Bei Per Device begrenzt die technische CAL-Ausgabe dagegen die abgedeckten Geräte. Gleichzeitige Sitzungen sind daher keine gemeinsame Zählgrundlage beider Modelle.

Hypothetisches Beispiel, keine Kundendaten: 60 Mitarbeiter teilen sich in Schichten 20 Büroarbeitsplätze. Drei Führungskräfte aus derselben Gruppe greifen zusätzlich von ihren eigenen Notebooks zu. Sämtliche Zugriffe dienen interner Arbeit über RDS; passende Lizenzversionen stehen zur Verfügung.

Die Zahlen enthalten keine grundlegenden Windows-Server-Rechte, Serverlizenzen oder Anwendungen. Die Tabelle ist keine Preisempfehlung: Per Device erfordert Geräteverwaltung, und jedes zusätzliche Zugriffsgerät verändert den Umfang. Per User kann bei häufigem Wechsel zwischen Notebook, privatem PC und weiteren Geräten einfacher zu verwalten sein.

Untersuchen Sie im gerätebezogenen Modell die Endgeräte, von denen die Personen tatsächlich zugreifen. Weder der ERP-Server noch ein gemeinsames Anmeldekonto ersetzen die Endgeräteinventur. Wenn Mitarbeiter Firmen- und Privatcomputer verwenden, erfassen Sie beide Zugriffswege vor dem Angebotsvergleich.

Ein Upgrade betrifft drei getrennte Versionen

Der Sitzungshost bestimmt, welche RDS-CAL-Version benötigt wird. Neuere RDS CALs können ältere Hosts abdecken; umgekehrt gilt das nicht. Zugleich muss der Lizenzserver die Installation des jeweiligen CAL-Pakets unterstützen. Microsoft beschreibt diese beiden Beziehungen getrennt in der RDS-CAL-Kompatibilitätsübersicht.

Die Tabelle bestätigt weder ausreichende Stückzahlen noch den Lizenzmodus oder die gesamte RDS-Topologie. Prüfen Sie beim Upgrade von Broker, Gateway und weiteren Rollen auch die unterstützten RDS-Konfigurationen. Beschreiben Sie in der Beschaffung mehrere unterschiedliche Komponenten nicht mit einem einzigen Eintrag „RDS 2025“.

Arbeitsgruppen verändern Modell und Diagnose

In einer Domäne können Sie den passenden Per-User- oder Per-Device-Modus wählen. In einer Arbeitsgruppe verlangt der Leitfaden zur Sitzungshost-Lizenzierung Per Device. Es fehlen nicht nur Benutzerberichte; die Dokumentation lässt Per User in dieser Umgebung ausdrücklich nicht zu.

Laufen RD Session Host und Lizenzserver in einer Arbeitsgruppe auf unterschiedlichen Computern, kommt eine weitere Prüfung hinzu. Nach dem Sicherheitsupdate für CVE-2024-38099 verlangt der Lizenzserver nichtanonyme Anmeldeinformationen. Microsoft beschreibt dafür ein eigenes Konto auf dem Lizenzserver und die Bereitstellung seiner Zugangsdaten für den Dienst auf dem Sitzungshost. Dieser konkrete Schritt betrifft weder das Domänenszenario noch die Ausführung beider Rollen auf demselben Computer.

Eine Fehlermeldung nach einem Update bedeutet daher nicht zwangsläufig zu wenige gekaufte CALs. Prüfen Sie zuerst Modus, Versionen, Erreichbarkeit und Authentifizierung. Das Abschalten der Authentifizierungsanforderung ist kein empfohlener Standardweg; die Dokumentation warnt vor erhöhtem Sicherheitsrisiko. Unterschiede zwischen Domänen, Vertrauensstellungen und Arbeitsgruppen erläutert der Leitfaden zum Lizenzserver über Umgebungsgrenzen hinweg.

Vor dem Start des neuen Servers prüfen

Nach Installation von RD Session Host besteht ein technischer Kulanzzeitraum von 120 Tagen ohne Anforderung eines Lizenzservers. Das belegt keine ausreichende Lizenzierung. Planen Sie funktionierende Lizenzvergabe ein, bevor der reguläre Betrieb vom neuen Host abhängt.

1. Zugriffe erfassen. Konkrete Personen, Geräte, Anwendungen, Zwecke und Verbindungswege; auch Zugriffe außerhalb des Büros.
2. Modell auswählen. User oder Device und die begründete Anzahl dokumentieren. In Arbeitsgruppen Device verwenden. Grundlegende Server- und Anwendungsrechte separat nachweisen.
3. Drei Versionen zusammenstellen. Host, CAL und Lizenzserver. Kaufbelege und gegebenenfalls Upgraderechte ergänzen, nicht nur einen Screenshot des installierten Pakets.
4. CAL-Ausgabe vorbereiten. Den Lizenzserver aktivieren und das passende gekaufte Paket nach Microsofts Anleitung installieren. Anschließend Lizenzserver und Modus am Host konfigurieren. Für Bereitstellungen ohne Connection Broker die entsprechenden Richtlinien verwenden. Wirksame Einstellungen und mögliche Überschreibungen durch andere Richtlinien prüfen.
5. RD Licensing Diagnoser ausführen. In Arbeitsgruppen zusätzlich die Dienstauthentifizierung prüfen. Eine Netzwerkverbindung belegt keine korrekten Zugangsdaten.
6. Typische Zugriffe testen. Regulärer Benutzer, gemeinsam genutzte Station und entferntes Notebook; danach CAL-Ausgabe und Bestand vergleichen. Fehlende Blockierung im User-Modus ist keine zusätzliche Lizenz.
7. Verantwortung für Änderungen festlegen. Neue Geräte, Mitarbeiter, Serverupgrades und Modellwechsel benötigen einen konkreten Verantwortlichen für die Lizenzdokumentation.

Das Ergebnis sind zwei getrennte Bestätigungen: eine unterstützte, funktionierende technische Bereitstellung und die Lizenzabdeckung der beschriebenen Nutzung. Ein erfolgreicher Sitzungstest liefert nicht beides.