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

Inhaltsverzeichnis
Geleitwort
1 Warum eine neue Server-Version?
2 Editionen und Lizenzen
3 Hardware und Dimensionierung
4 Protokolle
5 Was ist .NET?
6 Installation
7 Die 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 Foundation und SharePoint Server
19 Remotedesktopdienste (Terminaldienste)
20 Hochverfügbarkeit
21 Datensicherung
22 Servervirtualisierung mit Hyper-V
23 Windows PowerShell
Stichwort

Jetzt Buch bestellen
Ihre Meinung?

Spacer
Windows Server 2012 R2 von Ulrich B. Boddenberg
Das umfassende Handbuch
Buch: Windows Server 2012 R2

Windows Server 2012 R2
Rheinwerk Computing
1392 S., 4., aktualisierte Auflage 2014, geb.
59,90 Euro, ISBN 978-3-8362-2013-2
Pfeil 4 Protokolle
Pfeil 4.1 Mein Freund, der Netzwerkmonitor
Pfeil 4.1.1 Kurzüberblick
Pfeil 4.1.2 Messen und Auswerten – ein Schnelleinstieg
Pfeil 4.2 IPv4 vs. IPv6
Pfeil 4.2.1 Unterschiede
Pfeil 4.2.2 IPv6 – die Adressierung
Pfeil 4.2.3 Vergabe von IPv6-Adressen
Pfeil 4.2.4 Abschalten von IPv6
Pfeil 4.3 Einige grundlegende Netzwerkprotokolle
Pfeil 4.3.1 DHCP – Dynamic Host Configuration Protocol
Pfeil 4.3.2 ARP – Address Resolution Protocol
Pfeil 4.3.3 DNS – Domain Name System
Pfeil 4.4 Authentifizierung und Kerberos
Pfeil 4.4.1 Authentifizierung vs. Autorisierung
Pfeil 4.4.2 Kerberos – Funktionsweise
Pfeil 4.4.3 Delegier ung
Pfeil 4.4.4 Der Service Principal Name (SPN)
Pfeil 4.4.5 Kerberos-Delegierung verwenden
Pfeil 4.4.6 Shoot the Trouble
Pfeil 4.4.7 Kernelmodus-Authentifizierung im IIS 7

Rheinwerk Computing - Zum Seitenanfang

4.3 Einige grundlegende Netzwerkprotokolle Zur nächsten Überschrift

In einer modernen Netzwerkumgebung gibt es eine Unmenge von Netzwerkprotokollen, die man als wichtig und grundlegend einstufen könnte. So könnte man beispielsweise argumentieren, dass die heutige Welt ohne das HTTP-Protokoll eigentlich undenkbar wäre und dass in einer Umgebung mit Outlook und Exchange das MAPI-Protokoll eines der meistgenutzten Protokolle im Netz ist. Gut, das ist alles richtig, aber für diesen Abschnitt habe ich folgende Kriterien bei der Auswahl der zu besprechenden Protokolle angelegt:

  • Ich möchte nicht zu sehr in die Theorie abdriften – daher bespreche ich beispielsweise nicht TCP und UDP. Das wäre zwar auch nicht uninteressant, aber schließlich soll es in dem vorliegenden Buch schwerpunktmäßig um den Windows Server 2012 und weniger um Protokolltheorie gehen.
  • Ich möchte auch nicht zu sehr in die Anwendungsschicht gehen, sondern mich auf einige Basisprotokolle konzentrieren. Was könnte mehr Basisprotokoll sein als DHCP, ARP und DNS?

Ich gehe zwar davon aus, dass jeder, der sich professionell mit IT-Systemen beschäftigt, grundsätzlich weiß, was diese Protokolle tun, ich denke aber, dass eine etwas tiefergehende Betrachtung, unter anderem mit dem Netzwerkmonitor, nicht schaden kann. Zumal ich in der Praxis immer wieder sehe, dass bereits bei diesen grundlegenden Protokollen Probleme auftreten – die aber im Allgemeinen noch vergleichsweise einfach zu diagnostizieren sind.

Hinweis

