Windows Server Blog

Warum IIS? - Folge 1

Marketing Phrasen gibt es viele - da die Leserschaft hier technisch und ich ein Pragmatiker bin, mal ein  Versuch die obige Frage nach dem Motto:
Szenario -> Problem -> Lösung   zu beantworten.

Beispiel 1:
Auf meinem Webserver liegen große Medien Dateien (z.B. Videos)
Viele Leute kucken sich aber nur einen Bruchteil des Inhaltes an, laden aber immer die komplette Datei herunter - was das Netzwerk verpestet und mich Datentransfer Gebühren kostet

Lösung:
Die IIS Bit Rate Throtteling Extension drosselt den http-Antwort-Datenstrom basierend auf der Encodierten Bitrate der Mediendatei. Ganz automatisch. Ich kann das Verhalten für Datei-Typen in Regeln definieren und das Ganze funktioniert auch für Docs, Zips, Pics....

Lohnt sich eine Investition in Windows Server 2008 R2?

Das Analystenhaus Forrester bejaht dies eindeutig in Ihrer neuen Studie ”The Total Economic Impact of Windows Server 2008 R2“. In dieser, im Auftrag von Microsoft erstellten Studie, untersuchte Forrester den Return on Investment sowie den Break-Even Punkt einer Investition in Windows Server 2008 R2. Das Ergebnis des Modells: ein risk-adjusted ROI von 189% mit einem Break-Even Point unter 6 Monaten.
Die ganze Studie steht zur Verfügung unter: http://go.microsoft.com/?linkid=9695563

Viel Spaß beim Lesen wünscht

Jochen

Terminal Server Gateways und Hosts Rewrite von SSL-VPN Gateways

Einige standen schon vor dem Problem, dass hinter einem SSL-VPN Gateway ein Terminal Server Gateway (TSGW) implementiert werden soll, obwohl das TSGW selbst direkt die Verbindung entgegen nehmen könnte.

Hier wird kurz ein Workaround beschrieben, wie man ein Terminal Server Gateway, das hinter SSL-VPN Gateways die mit Hosts rewrite arbeiten, kontaktieren und verwenden kann. Bevor dieser Workaround produktiv eingesetzt wird, empfehle ich nochmalige Rücksprache mit dem Microsoft Produkt Support.

Um den Hosts rewrite bei SSL-VPN Gateways ranken sich viele Diskussionen - doch folgendes Problem gilt es meist zu lösen: Spätestens nach der Einführung von User Account Control (UAC) mit Windows Vista ist ein Hosts File rewrite ohne entsprechende Änderungen auf dem Clients „out of the box“ nicht möglich. Selbst wenn man einen Workaround für seine managed Clients schafft, funktioniert dieser nicht gesichert auf unmanaged Clients wie z.B. Home PCs oder gar Maschinen von Partner Firmen.

Viele SSL-VPN Lösungen arbeiten mit einem lokalen Port forwarding beim dem ein Port über ein Java Applet auf eine lokale IP-Adresse gemapped wird. Damit nun das Mapping für den User transparent wird, passt das Java Applet die lokale Hosts an damit der Anwender wie gewohnt (u.a.) interne FQDNs verwenden kann.

Bsp.: Hosts Datei nach einem Rewrite

# Copyright (c) 1993-2009 Microsoft Corp. # # This is a sample HOSTS file used by Microsoft TCP/IP for Windows. # # This file contains the mappings of IP addresses to host names. Each # entry should be kept on an individual line. The IP address should # be placed in the first column followed by the corresponding host name. # The IP address and the host name should be separated by at least one # space. # # Additionally, comments (such as these) may be inserted on individual # lines or following the machine name denoted by a '#' symbol. # # For example: # 102.54.94.97 rhino.acme.com # source server # 38.25.63.10 x.acme.com # x client host # localhost name resolution is handled within DNS itself. # 127.0.0.1 localhost # ::1 localhost 127.0.11.101  tsgw.contoso.msft

Kann nun durch fehlende Rechte oder durch die UAC Restriktionen das Java Applet die Hosts Datei nicht umschreiben, steht am Ende auf dem Client zwar die Verbindung mit einem Port zur Verfügung aber FQDNs für das Ansprechen dieser Verbindung können nicht verwendet werden (Bsp.: 127.0.11.101:443).

Die größten Herausforderungen dürften an dieser Stelle die Konfiguration des Terminal Server Gateway Portals, die des Terminal Server Gateways selbst sowie das Erstellen eines entsprechenden X.509 Zertifikates sein. Folgende Punkte sollen aufzeigen welche Schritte hierfür notwendig sind:

1. In der Konfiguration des Terminal Server Web Access muss die lokal verwendete statische IP-Adresse der SSL-VPN Verbindung auf dem Client (z.B. 127.0.1.101) hinterlegt werden.
   
   
   
   
2. Nun muss passend zu dieser IP-Adresse ein entsprechendes Zertifikat für das Terminal Server Gateway generiert werden.
   In diesem Zertifikat sollte nun zum einen der FQDN des TSGWs und zum anderen die auf dem Client verwendete IP-Adresse enthalten sein. Dies kann zum Beispiel über das Web Enrollment Interface der Microsoft Active Directory Certificate Services (AD CS) von statten gehen. Hierzu kann der folgende Beispiel String „SAN:DNS=tsgw.contoso.msft&DNS=127.0.1.101” unter Attributes verwendet werden.
   
   Weiter Informationen hierzu
   TechNet Libary: Enrollment Processing
   (bitte auch folgende Artikel hierzu beachten, da dies nicht ganz den X.509 RFCs entspricht).
   RFC: Internet X.509 Public Key Infrastructure Certificate and CRL Profile
   RFC: DOMAIN NAMES - CONCEPTS AND FACILITIES
   
   AD CS Web-Enrollment Interface
   
   
   
3. Nachdem das Zertifikat generiert wurde, kann es in die Konfiguration eingebunden werden. Danach kann das TSGW über den FQDN und über die im Zertifikat enthaltene IP-Adresse Verbindungen ohne Fehler entgegen nehmen.
   
   Terminal Server Gateway Eigenschaften (Screenshot wurde angepasst)
   
   
   
4. Nun kann auf der Portalseite des SSL-VPN Gateways die Web-Site des Terminal Server Web Access eingebunden und die Verbindung zum TSGW über die SSL-VPN Verbindung getestet werden.

Achtung Fälschung: Angebliche Microsoft-Email fordert zur Installation von Zertifikaten auf!

