Haikos Blog Blog von Haiko Hertes zu allen Themen rund um Microsoft und Datacenter

28Nov/170

PowerShell: Alte Offline-Backups von Windows Server Sicherung entfernen

Mir ist kürzlich bei einem Server das Sicherungsziel der täglichen Windows Serversicherung gestorben, da dieser (sehr einfache) Hyper-V-Server nur auf eine USB-Disk sichert, deren Speicherplatz per iSCSI an die VMs durchgereicht wird. Dies hat zur Folge, dass die Windows Serversicherung die dort abgelegten Sicherungen für alle Ewigkeit weiterhin anzeigt und mitzählt. Bei dem Versuch einer Wiederherstellung von Daten auf der gestorbenen Platte würde angezeigt werden, dass das Sicherungsziel offline ist und man hätte die – praktisch nicht mehr umsetzbare – Möglichkeit, die Daten verfügbar zu machen.

wsbkp1

Wenn man jetzt die Infos über die nicht mehr vorhandenen Sicherungen löschen will, um eine saubere “Statistik” zu haben, kann man sich eines PowerShell-Cmdlets bedienen: Remove-WBBackupSet.

Der Aufruf dazu sieht so aus:

Remove-WBBackupSet –MachineName SERVERNAME -KeepVersions 4

Der Parameter –KeepVersions gibg dabei an, wieviele der letzten Sicherungen man behalten möchte. Alternativ kann man mit –DeleteOldest die X ältesten Sicherungen entfernen.

wsbkp2

Bei dem Aufruf wird es aber sehr wahrscheinlich zu vielen Fehlern kommen, wie man im Screenshot sieht. Da die Sicherungen nicht mehr erreichbar sind, das Cmdlet aber eigentlich die Files dazu löschen würde, muss man sich hier zusätzlich des –Force Parameters bedienen:

wsbkp3

Dabei wird die Tatsache, dass die Sicherungen auf der ausgefallenen Platte nicht mehr erreichbar sind, ignoriert und nur der Verweis auf diese Sicherungen entfernt.

Mit dem Aufruf Get-WBBackupSet kann man sich nochmal ausgeben lassen, wieviele Sicherungen Windows Server Backup “kennt”:

wsbkp4

16Mai/160

Windows Server: HowTo Video zum Aufbau eines Clusters für Hyper-V

In einem weiteren YouTube-Video zeige ich euch, wie ihr einen Hyper-V Cluster mit dem Windows Server 2012 R2 oder 2016 aufbauen könnt. Das ist leichter als man denkt! Viel Spaß beim Anschauen.

Hyper-V-Cluster_Deckblatt

https://youtu.be/4bCeqfhoW0c

29Jan/150

Server 2012 R2: WDS macht Probleme beim Aufzeichnungsabbild

In den Windows Bereitstellungsdiensten gibt es die Möglichkeit, ein “Aufzeichnungsabbild” aus einem regulären “Startabbild” zu erzeugen. So natürlich auch beim aktuellen Windows Server 2012 R2:

wds2

Häufig kommt es dann aber bei dieser Server-Version später beim Booten der aufzuzeichnenden Maschine zu einem Fehler:

wds1

Dieser Fehler tritt dann auf, wenn man:

  • auf einem Windows Server 2012 R2 (mit oder ohne Update1) im WDS ein Startabbild (Boot Image) auf Basis eines Windows Server 2012 R2 MIT Update1 oder Windows 8.1 MIT Update1 hinzufügt (dabei ist es dann später egal, auf welchem Startabbild das Aufzeichnungsabbild basiert)
  • auf einem Windows Server 2012 (“R1”) im WDS ein Startabbild auf Basis eines Windows Server 2012 R2 mit Update1 oder Windows 8.1 mit Update1 erzeugt

Der Fehler würde NICHT auftreten, wenn man vor dem Erzeugen des Aufzeichnungsabbildes noch nie ein Startabbild von Windows 8.1 Update1 oder Windows Server 2012 R2 Update1 importiert hatte.