In den folgenden drei Abschnitten geht es weniger um die konkrete Konfiguration, sondern um die Funktionsweise des jeweiligen Protokolls. Mehr über die Einrichtung und Einstellungen erfahren Sie in den entsprechenden Abschnitten des Buchs.


Rheinwerk Computing - Zum Seitenanfang

4.3.1 DHCP – Dynamic Host Configuration Protocol Zur nächsten ÜberschriftZur vorigen Überschrift

Das DHCP-Protokoll wird verwendet, um Systemen eine IP-Adresse nebst grundlegenden Konfigurationsparametern zuzuweisen. Diese Parameter können beispielsweise das Standard-Gateway, die DNS-Server und dergleichen mehr sein.

Der grundlegende Ablauf ist in Abbildung 4.23 skizziert:

  • Ein startender IPv4-Client (!), der seine Adresse über DHCP beziehen soll, sucht per Broadcast nach einem DHCP-Server. Dass der Vorgang mit einem Broadcast beginnt, ist letztendlich einleuchtend, denn der Client hat ja keine andere Möglichkeit, als zunächst ganz allgemein in das Netz hineinzurufen. Zu beachten ist allerdings, dass Broadcasts im Allgemeinen nicht so ohne Weiteres über Netzgrenzen transportiert werden. Soll der DHCP-Server also auch für andere Netzsegmente außer seinem eigenen zuständig sein, muss man in den übrigen Segementen DHCP Relay Agents installieren.
  • Ein DHCP-Server, der den DISCOVER-Broadcast empfängt, antwortet dem Client mit einer DHCPOFFER-Nachricht. In dieser bietet der Server dem Client eine IP-Adresse aus seinem Bereich an.
  • Möchte der Client die DHCP-Adresse erhalten, was im Allgemeinen der Fall sein wird, sendet er eine DHCPREQUEST-Nachricht – also sozusagen die »offizielle Anforderung«.
  • Der Server bestätigt dies schließlich mit einem DHCPACK (ACK = acknowledge = Bestätigung).

    Abbildung

    Abbildung 4.23 Funktionsweise von DHCP

Der Vorgang ist so weit einleuchtend und dürfte auch bekannt sein. Interessant ist nun, mit dem Netzwerkmonitor ein wenig unter die Haube von DHCP zu schauen. Dazu habe ich einen DHCP-Vorgang protokolliert und nach dem DHCP-Protokoll gefiltert. Abbildung 4.24 zeigt das Ergebnis: Man kann die vier Phasen des DHCP-Vorgangs, nämlich DISCOVER, OFFER, REQUEST, ACK deutlich erkennen. Zu sehen ist weiterhin, dass der Vorgang eine TransactionID erhalten hat, anhand derer er identifiziert werden kann.

Abbildung

Abbildung 4.24 Der DHCP-Datenverkehr im Netzwerkmonitor

Abbildung 4.24 ist auch zu entnehmen, dass als Destination stets die Broadcast-Adresse des Netzes (255.255.255.255) eingetragen ist. Das ist auch einleuchtend, denn der Client hat ja bislang noch keine IP-Adresse, mit der eine »normale« Kommunikation möglich wäre.

Abbildung 4.25 zeigt einen detaillierten Blick in das erste Paket, nämlich den DISCOVER-Broadcast, mit dem der DHCP-Client einen Server sucht. Die interessantesten Details im Kurzüberblick:

  • Anhand des OpCodes und des MsgType (Message Type) kann dieses Paket als DISCOVER-Request identifiziert werden. Um die DHCP-Vorgänge eindeutig zuordnen zu können, wird eine TransactionID vergeben, die auch in sämtlichen anderen Paketen zu finden sein wird, die zu diesem Vorgang gehören.
  • Wenn ein Client zuvor bereits eine IP-Adresse via DHCP bezogen hatte, versucht er, diese Adresse wieder zu bekommen. In dem DHCPDISCOVER-Paket ist dementsprechend die RequestedIPAddress zu finden.
  • Auf der Abbildung ist die ParameterRequestList (zweiter Eintrag von unten) zwar nicht aufgeklappt, ist aber trotzdem nicht uninteressant: Der Client nennt dort die Konfigurationsparameter, die er benötigt, beispielsweise Subnet Mask, Domain Name oder Router.

    Abbildung

    Abbildung 4.25 Der DHCPDISCOVER-Broadcast

