Im IP-Insider-Test: NetMan Desktop Manager 5 von H+H Software

NDM 5 – Remote Desktop Programme und Lizenzen im Griff

Seite: 2/3

Firmen zum Thema

Schnellere und einfachere Installation

Die Installation einer RDS-Farm (Remote Desktop Services) von Microsoft erfordert entweder sehr viel Detailwissen der Administratoren oder den Einsatz eines externen Consultants. Wie wir bei der Installation und Inbetriebnahme der Testumgebung feststellen konnten, erfordern Installation und Konfiguration von NDM dagegen insgesamt recht wenige Zeit und Aufwand. Wer es selbst ausprobieren möchte: Der Hersteller stellt die Software in Form einer 30-tägigen Demoversion für Interessierte kostenlos zur Verfügung. Dazu sind lediglich die Angaben einiger persönlicher Informationen und einer E-Mail-Adresse erforderlich.

Wir wählten für unseren Test den klassischen Aufbau für eine kleine Umgebung: Auf einem virtualisierten Windows Server 2008 R2, der als Member-Server in einem Active Directory agierte, haben wir zunächst gemäß der deutschsprachigen PDF-Anleitung die Rolle „Remotedesktopdienste“ hinzugefügt. Da der NDM alle wichtigen Komponenten selbst zur Verfügung stellt, war es nicht notwendig, dass wir Techniken wie Web-Zugriff, Gateway und Load Balancing auf Seiten des Windows-Systems installierten. Wir mussten im Test nur wenige Veränderungen gegenüber der Standardkonfiguration von Windows vornehmen: So war es bspw. notwendig, die „Authentifizierung auf Netzwerkebene“ zu deaktivieren und sicherzustellen, dass die Option „Sitzung beenden“ bei Erreichung des Sitzungs-Limits aktiviert ist.

Bildergalerie
Bildergalerie mit 11 Bildern

Wenige Minuten später beginnt die eigentliche Installation des rund 400 MByte großen Setup-Programms. Neben der Eingabe eines Passworts, dem Zielverzeichnis und dem Hinterlegen der Lizenzdatei gibt es nicht viel zu tun: nach wenigen Minuten war der NetMan-Server einsatzbereit.

Die notwendige Client-Komponente für Windows-Computer verteilten wir gemäß der Anleitung per „Push“-Kommando. Dafür mussten wir nur eine Anpassung der Firewall-Regeln vornehmen. Alternativ bietet sich die Verteilung der Client-Software auch über das Windows-Anmelde-Skript oder über einen Webseiten-Zugriff an. Für NetMan gibt es zwei RDP-Web-Clients: den nativen Windows-Windows Webclient mit etwas besserer Performance und den Java-Client. Durch den Java-Client ist NetMan plattformunabhängig, lediglich Java 6.x oder höher ist erforderlich. In Tests konnten wir die Clients problemlos auf Windows XP und höher sowie unter OS X einsetzen.

Da in Remote Desktop-Umgebungen typischerweise ThinClients zum Einsatz kommen, unterstützt die Lösung beispielsweise die Geräte von Igel über angepasste Client-Komponenten, die auf die Custom-Partition installiert werden. Andere Hersteller wie Rangee integrieren die Software direkt in ihre Geräte.

Der erste Kontakt

Nach der Installation entdeckt der Administrator auf dem Server-Desktop drei neue Icons – die NetMan Tools, den Link zur NetMan Desktop Manager Homepage und den Verweis auf die Kurzanleitung „Erste Schritte“. Über die Tools gelangt er dann auf das „Center“ zur Datenverwaltung von Programmen, Stationen und Benutzern – dem Herzstück der Software.

Technisch und optisch ist das Programm auf dem Stand der Zeit: Es bietet Ribbons und die klassische Dreiteilung in Ansicht-, Funktions- und Infobereich. Kontextabhängige Hilfetexte, die sich passend zum Fensterinhalt ändern, ersparen den Blick in die Anleitung. Sollte dieser dennoch einmal erforderlich sein, so stehen knapp 400 Seiten im PDF-Format zur Verfügung. Konfigurationseinstellungen nennen die Produkt-Manager von NDM „Skripte“, Verknüpfungen mehrerer Skripte mit einem oder mehreren Benutzer werden als „Kollektionen“ bezeichnet.

Über diese Kaskade steuert der Administrator sehr genau, welche RDP-basierten Programme ein Benutzer erhält: Er kann entscheiden, ob sie im Startmenü oder auf dem Desktop erscheinen sollen, welche Pfade im Hintergrund zugewiesen werden und welche Drucker zu verknüpfen sind. Für den Anwender eines Windows-Fat-Clients unterscheidet sich ein per RDP zur Verfügung gestelltes Programm kaum von einer lokalen Applikation. NetMan beherrscht die für die Benutzerzufriedenheit notwendigen Features wie das gezielte Mapping von Dateinamenerweiterung. Nur recht kurz sieht der Benutzer, dass im Hintergrund eine RDP-Verbindung aufgebaut wird. Auch dies können Administratoren aber bei Bedarf abschalten. Grundsätzlich ist es jedoch unserer Meinung nach gut für die Anwender, wenn ihnen auf diese Art mitgeteilt wird, dass die Applikation derzeit geladen wird.