Natürlich kann man den Fehler aber auch anderweitig umgehen bzw. beheben:

Dazu hinterlegt man zunächst das gewünschte Startabbild (dabei spielt es keine Rolle, ob bisher ein Update-1-Startabbild hinterlegt wurde oder nicht, das zu hinterlegende Abbild selbst darf auch von einer Update-1-Version stammen):

wds7

Danach erzeugt man aus diesem ein Aufzeichnungsabbild:

wds2

Dabei sollte man dass entstehende Abbild nicht direkt dem WDS Server hinzugefügt wird:

wds3 wds4

Anschließend muss das entstandene WIM-File (in meinem Beispiel “C:\aufz.wim”) mittels DISM gemountet werden:

wds5

Für das Mounten verwendet man einen Aufruf in dieser Form:

dism /Mount-Wim /WimFile:C:\aufz.wim /index:1 /MountDir:C:\mount

(Achtung: Keine Leerzeichen nach den Doppelpunkten!)

Im Anschluss kann die Datei direkt wieder “unmounted” werden (ohne dass sie dabei inhaltlich wirklich verändert wurde):

wds6

Hierzu wird folgender Aufruf verwendet:

dism /Unmount-Wim /MountDir:C:\mount /commit

Das nun neu erzeugte WIM-File kann jetzt als funktionsfähiges Aufzeichnunge-/Startabbild auf dem WDS-Server hinterlegt werden:

wds7

Nun kann eine (Test-)Maschine per PXE gebootet werden, es sollte nun, da es mehrere Startabbilder gibt, eine Auswahl möglich sein:

wds8

Wenn man das Aufzeichnungsabbild gewählt und die Maschine komplett gebootet hat sollte in etwa folgendes Menü zu sehen sein:

wds9

Nun kann die Festplatte der (Test-)Maschine aufgezeichnet werden. Wichtig ist dabei allerdings, dass dies nur funktioniert, wenn man das dort laufende Betriebssystem vorher mit sysprep vorbereitet hat.

18Dez/140

AutoAdminLogon für Windows Server 2012 R2 und andere OS

Manchmal besteht der Wunsch, auf einem Windows-System eine automatische Anmeldung nach dem (Neu)Start durchzuführen. Dies ist mit sehr einfachen Mitteln möglich und funktioniert sowohl bei Client- als auch Server-Betriebssystemen, auch bei älteren. Nötig ist dazu nur der Zugriff auf die Registry und ein passendes Benutzerkonto.

Als erstes wird der Registrierungseditor mittels “regedit.exe” geöffnet:

autoadminlogon1

Dort muss zu dem Schlüssel unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon navigiert werden.

Abschließend sind folgende Schlüssel nötig (alle als Zeichenfolge, REG_SZ)

  • AutoAdminLogon = “1”
  • DefaultUserName = BENUTZER
  • DefaultPassword = PASSWORT
  • DefaultDomainName = DOMÄNE

So etwa wie im Screenshot…

autoadminlogon2

Das war es schon gewesen. Beim nächsten Neustart ist die automatische Anmeldung aktiv…

8Dez/140

Windows Server 2012 R2: WSUS automatisch bereinigen

Mit der Zeit sammeln sich auf einem WSUS (Windows Server Update Service) einige Updates an. Da können auch schnell mehrere hundert Gigabyte an Daten zusammenkommen. Nicht jedes Update, welches auf dem WSUS gespeichert ist, wird aber noch benötigt. Daher ist es aus Gründen der Speicherplatzeffizienz sinnvoll, von Zeit zu Zeit etwas aufzuräumen. Dafür gibt es schon seit längerem einen passenden Assistenten in der WSUS-Konsole:

wsus_cleanup_00

Dieser Assistent ließ sich “früher” (also z.B. unter Windows Server 2008 R2, WSUS 3.0 SP2) nur manuell oder über komplizierte Skripte ausführen.

