Galileo Computing < openbook > Galileo Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Geleitwort zu diesem Buch
Inhalt des Buchs
1 Warum eine neue Server-Version?
2 Editionen und Lizenzen
3 Hardware und Dimensionierung
4 Protokolle
5 Was überhaupt ist .NET?
6 Installation
7 Core-Installationsoption
8 Active Directory-Domänendienste
9 Netzwerkdienste im AD-Umfeld
10 Active Directory Lightweight Directory Services (AD LDS)
11 Active Directory-Verbunddienste (Federation Services)
12 Active Directory-Zertifikatdienste
13 Active Directory-Rechteverwaltungsdienste (AD RMS)
14 »Innere Sicherheit«
15 Dateisystem und Dateidienste
16 Drucken
17 Webserver (IIS)
18 SharePoint (Windows SharePoint Services, WSS)
19 Remotedesktopdienste (Terminaldienste)
20 Hochverfügbarkeit
21 Datensicherung
22 Servervirtualisierung mit Hyper-V
23 Windows PowerShell
24 Windows 7 und Windows Server 2008 R2
Stichwort

Download:
- ZIP, ca. 104 MB
Buch bestellen
Ihre Meinung?

Spacer
<< zurück
Windows Server 2008 R2 von Ulrich B. Boddenberg
Das umfassende Handbuch
Buch: Windows Server 2008 R2

Windows Server 2008 R2
geb., 1.410 S., 59,90 Euro
Galileo Computing
ISBN 978-3-8362-1528-2
Pfeil 19 Remotedesktopdienste (Terminaldienste)
Pfeil 19.1 Die Funktionen aus 10.000 m Höhe
Pfeil 19.2 Installation
Pfeil 19.3 Feature »Desktopdarstellung« installieren
Pfeil 19.4 Benutzerzugriff
Pfeil 19.5 Installation von Anwendungen
Pfeil 19.6 Desktop bereitstellen
Pfeil 19.7 RemoteApp-Programme
Pfeil 19.8 Administration und Verwaltung
Pfeil 19.8.1 Konfiguration des Remotedesktop-Sitzungshosts
Pfeil 19.8.2 Benutzeradministration
Pfeil 19.8.3 Remotedesktopdienste-Manager
Pfeil 19.8.4 Loopback-Verarbeitung
Pfeil 19.8.5 Remotedesktopdienste-Lizenzierungung
Pfeil 19.9 Drucken, Easy Print
Pfeil 19.9.1 Installation von Easy Print
Pfeil 19.9.2 Kurze Überprüfung
Pfeil 19.9.3 Gruppenrichtlinien
Pfeil 19.10 Web Access für Remotedesktop
Pfeil 19.11 RemoteApp- und Desktopverbindungen mit Windows 7
Pfeil 19.12 Remotedesktopdienste-Farmen mit Netzwerklastenausgleich und Remotedesktopdienste-Verbindungsbroker
Pfeil 19.12.1 Installation
Pfeil 19.12.2 Überwachen
Pfeil 19.12.3 RemoteApp-Programme »umpaketieren«
Pfeil 19.13 Remotedesktopdienste-Farmen mit DNS Round Robin bzw. Verbindungsbroker
Pfeil 19.14 Remotedesktopgateway
Pfeil 19.14.1 Anwendung und Architektur
Pfeil 19.14.2 Installation
Pfeil 19.14.3 Konfiguration
Pfeil 19.14.4 Clientkonfiguration und Verbindungsaufbau
Pfeil 19.14.5 Überwachung
Pfeil 19.14.6 NAP und das Remotedesktopgateway
Pfeil 19.15 Host für Remotedesktopvirtualisierung
Pfeil 19.15.1 Funktionsweise
Pfeil 19.15.2 Installation
Pfeil 19.15.3 Virtuelle Maschinen konfigurieren
Pfeil 19.15.4 Benutzer administrieren
Pfeil 19.15.5 Testen und verwenden
Pfeil 19.16 Schlussbemerkung


Galileo Computing - Zum Seitenanfang

19.15 Host für Remotedesktopvirtualisierung Zur nächsten ÜberschriftZur vorigen Überschrift