Nur gewünschte Programme

IT-Verantwortliche, die sowohl die Bereitstellung von Anwendungen wie auch deren Rollout mit dem Desktop Manager umsetzen möchten, machen sich sicher Gedanken darüber, ob es ihren Nutzern trotzdem gelingen kann, weitere Applikationen „an dieser Software vorbei“ zu verwenden. Diesen Fall könnte beispielsweise dann eintreten, wenn ein Unternehmen eine neue Office-Version via Remote Desktop Server bereitstellt, und sich noch ältere Office-Versionen auf den lokalen PCs befinden.

In der Regel sollten die Anwender diese dann nicht mehr einsetzen. Für ein derartiges Szenario gibt es in der NetMan Software die Funktion „Programmkontrolle“: Sie verhindert den Start von nicht erwünschten Programmen auf dem Ziel-PC. Damit ein umfassender Schutz gewährleistet ist, muss dazu allerdings der NetMan-Client auf dem System gestartet sein. Die Software verfügt deshalb über zwei Modi, die auch bei ausgeschaltetem Client einen Schutz ermöglichen: Die Service-Kontrolle bietet eine Grundkontrollfunktion bei gestartetem Client-Service während die Client-Kontrolle dies bei gestartetem Client bewirkt.

Wer schon einmal versucht hat ein Windows-System zu „härten“, wird sicher wissen, dass es hierfür mehr bedarf, als nur Applikationen auszusperren. So muss ein Administrator auch auf einem derart geschützten System sicherstellen, dass beispielsweise alle Windows-Programme, die vom System oder vom lokalen Administrator gestartet wurden, auch weiterhin arbeiten dürfen. Zudem „vererben“ viele Anwendungen Prozesse und Programmteile. Das gilt zum Beispiel dann, wenn ein Programm ein anderes aufruft, um die Arbeit fortzusetzen. Entsprechend wichtig ist es, dass der NetMan-Schutz auch solche Prozesse gewähren lässt.

Alle anderen Programme darf der Benutzer nur dann starten, wenn der Administrator diese genehmigt hat. Das gilt selbstverständlich auch dann, wenn es sich um Programm handelt, die dem Anwender via Skript zur Verfügung gestellt werden sollen. Das Programm kann zu diesem Zweck aber nicht nur mit der reinen Bezeichnung eines Programmstartorts sondern auch mit Zertifikaten zusammenarbeiten.

Nach der Installation der Software ist die so genannte Programmkontrolle zunächst inaktiv. In den Einstellungen der Software findet der Administrator diese im linken Hauptmenü: In diesem dreigeteilten Fenster zeigt eine Auflistungen die grundsätzlich genehmigten Ordner, die grundsätzlich erlaubten Programmen und die Programme, für die ein Zertifikat vorliegt. Als Ergänzung existieren dann noch zwei weitere Checkboxen, mit deren Hilfe die Programmkontrolle in den beiden bereits genannten Modi aktiviert wird. Wir konfigurierten die Einrichtung im Test so, dass für den Nutzer nur noch die per NetMan über Remote Desktop Services freigegebenen Programme erlaubt waren. Zudem genehmigten wir den Zugriff auf c:\windows\* und wählten den VMware-Ordner für die Tools sowie den Java-Pfad aus. Richtet der Systembetreuer den Pfad über die Oberfläche ein, so ersetzt die Software automatisch den statischen Pfad durch die entsprechenden Variablen, beispielsweise %nmwinprogdir% oder %nwinprogdir32%. So stellt die Lösung zur nächsten Benutzeranmeldung sicher, dass ein Anwender keine unerlaubten Programme starten kann.

Auf dieser Art gelang es uns im Test, innerhalb weniger Minuten eine Umgebung zu konfigurieren, in der ein Benutzer ausschließlich über RDP-basierte Browser arbeiten kann. Zudem verhinderte NetMan den Start möglicherweise unerwünschten Fernwartungsprogramme wie Teamviewer. Weiterhin waren wir dazu in der Lage, eine Legacy-Anwendung wie beispielsweise das uralte WordStar in einer Terminalsitzung auf Basis der freien DOSBox-Software bereitzustellen. Das klappte in unserer Testumgebung auch über die Web- und Java-Clients für ThinClients oder OS-X-Computer. Dass es sich bei dem Basisbetriebssystem um ein x64-Windows ohne die Fähigkeit zum Betrieb von 16-Bit-Applikationen handelte, wurde in diesem Szenario durch die Emulation der DOSBox wirkungsvoll aufgehoben.

weiter mit: Lizenzmanagement, Preisinformationen und Fazit

(ID:42458534)