wsus_cleanup_01

wsus_cleanup_02

Seit Windows Server 2012 lässt sich WSUS aber auch über PowerShell steuern. Hier gibt es ein passendes Commandlet “Invoke-WsusServerCleanup”, welches die Bereinigung durchführt. Als Parameter kann verwendet werden:

Invoke-WsusServerCleanup [-CleanupObsoleteComputers] [-CleanupObsoleteUpdates]

[-CleanupUnneededContentFiles] [-CompressUpdates] [-DeclineExpiredUpdates]

[-DeclineSupersededUpdates] [-UpdateServer <IUpdateServer> ] [-Confirm] [-WhatIf]

 

Damit lässt sich unkompliziert steuern, welche Komponenten beräumt werden sollen.

wsus_cleanup_03

Dieses PowerShell-Commandlet kann nun z.B. im Rahmen eines kleinen Skriptes regelmäßig und automatisch (z.B. per Aufgabenplanung) ausgeführt werden. Damit spart man sich die regelmäßige, manuelle (aufwändige) Bereinigung mit Hilfe des Assistenten.

Die komplette Syntax zum angesprochenen PowerShell-Commandlet findet sich hier: http://technet.microsoft.com/en-us/library/hh826162.aspx 

3Dez/140

Hyper-V VMs werden angehalten, wenn der Speicherplatz knapp wird

Auch wenn die Tatsache selbst nicht neu ist möchte ich den folgenden Fakt etwas genauer beleuchten, da immer mehr Unternehmen Hyper-V für produktive Virtualisierungszwecke verwenden.

Eine Hyper-V VM wird vom System angehalten, wenn der Speicherplatz auf dem Laufwerk, welches von der VM für die virtuelle Festplatte verwendet wird, knapp wird. Dies geschieht in erster Linie nur dann, wenn die VM mit einer dynamisch wachsenden VHD oder VHDX arbeitet. Auf Grund eines Bugs waren aber bei früheren Hyper-V Versionen (2008 / 2008 R2) auch VMs mit statischen VHDs betroffen.

Das Anhalten der VM geschieht, um einen Absturz des Gastbetriebssystemes auf Grund von Speicherplatzmangel zu vermeiden (die VM “glaubt” noch reichlich Speicherplatz zu haben und versucht, diesen zu belegen, u.a. auch für die Auslagerungsdatei, in Wahrheit ist der Speicherplatz auf dem Datenträger bereits fast vollständig belegt).

Das Anhalten der VM wird dann mit dem Status “Angehalten – Kritisch” markiert (“Paused – Critical” auf englischen Systemen):

HVFreeSpace01

Insbesondere wenn viele VMs mit dynamisch wachsenden VHDs das selbe Plattensystem nutzen ist das Risiko, dass dies geschieht, relativ groß.

Glücklicherweise kündigt sich das bereits vorab an:

HVFreeSpace03

Im Ereignisprotokoll wird unterhalb von “Microsoft / Windows / Hyper-V-VMMS / Admin” ein Ereignis 16050 protokolliert, welches auf den zur Neige gehenden Speicherplatz hinweist.

Das Problem dabei: Dies geschieht erst, wenn der freie Speicherplatz unter 2GB fällt und benötigt auch einige Sekunden nach dem diese Grenze erreicht wurde, bis der Eintrag protokolliert wird.

Wenn der Speicherplatz dann noch knapper wird und eine oder mehrere VMs angehalten wurden wir dies ebenfalls vermerkt:

HVFreeSpace04

Hier wird im selben Protokoll das Ereignis 16060 vermerkt. Dieses weist nun also auch auf die Tatsache hin, dass eine VM angehalten wurde. Dies geschieht allerdings erst, wenn nur noch 200MB oder weniger zur Verfügung stehen!

HVFreeSpace02

(Hinweis: Die Screenshots stammen von einem Testsystem; Es wird ausdrücklich nicht empfohlen, Hyper-V Daten auf dem Betriebssystem-Laufwerk abzulegen!)