Eine R2-Neuerung ist der Host für Remotedesktopvirtualisierung. Die Idee ist so einfach wie naheliegend:

  • Teilweise benötigen Anwender mehr Funktionalität, als auf einem Remotedesktop-Sitzungshost bereitgestellt werden kann. Hierfür kann es mehrere Gründe geben: Vielleicht sind die benötigten Programmpakete einfach nicht für den Betrieb auf einem Remotedesktop-Sitzungshost geeignet. Es könnte auch sein, dass der Benutzer individuelle Anpassungen benötigt, die in einer Remotedesktopdienste-Umgebung nicht machbar und/oder gewollt sind. Möglich ist auch, dass ein Poweruser eigene Programme installieren können soll oder muss oder aus sonstigen Gründen administrative Berechtigungen benötigt.
  • Die Idee ist nun, für diesen Benutzer das komplette Client-Betriebssystem zu virtualisieren und auf einem Hyper-V-Server auszuführen.

Dieser Plan klingt nicht besonders verwegen, allerdings wäre es wenig komfortabel, wenn Sie einfach für jeden Benutzer einfach ein virtuelles Windows 7 installieren und hoffen würden, dass jeder schon irgendwie auf die richtige Maschine kommt. Es geht aber besser, denn Microsoft hat dieses Konzept in die Remotedesktopdienste eingebaut. Hier wird nun auch klar, warum die Technologien von Terminaldienste in Remotedesktopdienste umbenannt worden sind: Es steckt mittlerweile wesentlich mehr dahinter als »nur« der Terminalzugriff.


VDI

Es gibt eine weitere Abkürzung, die in diesem Zusammenhang zu erwähnen ist, nämlich VDI (Virtual Desktop Infrastructure).


Trotz einer nicht nur auf den ersten Blick charmanten Lösung, sollten Sie einige strategische Aspekte nicht vergessen:

  • Der Vorteil der »Klassik-Terminaldienste« liegt darin, dass Sie viel weniger Maschinen administrieren müssen. Bei der Remotedesktopvirtualisierung betreiben Sie letztendlich Dutzende, Hunderte oder noch mehr »vollständige« Clients, die gepflegt und mit Software (Updates, Virenscanner und so weiter) versorgt werden müssen. Um eine Softwareverteilungslösung werden Sie also nicht umhinkommen.
  • Wenn Sie sehr nachhaltig auf Remotedesktopvirtualisierung setzen, benötigen Sie erhebliche Rechenleistung und Speicher im Serverumfeld. Eine vollständige Windows 7-Client-Umgebung ist bei Weitem nicht so schlank wie eine Word-Instanz.
  • Wenn Sie mobile Benutzer per Remotedesktopvirtualisierung beglücken, bleibt die Frage nach den Offline-Szenarien. Es gibt noch immer hinreichend Punkte auf der Landkarte, die mit UMTS nicht so gut versorgt sind. Insbesondere in Bürogebäuden mit bedampften Scheiben und dergleichen ist das mitunter problematisch.

Ich glaube nicht, dass die Remotedesktopvirtualisierung insgesamt so deutliche Kosteneffekte bringt wie die klassischen Terminaldienste. Das bedeutet allerdings nicht, dass dieser Ansatz nicht auch in etlichen Teilbereichen der Unternehmen deutliche Vorteile bringen kann. Immer dann, wenn ein Unternehmen ausgiebig auf die Terminaldienste setzt und die »Spezial-PCs« über diesen Weg nicht vernünftig bereitstellen kann, schlägt die Stunde der Remotedesktopvirtualisierung.


Galileo Computing - Zum Seitenanfang

19.15.1 Funktionsweise Zur nächsten ÜberschriftZur vorigen Überschrift

Um die Remotedesktopvirtualisierung nutzen zu können, ist es nicht damit getan, die gleichnamige Rolle zu installieren. Sie benötigen außerdem die folgenden Komponenten:

  • Einen oder mehrere Server, die als Host für die Remotedesktopvirtualisierung fungieren; auf diesen sind die diversen Instanzen des Client-Betriebssystems installiert.
  • Einen Remotedesktop-Sitzungshost, der die Umleitung der Client-Anfragen übernimmt
  • Einen Remotedesktop-Verbindungsbroker, der dafür sorgt, dass die Client-Anfragen an die richtige virtuelle Maschine umgeleitet werden
  • Einen Server, der den Rollendienst Web Access für Remotedesktop ausführt und den Clients einen oder mehrere Desktops und Rollendienste anbietet. Dies ist übrigens optional: Sie können stattdessen die Benutzer auch über einen einheitlichen DNS-Eintrag auf die jeweils zugeordnete virtuelle Maschine zugreifen lassen.
  • Befindet sich der Benutzer »draußen« im Internet, benötigen Sie das Remotedesktopgateway. Sofern die Remotedesktopvirtualisierung nur aus dem LAN oder über klassische VPNs verwendet wird, benötigen Sie das Gateway nicht.