Ich möchte nun nicht jeden Frame des DHCP-Vorgangs in epischer Breite besprechen (ein wenig möchte ich Ihnen zum Selbst-Entdecken übrig lassen), aber das letzte Paket (DHCPACK) möchte ich Ihnen noch kurz vorstellen (Abbildung 4.26):

  • Unter der Bezeichnung YourIP ist die zugewiesene IP-Adresse zu sehen.
  • Anhand der Parameter RenewTimeValue, RebindingTimeValue und IPAddressLeaseTime kann der Client erkennen, wie lange die DHCP-Adresse gültig ist und wann sie erneuert werden muss.
  • Eine große Stärke von DHCP ist, dass der Client über diesen Weg nicht nur eine Adresse erhält, sondern auch weitergehende Konfigurationsinformationen. Diese Informationen sind im Network Monitor ebenfalls sehr gut zu erkennen – achten Sie auf die Einträge SubnetMask, DomainName, Router und DomainNameServer.

    Abbildung

    Abbildung 4.26 Die Bestätigung der Überlassung der IP-Adresse

DHCP hat sich in meiner Praxis insgesamt als sehr unproblematisch herausgestellt. Hin und wieder gibt es aber den Fall, dass ein Client ohne erkennbaren Grund keine IP-Adresse erhält. Solche Effekte kann man mit dem Netzwerkmonitor recht simpel untersuchen.


Rheinwerk Computing - Zum Seitenanfang

4.3.2 ARP – Address Resolution Protocol Zur nächsten ÜberschriftZur vorigen Überschrift

Meistens spricht man über die Auflösung des Computernamens in eine IP-Adresse. Damit ist es aber noch nicht getan, denn damit wirklich eine Kommunikation stattfinden kann, muss die IP-Adresse noch in eine Hardwareadresse aufgelöst werden – im Fall von Ethernet ist dies die MAC-Adresse.

IPv4 verwendet für die Ermittlung der Hardwareadresse das ARP-Protokoll (Address Resolution Protocol). IPv6 nutzt übrigens kein ARP, sondern setzt hier auf das Neighbor Discovery Protocol (NDP).

Viele Leser werden vermutlich mit dem ARP-Protokoll noch nicht direkt zu tun gehabt haben, denn es werkelt im Allgemeinen still und heimlich im Hintergrund und bereitet wenig Probleme; trotzdem kann es nicht schaden, es ein wenig näher zu betrachten.

Die Auflösung der Hardwareadresse wird natürlich nicht bei jedem Kommunikationsvorgang durchgeführt, vielmehr speichert das Betriebssystem die aktuellen Zuordnungen zwischen. Mit dem Kommandozeilenwerkzeug arp.exe, das im Betriebssystem standardmäßig vorhanden ist, kann man sich diese gespeicherten Zuordnungen anzeigen lassen. Der Befehl lautet arp -a, das Ergebnis ist auf Abbildung 4.27 zu sehen:

  • Zunächst sehen Sie die Auflösung der Hardwareadressen diverser IPs des lokalen Netzes. Diese sind als dynamische Einträge gekennzeichnet. Wenn der Computer mit einer dieser IPs kommunizieren soll, löst er diese also mittels ARP-Protokoll auf und speichert das Ergebnis für eine gewisse Zeit zwischen.
  • Als statische Einträge sind einige »spezielle Adressen« gespeichert, das sind beispielsweise die Broadcast-Adresse des Netzes oder Multicast-Adressen.

Es ist durchaus möglich, für bestimmte IP-Adressen einen statischen ARP-Eintrag vorzunehmen – das ist aber eher unüblich.

Abbildung

Abbildung 4.27 Mit dem Konsolenbefehl »arp -a« können die zwischengespeicherten Hardwareadressen angezeigt werden.

