Schlagwort-Archive: Windows Server

Windows Server 2012 R2 (Build 9600) auf HP Microserver N36L

In meinem Hardware-Park darf ich auch einen HP Microserver N36L mein eigen nennen. Im Jahr 2011 habe konnte ich bereits Testberichte über den N36L in Bezug auf Windows 7 bzw. Windows Server 2008 R2 liefern (hier, ich war der Projektkollege).

Nun folgt vor kurzem ein weiterer kleiner Machbarkeits-Test für die inzwischen etwas betagte Lady mit Windows Server 2012 R2 (Build 9600).

Leider verlief die Installation nicht ganz so reibungslos wie beim Windows Server 2008 R2.

Das initiale Betanken mit dem Image klappte, jedoch stockte es beim ersten in dem Punkt „Getting devices ready“ bei genau 84%. In meinem Microserver N36L war sowohl Remote Access Karte als auch eine Intel PRO/1000 PT Dual Port Netzwerkkarte verbaut. Da es sich offensichtlich um ein Hardwarethema begann ich Geräte zu deaktivieren. Erster Ansatz war der Onboard Netzwerkchipsatz (Sorry Broadcom), da dieser Port unter Windows Server 2008 R2 Hyper-V eh deaktiviert war kein starker Verlust und siehe da, die Maschine installierte nun sauber durch.

Die Installation von Windows Server 2012 R2 (Build 9600) klappte problemlos. Alle weiteren Geräte und Treiber wurden erkannt.

Die Intel PRO/1000 PT Dual Port Netzwerkkarte läuft im LACP Teaming. Eine weitere Intel Gigabit-CT-Desktop-Adapter dient als Management-Interface für den darauf laufenden Hyper-V Host.

Um der Parent-Partition etwas „boost“ zu geben hängt eine kleine SSD am SATA Port, der ursprünglich mal für ein 5,25″ Laufwerk gedacht war.

Noch ein Tipp:Der Original-Lüfter ist inzwischen gegen einen Sharkoon SILENT EAGLE 1000 (120mm) getauscht. So ist das Gerät nahezu geräuschlos.

Windows Server 2012 R2 (Build 9600) auf HP DL380 G5

Obwohl es seitens HP, meines Wissens, keinen offiziellen Support mehr für Windows Server 2012 R2 auf einem HP DL380 G5 gibt, war es mal einen Versuch wert. Erfolg!

Wie? Da in div. Foren ggf. Probleme mit dem Controller P400 dokumentiert sind, habe ich vor der Windows Server 2012 R2 Installation das Supportpack 2013.09.0 drüber laufen lassen (es war noch ein Windows Server 2008 R2 enthalten) um auch alle Firmware-Stände aktuell zu bekommen.

Die Installation des Windows Severs 2012 R2 lief problemlos durch. Einige Geräte wurden nicht sauber erkannt, jedoch konnte ich nach der Installation des Windows Servers 2012 R2 das Supportpack 2013.09.0 nochmal drüber laufen lassen. Beim ersten Durchlauf schlugen einige Installationen fehl, der zweite Rest lief dann sauber durch.

Alle Geräte im Device Manager laufen, IML als auch HP System Management Homepage sind sauber und Windows Eventlog auch. Danach der Hyper-V Test – auch hier alles ok.

Virtuelle Maschine sporadisch nicht erreichbar

Gestern erreichte mich ein Problem, dass nach dem Umbau div. Hyper-V Singlehosts zwei virtuelle Maschinen auf einem neuen Host sporadisch nicht mehr erreichbar waren. Die Umgebung bestand aus div. HP Procuve Switchen incl. einem L3 Switch sowie div. HP Proliant DL Servern. Die Hyper-V Hosts hatten Windows Server 2008 R2 Enterprise und die virtuellen Maschinen Windows Server 2008 R2 Standard.

Ein Dauerping auf eine der betroffenen virtuellen Maschinen zeigte sporadische Timeouts.