Erst alle Rollendienste kennen

Wenn man die nachfolgenden Funktionszeichnungen betrachtet, drängt sich der Verdacht auf, dass mindestens drei zusätzliche Server benötigt werden, um die Remotedesktopvirtualisierung zu nutzen (Verbindungsbroker, Sitzungshost für die Umleitung, Web Access und gegebenenfalls noch das Gateway). Dem ist glücklicherweise nicht so, da verschiedene Remotedesktopdienste-Rollen auf einer Betriebssysteminstanz ausgeführt werden können.

Bevor Sie sich an die Implementierung der Remotedesktopvirtualisierung heranwagen, sollten Sie Funktion und Konfiguration der übrigen Rollendienste verstanden und möglichst ein wenig Erfahrung damit gesammelt haben. Wenn Sie als Remotedesktopdienste-Neuling direkt mit der Virtualisierung anfangen, könnte sich das als ziemlich schwierig erweisen.


Abbildung 19.156 skizziert die Funktionsweise, wenn kein Remotedesktopgateway eingesetzt wird:

1. Der Benutzer greift auf Web Access für Remotedesktop zu.
2. Der Web Access-Server ermittelt beim Remotedesktop-Verbindungsbroker, welche virtuellen Desktops für den aktuellen Benutzer vorhanden sind.

Die hier ermittelten Einträge werden dem Anwender in seinem Web Access-Dialog angezeigt.
3. Der Anwender wählt einen virtuellen Desktop aus und verbindet sich mit einem Remotedesktop-Sitzungshost, der im Umleitungsmodus läuft.
4. Der Remotedesktop-Sitzungshost fordert beim Verbindungsbroker den Zugriff auf den virtuellen Desktop des Benutzers an.
5. Der Verbindungsbroker erfragt im Active Directory, welcher virtuelle Desktop dem Benutzer zugewiesen ist.
6. Der Verbindungsbroker startet gegebenenfalls die zugewiesene virtuelle Maschine und ermittelt deren IP-Adresse. Diese gibt er an den Remotedesktop-Sitzungshost zurück, der den Client-Zugriff zu dieser virtuellen Maschine umleitet.
7. Nun greift der Client direkt auf »seine« virtuelle Maschine zu.

Abbildung 19.156 Die Remotedesktopvirtualisierung im Einsatz – ohne Remotedesktopgateway

Sofern sich der zugreifende Benutzer im Internet befindet, wird das Remotedesktopgateway benötigt, das sich nahtlos in das Gesamtszenario integriert (Abbildung 19.157):

1. Der Benutzer greift auf Web Access für Remotedesktop zu. Dieser Server muss im Internet über eine HTTPS-Verbindung verfügbar sein – um dies zu realisieren, lässt sich beispielsweise der ISA Server verwenden.
2. Der Web Access-Server ermittelt beim Remotedesktop-Verbindungsbroker, welche virtuellen Desktops für den aktuellen Benutzer vorhanden sind. Die hier ermittelten Einträge werden dem Anwender in seinem Web Access-Dialog angezeigt.
3. Der Anwender wählt einen virtuellen Desktop aus und verbindet sich über das Remotedesktopgateway mit einem Remotedesktop-Sitzungshost, der im Umleitungsmodus läuft.
4. Der Remotedesktop-Sitzungshost fordert beim Verbindungsbroker den Zugriff auf den virtuellen Desktop des Benutzers an.
5. Der Verbindungsbroker erfragt im Active Directory, welcher virtuelle Desktop dem Benutzer zugewiesen ist.
6. Der Verbindungsbroker startet gegebenenfalls die zugewiesene virtuelle Maschine und ermittelt deren IP-Adresse. Diese gibt er an den Remotedesktop-Sitzungshost zurück, der den Client-Zugriff zu dieser virtuellen Maschine umleitet.
7. Nun greift der Client via Remotedesktopgateway direkt auf »seine« virtuelle Maschine zu.

Abbildung 19.157 Die Remotedesktopvirtualisierung im Einsatz – diesmal mit Remotedesktopgateway


Galileo Computing - Zum Seitenanfang

19.15.2 Installation Zur nächsten ÜberschriftZur vorigen Überschrift