Mit dem Aufruf arp -d können Sie eine oder alle gespeicherten Adresszuordnungen löschen. Ein typischer Anwendungsfall ist, dass sich die physikalische Adresse einer IP-Adresse geändert hat, beispielsweise durch Austausch einer Netzwerkkarte. Ein mögliches Szenario ist auch der Austausch eines (Hardware-)Routers.

Würde man den ARP-Cache nicht leeren, würden die Netzwerkpakete an eine falsche bzw. nicht existierende Hardwareadresse gesendet – also ins Nirvana.

ARP funktioniert erfreulich simpel:

  • Der IP-Client, der mit einem anderen System kommunizieren will, aber dessen Hardwareadresse nicht kennt, versendet einen Broadcast, in dem das gesuchte System aufgefordert wird, sich zu melden und somit seine Hardwareadresse mitzuteilen.
  • Alle Systeme im Netzwerksegment empfangen den Broadcast, aber nur das System mit der gesuchten IP-Adresse antwortet und übermittelt seine Hardwareadresse.

Abbildung 4.28 zeigt einen Auszug aus dem Datenverkehr eines Vista-Clients, bei dem ich gerade den ARP-Cache geleert habe:

  • Zunächst ist zu sehen, dass innerhalb kurzer Zeit die Hardwareadressen von diversen Systemen ermittelt werden müssen. Klar, nach dem Leeren des ARP-Caches muss alles neu ermittelt werden.
  • Weiterhin ist zu erkennen, dass das System verzweifelt versucht, die 192.168.2.33 aufzulösen. Dieser Server ist allerdings offline und antwortet folglich nicht.

Dieses Nicht-Auflösen-Können einer Adresse ist zwar zunächst kein Problem, es kann aber nicht schaden, hin und wieder in das Netz zu schauen, um solche Szenarien zu erkennen:

  • Ein modernes geswitchtes Netz »leidet« unter ständigen Broadcasts zwar bei Weitem nicht so wie ein Aufbau mit Hubs oder gar eine BNC-Verkabelung. Trotzdem gilt natürlich, dass überflüssige Broadcasts vermieden werden sollten.
  • Viel schwerwiegender dürften die Probleme auf den betroffenen Clients sein. Wenn Benutzer berichten, dass der komplette PC für einige Sekunden einfriert und dann wieder ganz normal weiterläuft, deutet das darauf hin, dass das System erfolglos versucht, eine Netzwerkressource zu erreichen.

Zum letzten Punkt wäre zu ergänzen, dass es grundsätzlich zwei Szenarien gibt:

  • Ein PC versucht, einen Server bzw. eine Ressource zu erreichen, von der es keinerlei Spuren gibt, also auch nicht im DNS. Dies würde sich nicht in vergeblichen ARP-Anfragen äußern, sondern der Client wird versuchen, den nicht existierenden Namen aufzulösen (und eben nicht die IP-Adresse).
  • In dem hier gezeigten Fall konnte der PC den Hostnamen zwar im DNS finden, der Server war aber schlicht und ergreifend offline. Das Verhalten würde man beispielsweise auch beobachten, wenn als DNS-Server eine IP-Adresse eingetragen ist, die im Netz nicht mehr vorhanden ist.

    Abbildung

    Abbildung 4.28 Paket 247 ist die Anfrage für die Hardwareadresse des Hosts 192.168.2.108. Das System versucht erfolglos, die Hardwareadresse von 192.168.2.33 aufzulösen.

Wenn ein PC vergeblich immer wieder versucht, eine Hardwareadresse mittels ARP aufzulösen, müssen Sie übrigens nicht gezielt auf dem betroffenen PC messen. Die ARP-Auflösung beginnt mit einem Broadcast, der auf allen Systemen des Netzwerks protokolliert werden kann.

Verlassen wir das Feld der Probleme, und schauen wir uns einen erfolgreichen ARP-Vorgang an:

  • Das in Abbildung 4.28 im Detail gezeigte Paket 247 ist der ARP-Request für die Identifizierung der Hardwareadresse von 192.168.2.108. Sie sehen, dass die TargetMacAddress unbekannt ist (00-00 usw.).
  • Auf Abbildung 4.29 ist die Antwort von 192.168.2.108 zu sehen. Das System, das die Anfrage gestellt hat, braucht nur die SendersMacAddress auszuwerten und kennt somit die Hardwareadresse des Hosts, mit dem kommuniziert werden soll.

    Abbildung

    Abbildung 4.29 Die Antwort auf die ARP-Anfrage