Folgende Email fand ich gestern in meinem Postfach, angeblich kam sie vom ‘Microsoft System Administrator’:

Attention!

On October 30, 2009 server upgrade will take place. Due to this the system may be offline for approximately half an hour.
The changes will concern security, reliability and performance of mail service and the system as a whole.
For compatibility of your browsers and mail clients with upgraded server software you should run SSl certificates update procedure.

This procedure is quite simple. All you have to do is just to click the link provided, to save the patch file and then to run it from your computer location. That's all.

<Malware Link>

Thank you in advance for your attention to this matter and sorry for possible inconveniences.

System Administrator

Typisches Beispiel für eine Fälschung. Z.B. scheint der Link zu Microsoft zu gehören (updates.microsoft.com), tatsächlich ist es jedoch eine ganz andere Domäne (global-cert.net). Auch den Absender der Email, angeblich von microsoft.com, gibt es bei uns gar nicht.

Microsoft wird Sie niemals per Email auffordern, etwas über einen solchen Link zu installieren. Unsere Software finden Sie immer auf Microsoft Update oder Microsoft Downloads. Also: bitte diese ‘Zertifikate’ nicht installieren!!!

Mit freundlichen Grüßen!

Ralf M. Schnell

Faszinierende Einblicke ins eigene Rechenzentrum (und auch noch kostenlos)

Haben sie sich schon mal eine der folgenden Fragen gestellt?

• Wieviele Windows 2000 Server habe ich noch im Rechenzentrum?
• Gibt es Server, die wenig ausgelastet sind?
• Wieviele verschiedene SQL Server Versionen sind bei mir im Einsatz?
• Könnte ich einige meiner Server eventuell virtualisieren?
• Kann ich durch Virtualisierung Geld sparen?

Es gibt auf dem Markt diverse Softwareprodukte, die ihnen Daten liefern, um Fragen dieser Art beantworten zu können. Von Microsoft seien beispielsweise System Center Configuration Manager 2007 R2 und System Center Operations Manager 2007 R2 genannt. Mit Hilfe der von diesen Management Tools gelieferten Daten lassen sich Auswertungen erstellen, die ihnen die gewünschten Einblicke in ihr Rechenzentrum liefern.

Allerdings ist der Einsatz dieser Produkte weder trivial noch kostenlos. Auch die Erstellung der Auswertungen erfordert einiges an Zeit und Know-how. An dieser Stelle kann ihnen das lizenzkostenfreie Microsoft Assessment and Planning (MAP) Toolkit helfen. MAP wurde von Microsoft im Rahmen der Microsoft Virtualization Solution Accelerators entwickelt und umfasst folgende Funktionen:

• Inventarisierung der gesamten Windows-basierten IT-Umgebung
• Erfassung der Auslastungsinformation der inventarisierten Systeme über einen definierten Zeitraum
• Automatische Generierung von Auswertungen und Berichten
• Beurteilung der Serverlandschaft im Hinblick ihr Virtualisierungsprojekt

Speziell der letzte dieser Punkte ist für eine schnelle Umsetzung eines Virtualisierungsprojekts hin zu Hyper-V sehr gut geeignet. MAP liefert ihnen sehr detaillierte Konsolidierungsvorschläge (Server Consolidation Proposal), in denen die für eine Konsolidierung geeigneten Systeme auf Basis der erfassten Auslastungsdaten auf eine ermittelte Anzahl von Hyper-V Hosts verteilt werden.

Die Vorher/Nachher-Auswertung (Server Consolidation Report) und der Energieeinsparungs-Rechner (Power Savings Calculator and Proposal) liefern ihnen Berichte, die die Effizienzsteigerung und die Kosteneinsparungspotentiale sehr Manager-freundlich darstellen (grafisch, bunt, einfach zu lesen und einfach nachzuvollziehen :-).

Voraussetzungen für den Einsatz von MAP

MAP skaliert sehr gut von kleinen, lokalen Serverlandschaften bis hin zur großen, verteilten Unternehmens-IT. Eine Inventarisierung von MAP kann bis zu 120.000 Systeme erfassen.

MAP installiert keine Agenten auf den Systemen, die analysiert werden sollen. Die benötigten Informationen werden über die Windows Management Instrumentation (WMI) und über den Zugriff auf die Registrierung gesammelt. Die Herausforderung besteht darin, gegebenenfalls vorhandene Firewalls so zu konfigurieren, dass dies möglich ist.

In der MAP Dokumentation („Getting_Started_Guide.en.doc“ - Bestandteil des MAP Downloads) ist im Detail beschrieben, über welche Ports eine Kommunikation möglich sein muss. Der MAP Server kommuniziert über die TCP Ports 135, 139, 445 und die UDP Ports 137 und 138. Auf eine Besonderheit will ich an dieser Stelle hinweisen. Laut der Dokumentation ist die „Remote Administration exception“ in der Windows Firewall zu aktivieren. Nun soll es aber Kunden geben, die auch andere Firewalls im Einsatz haben (na so was). Konfiguriert man solch eine Firewall für die oben genannten Ports, so wird man feststellen, dass der MAP Server nicht in der Lage ist, die WMI Verbindung aufzubauen. Hier sehen sie das Flussdiagramm einer Kommunikation zwischen dem MAP Server (10.253.22.71) und dem Ziel (10.244.128.33):

Zu erkennen ist, dass der MAP Server die Verbindung zwar über Port 135 initialisiert, dann aber versucht, auf einen ausgehandelten Port (hier 1536 - rot markiert) zu wechseln. Da die Firewall dies blockiert, schlägt die WMI Verbindung fehl.

Eine Firewall muss also so konfiguriert sein, dass der MAP Server seinen ausgehenden Kommunikationsverkehr auf einen beliebigen High Port wechseln darf.

Die weiteren Voraussetzungen finden sie in der ebenfalls zum MAP Download gehörenden Datei „Release_Notes.en.htm“.

Noch ein Hinweis: In der Dokumentation steht, dass der Windows Installer Provider auf den zu inventarisierenden Maschinen zur Verfügung stehen muss. Das ist ab der MAP Version 4.0 nicht mehr notwendig. Der MAP Server liest die Liste der installierten MSI Pakete aus der Registrierung aus.

Installation von MAP

