Ab jetzt habt Ihr somit zwei Zentrale Anlaufstellen; MSPFE für alles rundum die Technologie die euch am meisten interessiert und den Microsoft Services Blog worüber Ihr Schulungsinformationen, Case Studies oder auch kurze Feature Informationen erhält.

• Premier Field Engineering – Notes from the Field
  http://blogs.technet.com/b/mspfe/ 
• Microsoft Services Deutschland
  http://blogs.technet.com/b/microsoft_services_deutschland/

Euer Blogger Team

Heute werden wir uns um SuperFetch und ReadyBoost kümmern. Beides sind Prefetching Technologien die Microsoft in Windows 7 einsetzt um das System und Zugriffe auf Anwendungen zu beschleunigen.

SuperFetch

Als erstes sprechen wir über SuperFetch, eine Speicherverwaltungs-Technologie die entwickelt wurde um den Arbeitsspeicher eines Rechners effektiver zu nutzen und das System in bestimmten Szenarien zu beschleunigen, indem Daten in den RAM geladen werden bevor Sie benötigt werden. SuperFetch arbeitet im Hintergrund und nutzt Zeiten in den das System gerade "idle" ist, d.h. nicht viel zu tun hat um die Daten vorzuladen.

SuperFetch analysiert im Zusammenspiel mit dem Memory Manager Dienst die Speichernutzung, darauf welche Speicherseiten oft benötigt werden und ob es bestimmte Muster gibt die sich an bestimmte Zeiten oder Daten wiederholen (das ist auch als Proactive Memory Population bekannt). Aufgrund dieser Ergebnisse, ist SuperFetch in der Lage benötigte Daten in den RAM zu laden, noch bevor sie durch die Anwendung angefordert werden. Dies spart bei der anschließenden wirklichen Anforderung Zeit, da langsames Laden vom Datenträger entfällt. Natürlich werden die Seiten im RAM nicht blockiert, sondern auch schnell wieder freigegeben sollte er anderweitig benötigt werden.

Ein Beispiel des Vorteils von SuperFetch ist z.B. Ihre Buchhaltung macht immer zum Monatsende am letzten Freitag im Monat die Abrechungen und startet immer dann Ihre Buchhaltungssoftware. Da SuperFetch bestimmte wiederkehrende Nutzungsmuster erkennen kann lädt es an diesem Tag, nach dem Ihr System gestartet ist, wenn es gerade nichts zu tun hat bereits die benötigten Daten in den RAM vor. Wenn die Buchhaltungssoftware dann aufgerufen wird startet Sie schneller, da sie nicht erst von der Festplatte geladen werden muss.

SuperFetch wurde entwickelt um in den folgenden Situationen zu helfen und diese vorbeugen:

Schlechte Speicherausnutzung

• Die Performance verschlechtert sich nach und nach
• Programme wurden längere Zeit nicht genutzt, daher müssen evtl. Speicherseiten erst wieder von der Festplatte/aus dem Pagefile geladen werden.
• Hintergrundprogramme benötigten viel Speicher, wodurch Seiten anderer Anwendungen aus dem RAM entfernt werden, diese müssen dann bei erneutem Zugriff von Festplatte oder aus dem Page File geladen werden

Systemzustände benötigten Speicher

• Nach dem Boot
• Nach Hibernation
• Große Applikationen

Schlechte Festplattenperformance

• Programme benötigen lange zum Starten
• Hard Page Faults treten auf, d.h. Speicherseiten müssen von Festplatte oder aus dem Pagefile geladen werden

ReadyBoost

ReadyBoost und ReadyBoot. Beide Begriffe hören sich beim ersten Hören zunächst gleich an, es geht aber um 2 verschiedene Dinge. ReadyBoot haben wir bereits in Teil 1 behandelt, heute geht es um ReadyBoost.

ReadyBoost hingegen ist Teil der SuperFetch Technologie und stellt dem Betriebssystem einen Speicherort (Cache) auf einem Flashspeicher zur Verfügung um diesen als schnellen dedizierten Speicherort außerhalb des RAM für die Zwischenspeicherung von relevanten Daten zu nutzen. ReadyBoost speichert Daten für den schnelleren Zugriff auch pro aktiv durch die Nutzung der von SuperFetch erstellten Nutzungsmuster, z.B. wann wird eine bestimmte Speicherseite benötigt wird.