Rheinwerk Computing - Zum Seitenanfang

4.3.3 DNS – Domain Name System Zur vorigen Überschrift

In einer Active Directory-(AD-)Umgebung extrem wichtig ist DNS, das Domain Name System. Es wird im AD nicht »nur« verwendet, um Rechnernamen aufzulösen, sondern auch, um Dienste (wie einen Domänencontroller oder einen globalen Katalogserver) zu finden.

Die Funktionsweise von DNS dürfte jedem Leser bekannt sein, daher möchte ich mich direkt in die Niederungen des Protokolls begeben.

Genauso wie bei dem im vorigen Abschnitt besprochenen ARP-Protokoll führt DNS nicht bei jedem Kommunikationsvorgang eine Namensauflösung durch. Vielmehr gibt es auch hier einen Zwischenspeicher. Den Inhalt dieses Zwischenspeichers kann man mit dem Konsolenbefehl ipconfig /displaydns anzeigen. Man erhält das in Abbildung 4.30 gezeigte Ergebnis. Was ist dort zu erkennen? Es wurde unter anderem der Name www.galileocomputing.de aufgelöst und eine zugehörige IP-Adresse ermittelt – nicht unbedingt spektakulär. Deutlich interessanter ist, dass der Eintrag noch eine Gültigkeitsdauer von 3.554 Sekunden hat (ca. 1 Stunde). Das Wort noch im vorigen Satz ist durchaus wichtig, denn ipconfig /displaydns zeigt immer die Restgültigkeitsdauer des Ergebnisses des Namensauflösungsvorgangs.

Etwas anders formuliert: Bei einem Zugriff auf diesen Host würde in 3.555 Sekunden eine erneute Auflösung des Namens durchgeführt werden. Diese Ablaufintervalle gelten natürlich auch für interne DNS-Einträge. Ändert sich die IP-Adresse einer Ressource, kann es also eine Weile dauern, bis der Name neu aufgelöst wird und somit die »neue« Adresse verwendet wird. Bis dahin laufen Kommunikationsvorgänge ins Leere. Dies sollten Sie bei Umstellungsarbeiten berücksichtigen.

Der DNS-Zwischenspeicher kann natürlich geleert werden. Der Konsolenbefehl dazu lautet ipconfig /flushdns.

Abbildung

Abbildung 4.30 Mit dem Befehl »ipconfig /displaydns« kann man die zwischengespeicherten Namensauflösungen abrufen.

Die DNS-Kommunikation besteht im einfachsten Fall aus zwei Paketen: Frage und Antwort. In Abbildung 4.31 und Abbildung 4.32 ist ein Mitschnitt der Netzwerkkommunikation zu sehen:

  • Abbildung 4.31 zeigt das Query-Paket im Detail: Im QRecord ist der Name des angefragten Hosts (QuestionName) nebst des QuestionType zu sehen. Im QuestionType ist festgelegt, dass nach einem A-Eintrag, also nach dem Host-Eintrag einer IPv4-Adresse, gesucht wird.
  • Abbildung 4.32 zeigt die Antwort des DNS-Servers, wobei natürlich speziell der ARecord von Interesse ist. Hier findet sich natürlich die IP-Adresse, aber auch viele andere Einträge, wie beispielsweise der ResourceType sowie die TimeToLive, also die Gültigkeitsdauer der Antwort.

    QuestionTypes

    Es sind viele unterschiedliche QuestionTypes bei der Anfrage an einen DNS-Server denkbar. Neben der Suche nach einem IPv4-Host (gesucht wird nach dem A-Record), könnte beispielsweise auch nach einem IPv6-Host (AAAA), nach dem Namensserver (NS) oder dem Mail Exchanger (MX) gesucht werden.

Abbildung