Die Installation von MAP ist ziemlich problemlos, naja, wenn man mal die Liste der Installationsvoraussetzungen abgearbeitet hat (siehe „Release_Notes.en.htm“). MAP speichert seine Daten in einem SQL Server ab. Wird nichts anderes spezifiziert, lädt die Installation den lizenzfreien Microsoft SQL Server 2008 Express von der Microsoft Download Webseite herunter und installiert und konfiguriert einen SQL Server Instanz mit dem Namen „MAPS“. Hat der MAP Server keine Verbindung zum Internet, können sie angeben, wo die Installationsdatei von SQL Server 2008 Express zu finden ist. Alternativ können sie auch eine bestehende SQL Server Instanz angeben, die aber mit auf dem MAP Server installiert sein muss. Der Name dieser SQL Server Instanz muss „MAPS“ sein.

Microsoft SQL Server 2008 Express hat eine Beschränkung auf 4 GB Datenbankgröße. Das ist auch für große Umgebungen in der Regel ausreichend. So hat z.B. die Inventarisierung und 4-wöchige Auslastungsanalyse einer Umgebung mit knapp 3.000 Servern zu einer 2,5 GB großen Datenbank geführt.

Ab ca. 5.000 Maschinen würde ich zu einer Installation von SQL Server 2008 Standard raten. Da es sich beim Einsatz dieses SQL Servers um eine zeitlich befristete Aktion handelt, können sie auch die Evaluierungs-Version von SQL Server 2008 nutzen.

MAP in Aktion – Die Inventarisierung

Nun kann’s endlich los gehen. Beim Start von MAP müssen sie zuerst eine Datenbank auswählen oder eine neue erzeugen. Wechseln sie dann auf den Punkt „Server Consolidation“. Alles was sie unter „Discovery and Readiness“ auswählen können, wird erst interessant, wenn sie Inventardaten haben.

Der Gesamtvorgang besteht aus den Schritten

1. Inventory Server Environment
2. Gather Performance Metrics
3. Configure Host and Run Analyses Engine

Bei einer neuen Datenbank sehen sie diese Punkte im Status „Incomplete“.

Mit Hilfe des „Inventory and Assessment Wizard“ wählen sie zuerst die Discovery Methode aus.

Die besten Discovery Methoden sind wohl die “Active Directory domain Services“ und die Möglichkeit, Computernamen aus einer Datei heraus zu lesen.

Fragen sie besser ihren Netzwerkadministrator, wenn sie „Scan an IP address range“ nutzen wollen. Ruck zuck hängt sonst ein Intrusion Detection System ihren MAP Server vom Netz ab (raten sie mal, wie ich das wohl herausgefunden habe…).

Achten sie darauf, dass ihr MAP Server alle Servernamen mit jedem auftauchenden DNS Domain Namen auch tatsächlich auflösen kann. MAP verwendet aus dem Active Directory den Full Qualified Domain Name (FQDN) des Active Directory Computer Objekts. Kann der DNS Server, den der MAP Server verwendet, nicht alle Servernamen auflösen, müssen sie im schlimmsten Fall eine ziemlich lange Liste in die Hosts-Datei des MAP Servers eintragen.

Je nach Discovery Methode müssen sie im Wizard unterschiedliche Informationen eintragen. Ganz am Ende kommt aber auf jeden Fall die Liste der Benutzerkonten, die für den Zugriff auf WMI und Registrierung genutzt werden soll.

Aus Sicherheitsgründen speichert MAP diese Liste übrigens nicht, sondern hält sie nur für die Dauer des Assessments im Speicher. Sobald sie das MAP Tool verlassen, hat MAP die Benutzerkonten vergessen. Sie müssen sie beim nächsten Mal wieder eingeben.

Die Benutzerkonten, die sie hier eingeben, werden in der Reihenfolge verwendet, in der sie in der Liste stehen. Ab besten ist es natürlich, wenn sie nur ein einziges Konto verwenden müssen, das auf allen Maschinen administrative Rechte besitzt. Haben sie aber mehrere unterschiedliche Domains oder viele Maschinen, die nicht in Domains sondern in Workgroups verwaltet werden, müssen sie gegebenenfalls mehrere Benutzerkonten eintragen, die der MAP Server dann in der richtigen Reihenfolge ausprobieren muss.

Die Inventarisierung geht verhältnismäßig schnell von statten. So hat beispielsweise ein virtualisierter MAP Server, der mit einer CPU und 2 GB Hauptspeicher ausgestattet war, 2.500 Server in ca. 2 Stunden inventarisiert, wobei diese Server auf 20 Standorte in ganz Europa verteilt waren.

Einige Hinweise zur Inventarisierung:

• Wenn sie mehrere Inventarisierungsläufe starten, addieren sich die Informationen in der Datenbank. Sie können also den MAP Server z.B. auf einen Laptop installieren und diesen dann zu verschiedenen Standorten tragen, um dann vor Ort eine Inventarisierung machen.
• Die Inventarisierung belastet das Netzwerk mit 512 KB bis ca. 1 MB pro inventarisierter Maschine. Der Hauptgrund für diese unterschiedlichen Werte ist in der unterschiedlichen Anzahl der installierten MSI Pakete zu suchen.

Ab jetzt macht es Spaß, auf die verschiedenen Auswertungen im Bereich „Discovery and Assessment“ zu klicken:

Für jeden Bereich gibt es unter „Actions“ die Möglichkeit, sich die entsprechenden Auswertungen erstellen zu lassen. Diese werden dann als Excel- und/oder Word-Format im Verzeichnis „DocumentsàMAPà<Name der MAP Datenbank>“ abgespeichert. Über den Menüpunkt „ViewàSaved Reports and Proposals“ gelangen sie direkt dorthin.

Sammeln der Auslastungsdaten

Am Anfang dieses Prozesses steht eine Text-Datei. In dieser stehen die Namen aller Maschinen, für die Auslastungsdaten gesammelt werden sollen. Falls sie diese Datei nicht ohnehin schon für die Inventarisierung erstellt haben, können sie sie auch aus der Excel-Datei erstellen, die ihnen z.B. der Windows Server 2008 Readiness Report erstellt. Im Rahmen dieser Auswertung wird die Datei „WS2008HardwareAssessment-<Datum und Uhrzeit der Erstellung>.xlsx“ erzeugt. Im Arbeitsblatt „ServerInventory“ finden sie die Namen aller inventarisierten Server. Daraus eine Textdatei mit den Servernamen zu extrahieren sollte ein Leichtes sein.