ReadyBoost wurde entwickelt um die gesamte System-Performance zu verbessern indem die schnellen Speichermedien, wie USB Flash Laufwerke, USB Sticks, SD oder CF Karten, als zusätzlicher Cache genutzt werden können. Da gerade kleine und nicht zusammenhängende Datenpakete von Flash Speichern schneller geschrieben und gelesen werden können als von herkömmlichen Festplatten, greift die ReadyBoost Technologie nur hier um den Geschwindigkeitsvorteil zu nutzen. Große zusammenhängende Datenpakete werden erkannt und diese werden weiterhin von der Festplatte gelesen.

Die Festplatte ist trotz einer evtl. verbauten SATA-Festplatte immer noch der langsamste Faktor und somit der Flaschenhals in Sachen Performance. Aus diesem Grunde nutzen Betriebssysteme den zur  Verfügung stehenden Arbeitsspeicher möglichst optimal aus und versuchen so viele Speicherseiten wie möglich von der Festplatte im RAM zu halten, um darauf bei Bedarf schneller zugreifen zu können. Flashspeicher sind hier eine hervorragende Möglichkeit, um bei Hard Page Faults nicht von langsamen Festplatten, bzw. aus dem Page File auf der Festplatte laden zu müssen, sondern hier eine schnellere Alternative zu haben. Zudem sind Flashspeicher nicht nur sehr schnell sondern auch günstig.

Geschwindigkeiten der einzelnen Speichertypen:

Memory type Latency          (in milliseconds)

Main memory (DRAM)                   ~0.0001

Flash memory (NVRAM)                ~0.5–1

Disk media (HDD)                          ~0.5–24

Das Zwischenspeichern von ReadyBoost bezieht sich auf den gesamten Festplatteninhalt nicht nur auf das Paging File oder DLL´s. Sämtliche Daten die auf den Flashspeicher zwischengespeichert werden, sind zusätzlich immer noch auf der Festplatte vorhanden, die Daten sind also gespiegelt. Durch diese Spiegelung gibt es z.B. auch keine Probleme wenn den Stick im Betrieb den ReadyBoost Speicher aus dem System entfernen. In diesem Fall fällt das Betriebssystem wieder auf die Festplatte zurück und fährt dort mit der Verarbeitung der Daten fort, der Geschwindigkeitsvorteil fällt dann weg.

Um ReadyBoost auf einem Flashspeicher zu aktivieren gibt es einige Anforderungen an das Gerät:

• Der USB Key muss USB 2.0 fähig sein
• Das USB Gerät muss folgende Schreib-/Lesegeschwindigkeiten mindestens mitbringen: Lesegeschwindigkeit für 4 kb Paket  3,5 MB/s / Schreibgeschwindigkeit: 2,5 MB/s
• Das USB Gerät muss über mindestens 64 MB freien Speicher verfügen.

Sind die zwischengespeicherten Daten auf dem genutzten Flashspeicher sicher?

Definitiv JA, alle Daten mit einer AES-128 Verschlüsselung und einem Pro Boot Session Key verschlüsselt. ReadyBoost komprimiert zusätzlich alle Daten mit einer Kompressionsrate von schätzungsweise 2:1 um den zur Verfügung stehenden Speicherplatz optimal zu nutzen.

Wie aktiviert man ReadyBoost?

Vermutlich wird jeder es bereits einmal gesehen, allerdings nicht realisiert haben. Wenn man einen USB Stick oder eine USB Festplatte in das Gerät einsteckt, der/die den Anforderungen für ReadyBoost entspricht, hat man zusätzliche Optionen im Autoplay Dialog der erscheint. Ebenfalls hat man in den Eigenschaften eines für ReadyBoost nutzbaren USB Geräts die Option das Gerät für ReadyBoost zu nutzen.

Nach dem ich diese beiden Begriffe erklärt habe, werde ich in meinem nächsten Beitrag darauf eingehen, warum man SuperFetch nicht deaktivieren sollte.

Weiterführende Links (englisch-sprachig) zum Thema Prefetching:

Das Whitepaper zu den angesprochenen Technologien finden Sie hier