Wenn man mit Snapshots / Checkpoints arbeitet, dann sollte man noch beachten, dass die Daten nach dem Snapshot evtl. auf einem anderen Laufwerk abgelegt werden als vorher!

Mittels “Aufgabe an dieses Ereignis anfügen…” kann man z.B. ein Skript oder eine E-Mail auslösen, wenn die betreffenden Ereignisse eintreten:

HVFreeSpace05

(Dazu muss dann das betreffende Ereignis mittels Rechtsklick angeklickt werden, im Screenshot habe ich ein beliebiges anderes Ereignis gewählt)

5Aug/140

PowerShell: Anmelde-Konto der Windows-Dienste überprüfen

Wenn auf einem Windows Server Dienste nicht mit dem richtigen Konto gestartet werden, können diverse Fehler auftreten, z.B. der Fehler 1079:

pwservices1

Der Fehler entsteht, wenn mehrere Konten unter dem selben Prozess (z.B. svchost) laufen, dabei aber verschiedene Konten nutzen sollen.

Nun muss man also herausfinden, welche Dienste betroffen sind. Dies geht sicherlich auch über die services.msc (also in der GUI) – ist dann aber mit viel Arbeit verbunden. Einfacher wäre es sicherlich, dies über PowerShell herauszufinden.

Leider kennt das Cmdlet “Get-Service” keine Möglichkeit, die Logon-Werte auszugeben:

pwservices2

Selbst der Aufruf “Get-Service | fl *” zeigt kein passendes Attribut:

pwservices3

Was bleibt nun also? Eine Abfrage mittels WMI!

pwservices4

Und tatsächlich – hier gibt es nun ein Attribut “StartName”, welches das verwendete Konto enthält. Nun kann man also eine einfache Liste aller Dienste mit ihren Konten abrufen:

pwservices5

Will man statt den “internen” (teil kryptischen) Dienstnamen die sprechenden Namen sehen, und auch nach diesen sortieren, dann kann man folgenden Aufruf verwenden:

Get-WmiObject win32_service | Sort-Object Caption | ft Caption,StartName

pwservices45

Über Where-Object kann man nun auch gezielt nach Diensten mit einem bestimmten Konto suchen:

pwservices7

4Aug/142

Windows Server 2012 R2: Netzwerk-Profil mit PowerShell von “Öffentlich” auf “Privat” ändern

Oft kommt es vor, dass ein Windows Server das Netzwerk-Profil (Domäne oder Privat) nicht sauber erkennt und stattdessen auf “Öffentlich” steht. Dies hat natürlich Auswirkungen, z.B. auf die gesetzten Firewall-Regeln:

fw0

Eine kurze Überprüfung im “Netzwerk- und Freigabecenter” fördert das gleiche Ergebnis zu Tage:

fw1

Auch mit Hilfe der Windows PowerShell kann man dies sehen…

fw2

… und ändern!

fw3

Mit Hilfe des Aufrufs

Set-NetConnectionProfile –InterfaceIndex # –NetworkCategory Private

wird das Verbindungsprofil auf “Privat” gesetzt (“Domain” setzt auf Domäne). Nun kann man auch im Netzwerk- und Freigabecenter das korrekte Verbindungsprofil sehen:

fw4

17Jul/140

WDS und SCCM oder 2x WDS parallel betreiben / Probleme mit PXE lösen

Wenn man (z.B. während der Einführungsphase vom System Center Configuration Manager) den bisherigen WDS-Server (Windows Bereitstellungsdienste / Deployment Services) weiterhin nutzen will, aber parallel die Betriebssystembereitstellung (OSD) von SCCM benötigt, dann besteht im Wesentlichen das folgende Probleme:

Da PXE auf Broadcasts basiert, kann es nur einen PXE-Server geben, den der Client letztlich kontaktiert (man kann per Verzögerung dafür sorgen, das einer immer schneller ist als der andere). Wenn man nun also PXE am SCCM aktiviert, dann ist es quasi Glückssache, ob der Client zuerst die Meldung vom WDS oder zuerst die von SCCM empfängt – in den meisten Tests war SCCM schneller. Damit bleibt also nur eine der beiden Technologien nutzbar.

Aber es gibt eine Lösung! Diese ist leider a) nicht wirklich dokumentiert und b) seitens Microsoft auch nicht unterstützt (man hört aber, das selbst Microsoft diese Lösung intern einsetzen soll).

Die Lösung besteht darin, dem Benutzer am Client die Wahl zu lassen, welchen der gefundenen PXE-Server er nutzen will. Um dies zu erreichen, ist am WDS-Server (also derjenige, der nicht der SCCM-Server ist) ein Registry-Key zu setzen:

pxe1

Zusätzlich muss am SCCM in den eigenschaften des Distribution-Points (Verteilungspunkt) für eine ausreichende Verzögerung gesorgt werden (würde man zuerst den PXE vom SCCM booten, dann hat der RegKey dort keine Wirkung, da dieser nur auf den WDS-eigenen PXE-Provider wirkt, nicht aber auf den vom SCCM):

pxe5

Wenn nun ein Client einen PXE-Boot versucht (und die Verzögerung ausreichend war, dass sich zuerst der Nur-WDS-PXE-Server meldet), dann bekommt der Benutzer zusätzlich zu der Möglichkeit, per F12 vom Netzwerk zu booten eine weitere Option: F11 für eine Server-Auswahl!

pxe2

Drückt man jetzt F12, wird wie gewohnt DIESER WDS-Server genutzt und von dort mittels PXE gebootet. Drückt man jedoch F11, werden zuerst alle verfügbaren WDS-Server erkannt:

pxe3

Danach bekommt man eine Auswahl-Liste mit allen gefundenen PXE-Servern:

pxe4

Hier kann nun der jeweilige PXE-Server gewählt werden. Der WDS-Server selber steht an erster Stelle, an zweiter Stelle steht hier der SCCM mit aktiviertem PXE.

Auf diese Weise ist es möglich, WDS und SCCM oder mehrere WDS-Server parallel zu betreiben. Natürlich muss die entsprechende DHCP-Infrastruktur aufgebaut sein, damit PXE überhaupt funktionieren kann!

5Mai/140

BranchCache mit Windows Server 2012 R2 und Windows 8.1

BranchCache, eine Technologie die mit dem Windows Server 2008 R2 und Windows 7 eingeführt wurde, ermöglicht es, den Datenverkehr auf WAN-Strecken und die damit einhergehende Wartezeit bei der Übertragung zu reduzieren. Es geht darum, den lesenden Zugriff von einem Unternehmens-Standort (hier als “Filiale” bezeichnet) auf Daten in einem anderen Standort (hier als “Firmensitz” bezeichnet) zwischen zu speichern (“caching”).

Grundsätzlich stehen zwei verschiedene Modi zur Verfügung:

  • Hosted Cache (“Gehosteter Cache”)
  • Distributed Cache (“Verteilter Cache”)

Beim Hosted Cache übernimmt ein Server in der Filiale die Aufgabe des Caches. Er speichert die Daten entsprechend zwischen. Beim Distributed Cache wird auf einen dedizierten Server verzichtet – die Clients der Filiale übernehmen das Caching. Vorteil des Distributed Cachings ist also der Verzicht auf zusätzliche Hardware und den damit verbundenen Verwaltungsaufwand. Allerdings entsteht der Nachteil, dass das Endgerät, welches die Daten in seinem Cache hält, zum benötigten Zeitpunkt nicht online ist und somit der Cache nicht genutzt werden kann.

Es existieren mittlerweile zwei verschiedene Versionen:

  • V1 steht bereits ab Windows Server 2008 R2 und Windows 7 zur Verfügung
  • V2 steht erst ab Windows Server 2012 und Windows 8 zur Verfügung