Wie Sie auf den vorhergehenden Skizzen erkennen können, sind einige weitere Remotedesktop-Rollendienste erforderlich, damit die Remotedesktopvirtualisierung eingesetzt werden kann. Sie können den Host für die Remotedesktopvirtualisierung zwar installieren, eine Inbetriebnahme wird aber nicht möglich sein, wenn beispielsweise kein Remotedesktop-Verbindungsbroker vorhanden ist.

Bei der Installation wählen Sie als Rollendienst den Host für Remotedesktopvirtualisierung aus. Als erforderlicher Rollendienst wird Hyper-V angezeigt werden, schließlich laufen die virtuellen Maschinen, auf die zugegriffen werden soll, mit dieser Virtualisierungslösung (Abbildung 19.158).

Abbildung 19.158 Bei der Installation des Rollendienstes »Host für Remotedesktopvirtualisierung« wird automatisch Hyper-V installiert.

Der weitere Verlauf der Installation des Hosts für Remotedesktopvirtualisierung ist nicht erwähnenswert. Die eigentliche Arbeit kommt ohnehin erst jetzt: Wenn Sie den Remotedesktopverbindungs-Manager starten, werden Sie feststellen, dass irgendwie alles rot ist (Abbildung 19.159). Es gibt allerdings direkt eine gute Nachricht: Im Normalfall lassen sich die roten Meldungen durch die Konfiguration mit einem einzigen Assistenten eliminieren.

Abbildung 19.159 Im Remotedesktopverbindungs-Manager ist noch vieles rot markiert – da müssen wir etwas tun.

Der Assistent, der (wahrscheinlich) alle Ihre Probleme löst, startet, wenn Sie auf die Schaltfläche Konfigurieren neben dem Eintrag RD-Verbindungsbroker wurde nicht für persönliche virtuelle Desktops konfiguriert klicken (Abbildung 19.159). Er weist erst auf diverse Voraussetzungen hin (siehe auch die Skizzen auf Abbildung 19.156 und Abbildung 19.157):

  • Es muss ein Host für die Remotedesktopvirtualisierung vorhanden sein – den haben Sie bereits installiert.
  • Es muss ein Remotedesktop-Sitzungshost vorhanden sein, der für die Umleitung konfiguriert ist. Hierbei handelt es sich um einen »normalen« Remotedesktop-Sitzungshost, der allerdings keine Anwendungen bereitstellt, sondern »nur« die Umleitung der zugreifenden Benutzer auf einen anderen Remotedesktop-Sitzungshost bzw. den Host für die Remotedesktopvirtualisierung übernimmt.
  • Es muss Web Access für Remotedesktop installiert worden sein.

Der erste Schritt ist die Eingabe eines oder mehrerer Hosts für die Remotedesktopvirtualisierung (Abbildung 19.161). In einer produktiven Umgebung, in der mehr als nur eine Handvoll Benutzer versorgt werden, dürften das mit Sicherheit mehrere Systeme sein, die Sie bei Bedarf alle in einem Durchgang hinzufügen können. Alternativ geht das natürlich auch nach und nach.

Abbildung 19.160 Beachten Sie die Vorbemerkungen.

Abbildung 19.161 Zunächst fügen Sie den oder die Remotedesktop-Virtualisierungshostserver hinzu.

Als Nächstes wird nach einem Remotedesktop-Sitzungshost gefragt, der als Umleitungsserver fungiert. Dies ist, wie bereits erläutert, ein »normal« installierter Remotedesktop-Sitzungshost, dessen einzige Funktion es ist, die Benutzer auf den »richtigen« Remotedesktop-Sitzungshost umzuleiten – in diesem Fall auf die jeweilige virtuelle Maschine.

Hier gibt es drei Einstellungsmöglichkeiten (Abbildung 19.162):

  • Zunächst wird der kurze oder der lange Name (NetBIOS-Name oder FQDN) des für diese Aufgabe vorgesehenen Remotedesktop-Sitzungshost angegeben.
  • Wenn Sie mit älteren Remotedesktop-Clients arbeiten möchten, können Sie einen alternativen Servernamen angeben. Diesen müssen Sie allerdings manuell im DNS eintragen.
  • Die dritte Konfigurationsmöglichkeit ist eine Checkbox, mit der Sie verhindern können, dass der für die Umleitung vorgesehene Remotedesktop-Sitzungshost automatisch konfiguriert wird. Im Normalfall werden Sie von dieser Option allerdings keinen Gebrauch machen.