Im nächsten Schritt haben sie wieder die Benutzerkonten anzugeben, mit denen die Auslastungsdaten eingesammelt werden. Das Verfahren habe ich weiter oben bereits beschrieben.

Zuletzt müssen sie angeben, wie lange der MAP Server Auslastungsdaten sammeln soll. Um repräsentative Werte zu erhalten sollten sie mindestens vier Wochen Daten sammeln. So können sie z.B. auch monatlich auftretende Auslastungsspitzen erfassen.

Einige Hinweise zur Sammlung der Auslastungsdaten:

• Leider sind die Datensammlungen nicht additiv wie im Fall der Inventarisierung. Jeder Lauf des „Performance Metrics Wizards“ löscht die in der Datenbank befindlichen Daten.
• Solange die Datensammlung läuft, muss der Benutzer angemeldet sein und das MAP Tool muss laufen. Am besten sperren sie den Bildschirm.
• Verhindern sie, dass ein anderer Benutzer sich an der Maschine anmeldet und damit ihre Sitzung beendet.
• Verhindern sie, dass der MAP Server in der Zeit, in der er die Auslastungsdaten einsammelt, neu gestartet wird. Deaktivieren sie automatische Updates, nehmen sie ihn aus Softwareverteilungsmechanismen heraus und verwenden die Hardware, die gar nie kaputt geht :-).
• Es ist durchaus möglich, dass der MAP Server über die gesamte Zeit der Datensammlung auf nahezu 100% CPU-Last läuft, insbesondere, wenn sich in ihrer Umgebung sehr viele Workgroup-Server befinden. Sollte ihr MAP Server virtuell laufen: Das gefällt in der Regel den Jungs von der Virtualisierungstruppe nicht sonderlich und sie könnten auf die Idee kommen, den Server neu zu starten (auch hier eine leidvolle Erfahrung).
• Der MAP Server sammelt CPU-, Hauptspeicher-, Netzwerk- und I/O-Auslastungsdaten ein. Die in den Ergebnisauswertungen angezeigten CPU- und Hauptspeicher-Werte sind Durchnittswerte, Netzwerk- und I/O-Werte sind Maximalwerte.
• Der MAP Server startet auf den Maschinen die Auslastungsmessung und holt die Werte dann alle fünf Minuten ab, wobei jeweils ca. 1 MB Daten übertragen werden. Es werden je nach Ausstattung des MAP Servers bis zu 200 Maschinen gleichzeitig abgefragt.

Nach der angegebenen Zeit stehen ihnen die Ergebnisse der Datensammlung zur Verfügung.

Wenn sie „nur“ einen Einblick in ihre Infrastruktur gewinnen wollten, können sie sich nun noch die Auswertung in Form einer Excel-Datei erzeugen lassen und an dieser Stelle nun aufhören.

Haben sie aber vor, sich des Themas Servervirtualisierung anzunehmen, wird es nun erst richtig interessant.

Um diesen Eintrag aber nicht überzustrapazieren werde ich dieses Thema in einem nächsten Blog-Eintrag behandeln.

Kostenloses e-Book zu Windows Server 2008 R2

Aktuell bietet Microsoft ein kostenloses e-Book an, das eine Einführung in Windows Server 2008 R2 gibt. Das e-Book steht hier zum Download bereit.

Viel Spaß beim Lesen wünscht Jochen Katz

Support-Lebenszyklus für Microsoft-Produkte

Am 13.07.2010 läuft der Extended Support für Windows 2000 Server und Windows 2000 Professional aus, gleichzeitig wechseln Windows XP und Windows Server 2003 vom Mainstream Support in den Extended Support. “Mainstream Support”, “Extended Support” – was genau bedeutet das eigentlich? Die folgende Tabelle fasst das wesentliche übersichtlich zusammen:

Der wichtigste Punkt ist sicher, daß neue Sicherheitsupdates nach Ende des Extended Support nicht mehr zur Verfügung gestellt werden. Die bereits veröffentlichten Sicherheitsupdates bleiben natürlich verfügbar, aber neu entdeckte Sicherheitslücken werden nicht mehr geschlossen. Für alle PCs und Server, die sich in einem Netzwerk befinden, ist daher ein rechtzeitiger Wechsel auf eine neuere Version dringend zu empfehlen!

Mit freundlichen Grüßen!

Ralf M. Schnell

Advanced Windows Troubleshooting with Sysinternals Process Monitor

Hallo, Fabian schreibt. Auf der Suche nach einem interessanten Blog Thema kam mir in den Sinn, einen kurzen Blog oder Webcast zum Thema Process Monitor fertig zu machen. Es gibt einige Programme, bei denen man sich fragt: “Wie habe ich eigentlich gearbeitet, bevor ich dieses Tool hatte?” – der ProcMon zählt definitiv dazu.

Bevor man dann mit so einem Blog-Vorhaben beginnt, schaut man natürlich, ob das Thema nicht schon allumfänglich irgendwo in der großen Weite des World Wide Webs aufgegriffen wurde. Und falls ja, ob man trotzdem etwas dazu beginnt, um vielleicht andere Schwerpunkte zu setzen o.ä.

Na ja – was soll ich sagen? Ich wurde fündig, denn es gibt zu dem Thema einen Webcast von Mark Russinovich. Jeder, der den Namen kennt, weiß, daß man das Thema wohl kaum besser gestalten kann als einer der Autoren des Programms. ;-)

Von daher an dieser Stelle der Link zum (englischen) Webcast, der meiner Meinung nach wirklich sehr gut ist: http://www.microsoft.com/emea/spotlight/sessionh.aspx?videoid=346

Sollte von Euch dennoch Interesse bestehen, daß wir dazu einmal einen deutschen Blog oder Webcast fertig machen, dann nutzt die Kommentarfunktion und ruft einfach “Zugabe, Zugabe, Zugabe!” ^^

Viele Grüße
Fabian

Mein Einstand!

Wie der Titel schon sagt gebe ich mit diesem Eintrag mein Debüt auf dem deutschen Windows Server Blog!

Mein Kollege Ralf S. hat mich genö…  ähhmm, gebeten endlich was zu meinen Themen zu schreiben. Recht hat er!
Aber erst mal der Reihe nach. Mein Name: Bernhard Frank, mein Titel: Web Platform Architect Evangelist (Anm. d. Autors „den hab ich mir nicht ausgedacht“), mein Thema: In meiner Bio heißt es:
„Er konzentriert sich derzeit auf den Bereich Webhosting mit Microsoft Technologien, ein durch die gegenwärtige Marktlage - spannendes Thema, wie er findet.“