Der Ablauf beim Distributed Cache ist (etwas vereinfacht) der folgende:

  1. Client1 in der Filiale soll ein File auf einem Dateiserver am Firmensitz öffnen; durch eine GPO ist er für BranchCache und den Modus “Distributed Cache” konfiguriert. Beim Dateiserver fragt er nicht die Datei selber sondern deren Hash (eine Art Fingerabdruck, die das File in seiner aktuellen Version identifiziert) an.
  2. Der Dateiserver überträgt den Hash zum Client1 (Der Hash wurde vom Dateiserver generiert, dieser ist ebenfalls durch eine GPO entsprechend konfiguriert)
  3. Client1 fragt per Broadcast in seinem Subnetz an, ob andere Clients das File in ihrem Cache haben, welches durch den Hash identifiziert wird; im Beispiel gehen wir nun davon aus, dass keiner der anderen Clients dieses File bisher geöffnet hat
  4. Client1 fragt nun noch einmal beim Dateiserver an; dieses Mal jedoch direkt nach der Datei statt nach deren Hash
  5. Die Datei wird zum Client1 übertragen und dort geöffnet
  6. Wenn nun auch Client2 in der Filiale diese Datei öffnen will, dann beginnt der Prozess wieder “von neuem”: Client2 fragt beim Dateiserver den Hash für das File an
  7. Der Dateiserver überträgt den Hash an Client2
  8. Client2 fragt per Broadcast in seinem Subnetz nach dem Hash
  9. Client1 meldet sich, da dieser das File in seinem Cache hat (Voraussetzung ist, dass sich das File zwischenzeitlich auf dem Dateiserver nicht geändert hat, denn dann hätte es einen anderen Hash!); Die Datei wird nun aus dem Cache von Client1 zum Client2 übertragen; dieser kann das File nun öffnen (und er hält es fortan auch in seinem Cache vor!)

Dabei haben also folgende Übertragungen stattgefunden:

  • 2x Abfrage des Hashes über WAN
  • 1x Übertragung des Files über WAN
  • 1x Übertragung des Files über LAN

Eingespart wurde also die zweite Übertragung des Files über WAN; stattdessen kommt die Übertragung der Hashes hinzu, die aber im Verhältnis deutlich kleiner sind

BranchCache ist also insbesondere sinnvoll bei:

  • Unternehmen mit verschiedenen Standorten
  • Häufigen lesenden Zugriffen auf sich selten ändernde Dateien über das gesamte Unternehmensnetzwerk

Die Edition des Server-Betriebssystems spielt bei einem Server 2012 R2 keine Rolle, bei den Clients muss unter Windows 8.1 die Enterprise-Edition eingesetzt werden. (Unter Server 2008 R2 muss der Caching-Server mindestens die Enterprise-Edition verwenden, für den Dateiserver spielt die Edition keine Rolle; Windows 7 Clients müssen mindestens die Enterprise-Edition verwenden.)

Im Folgenden möchte ich den Aufbau einer einfachen BranchCache-Umgebung darstellen. Dabei gibt es einen Server, SRV1, der neben der Aufgabe des Domänen-Controllers auch gleichzeitig die Aufgabe des Dateiserver übernimmt. Die beiden Clients WIN8-1 und WIN8-2 werden dann den Zugriff auf eine Datei des Dateiservers durchführen.

Auf SRV1 wird über den Servermanager / “Verwalten” / “Rollen und Features hinzufügen” ein Rollendienst hinzugefügt:

branchcache1

Unterhalb der Rolle “Datei-/Speicherdienste” findet sich “BranchCache für Netzwerkdateien”:

branchcache2

Nach der Installation dieses Rollendienstes kann nun an jeder Freigabe, bei der dies gewünscht ist, BranchCache aktiviert werden. Dies geschieht in den Eigenschaften der “Erweiterten Freigabe” über den Button “Zwischenspeichern”:

branchcache3

branchcache4