Ein ReadyBoost Q&A von Tom Archer, aus einem Interview mit Matt Ayers, einem Programm Manager aus der Windows Client Performance Gruppe gibt es hier

Ein sehr schöner Beitrag von Mark Russinovich zu Windows Vista in denen er über die besprochenen Themen ReadyBoot, SuperFetch und ReadyBoost schreibt finden sie hier.

Das möchte ich heute einlösen. In diesem Eintrag kümmern wir uns um ReadyBoot. Wenn man von Prefetching in Windows 7 spricht, gibt es allerdings mehr als nur diesen einen Begriff, daher wird es noch einen zweiten Teil zum Prefetching in Windows 7 geben. Darin werde ich die Begriffe SuperFetch und ReadyBoost erklären.

Genug der Vorrede, fangen wir an.

Was ist ReadyBoot?

ReadyBoot ist eine von Microsoft entwickelte Technologie die Boot Performance eines Rechners zu verbessern. Latenzen die durch den „langsamsten“ Bestandteil eines Rechners auftreten sollen vermieden oder ausgeglichen werden.

ReadyBoot kommt vor allem bei herkömmlichen Festplatten zum Einsatz. Bei SSD Festplatten werden von Windows 7 einige Tests durchgeführt, um festzustellen ob ReadyBoot einen Mehrwert bietet oder nicht. Bei einer Festplatten WinSAT Wertung von mehr als 6.5 und einer durchschnittlichen Lese Rate von mind. 8 MB/s erreichen, was gute und schnelle SSD Festplatten erreichen, wird ReadyBoot deaktiviert. Zusätzlich zu ReadyBoot wird bei Erreichen der genannten Werte auch die automatische Defragmentierung abgeschaltet. SSD Festplatten basieren auf Speicherzellen, welche durch die Logik des in der SSD Festplatte eingebauten Controllers gleichmäßig beschrieben werden. Die einzelnen Speicherzellen einer SSD haben jeweils nur eine begrenzte Lebensdauer an Schreibzugriffen die Sie durchführen können, bevor sie unbrauchbar werden. Jeder Schreibzugriff der unnötig durchgeführt wird, ist aufgrund dessen kontraproduktiv für die Lebensdauer einer SSD. Mehr zum Thema SSD Festplatten und der Behandlung in Windows 7 finden sie hier (englisch-sprachig)

Während des Betriebssystemstarts werden sehr viele Daten von der Festplatte gelesen:

• ~ 150-170 MB bei einer sauberen  Retail Windows 7 Installation
• ~ 300-500 MB bei OEM Pre Installationen 

Die Lesegeschwindigkeit beim Start ist ungefähr bei:

• < 1 MB/s bei herkömmlichen Festplatten
• 8-12 MB/s bei einem System mit aktivierten ReadyBoot

Daran sieht man das es einen enormen Vorteil bringt Dateien in den ReadyBootCache vor zu laden und dann bei Bedarf von dort zu laden. Nach dem Bootvorgang wird der ReadyBoot Cache wieder gelöscht.

Wie funktioniert ReadyBoot ?

Bei einem neu installierten Windows 7 System ist ReadyBoot ganz zu Beginn noch nicht optimiert. ReadyBoot analysiert die letzten 5 Bootvorgänge und erstellt davon Traces, um sich selbst zu trainieren. Anhand der Informationen die ReadyBoot aus diesen Boots gewonnen hat erstellt es einen „Bootplan“.

In diesem Bootplan ist verzeichnet welche Dateien bei den letzten Windows Starts geladen wurden. Beim Windows Start lädt ReadyBoot dann die benötigten Dateien anhand des Bootplans in den RAM bevor diese benötigt werden. Dadurch stehen diese aufgrund der wesentlich schnelleren Zugriffszeiten des RAM´s für den Bootvorgang schneller zur Verfügung.

Dateien die sich im Cache befinden, können wenn diese vom Betriebssystem oder Applikationen angefordert werden, viel schneller von dort geladen werden, als wenn diese erst von der Festplatte geladen werden müssen.

Hier noch eine kleine grafische Übersicht über ReadyBoot:

In einem xperf Trace kann man einen ersten Hinweis auf etwaige Probleme im ReadyBoot Graph sehr leicht an vielen schwarzen Feldern erkennen. Schwarz zeigt im ReadyBoot Graph in einem Trace sogenannte misses an. Wie in der Übersicht erkennbar, sind das Lesevorgänge die Betriebsystem, Dienste oder Applikation direkt von der Festplatte durchführen, statt aus dem ReadyBootCache. Um ReadyBoot z.B. bei einem frisch installiertem System zu optimieren, kann die Aktion -prepsystem von xbootmgr genutzt werden. Dabei werden automatisch 5 Neustarts durchgeführt und davon Traces erstellt, außerdem wird dabei ein neuer Bootplan für ReadyBoot erstellt. Ein einfacher Befehl von xbootmgr sieht dann z.B. so aus:

Mehr zum Prefetching in Windows 7 lesen Sie hier in Teil 2, darin geht es um Superfetch und ReadyBoost.

Wolltet Ihr z.B. schon immer einmal wissen wie etwas bestimmtes funktioniert? Oder wie man in einer bestimmten Problemsituation reagiert? Dann schreibt einfach ein Kommentar, mit den Eckpunkten und wir bemühen uns zeitnah darauf zu reagieren.

Bitte beachtet, dass wir wahrscheinlich nicht auf alle Wünsche reagieren können. Wir werden uns aber bemühen, bei den Interessantesten schnell zu reagieren.

Die folgenden Windows Dienste waren betroffen:

• CertPropSvc
• IKEEXT
• iphlpsvc
• LanmanServer
• MMCSS
• ProfSvc
• Schedule
• SENS
• ShellHWDetection
• Themes
• Winmgmt

Auf allen betroffenen Workstations war als Betriebssystem Windows 7 SP1 Enterprise Edition installiert, und zusätzlich der Microsoft Application Virtualization Client aktiv im Einsatz.

Innerhalb der System-Ereignisanzeige tauchten immer wieder die Einträge 1129 und 7031 auf. Die Event-ID 1129 informiert darüber, dass es Verbindungsprobleme zum Domain Controller gibt, die ID 7031, zeigt an, dass ein Windows Dienst abgestürzt ist. Zusätzlich prüfte ich die Version der einzelnen Dienste um sicherzustellen, dass diese auf dem aktuellsten Stand waren.

Nach meiner Recherche stellte ich fest, dass der Microsoft Application Virtualization Client, während des Windows Login Prozesses, einen Laufwerk anlegt, und dabei die svchost.exe worin die betroffenen Windows Dienste gehostet werden abstürzen.

Nachdem ich das Warum lüften konnte, ging es darum, das Problem auch zu lösen. Gemeinsam mit einem Kollegen, haben wir den untenstehenden Support Artikel gefunden, geprüft, und im Anschluss angewandt.

• Der Desktop wird nicht geladen und zeigt nur einen schwarzen oder blauen Hintergrund, nachdem Sie sich an einem Computer anmelden, auf dem Windows 7 oder Windows Server 2008 R2 ausgeführt wird
  http://support.microsoft.com/kb/2590550/en-us

Mit dem im Support Artikel angebotenen Hotfix konnte das Problem gelöst werden.

Alle Treiber die in das Betriebssystem integriert sind, werden im sogenannten Treiber Repository abgelegt. Den zugehörigen Ordner findet Ihr unter %SYSTEMDRIVE%\Windows\System32\DriverStore.

Mit Pnputil, welches ein Built-In Tool für die Eingabeaufforderung ist,  könnt Ihr Treiber in die Repositiory hinterlegen bzw. auch entfernen.

Schritt-für-Schritt:

• Administrator Command Prompt öffnen
• Hinzufügen von einem Treiber:
• pnputil.exe -a  C:\MausTreiber\maus.inf
• Der Pfad kann entweder Lokal oder aber auch Remote sein
• pnputil.exe -a C:\MausTreiber\*.inf
• Importiert alle .INF Dateien in einem Ordner
• Entfernung von einem Treiber:
• pnputil.exe -d TREIBERNAME.inf

Nähere Informationen:

• PnPUtil Examples
  http://msdn.microsoft.com/en-us/library/windows/hardware/ff550428(v=vs.85).aspx