Ich bin noch ein bisschen schüchtern und gespannt ob meine Themen und mein Sprach-Mix als Entwicklistrator oder Administwickler hier Gefallen finden.

Zum obligatorischen Einstands-Kuchen kann ich leider nicht laden, versuche aber das in Form von virtuellen Sahnestücken aus den Bereichen Web, IIS, Hosting soweit für Administratoren relevant, nachzureichen.

Viel Spaß,
Bernhard Frank

Hochverfügbarkeit für DHCP: Statische oder Dynamische IP-Konfiguration?

DHCP oder nicht DHCP – das ist hier die Frage! In den sechs Jahren, die ich bei Microsoft IT angestellt war, herrschte dort ein Konsens: alles mit DHCP, was irgend möglich ist, auch Server. Ich schien der einzige zu sein, der die Meinung vertrat, alle Server seien so statisch wie irgend möglich zu konfigurieren, und der sämtliche Netzwerk-Interfaces manuell konfigurierte. Sehr gut erinnere ich mich noch an den Kommentar meines Nachfolgers, den ich hier aus Gründen des Jugendschutzes leider nur mit ‘Beeeeep!!!’ wiedergeben kann …

Ein ernsthafter Versuch einer Antwort auf diese Frage muß mehrere Aspekte berücksichtigen. Der einfachste ist der rein technische Aspekt: es gibt einige Server-Rollen, die zwingend eine statische IP-Konfiguration benötigen. Dazu gehört DNS, aber z.B. auch DHCP (Router adressieren DHCP-Anfragen bei der Weiterleitung an statische IP-Adressen). Die meisten Server-Rollen benötigen dagegen keine statische IP-Konfiguration, das gleiche gilt für die meisten Server-Applikationen. Aus diesem – recht einseitigen - Blickwinkel betrachtet ist die Antwort leicht: DHCP immer dann, wenn’s technisch möglich ist.

Ein anderer Aspekt ist die Überlegung, daß es einen grundlegenden Unterschied zwischen Client- und Serversystemen gibt, der wiederum eine grundsätzlich andere Zielsetzung bei deren Konfiguration und Verwaltung mit sich bringt. Clientsysteme sind sehr häufig dynamische Systeme. Ihre Software unterliegt einer relativ hohen Änderungsrate, wechselt zum Teil mit jeder neuen Benutzeranmeldung, Treiber und ggf. Firmwareversionen werden häufig aktualisiert, Notebooks werden oft auch physikalisch bewegt. Eine statische Konfiguration widerspricht ein gutes Stück weit der Zielsetzung eines Desktop-Systems. Nicht umsonst bietet gerade die Desktop- und Applikationsvirtualisierung ein so großes Potential zur Wertsteigerung und gleichzeitiger Kostenreduktion für Desktopsysteme: die Entkoppelung der Applikationen untereinander und vom Desktop selbst erlaubt eine noch größere Flexibilität. Natürlich gibt es auch relativ statische Desktop-Systeme. Je intensiver die IT jedoch den Erfolg eines Unternehmens mitbestimmt, desto mehr ist Flexibilität und Dynamik auf dem Desktop ein wesentlicher Mehrwert.

Server hingegen sind Systeme, bei denen Änderungen sehr viel seltener – und dann mit sehr viel mehr Aufwand für Tests und Fall Back-Prozeduren – durchgeführt werden. Das liegt auch daran, daß Server oft zahlreiche und komplexe Abhängigkeiten untereinander aufweisen, was dazu führt, daß Änderungen mitunter zu erstaunlichen Resultaten führen. Die Erfahrung lehrt jeden Administrator früher oder später, daß Dynamik im Server-Umfeld gleichzusetzen ist mit Unberechenbarkeit. Statische Konfiguration führt zu vorhersagbarem Verhalten und – bei ausreichend guter Planung – zu mehr Verfügbarkeit. Das gilt für IP-Konfiguration genauso wie z.B. für SANs und Host Bus Adapter.

Selbstverständlich funktioniert ein Server im Normalfall zuverlässig, auch wenn seine Netzwerk-Konfiguration über DHCP durchgeführt wird. Es existiert jedoch dann eine zusätzliche Abhängigkeit zu DHCP, und damit gibt es eine ganze Reihe von Möglichkeiten, über diese Abhängigkeit den Server nachhaltig zu stören: DHCP fällt aus, der Scope hat zu wenige Adressen, ein DHCP-Restore löscht die Informationen über bereits vergebene Adressen und der DHCP-Server vergibt diese dann doppelt, …, … diese Liste kann man durchaus noch verlängern.

ITIL und administrative Erfahrung lehren uns, daß Verfügbarkeit und Zuverlässigkeit nur dann nachhaltig gesteigert werden können, wenn Abhängigkeiten zwischen Systemen so weit wie möglich reduziert werden und die verbleibenden Abhängigkeiten vollständig dokumentiert und proaktiv verwaltet sind. Aus diesem Grund habe ich für mich die Frage “DHCP oder nicht DHCP?” umgekehrt – zu rechtfertigen ist die dynamische Konfiguration, nicht die statische. Bei Desktop-Systemen, zumal bei Notebooks, macht eine statische Konfiguration schlichtweg keinen Sinn, daher ist der Einsatz von DHCP die logische Konsequenz. Daß das bei Server-Systemen anders ist, zeigt wiederum beispielhaft eine Erfahrung aus meiner Zeit bei Microsoft IT. Dort war ein Server in einer Zweigstelle mit DHCP über das WAN konfiguriert. Murphy hat das gesehen, das WAN fiel aus, und obwohl alle benötigten Dienste und Daten lokal auf dem Server vorhanden waren, konnte nach kurzer Zeit kein Benutzer mehr arbeiten. Der zuständige Kollege versuchte dann, über ein Modem auf das Management-Interface des Servers zu kommen, um nachträglich eine statische IP-Konfiguration und einen DHCP-Scope zu konfigurieren. Nur war das Management-Interface ebenfalls per DHCP konfiguriert und somit ebenfalls nicht erreichbar …

Auch im Rechenzentrum ist übrigens Virtualisierung das wichtigste Mittel, um Dynamik und Zuverlässigkeit gleichermaßen zu realisieren. Die Entkoppelung von Hardware und Betriebssystemen dient genau diesem Ziel, und Applikations-Virtualisierung für Server-Applikationen oder sogar Server-Rollen ist eine Technologie, deren Einzug ins Rechenzentrum im Laufe der nächsten Jahre absehbar ist.