Als nächstes müssen nun zwei Gruppenrichtlinien konfiguriert werden:

  • CPR_BranchCache_Content ist für den Fileserver gedacht und wird sinnvollerweise über die Sicherheitsfilter nur auf diese angewendet
  • CPR_BranchCache_Clients ist für die Clients gedacht und kann z.B. per WMI-Filter dynamisch auf diese wirken

branchcache5

Innerhalb der Content-Policy wird zum einen die Hash-Veröffentlichung aktiviert und zum anderen die Version festgelegt. Man kann hier zwischen “Nur V1”, “V1 und V2” oder “Nur V2” wählen:

branchcache6

Der relevante Pfad innerhalb der GPO lautet “Computerkonfiguration” / “Richtlinien” / “Administrative Vorlagen” / “Netzwerk” / “LanMan-Server”

branchcache7

branchcache8

Innerhalb der Client-Policy sind etwas mehr Einstellungen vorzunehmen:

branchcache9

Hier muss BranchCache aktiviert werden, der Modus “Verteilter Cache” festgelegt werden und optional können die maximale Speicherbelegung, das maximale Alter und weitere Dinge konfiguriert werden. Aus Demo-Zwecken werde ich außerdem in der Einstellung “BranchCache für Netzwerkdateien konfigurieren” die minimale Latenz von 80ms auf 0ms herabsetzen und somit das Nutzen des Caches auch in einem schnellen Netzwerk erzwingen:

branchcache10 branchcache11
branchcache12 branchcache13
branchcache14  

Sinnvollerweise wird nun auf dem Server und den Clients ein gpupdate durchgeführt, um nicht erst auf das Verarbeiten der GPOs warten zu müssen:

branchcache15

Nun kann man auf den Clients noch einmal die Branchcache-Konfiguration überprüfen. Dies geschieht mit Hilfe des Aufrufes

netsh branchcache show status all

Sollte dann in etwa so aussehen:

branchcache16

Nun kann mittels Leistungsüberwachung getestet werden, ob die Konfiguration funktioniert. Dazu sind die entsprechenden Indikatoren hinzuzufügen:

branchcache18

Sinnvollerweise schaltet man nun die Leistungsüberwachung auf “Bericht” um (drittes Symbol in der Leiste oben von links gezählt).

Der Benutzer “Franz Iskaner” öffnet nun von WIN8-1 aus ein Dokument auf dem Dateiserver:

branchcache19

Eine Eigenart des integrierten PDF-Readers auf WIndows 8 ist, dass dieser das Dokument nur in Teilen öffnet und beim Lesen dann entsprechend die Inhalte nachlädt. Daher wurde nun also nicht das gesamte Dokument mit ca. 13MB sondern nur ein Teil davon vom Server abgerufen (ich habe die ersten hundert Seiten von ca. 2000 durchgeblättert):

branchcache20

Auf WIN8-2 öffnet nun “Karl Auer” das selbe Dokument, die Leistungsüberwachung ist geöffnet und zeigt nun folgende Werte auf WIN8-2:

branchcache21

(WIN8-1 hatte zwischenzeitlich weitere Teile des Dokumentes abgerufen, weshalb WIN8-2 etwas mehr vom Cache abrufen konnte als WIN8-1 im oberen Screenshot vom Server abgerufen hatte)

Ein Teil des Dokumentes kommt hier (das aber insbesondere wegen des PDF-Readers) immer noch vom Server – nämlich der Teil, der nicht im Cache auf WIN8-1 liegt, weil er dort bisher nicht geöffnet wurde.

Die Funktionsfähigkeit der BranchCache-Konfiguration ist damit aber gezeigt.

An dieser Stelle sei nochmal darauf hingewiesen, das BranchCache nur LESEND funktioniert – beim Schreiben wird direkt auf den Server geschrieben und nicht in den Cache!

Weitere Informationen zum Thema Branchcache finden sich im Microsoft Technet:

http://technet.microsoft.com/de-de/library/hh831696.aspx