Abbildung 19.162 Ein Remotedesktop-Sitzungshost muss für den Umleitungsmodus konfiguriert werden.

Auf der nächsten Dialogseite wird der Server angegeben, auf dem Web Access für Remotedesktop ausgeführt wird (Abbildung 19.163). In diesem Fall ist dieser Server bereits konfiguriert worden – Sie sehen also, dass dieser Assistent problemlos mehrfach ausgeführt werden kann. Der Remotedesktopverbindungs-Manager ermöglicht durchaus auch den »einzelnen« Zugriff auf die Konfigurationsabschnitte (siehe Abbildung 19.159).

Im weiteren Verlauf des Assistenten werden Sie gefragt, ob Sie wirklich die geplanten Änderungen übernehmen wollen. Weiterhin werden Sie direkt zu einem Dialog geleitet, in dem Sie Benutzern eine virtuelle Maschine zuordnen können. Wenn Sie noch keine virtuelle Maschinen eingerichtet haben, können Sie diesen Vorgang getrost abbrechen.

Abbildung 19.163 Ein Server mit Web Access für Remotedesktop muss angegeben werden – das ist hier bereits geschehen.

Falls Sie sich fragen, was auf dem Remotedesktop-Sitzungshost, der für die Umleitung verwendet wird, während der automatischen Konfiguration passiert. Abbildung 19.164 zeigt das Ergebnis: In den Eigenschaften des Remotedesktop-Sitzungshost werden auf der Registerkarte Remotedesktop-Verbindungsbroker sowohl die Umleitung als auch der Name des Remotedesktop-Verbindungsbrokers konfiguriert. Die automatisch vorgenommenen Einstellungen passen, und eine manuelle Nachbearbeitung ist im Allgemeinen nicht erforderlich.

Auf Abbildung 19.165 können Sie sehen, dass nach dem Ausführen des Assistenten alle Anzeigen grün sein sollten. Weshalb ich diesen Dialog an dieser Stelle nochmals zeige: Man kann sehen, dass Sie an alle im zuvor vorgestellten Assistenten konfigurierten Einstellungen auch »von Hand« herankommen. Auch bei späteren Erweiterungen hilft der Remotedesktopverbindungs-Manager, beispielsweise, wenn Sie einen weiteren Host für die Remotedesktopvirtualisierung hinzufügen möchten.

Sie können übrigens auch den Assistenten nochmals ausführen und Änderungen vornehmen.

Abbildung 19.164 Auf dem angegebenen Remotedesktop-Sitzungshost werden automatisch einige Einstellungen auf der Registerkarte »Remotedesktop-Verbindungsbroker« vorgenommen.

Abbildung 19.165 Nach Ausführung des Assistenten ist alles grün markiert – das System ist einsatzbereit.


Galileo Computing - Zum Seitenanfang

19.15.3 Virtuelle Maschinen konfigurieren Zur nächsten ÜberschriftZur vorigen Überschrift

Nachdem bislang die erforderliche Infrastruktur für die Remotedesktopvirtualisierung betrachtet worden ist, geht es nun darum, die virtuellen Maschinen, auf die die Benutzer zugreifen sollen, entsprechend zu konfigurieren. Zunächst ist anzumerken, dass die virtuelle Maschine auf einem beliebigen Betriebssystem laufen kann, auf das über das RDP-Protokoll zugegriffen werden kann, also XP, Vista und Windows 7. Besondere Anforderungen an den Client gibt es außer der RDP-Fähigkeit nicht. Die sonstige »Infrastruktur« dient letztendlich nur dem Zweck, den zugreifenden Benutzer auf die »richtige« virtuelle Maschine umzuleiten.

Bei der Einrichtung der virtuellen Maschine sind allerdings einige Voraussetzungen zu beachten:

  • Der Name der virtuellen Maschine muss dem FQDN des Gastbetriebssystems entsprechen (Abbildung 19.166).

Abbildung 19.166 Erste Anforderung: Die Namen der virtuellen Computer müssen dem FQDN des Gastbetriebssystems entsprechen.

  • Zweite und dritte Anforderung: Die Remotedesktop-Funktionalität des Gastbetriebssystems muss aktiviert werden. Da der Zugriff standardmäßig nur für Administratoren aktiviert ist, müssen Sie den Benutzer, der zugreifen soll, hinzufügen (Abbildung 19.167). Sie können natürlich pauschal vorgehen und beispielsweise Domänenbenutzer berechtigen, alternativ erteilen Sie nur bestimmten Benutzern die erforderlich Berechtigung.