Mit freundlichen Grüßen!

Ralf M. Schnell

TechNet Webcast: Migration von Windows 2000 Server nach Windows Server 2008 R2

Nein, der 13.07. 2010 ist kein Freitag! Aber es ist ein wichtiges Datum: An diesem Tag endet der Support für Windows 2000 Server. In dem Beitrag “Support für Windows 2000 Server endet am 13.07.2010” habe ich bereits auf die Konsequenzen hingewiesen. Fehlende Support-Optionen machen den Upgrade zu neueren Server-Versionen zu einer Notwendigkeit, die neuen Funktionen in Windows Server 2008 R2 sind ein noch viel besseres Argument, die Ablösung von Windows 2000 Server-Systemen jetzt zeitnah zu planen und durchzuführen.

Die neuen Funktionen in Windows Server 2008 R2 haben wir bereits in zahlreichen Webcasts und TechNet Edge-Videos beschrieben. Speziell zu den technischen Aspekten der Migration von Windows 2000 zu Windows Server 2008 R2 bieten wir für Sie nun einen Live-Webcast an:

TechNet Webcast: Windows 2000 Server: Optionen für die Migration (Level 200)
Datum: 21.10.2009, 11:00 – 11:40 Uhr
Referent: Ralf Schnell
Anmeldung: http://www.microsoft.com/germany/events/eventdetail.aspx?EventID=1032427931

In diesem Webcast geht es einerseits um besondere Probleme bei der Migration und um die notwendigen Prozesse – so ist z.B. ein ‘Rolling Upgrade’ eines Clusters nicht möglich! Andererseits geht es um die notwendigen Vorbereitungen – u.a. werden wir mit dem Microsoft Assessment and Planning Toolkit nach vorhandenen Windows 2000 Server-Instanzen suchen.

Mit freundlichen Grüßen!

Ralf M. Schnell

Hochverfügbarkeit für DHCP: IPv4 vs. IPv6

In dem Beitrag “Hochverfügbarkeit für DHCP: Optionen für Windows Server” habe ich die grundlegenden Optionen beschrieben, die verfügbar sind, um einen DHCP-Server gegen ungeplante Ausfälle abzusichern. Es gibt allerdings Unterschiede zwischen IPv4 und IPv6, die beachtet werden sollten. Diesem Thema möchte ich mich in diesem Beitrag widmen.

Für die Konfiguration einer IPv4-Adresse gibt es zwei Optionen: die statische Konfiguration in den Eigenschaften der Netzwerk-Karte und die automatische Konfiguration. Letztere gibt es wiederum in zwei Varianten: Auto-Konfiguration der Netzwerkkarte und Konfiguration über DHCP. Die Auto-Konfiguration der Netzwerkkarte benutzt das Subnet 169.254.0.0/48, welches zwei wesentliche Einschränkungen mit sich bringt. Zum einen ist das Subnet nicht Routing-fähig, es gibt also keine Kommunikation außerhalb des physikalischen Subnets. Zum anderen benutzen dieses Subnet ausschließlich Geräte ohne gültige IP-Konfiguration, also ist auch innerhalb des eigenen physikalischen Subnets die Kommunikation eingeschränkt – alle Geräte, die noch eine gültige Konfiguration haben, werden nicht erreicht.

Die eingeschränkte Verwendbarkeit der automatischen Konfiguration (ohne DHCP, also 169.254.0.0/48) hängt mit einem grundlegenden Unterschied zwischen IPv4 und IPv6 zusammen. IPv4-Nodes haben keinerlei eigene eindeutige Adresse, sondern müssen diese über DHCP oder per statischer Konfiguration zugewiesen bekommen. Hat mein Notebook z.B. die Adresse 192.168.145.17 mit dem Subnet 255.255.255.0, dann ist ‘17’ die eigentliche eindeutige Adresse. Zwischen der ‘17’ und meinem Notebook bzw. meiner Netzwerkkarte gibt es jedoch keinerlei permanenten Zusammenhang.

Das ist bei IPv6 anders: dort wird die MAC-Adresse der Netzwerkkarte benutzt um jedem Gerät eine eindeutige – und damit garantiert konfliktfreie – Adresse zuzuweisen. Diese Adresse wird dann, wie bei IPv4, um ein Subnet ergänzt, das nicht Routing-fähig ist. Der nächste wichtige Unterschied zu IPv4 ist, daß alle IPv6-Nodes eine solche Adresse bilden, auch wenn sie eine gültige IPv6-Konfiguration bekommen. Es kann also jetzt mit jedem IP-Node innerhalb des physikalischen Subnets kommuniziert werden. Für Zweigstellen, die nur aus einem Subnet bestehen, ist somit die Kommunikation mit allen lokalen Ressourcen vollständig gewährleistet.

Der dritte wichtige Unterschied zwischen IPv4 und IPv6 ist, daß es für IPv6 eine zusätzliche Option gibt, um ein gültiges Subnet zu konfigurieren. Bei IPv6 kann das ein Router übernehmen. Ein IPv6-Node sucht bei der Initialisierung im eigenen Subnet nach einem IPv6-Router, und wenn er einen findet, der korrekt konfiguriert ist, dann bezieht er von diesem Router die korrekte Subnet-Information. Zusammen mit der eigenen Adresse, die aus der MAC-Adresse berechnet wird, hat das IP-Node dann eine vollständig gültige, Routing-fähige Adresse, und zwar ohne DHCP-Server und ohne die Notwendigkeit einer statischen Konfiguration.

DHCP kann bei IPv6 zwar auch benutzt werden, um analog zu IPv4 die vollständige IP-Konfiguration zu setzen, dies ist jedoch meist nicht die effizienteste Anwendungsart. Verwenden Sie Ihre IPv6-Router, um die Subnet-Konfiguration zu publizieren, und DHCP ausschließlich dafür, diejenigen IP-Attribute zu konfigurieren, die von Ihren Router nicht gesetzt werden können (z.B. DNS Server-Einträge). Dann haben Sie auch bei Ausfall Ihres DHCP-Servers eine weitestgehend uneingeschränkte Netzwerk-Kommunikation.

Mit freundlichen Grüßen!

Ralf M. Schnell

Hochverfügbarkeit für DHCP: Optionen für Windows Server