Das riecht nach Troubleshooting. Beginnen wir mit dem Layer 1 – nachdem die Verkabelung zum betroffenen Singlehost geprüft und die Zuordnung der virtuellen Netze im Hyper-V Manager geprüft war ging direkt auf die nächste Ebene. Da es nach einem Netzwerkproblem aussieht (sogar ICMPs gehen nicht durch) könnte der Fehler bereits im Layer 2 liegen.

Gesagt getan, erster Punkt, pingen vom Routerinterface des VLANs. Auch hier klappte es mal und mal nicht – gleiches Fehlerbild.

sw1# ping 10.10.1.10
10.10.1.10 is alive, time = 6 ms
Request timed out.
Request timed out.
Request timed out.
10.10.1.10 is alive, time = 1 ms
10.10.1.10 is alive, time = 1 ms
10.10.1.10 is alive, time = 1 ms

Als nächstes liegt es also nahe zu prüfen, ob die MAC Adresse hinter der virtuellen Maschine mit der IP 10.10.1.10 auch wirklich an dem Port des Public-Interfaces vom Hyper-V Host bekannt ist.

sw1# sh mac-address 00155d-32fb04
Status and Counters – Address Table – 00155d-32fb04
Port VLAN
Trk1 21

Der Ping lief zunächst, plötzlich brach der Ping weg und selbiger Befehl auf dem Switch sw1 zeigte nun folgendes:

sw1# sh mac-address 00155d-32fb04
Status and Counters – Address Table – 00155d-32fb04
Port VLAN
Trk2 21

Ok, die Ursache für die sporadische Nichterreichbarkeit scheint gefunden aber warum wechselt die ist die gleiche MAC plötzlich auf einem anderen Interface bekannt?

Es galt zu hinterfragen was genau beim Umbau passiert ist:

Es waren vor dem Umbau zwei Hyper-V Singlehost VH1 und VH2. Die IP des VH2 wurde geändert und es kam ein dritter Hyper-V Singlehost, VH3, hinzu und bekam die IP des VH2.

Ok der Fall wird klarer. Bei Hyper-V arbeitet Microsoft mit dynamischen MAC Adress Pools welche wie folgt zusammengesetzt sind:

Z. B. die MAC Adresse 00:15:5D:32:FB:01

  • 00:15:5D is the OEM identifier
  • 32:FB letzten zwei Oktetts des ersten Hyper-V Netzwerkadapters konvertiert in HEX
  • 01 aufsteigende Nummerierung

Nun war es relativ einfach, die dynamischen MAC Address Pools beider Hyper-V Singlehosts waren identisch. Warum? Als die Hyper-V Rolle auf dem VH2 zur Installation aktiviert wurde, wurde der MAC Adresspool generiert (wird abgelegt unter HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization bzw. ist im Hyper-V Netzwork Manager auch sichtbar) – der VH2 hatte zum Zeitpunkt der Aktivierung der Rolle „x.x.50.251“ gebunden insofern kam es zu „32:FB“. Während der Laufzeit des VH2 wurde die IP geändert aber der dynamische MAC Pool bleibt natürlich gleich.

Als der VH3 nun mit der alten IP des VH2 konfiguriert und dessen Hyper-V Rolle aktiviert wurde generierte er nach der gleichen Logik auch „32:FB“ und seine erste Maschine bekam die „01“ verpasst.

Btw: so ein Fehlerbild erhält man auch in größeren Umgebungen wenn jmd eine virtuelle Maschine von z.B. Singlehost A auf Singlehost B umzieht jedoch die alte VM auf Singlehost A heruntergefahren liegen lässt und dann später versehentlich hochfährt.

Hier ein weiterer interessanter Artikel zum Thema der MAC Address Kollision:

  • http://blogs.technet.com/b/jhoward/archive/2008/07/15/hyper-v-mac-address-allocation-and-apparent-network-issues-mac-collisions-can-cause.aspx

 

IIS, WPI, date.timezone=Asia/Kuwait und Cacti