Abbildung 4.31 Die DNS-Abfrage nach der IP-Adresse von »www.galileocomputing.de«

Abbildung

Abbildung 4.32 Die Antwort des DNS-Servers

Vielleicht wundern Sie sich, warum als TimeToLive für das Abfrageergebnis ein so »krummer« Wert wie 3.384 Sekunden zurückgegeben wird. Die Antwort ist simpel:

  • Der Server, der die Anfrage beantwortet hat, hatte den Eintrag bereits im Cache. Das kann man auch am Zeitverlauf (Zeitdifferenz der Pakete 52 und 53) erkennen, denn die Antwort war nach ca. einer Millisekunde bereits da – das wäre nicht zu schaffen, wenn der Server wirklich erst im Internet hätte nachfragen müssen.
  • Wenn man direkt auf dem für den Namensraum galileocomputing.de autorisierenden Namensserver nachfragt, erhält man eine Gültigkeit von 3.600 Sekunden für die Namensauflösung. Mein DNS-Server hatte diesen Namen also bereits vor 216 Sekunden aufgelöst und gibt beim Ergebnis dann als Gültigkeitsdauer die Restdauer seines Datensatzes mit.

Nun ist es natürlich auch denkbar, dass ein Namensauflösungsvorgang fehlschlägt. Das Ergebnis einer Abfrage, bei der nach einem nicht existierenden Namen gesucht wurde, ist in Abbildung 4.33 zu sehen. Falls eine Namensauflösung eigentlich funktionieren müsste, aber einfach nicht funktionieren will, sollten Sie sich die Flags genauer anschauen. Zu erkennen ist dort unter anderem, dass der Namensserver eine rekursive Abfrage durchführen konnte (Recursive query support available), dass also ihm unbekannte Hosts bei anderen DNS-Servern abgefragt werden konnten. Falls beim DNS-Server keine Weiterleitungen und keine Stammhinweise konfiguriert gewesen wären, wäre dieses Flag nicht gesetzt gewesen.

Abbildung

Abbildung 4.33 Hier sehen Sie eine nicht erfolgreiche Anfrage. Es liegt zwar kein Problem vor, aber es kann nicht schaden, die Flags zu kontrollieren.

Weiterhin ist der genaue Fehlercode (Rcode), in diesem Fall Name Error 3, nicht uninteressant.

Ich möchte keinesfalls den Eindruck vermitteln, dass Sie nun bei jeder Kleinigkeit den Netzwerkmonitor anwerfen müssten. Bei kniffligen und »irgendwie mysteriösen« Effekten kann es aber nicht schaden, ein wenig detaillierter in das System zu schauen, und das geht natürlich am gründlichsten mit dem Netzwerkmonitor.

Man könnte das Thema DNS natürlich noch beliebig weiter »auswalzen« und einmal genau anschauen, wie der DNS-Server mit Weiterleitungen umgeht oder, was noch interessanter ist, wie er die Namensauflösung mithilfe der Stammhinweise vornimmt. Das wäre vielleicht ein nettes Thema, das Sie sich selbst an einem verregneten Montagvormittag vornehmen könnten.



Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.

<< zurück




Copyright © Rheinwerk Verlag GmbH, Bonn 2014
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.


Nutzungsbestimmungen | Datenschutz | Impressum

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de

Cookie-Einstellungen ändern


  Zum Rheinwerk-Shop
Zum Rheinwerk-Shop: Windows Server 2012 R2






Windows Server 2012 R2
Jetzt Buch bestellen


 Ihre Meinung?
Wie hat Ihnen das Openbook gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Rheinwerk-Shop: Office 365






 Office 365


Zum Rheinwerk-Shop: Microsoft Hyper-V






 Microsoft Hyper-V


Zum Rheinwerk-Shop: Linux-Server






 Linux-Server


Zum Rheinwerk-Shop: Vmware vSphere 5






 Vmware vSphere 5


Zum Rheinwerk-Shop: Windows 8 für Administratoren






 Windows 8 für
 Administratoren


 Lieferung
Versandkostenfrei bestellen in Deutschland, Österreich und der Schweiz
InfoInfo