Durch die Lücke, konnte Code aus der Ferne ausgeführt werden. Unabhängig von der Sicherheitslücke, waren Anti-Viren Lösungen wie z.B. Forefront oder Security Essentials in der Lage trotzdem die Ausführung des Codes zu verhindern.

Nähere Informationen zum Windows Update:

• Microsoft Security Bulletin MS12-063 - Critical
  http://technet.microsoft.com/en-us/security/bulletin/ms12-063

Die neueste Version von Microsoft Deployment Toolkit - Version 2012 Update 1 - ist seit August verfügbar.

Hier der passende Link: Microsoft Deployment Toolkit 2012 jetzt herunterladen

Die wichtigste Nachricht:
MDT 2012 Update 1 unterstützt nach wie vor die Installation von allen existierenden Betriebssystemen (XP, Vista, Windows 7, Server 2003, Server 2008, Server 2008R2). Zusätzlich wird nun die Installation von Windows 8 RTM und Windows Server 2012 RTM unterstützt.

Allerdings lässt sich die MDT Workbench nur noch auf Windows 7/Server 2008R2 bzw. Windows 8/Server 2012 installieren.

Die Liste der Neuerungen ist lang und ein vollständiges Aufzählen würde den Umfang dieses Blogeintrags sprengen, deshalb hier nur die wichtigsten Neuerungen:

• Verwendung von ImageX anstatt Setup.exe zum installieren des Image
• Support für Windows 8 RTM und Windows Server 2012 RTM
• Support für die Integration von DaRT 7 und DaRT 8 Beta (DaRT = Diagnostics and Recovery Toolset)
• Support für das Windows Assessment and Deployment Kit (ADK) for Windows®  (= Nachfolger des WAIK 2.0)
• Support für PowerShell 3.0 und leichtere Integration in die Tasksequenzen
• Support für PE4.0 inkl. PowerShell Support innerhalb der PE (damit kann nun in jeder Phase des Deployment Prozess PowerShell verwendet werden)
• Support für System Center ConfigMgr 2012 SP1 CTP
• Support für System Center Orchestrator (ermöglicht das Aufrufen von Orchestrator Runbooks zu jeder Zeit im Deployment Prozess)
• Komplett überarbeitete "Rollen und Funktionen" Logik mit Unterstützung von Hinzufügen/Entfernen und einem verbesserten Auswahldialog während der Installation
• Ein neuer "Build Your Own Pages" Support bei UDI Installationen ermöglicht es den IT Professionals neue Fenster/Dialoge im Assistenten per Drag und Drop zu erstellen - kein programmieren nötig
• uvm...

Eine längere Liste mit mehr Details findet man bereits in den zahlreichen Blogeinträgen von Michael Niehaus. In den nächsten Wochen und Monaten wird es auch hier weitere Blogeinträge zu den einzelnen Features und Funktionen geben.

Weiterführende Links und Infos zu
Microsoft Deployment Toolkit Homepage
Microsoft TechNet Library zu MDT 2012 Update 1
Michael Niehaus' Windows and Office deployment ramblings
Microsoft Solution Accelerators

Das Blogging Team hat Zuwachs von weiteren PFE Kollegen bekommen. Deshalb möchten wir die Chance nutzen und uns kurz vorstellen:

Wir sind Manuel Singer und Matthias Mark und arbeiten beide bei Microsoft als Premier Field Engineers im Bereich Windows Client Technologie. Gemeinsam mit unseren Kollegen Ulf und Milad möchten wir euch interessante Themen rund um den Windows Client präsentieren.

Manuel vor allem in den Themen zu Deployment, Clientdesign, Group Policy, Reliability und täglicher Praxis im Enterprise Umfeld.

Matthias vor allem in den Themen zu Deployment, WDS, Update Mechanismen, WSUS, Performance, Bitlocker und Debugging.

Manuel Singer, Premier Field Engineer

Matthias Mark, Premier Field Engineer

Viel Spaß beim lesen...

Beispiel Command um eine hohe CPU Auslastung zu loggen:

• Command Prompt öffnen
  
• xperf.exe –on Latency
• Fehler reproduzieren
• XPerf.exe -d *name_der_datei*.etl
  

Syntax Erklärung:

Latency steht für eine Kernel Gruppe, die aus 8 Kernelflags besteht. Jede einzelne loggt bestimmte Informationen, und wird dann zu einer ETL Datei zusammengeführt.