Abbildung 19.167 Die Berechtigung für den Remotedesktop-Zugriff muss dahingehend angepasst werden, dass die jeweiligen Benutzer Zugriff erhalten.


Galileo Computing - Zum Seitenanfang

19.15.4 Benutzer administrieren Zur nächsten ÜberschriftZur vorigen Überschrift

Die Benutzeradministration bei der Remotedesktopvirtualisierung besteht eigentlich nur aus einem Aspekt: Sie müssen dem Benutzer einen virtuellen Computer zuweisen. Hierbei gibt es grundsätzlich zwei Möglichkeiten:

  • Wie so oft gibt es auch hierfür einen Assistenten. Sie können ihn aus dem Remotedesktopvirtualisierungs-Manager starten; Abbildung 19.168 hilft beim Suchen und Finden. Im Assistenten wird ein Benutzer und aus der Dropdownliste eine virtuelle Maschine ausgewählt (Abbildung 19.169).

Abbildung 19.168 Hier wird der Assistent zum Zuweisen eines persönlichen Desktops gestartet.

Abbildung 19.169 Wählen Sie den Benutzer und »seinen« virtuellen Computer aus.

  • Im Active Directory-Benutzer und -Computer-Konfigurationswerkzeug in der Version für Windows Server 2008 R2 gibt es im Eigenschaftendialog eines Benutzerobjekts eine Registerkarte Persönlicher Virtueller Desktop (Abbildung 19.170). Mit diesem kann die Zuweisung ebenfalls vorgenommen werden.

Abbildung 19.170 In den Eigenschaften des Benutzers wird nun der virtuelle Computer angezeigt.


Galileo Computing - Zum Seitenanfang

19.15.5 Testen und verwenden topZur vorigen Überschrift

Zeit zum Testen: Auf Abbildung 19.171 hat sich ein Benutzer, dem ein virtueller Desktop zugewiesen ist, mit Web Access für Remotedesktop verbunden. Zur Auswahl des virtuellen Desktops gibt es das Symbol Desktop, das einfach angeklickt werden kann. Es startet der Remotedesktopverbindungs-Client. Dieser wird zunächst anzeigen, dass der virtuelle Computer aktiviert wird. Sofern die diesem Benutzer zugewiesene virtuelle Maschine ausgeschaltet war, wird sie in diesem Moment aktiviert. Sobald sie gestartet ist, wird der Benutzer verbunden. Ist die virtuelle Maschine bereits aktiv, wird der Client ohne eine merkbare Verzögerung verbunden.

Sofern die Umleitung für ältere Remotedesktopverbindungs-Clients aktiviert und ein alternativer Servername angegeben wurde (siehe Abbildung 19.162), kann unter diesem Namen eine Verbindung zum persönlichen virtuellen Desktop aufgebaut werden (Abbildung 19.172). Dies funktioniert übrigens auch mit aktuellen Remotedesktop-Clients.

Abbildung 19.171 Nach der Auswahl des Desktops wird der virtuelle Computer aktiviert, dann wird die Verbindung hergestellt.

Abbildung 19.172 Auch so funktioniert’s: Einfach den konfigurierten DNS-Namen eingeben, und schon wird der Benutzer mit »seinem« virtuellen Desktop verbunden.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.






<< zurück
  Zum Katalog
Zum Katalog: Windows Server 2008 R2

Windows Server 2008 R2
Jetzt bestellen


 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Windows 7 für Administratoren






 Windows 7 für
 Administratoren


Zum Katalog: Konzepte und Lösungen für Microsoft-Netzwerke






 Konzepte und
 Lösungen für
 Microsoft-Netzwerke


Zum Katalog: Office SharePoint Server 2007 und Windows SharePoint Services 3.0






 Office SharePoint
 Server 2007 und
 Windows SharePoint
 Services 3.0


Zum Katalog: Exchange Server 2007 und Office Communications Server 2007






 Exchange Server 2007
 und Office
 Communications
 Server 2007


Zum Katalog: Citrix XenApp 5






 Citrix XenApp 5


Zum Katalog: PC-Netzwerke






 PC-Netzwerke


Zum Katalog: VMware vSphere 4






 VMware vSphere 4


Zum Katalog: VMware vSphere 4 - Videotraining






 VMware vSphere 4
 - Videotraining


Zum Katalog: VirtualBox






 VirtualBox


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Galileo Press 2010
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Galileo Computing]

Galileo Press, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de