<aside> <img src="notion://custom_emoji/2b85e994-2534-4e9f-884c-14fe51659c0a/1d160cde-e4c3-8092-a117-007abed4a446" alt="notion://custom_emoji/2b85e994-2534-4e9f-884c-14fe51659c0a/1d160cde-e4c3-8092-a117-007abed4a446" width="40px" />
Aktuelle Version: Download
</aside>
BdB at work ist mit sogenannten Terminalservern vollständig kompatibel. Terminalserver sind Microsoft Windows Server mit aktivierten Remotedesktop-Services (RDP). Auf dem Server kommt hierzu ein Windows Serverbetriebssystem zum Einsatz. Bitte beachten Sie dabei auch stets die aktuellen Systemanforderungen von BdB at work und den auch anbei verlinkten Microsoft Server Lifecycle.
Auch beim Einsatz von BdB at work auf Terminalservern gilt, dass eine Unterstützung durch den LOGO Kundenservice nur für aktuell von Microsoft unterstützte Versionen gegeben werden kann.
Beim Einsatz von BdB at work auf Terminalservern sind einige Unterschiede im Vergleich zum Einsatz auf normalen Büro-PCs zu berücksichtigen.
Die Verlagerung der Aufgaben mehrerer Büro-PCs auf einen Terminalserver bedeutet nicht, dass Sie mit der Hardware-Ausstattung eines PCs nun die Aufgaben von mehreren PCs erledigen können. Besonders die Ausstattung mit Arbeitsspeicher (RAM) des Servers muss bei einer parallelen Nutzung durch mehrere Benutzer entsprechen, denn zusätzlich zur Speichernutzung der nun gestarteten parallel arbeitenden Programme kommen die zum Betrieb des Servers notwendigen Systemdienste. Selbst beim geplanten parallelen Zugriff durch nur wenige Benutzer ist ein Betrieb mit weniger als 32GB RAM in der Regel nicht ratsam.
Für die Ausstattung solcher Server kann es jedoch keinen allgemeinen Rat geben, da diese stark vom Nutzungsverhalten wie z.B. der Anzahl gleichzeitiger Nutzer und deren jeweils benutzten Programmen abhängt. Hier ist die individuelle Beratung durch einen ausgewiesenen Experten für Microsoft Server unbedingt zu empfehlen.
Weiterhin ist bei der Bereitstellung eines Microsoft Windows Server als Terminalserver zudem zu berücksichtigen, dass Sie für jeden Nutzer der auf den Terminalserver zugreift zusätzlich zur Windows-Server-Lizenz eine gesonderte Client-Access-Licence (CAL) für den RDP-Dienst vorhalten müssen. Diese CALs sind zusätzlich zu den Lizenzkosten für den eigentlichen Server von Microsoft zu erwerben.
Es werden also pro Arbeitsplatz (wenn dort Windows zum Einsatz kommt) eine Windows-Lizenz, pro Nutzer der auf den Terminalserver zugreifen soll eine CAL plus eine Windows Server-Lizenz in einer der eingesetzten Hardware entsprechenden Größe benötigt.
Der Vorteil eines Terminalserver liegt dabei also nicht in Einsparung von Hardware (diese wird eher nur verlagert), sondern ist vielmehr in den flexiblen Zugriffsmöglichkeiten zu sehen. Zentrale Verwaltung mit zentraler Datenhaltung und -sicherung trotz weltweiter über das Internet erreichbarer Windows-Nutzung egal von welcher Hardware, denn der für den Zugriff notwendige RDP-Client ist von nicht nur von Microsoft für fast alle Plattformen verfügbar.
Zuletzt sollte auch nicht außer Acht gelassen werden, das die Planung und der Betrieb solcher RDS-Server-Konstruktionen Know-how benötigt, also im Zweifelsfall Zeit und Geld kostet. Das Vorhalten dieser Ressourcen ist für ein Rechenzentrum der Caritas oder des DRK kein Problem, kann sich für ein Betreuungsbüro schnell zu einem Problem auswachsen.
Mit fortschreitendem Einsatz von Virtualisierungslösungen werden in entsprechend ausgerüsteten Rechenzentren ganze Serversysteme virtualisiert abgebildet. Auch wenn normalerweise ein Programm auf einer derart betriebenen Serverinstallation nichts davon bemerkt, dass die eigentliche Plattform nur virtualisiert wurde, kann es leider bei nicht immer fachgerechtem Einsatz zu Problemen kommen.
Ein klassisches Problemszenario: Wenn Sie auf einem physikalisch Server einen Windows-Server einrichten und auf ebem diesem „echten“ Server einen weiteren Server virtualisiert aufsetzen der Ihnen dann als Terminalserver mit Daten-Zugriff auf den „echten“ Server dient, kann es zu massiven Problemen kommen.
Es entsteht eine mehrfach ineinander geschachtelte Virtualisierung von Dateisystem-Zugriffen die zu Problemen im low-level-Zugriff führt. Die Folge können Datenverlust durch Beschädigung der Dateien sein.
Ebenso ein kritisches Szenario: Sie schachteln ähnlich einer Matroschka-Puppe virtualisierte Server ineinander, d.h. der bereits virtualisierte Windows-Server betreibt selbst eine Hyper-V Instanz auf wiederum gleich mehrere weitere virtualisierte Server (z.B. Terminalserver und Fileserver) betrieben werden. Da ein Terminalserver auch bereits eine Virtualisierung (nämlich die der Nutzer-Desktops) darstellt, haben wir damit drei ineinander geschachtelte Virtualisierungen. Die Folgen davon bleiben leider nicht aus…
In diesem Beispiel wäre der physikalische Server ebenso gut in der Lage zusätzlich selbst die Remotedesktop-Dienste auszuführen. Man spart sich damit einen nicht unerheblichen Mehrbedarf der Systemressourcen für die Virtualisierung eines (eigentlich überflüssigen) Servers. Zumal bei einer Anhäufung von Virtualisierungen auch die Anzahl notwendiger Server-Lizenzen steigt. Schließlich ist es Microsoft egal ob Sie Windows Server virtualisiert oder real einsetzen. Es gilt den wirtschaftlich und praktisch vernünftigsten Kompromiss zu finden.