• PROC_THREAD:
• Nützlich um festzustellen, wann welcher Prozess bzw. Thread gestartet oder beendet wird.
• LOADER:
• Informiert welche Images (EXE / DLL) im Kernel Bereich geladen werden.
• DISK_IO:
• Festplattenauslastung
• HARD_FAULTS:
• Information wann ein Hard Fault geschieht, und was es verursacht.
• Hard Faults Erklärung:
• Pages eines RAM, die entweder vom RAM auf die Festplatte ausgelagert werden, oder von der Festplatte wieder in das RAM eingelagert werden.
• DPC:
• Zeitpunkt wann ein Deferred Procedure Call geschieht.
• Deferred Procedure Call Erklärung:
• Ein DPC wird ausgelöst, damit ein Interrupt (z.B. Disk I/O, Netzwerk Traffic) der sonst auf einem zu hohen IRQL läuft und somit die gesamte CPU blockieren würde. Der DPC läuft auf einem viel niedrigeren Interrupt Level, und arbeitet diese Interrupts in einem niedrigeren IRQL ab. DPC´s werden in eine Q gestellt und dort abgearbeitet.
• INTERRUPT:
• Wann ein Interrupt passiert.
• Interrupt Erklärung:
• Wenn ein Request wie z.B. eingehender Netzwerk Traffic für die Hardware da ist, löst es im Betriebsystem ein Interrupt aus. Dadurch wird die CPU von seiner aktuellen Tätigkeiten gelöst, und bearbeitet umgehend diesen Request.
• CSWITCH:
• Informiert wann ein Context Switch geschieht, und somit ein Thread entweder auf die CPU kommt oder entfernt wird.
• Context Switch Erklärung:
• Siehe hierfür den vorhergehenden Blog Eintrag: Wie bekommt ein Prozess CPU Zeit?
• PROFILE:
• Loggt auf die Millisekunde genau, was die CPU ausführt.

Sobald der Trace über XPerfview.exe geöffnet wurde, sieht man zwei verschieden CPU Graphen, CPU Sampling und CPU Usage. Obwohl beide Informationen auf dem ersten Blick ähnlich aussehen, sind sie trotzdem unterschiedlich. Die CPU Sampling Graphen, erhalten die Informationen vom Provider PROFILE, die CPU Usage Graphen vom Provider CSWITCH.

Informationen die man durch die beiden Graphen erhält:

CPU Usage: Wie viel Zeit hat jeder einzelne Thread genau, zur Ausführung auf der CPU. 

CPU Sampling: Dadurch, dass der PROFILE Provider die Stacks mit einsammelt, kann über CPU Sampling genau angezeigt werden, was der einzelne Thread im User bzw. im Kernel Modus durchführt.

Deswegen ist meine persönliche Empfehlung, erst mit CPU Usage zu überprüfen welcher Thread das Problem bereitet, und danach mit CPU Sampling, zu schauen, was der Thread versucht auszuführen.

CPU Sampling by CPU / CPU Usage by CPU:

Die oben abgebildeten Graphen zeigen die Auslastung je CPU an.

CPU Sampling by Process / CPU Usage by Process:

Hierüber kann auf dem ersten Blick eingesehen werden, welcher Prozess eine hohe CPU Auslastung verursacht.

CPU Sampling by Thread / CPU Usage by Thread:

Hier erfährt man welcher Thread, von einem Prozess, die hohe CPU Auslastung verursacht.

Nachdem die einzelnen Graphen überprüft wurden, kann man tiefer in die Analyse gehen. Hierfür, mit der rechten Maustaste auf einen der Graphen klicken, und Summary Table's auswählen:

CPU Sampling by Process Summary Table:

CPU Usage by Process Summary Table:

In diesem Beispiel Trace, kann man innerhalb der Summary Tables erkennen, dass der Grund für die Hohe CPU Auslastung die CPU100.exe ist, die mit seinen Threads insgesamt 97,04% der CPU belegt.

Kleiner Tipp, die Trennleiste nennt man die Golden Bar. Der Unterschied zwischen dem linken zum rechten Bereich ist, dass rechts die Daten zum sortieren genutzt werden, und sobald man diese nach links zieht eine Gruppierung der Daten erfolgt.