Bei der Vorbereitung einer Cacti-Installation auf einem Windows Server 2012 kann man sehr bequem PHP mit dem sogenannten „Microsoft Web Platform Installer“ installieren. Das ist eine sehr smarte Geschichte beim Deployment, die viel Zeit spart da bei der Installation sämtliche Abhängigkeiten mit installiert und konfiguriert werden (den WPI in der jeweils aktuellen Version gibt es hier http://www.microsoft.com/web/downloads/platform.aspx).

Nach der Installation und Konfiguration der Cacti-Komponenten konnte ich jedoch keine Datenpunkte in den jeweiligen Graphen sehen:

fehlende Daten im Cacti-Graphen

Es wurde lediglich ein „-1.#J“ im Interface-Graph angezeigt.

Ein Studium des Logs brachte auch keine Ergebnisse.

Die Jobs liefen sauber durch:

06/24/2013 06:35:16 PM – POLLER: Poller[0] CACTI2RRD: c:/rrdtool/rrdtool.exe update C:\inetpub\wwwroot\cacti\rra\da-vinci_traffic_in_191.rrd –template traffic_in:traffic_out 1372091715:0:0
06/24/2013 06:35:16 PM – POLLER: Poller[0] CACTI2RRD: c:/rrdtool/rrdtool.exe update C:\inetpub\wwwroot\cacti\rra\da-vinci_traffic_in_190.rrd –template traffic_out:traffic_in 1372091715:0:0
06/24/2013 06:35:16 PM – CMDPHP: Poller[0] Host[9] DS[259] SNMP: v2: 10.41.254.254, dsname: traffic_out, oid: .1.3.6.1.2.1.31.1.1.1.10.7, output: 0
06/24/2013 06:35:16 PM – CMDPHP: Poller[0] Host[8] DS[221] SNMP: v2: 10.41.254.250, dsname: traffic_in, oid: .1.3.6.1.2.1.31.1.1.1.6.10019, output: 0

… und auch die RRD-Dateien wurden aktualisiert…

C:\rrdtool>rrdtool.exe info C:\inetpub\wwwroot\cacti\rra\da-vinci_traffic_in_183
.rrd
filename = „C:\inetpub\wwwroot\cacti\rra\da-vinci_traffic_in_183.rrd“
rrd_version = „0003“
step = 300
last_update = 1372103415

C:\rrdtool>rrdtool.exe info C:\inetpub\wwwroot\cacti\rra\da-vinci_traffic_in_183
.rrd
filename = „C:\inetpub\wwwroot\cacti\rra\da-vinci_traffic_in_183.rrd“
rrd_version = „0003“
step = 300
last_update = 137210371

Die Erkenntnis kam dann nach dem Abendessen, als ein von mir beim Troubleshooten noch nicht gelöschter Graph plötzlich doch Datenpunkte anzeigte – ein Zeitthema lag nah.

Also fix die PHP.ini gecheckt (liegt bei einer WPI Installation C:\Program Files (x86)\PHP\v5.4), dort unter „Module Settings“ die „date.timezone“ auf:

date.timezone = Europe/Berlin

konfiguriert, IIS durchgestartet und erneut geprüft. Kein Erfolg – in der phpinfo(); stand die Zeit noch immer auf „Asia/Kuwait“. Also nochmal ab in die PHP.ini und auch fündig geworden:

[WebPIChanges]
date.timezone=Asia/Kuwait

In dem vom Microsoft Web Platform Installer konfigurierten Änderungen beim Deployment vom PHP wurde auch nochmal ganz am Ende der php.ini eine Zeitzone gesetzt.

Diesen Eintrag also raus (habe ja den korrekten Eintrag gesetzt), IIS durchgestartet und es lief.

Hyper-V Requirements via Systeminfo

Bei der systeminfo in der CMD wurde bei Windows 8 und Windows Server 2012 ein ziemlich cooles Feature nachgeschoben. Die letzten vier Zeilen des systeminfo Outputs in der CMD geben bei noch nicht aktivierter Hyper-V Rolle an, wie der Support ist aktuell konfiguriert ist.

Vor der Aktivierung der Hyper-V Rolle:

C:\Users\stefan>systeminfo
[…]
Anforderungen für Hyper-V:
Erweiterungen für den VM-Überwachungsmodus: Ja
Virtualisierung in Firmware aktiviert: Ja
Adressübersetzung der zweiten Ebene: Ja
Datenausführungsverhinderung verfügbar: Ja

C:\Users\stefan>systeminfo
[…]
Hyper-V Requirements:
VM Monitor Mode Extensions: Yes
Virtualization Enabled In Firmware: Yes
Second Level Address Translation: Yes
Data Execution Prevention Available: Yes

Nach der Aktivierung der Hyper-V Rolle:

C:\Users\stefan>systeminfo
[…]
Hyper-V Requirements: A hypervisor has been detected. Features required for  Hyper-V will not be displayed.

C:\Users\stefan>systeminfo
[…]
Anforderungen für Hyper-V: Es wurde ein Hypervisor erkannt.
Features, die für Hyper-V erforderlich sind, werden nicht angezeigt.

Access-Listen und DHCPOFFER

Vorgestern hatte ich ein interessantes Thema, bei dem ein Access-Point mit einer input-address-list und output-address-list auf dem Dot11Radio-Interface bei dem ein Windows Server mit DHCP-Rolle keine IP Adressen an Clients im WLAN verteilt hat.

Der Grund war, dass auf dem Dot11Radio-Interface die identische Access-Liste gebunden, welche keine Broadcasts durchließ. Warum? Der Grund liegt hinter der Idee von den entsprechenden ACL’s. Diese stellen nicht die Richtung dar sondern ob source (input) oder destination (output) Address.

Die Lösung letztendlich war denkbar übersichtlich, zwei verschiedene Access-Listen zu erstellen.

interface Dot11Radio0
! […]
bridge-group 1 input-address-list 700
bridge-group 1 output-address-list 701
! […]
access-list 700 permit 6067.20aa.1234 0000.0000.0000
access-list 700 deny 0000.0000.0000 ffff.ffff.ffff
access-list 701 permit 6067.20aa.1234 0000.0000.0000
access-list 701 permit 0000.0000.0000 0000.0000.0000
access-list 701 permit ffff.ffff.ffff 0000.0000.0000
access-list 701 deny 0000.0000.0000 ffff.ffff.ffff

Übrigens in einer Laborumgebung habe ich das nochmal mit einem Cisco Router als DHCP-Server getestet. Hier hat es auch ohne Broadcastadresse in der zweiten ACL Funktioniert.

Der Grund liegt in der Verteilung des DHCPOFFERS vom DHCP-Server. Windows Server nutzen hier abhängig vom Broadcast Bit im DHCPDISCOBVER Broadcast zur Verteilung, siehe KB169289 (http://support.microsoft.com/kb/169289/en-us).

Da obiges Beispiel im Layer 2 spielt ist die Broadcast- oder Unicast-Implementierung abhängig vom Hersteller.

Weiterführende Infos: http://www.ietf.org/rfc/rfc2131.txt

via CMD schnell prüfen ob ein KB installiert ist.

Oft fragt man sich doch „ist der KB installiert“? Wer schnell mal prüfen muss, ob ein bestimmter KB auf einem System installiert ist geht wie folgt vor.

  1. CMD im Adminmodus (cmd – rechtsklick – Als Admin ausführen)
  2. Dann den Befehl, das Pipe-Symbol „|“ filtert die Ausgabe

wmic qfe list | find „KB2750841“

Ist der KB installiert gibt es dann z.B. folgende Ausgabe (KB, wer hat installiert, wann wurde installiert).

C:\Users\stefan>wmic qfe list | find „KB2750841“
http://support.microsoft.com/?kbid=2750841     CONROE  Update
KB2750841               NT-AUTORITÄT\SYSTEM  11/16/2012
C:\Users\stefan>

WMIC steht für Windows Management Instrumentation Commandline, QFE für Quick Fix Engineering.

Das Ganze ist beispielsweise unwahrscheinlich nützlich wenn man sich eigene Inventarskripte baut oder nur mal schnell eine Info brauch ob der KB drauf ist oder nicht.

WMIC kann natürlich noch weit mehr. Aber dazu ggf. später.