Die Vergabe von gültigen IP-Adressen ist eine Grundvoraussetzung für jede Kommunikation in einem Netzwerk und damit eine kritische Komponente jedes IT-Service. In fast allen IT-Infrastrukturen kommt dabei DHCP zum Einsatz. Ob und in welchen Fällen DHCP die beste Lösung ist, bespreche ich in einem eigenen Blog-Artikel; für diesen Artikel gehen wir davon aus, daß ein DHCP-Server verwendet wird. Der wird somit potentiell zu einem ‘Single Point of Failure’ in der IT-Architektur, und eine gut durchdachte Hochverfügbarkeits-Lösung ist unverzichtbarer Bestandteil einer jeden Verfügbarkeits- und Desaster Recovery-Planung.

Bezüglich der Auswirkungen eines Ausfalls des DHCP-Servers auf die Verfügbarkeit der IT-Services muß man zum einen die Funktionsweise des DHCP-Protokolls berücksichtigen und zum anderen zwischen IPv6 und IPv4 unterscheiden.

Funktionsweise des DHCP-Protokolls

Ein DHCP-Client fragt prinzipiell immer bei der Initialisierung des Netzwerk-Protokolls einen DHCP-Server an. Die Initialisierung findet statt im Rahmen eines Neustarts des DHCP-Client und beim Erkennen einer neuen Verbindung (also z.B. beim einstecken des Netzwerkkabels). Die Protokoll-Sequenz ist ziemlich einfach:

‘DHCPDiscover’ wird vom Client per Broadcast gesendet (geht ja auch nicht anders – eine IP-Konfiguration ist ja noch nicht verfügbar …) und ggf. von einem Router weitergeleitet. Auf einen Broadcast antworten alle DHCP-Server im Subnet, die eine passende Adresse anzubieten haben, mit ‘DHCPOffer’. Wird die Client-Anfrage dagegen von einem Router weitergeleitet, so geschieht das in der Regel unter Verwendung einer statischen IP-Adresse des DHCP-Servers, und es antwortet dann natürlich auch nur dieser eine DHCP-Server.

Neben der Initialisierung des Netzwerk-Protokolls ist die Reservierungs-Dauer der IP-Konfiguration wichtig. Der DHCP-Server gibt diese als Attribut der IP-Konfiguration dem Client mit; festgelegt wird sie vom DHCP-Administrator. Jeder DHCP-Client fängt mit Ablauf der Hälfte der Reservierungs-Dauer an, einen DHCP-Server zu kontaktieren, um die Reservierung zu verlängern. Gelingt das nicht, verfällt die IP-Konfiguration nach Ablauf der Reservierungsdauer.

Ist ein DHCP-Server nicht verfügbar, dann wird ein DHCP-Client in folgenden Fällen keine gültige IP-Konfiguration erhalten:

• Neustart des Client-Computers
• Neue Verbindung zum Netzwerk (z.B. Netzwerk-Kabel abgezogen und wieder eingesteckt, Notebook ab- und wieder angedockt, aufwachen aus dem Stand-By)
• Reservierungs-Dauer der IP-Konfiguration abgelaufen

Das bedeutet: wenn der DHCP-Service ausfällt, bricht die Kommunikation im Netzwerk nicht gleich zusammen, man muß jedoch damit rechnen, daß sich die Supportanfragen um so mehr häufen, je länger der Dienst nicht verfügbar ist.

Hochverfügbarkeits-Optionen: Sicherung der DHCP-Konfiguration (Cold Stand-By)

Eine der am wenigsten aufwändigen Methoden, um die Verfügbarkeit des DHCP-Dienstes sicherzustellen, ist ein ‘Cold Stand-By’. Nach ITIL heißt das: es ist zwar ein Server verfügbar, der den DHCP-Dienst jederzeit übernehmen könnte, dieser ist jedoch in keiner Weise dafür konfiguriert. Man sichert lediglich die DHCP-Konfiguration in regelmäßigen Abständen und testet die Wiederherstellung dieser Konfiguration auf einem anderen Server. Randbemerkung: Ist überhaupt kein anderer Server im Netzwerk verfügbar, dann ist der Ausfall des DHCP-Dienstes ohnehin ihr geringstes Problem … ;-)

Die Sicherung der DHCP-Konfiguration kann manuell erfolgen (in der DHCP-Konsole gibt es eine Backup-Funktion im Kontext-Menü des DHCP-Servers), oder automatisiert per Skript. Dafür bietet sich ‘netsh’ an: ‘netsh dhcp server backup ?’ zeigt die gültige Syntax an.

Für die Wiederherstellung des Dienstes muß dann jeweils entschieden werden, ob man den ursprünglichen DHCP-Server benutzt und z.B. neu installiert, oder ob man irgendeinen anderen Server verwendet. Auf diesem kann dann die statische IP-Adresse des ursprünglichen Servers zusätzlich gebunden werden, die DHCP-Rolle ist zu installieren und die DHCP-Konfiguration ist wiederherzustellen. Alles in allem sollte das in 15-30 Minuten erledigt sein.

Kritisch ist hier eher die Frage, woran man merkt, daß der DHCP-Dienst ausgefallen ist. Wird der nicht überwacht (z.B. mit dem System Center Operations Manager), dann ist der erste Hinweis ein Anruf eines Benutzers beim Helpdesk … und dann können 15-30 Minuten schon wieder zu viel sein.

Hochverfügbarkeits-Optionen: Warm Stand-By

Geht man davon aus, daß ein Ausfall des DHCP-Servers die häufigste Ursache für einen Ausfall des DHCP-Dienstes ist, dann ist es naheliegend, sich mit Hilfe einer alternativen Server-Instanz dagegen abzusichern. Server gibt es in den meisten Infrastrukturen mehr als genug, und da DHCP als Dienst nicht allzuviel Last erzeugt, kann man die Rolle theoretisch jedem beliebigen Server als ständig laufende Komponente hinzufügen. Allerdings dürfen aktive DHCP-Scopes sich nicht überlappen! Ein guter Kompromiss ist ein ‘Warm Stand-By’: komplett konfiguriert, aber passiv, und mit sehr wenig Aufwand jederzeit aktivierbar. Das bedeutet: wir konfigurieren auf einem alternativen DHCP-Server Kopien aller DHCP-Scopes und lassen diese deaktiviert. Um Fehler zu vermeiden, sollten die Konfiguration und der periodische Abgleich automatisiert per Skript erfolgen (siehe dazu den Abschnitt ‘Cold Stand-By’). Die Aktivierung kann dann manuell erfolgen, oder man integriert diesen Vorgang in die Systemüberwachung (z.B. mit dem System Center Operations Manager) und triggert die Aktivierung per Skript.

