Zum Abschluss des Jahrs 2013 wünsche ich euch allen einen Guten Rutsch. Wir lesen uns wieder im Jahr 2014!!!
Und als Abrundung die letzten Management Pack Änderungen:
Neue Management Packs im Zeitraum zwischen 27.09.2013 und 31.12.2013
Active Directory
Wer bereits auf System Center 2012 R2 Configuration Manager setzt und beim Operation System Deployment (OSD) Geschwindigkeitseinbußen gegenüber älteren Versionen merkt, der sollte sich das gerade erschiene Hotfix KB2905002 genauer anschauen.
Scheinbar wurde der Fortschrittsbalken deutlich häufiger aktualisiert als in Vergangenheit. Dies hat zu einem extremen Einbruch bei der Übertragungsgeschwindigkeit geführt
Hier der entsprechende Link:
http://support.microsoft.com/kb/2905002/en-us
Die meisten sollten bereits mitbekommen haben, dass Volume Licence Kunden und MSDN Mitglieder bereits zugriff auf die neue System Center 2012 R2 Configuration Manager Version haben. Einen guten Überblick über die Neuerungen hat mein geschätzter MVP Kollege Adrian Stoian in seinem Blog bereitgestellt:
http://www.adrianstoian.com/?p=1387
Wie bereits in einem vorhergehenden Blogeintrag von mir erwähnt benötigt der neue ConfigMgr auch eine neue Version des ADKs. Die released Version wurde netzt nochmal aktualisiert. Wer also die alte Version bereits installiert hat, der sollte auf die aktuelle Version upgraden:
In einigen Fällen möchte man eine langsamere Verbindung simulieren. Mittels Netzwerkeinstellungen der virtuellen NIC in Hyper-V könnte eine Drosselung schon umgesetzt werden. Dies simuliert aber keine Paketverluste und was ist, wenn man das Host System (z.B. für Hyper-V replica Tests) einschränken möchte?
Eine alte und immer noch funktionale Lösung ist WANem. Es handelt sich dabei um eine Live-CD (knoppix) die einfach in eine VM eingelegt wird. Die VM ist mit 1GB RAM, einer NIC und keiner Platte ausgestattet. Die NIC sollte eine legacy NIC sein, da diese automatisch erkannt wird. In meinem Hyper-V 2012 R2 Preview hat die “neue” 3.0 Beta nicht funktioniert. Die ältere 2.3 funktioniert und reichte von den Featuren aus.
Für meine Szenarien reicht eine NIC, die im normalen VLAN der VMs (und Hyper-V) Knoten eine IP bekommt.
Im ersten Szenario möchte ich den Traffic zwischen zwei VMs einschränken. WANem hat dabei die IP Adresse 10.6.255.148 bekommen. VM1 die 10.6.255.11 und VM2 die 10.6.255.22.
Daher trage ich auf VM1 eine neue Route ein:
route add 10.6.255.22 mask 255.255.255.255 10.6.255.148
und auf VM2:
route add 10.6.255.11 mask 255.255.255.255 10.6.255.148
Metric und Interface erkennt Windows automatisch.
Dies bedeutet: Wenn VM1 die VM2 erreichen will, muss es über WANem gehen. Ebenso muss der Rückweg über WANem (von VM2 zu VM1) gehen.
Soweit deckt sich das Szenario mit der Dokumentation von WANem.
Im zweiten Szenario möchte ich den Traffic zu einer IP in einem anderen Subnetz einschränken. In diesem Fall (zentraler Webproxy) habe ich keine Chance auf dem fremden System eine Route einzutragen bzw. dem WANem ein zweites Bein in das fremdes Subnetz zu geben.
Ich kann somit eine Route auf der Quelle eintragen:
route add 10.6.200.12 mask 255.255.255.255 10.6.255.148
Simuliere ich dann eine 2MBit Leitung:
und teste die Geschwindigkeit im Webbrowser erhalte ich folgendes Ergebnis:
![clip_image002[7]](http://www.mbaeker.de/wp-content/uploads/2013/10/clip_image0027.jpg "clip_image002[7]")
Bedeutet: Die Upload Richtung wurde gedrosselt. Die Download Richtung nur etwas verlangsamt, da die ACK Pakete (“Upload”) ebenfalls gedrosselt wurden. Dies liegt daran, dass natürlich der Proxy auf seinen normalen bekannten Weg (=Gateway) die Pakete zurückschickt und diese somit nicht gedrosselt werden können.
Um auch die Rückrichtung zu drosseln muss WANem die Quelle-IP in den Paketen anpassen. Diese Verfahren kennen wir von unseren DSL Routern: NAT.
Auf der Kommandozeile des WANem Systems aktivieren wir daher NAT für das eth0 Interface (wenn das System nur eine NIC hat bzw. diese das Gateway zum fremden System eingetragen hat):
NAT ADD ETH0
Ein erneutes Ausführen des Tests ergibt folgendes Ergebnis:
Jetzt werden somit beide Richtung korrekt auf ca. 2000kbit/s gedrosselt.
Hier übrigens noch der Test mit WANem ohne Dorsselung:
![clip_image002[9]](http://www.mbaeker.de/wp-content/uploads/2013/10/clip_image0029.jpg "clip_image002[9]")
Wie ich bereits in einem früheren Blog Eintrag beschrieben habe, erweitert das CU3 den Configuration Manager (ConfigMgr) um den Support von Windows 8.1.
Um auch ein Windows 8.1 (supported) verteilen zu können wird das neuere WinPE 5 benötigt. Dieses WinPE ist bestandteil des Automated Installation Kit (Windows AIK) 8.1 und kann nicht auf dem ConfigMgr Server installiert werden, da dieser das ADK 8 benötigt.
Dies hat zur Folge, dass für die Verteilung von Windows 8.1 zwar das WinPE 5 als Bootimage importiert und genutzt werden kann, aber die Anpassungen (Treiber in das Bootimage importieren, Debugprompt aktivieren, …) nicht über die ConfigMgr Oberfläche erfolgen kann.
Ist eine Anpassung erforderlich, so sollte dies auf einem anderen Rechner mit installiertem AIK 8.1 erfolgen und das neue Image wieder importiert werden. Dies ist analog mit der Unterstützung von WinPE 3.1 im ConfigMgr.
Weitere Details zum Anpassen und zu den supporteten Versionen sind sehr ausführlich in folgendem TechNet Artikel beschrieben:
http://technet.microsoft.com/en-us/library/dn387582.aspx
Zertifizierungen:
[...]