Zu bedenken sind die folgenden Punkte:

• IP-Adresskonflikte: Ein DHCP-Client wird immer versuchen, seine bestehende Konfiguration zu erneuern. Der alternative DHCP-Server kennt die bereits vergebenen Adressen jedoch nicht vollständig, da seit der letzten Sicherung und Wiederherstellung ggf. einige Zeit vergangen ist, und wird daher evtl. eine bereits aktive Adresse erneut vergeben. Um dies zu vermeiden, sollte man die Prüfung der Adressen aktivieren. Das macht man in der DHCP-Konsole in den IPv4-Optionen (dort ‘Eigenschaften’ - ‘Erweitert’). Der DHCP-Server prüft dann pro Anfrage bis zu fünf Adressen per Ping und markiert diese ggf. als belegt.
• Statische Adresse des DHCP-Servers: Werden DHCP-Anfragen aus anderen Subnets über die Router weitergeleitet, dann zeigen die Router-Konfigurationen auf eine statische IP-Adresse, nämlich die des primären DHCP-Servers. Bei einem Failover muß dann entweder die Router-Konfiguration geändert werden, oder (wesentlich einfacher) die statische IP-Adresse an den sekundären Server gebunden werden.

Hochverfügbarkeits-Optionen: Failover Clustering

DHCP ist eine der bereits vordefinierten Rollen des Windows Failover Clusters. Die administrativ einfachste Art, sich gegen einen Ausfall des DHCP-Servers zu sichern, ist daher die Integration in einen Cluster – es sei denn, man hat in seiner Infrastruktur noch keinerlei Cluster zur Verfügung. Einzig und allein für DHCP einen Cluster aufzusetzen ist zwar relativ einfach (Shared Storage ist dafür nicht nötig!), bedingt jedoch ein Training der Administratoren für den Failover Cluster. Aber vielleicht möchten Sie ja bei dieser Gelegenheit die Hochverfügbarkeit weiterer Dienste konfigurieren und dafür den Failover Cluster ebenfalls benutzen … ;-)

Diese Option ist eine Kreuzung aus Warm Stand-By und Hot Stand-By: Einerseits ist die DHCP-Konfiguration und auch die Liste der aktiven Adressen auf jedem Cluster-Knoten stets verfügbar und aktuell und mit sehr geringer zeitlicher Verzögerung aktivierbar (also fast Hot Stand-By), andererseits ist eben auch nur eine Instanz der DHCP-Konfiguration vorhanden. Wird die DHCP-Konfiguration korrumpiert, dann bietet der Cluster keine Möglichkeit mehr, diese wieder zu korrigieren. Zusätzlich zum Einsatz des Clusters sollte daher auf jeden Fall eine regelmäßige Sicherung (siehe ‘Cold Stand-By’) vorgenommen werden.

Hochverfügbarkeits-Optionen: Split Scope (Hot Stand-By)

Neu in Windows Server 2008 R2 ist die Option ‘Split Scope’. Damit teilt man einen DHCP-Scope auf zwei DHCP-Server auf. Einer der Server antwortet optional verzögert auf DHCP-Anfragen, so daß zunächst die verfügbaren IP-Adressen des anderen Servers vergeben werden. Dann würde man z.B. 80% der Adressen des Scopes auf den Server legen, der ohne Verzögerung antwortet. Man kann aber auch problemlos je die Hälfte der Adressen auf einen der Server legen und die Verzögerung der Antwort deaktivieren. Dann antworten beide Server gleichzeitig, aber der DHCP-Client reagiert nur auf eine der Antworten, so daß auch nur eine Adresse von einem der DHCP-Server vergeben wird. Meine Empfehlung ist, auf jeden Fall die Verzögerung der Server-Antwort zu konfigurieren, denn aufgrund der physikalischen Netzwerkkonfiguration werden die beiden DHCP-Server ohnehin fast nie wirklich gleichzeitig antworten. Einer (immer der gleich) wird meist früher reagieren, und die gleichmäßig aufgeteilten Scopes werden eben nicht gleichmäßig verwendet werden. Da macht es dann mehr Sinn, das Verhalten der Server mit Hilfe der Antwort-Verzögerung bewußt zu steuern.

Mit freundlichen Grüßen!

Ralf M. Schnell

Support für Windows 2000 Server endet am 13.07.2010

Der ‘Extended Support’ für Windows 2000 Server (W2K) läuft am 13.07.2010 aus. Das bedeutet: Kunden, die noch Windows 2000 Server einsetzen, bekommen ab diesem Zeitpunkt nur noch ‘Self-Help Online Support’, also z.B. Knowledge Base-Artikel. Hotfixes werden ab diesem Zeitpunkt nicht mehr bereitgestellt.

Microsoft informiert ganz bewußt sehr frühzeitig über diesen Vorgang, da viele Kunden Windows 2000 Server noch im Einsatz haben, z.B. als Domain Controller. Prüfen Sie also am besten gleich, ob Sie hiervon betroffen sind, damit Ihnen genügend Zeit zur Umstellung der relevanten Systeme bleibt!

Gleichzeitig tritt Windows Server 2003 (WS03) in die ‘Extended Support’-Phase ein. Damit werden Security-relevante Hotfixes nach wie vor jedermann zur Verfügung gestellt, für alle anderen Hotfixes benötigen Sie jedoch einen ‘Extended Hotfix Support’-Vertrag. Diesen müssen Sie innerhalb von 90 Tagen nach dem 13.07.2010 abschließen!

Nähere Informationen finden Sie auf dem englischen Windows Server Blog oder in den Erläuterungen zum Produkt-Lebenszyklus.

Mit freundlichen Grüßen!

Ralf M. Schnell

Hyper-V™ Server 2008 R2 steht zum kostenlosen Download bereit

Der Hyper-V Server 2008 R2 steht jetzt zum kostenlosen Download bereit. Mit neuen Features wie Live Migration und erweiterter Prozessor- und Arbeitsspeicherunterstützung für Hostsysteme ermöglicht es Hyper-V Server 2008 R2 Unternehmen, Workloads auf einem einzigen physischen Server zu konsolidieren. Der Download ist verfügbar unter:
http://technet.microsoft.com/de-de/evalcenter/dd776191.aspx

Viel Spaß beim Virtualisieren

Jochen Katz