Drücke "Enter", um den Text zu überspringen.

Kategorie: Windows Client

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

Schreibe einen Kommentar...

Windows 8.1 als WLAN-Hotspot nutzen

Windows 8.1 hat eine einfache Möglichkeit an Board, eine bestehende Internetverbindung (z.B. 3G/UMTS) über WLAN mit bis zu 10 Geräten zu teilen. Diese Möglichkeit kann man mit passender Software auch schon in älteren Windows-Versionen nutzen, dort lautet das Stichwort “ICS” (Internet Connection Sharing). Hier ist die Einrichtung aber nicht ganz so einfach wie unter Windows 8.1. Dort existiert nämlich eine tiefere Einbindung von UMTS-Verbindungen in das Betriebssystem. Das Ganze wird dort als “Mobile Broadband” bezeichnet. Damit das Freigeben der Verbindung über WLAN klappt, benötigt man ein UMTS-Gerät mit NDIS 6.3 kompatiblem Treiber. Das lässt sich im Zweifelsfall per PowerShell-Kommando abfragen:

Get-NetAdapter | Select Name, NdisVersion

Um die UMTS-Verbindung freizugeben, müssen sowohl die WLAN-Verbindung als auch die UMTS-Verbindung eingeschalten sein:

hotspot1

Danach muss die “Mobile Broadband” Verbindung geöffnet werden. Dies geschieht über “Change PC setting” / “PC-Einstellungen ändern” ([WIN]+[I]), dort unter “Network” / ”Netzwerk”:

hotspot2

Dort kann das Freigeben der Verbindung aktiviert werden (“Share this connection” / ”Diese Verbindung freigeben”):

hotspot3

Dazu ist einfach der Schieber auf “on” zu bewegen. Die standardmäßige SSID entspricht dem Hostnamen, kann aber, ebenfalls wie das (zufällig generierte) Kennwort über den “Edit”-Button geändert werden.

Bis der Hotspot auf anderen WLAN-Geräten zu sehen kann eine Weile dauern (bis zu 30 Sekunden). Danach kann die Verbindung genutzt werden.

Dabei ist zu beachten, dass bei einem Verbindungsabbruch der UMTS-Verbindung standardmäßig kein Wiederverbinden stattfindet. Dies lässt sich aber so einstellen:

hotspot4

Weitere Informationen siehe hier:

http://windows.microsoft.com/de-DE/windows-8/mobile-broadband-from-start-to-finish#

Schreibe einen Kommentar...

Hyper-V und USB-Datenträger

Oft liest und hört man, dass Hyper-V nicht mit USB-Datenträgern umgehen kann/könne. Dies wird mit der Generation-2-VM unter Windows Server 2012 R2 (Hyper-V 4.0) anders. Dort ist es dank des “Erweiterten Sitzungsmodus” möglich, eine Hyper-V VM auch ohne Netzwerk per RDP anzusprechen und dabei auch Laufwerke mitzunehmen.

Aber: Auch unter den älteren Hyper-V-Versionen bzw. auch bei Generation-1-VMs lassen sich USB-Datenträger mit in die VM “hineinreichen”. Dies klappt allerdings leider nur dann, wenn sich der Datenträger als Festplattenlaufwerk präsentiert (i.A. also bei USB- und Firewire-Festplatten). Dazu muss folgendermaßen vorgegangen werden:

1. Datenträger am Host-System über die Datenträgerverwaltung offline schalten:

hvusb1

(Die Datenträger-Verwaltung erreicht man bei Windows 8 bzw. dem Server 2012 am einfachsten mit [WIN]+[X])

Dann kann man per Rechtsklick auf den gewünschten Datenträger diesen offline schalten:

hvusb2

hvusb3

2. Den Datenträger als Pass-Through-Disk an die Hyper-V VM als neues Laufwerk anbinden:

hvusb4

(Da Hyper-V mit dem SCSI-Controller auch hotplug-fähig ist, klappt dies sogar, während die VM läuft)

hvusb5

Statt einer vorhandenen virtuellen Festplatte wählt man eben unten eine physische Festplatte aus; hier werden nur Datenträger zur Auswahl angeboten, die beim Host offline sind.

3. Datenträger an der VM online schalten und benutzen:

In der Datenträgerverwaltung des Gast-Systems taucht nun eine Festplatte auf, die aber noch offline ist. Analog zum Offline-Schalten im ersten Schritt erfolgt hier nun die Online-Schaltung:

hvusb6

 

Anschließend steht die USB-Festplatte in der Gastbetriebssystem-Umgebung zur Verfügung:

hvusb7

Vor dem Trennen der USB-Platte sollte diese sauber (den bisherigen Weg rückwärts) ausgehangen werden, um Datenverlust o.ä. zu vermeiden.

2 Comments

PowerShell: Alle Windows-Updates automatisch entfernen

Das entfernen ALLER Windows-Updates von Hand ist sehr mühsam. Die PowerShell schafft hier abhilfe. Das folgende kleine Skript ermittelt alle installierten Windows-Updates und entfernt diese der Reihe nach:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
$hotfixes = Get-WmiObject -Class Win32_QuickFixEngineering | select hotfixid
 
foreach($hotfix in $hotfixes)
{
    $KBNummer = $hotfix.HotfixId.Replace("KB", "")
    $Kommando = "wusa.exe /uninstall /kb:$KBNummer /quiet /log /norestart"
    Write-Host ("Removing update with command: " + $Kommando)
    Invoke-Expression $Kommando
    While (@(Get-Process wusa -ErrorAction SilentlyContinue).Count -ne 0)
    {
        Start-Sleep 1
        Write-Host "Waiting for update removal to finish ..."
    }
}
Schreibe einen Kommentar...

RDP 8.0 nun auch für Windows 7 und Server 2008 R2 (KB2592687)

Parallel zum Launch von Windows 8 wird das in Win8 enthaltene RDP-Protokoll in der Version 8.0 nun auch für Windows 7 und den Server 2008 R2 nachgeliefert:

http://support.microsoft.com/kb/2592687

Auszug aus dem Technet:

Neue Funktionen für Clientcomputern mit Windows 7 SP1 oder Windows Server 2008 R2 SP1

Das RDP-8.0-Update enthält die folgenden neuen Funktionen für Clientcomputer, auf denen Windows 7 SP1 oder Windows Server 2008 R2 SP1 ausgeführt wird:

  • Remote Desktop Connection 8.0-client
  • Dynamische-Session-USB-Umleitung
  • Schließen Sie für die RemoteApp- und Desktopverbindungen
  • Verbesserte single Sign-on Erfahrung für Web Access für Remotedesktop
  • Unterstützung für RemoteFX Media Umleitung APIs für VoIP-Anwendungen
  • Unterstützung für geschachtelte Sitzungen

Neue Funktionen für remote-Computern mit Windows 7 SP1

Der RDP-8.0-Aktualisierung können remote-Computern, auf denen Windows 7 SP1 verwendet RDP 8.0 ausgeführt werden. Das Update enthält die folgenden Funktionen für remote-Computern, auf denen Windows 7 SP1 ausgeführt werden:

  • RemoteFX für WAN
  • RemoteFX Netzwerk automatisch erkennen
  • RemoteFX Adaptive Grafiken
  • RemoteFX USB-Umleitung für nicht RemoteFX vGPU virtuelle desktops
  • Unterstützung für geschachtelte Sitzungen
  • Leistungsindikatoren zur Überwachung der Benutzerfreundlichkeit

RDP 8.0 kann für remote-Computern aktiviert werden, die Windows Server 2008 R2 SP1 ausgeführt werden.

 

Quelle:  http://support.microsoft.com/kb/2592687

Schreibe einen Kommentar...

Erstes Cumulative Update (CU) für Windows 8 RTM und Windows Server 2012 RTM

Seit heute ist das erste große Update für Windows 8 und Windows Server 2012 (jeweils RTM) verfügbar.

Änderungen laut TechNet:

„Dieses kumulative Update enthält die folgenden Verbesserungen der Leistung und Zuverlässigkeit:

  • Mehr Energieeffizienz, Akkulebensdauer
  • Leistungsverbesserungen in Windows 8 Anwendungen und Startbildschirm
  • Verbesserte Audio- und Videowiedergabe in vielen Szenarios
  • Verbesserte Anwendungs- und Kompatibilität mit Windows 8″

Quelle: http://support.microsoft.com/kb/2756872

Das Update kommt automatisch per Windows Update oder kann hier heruntergeladen werden:

http://www.microsoft.com/en-us/download/details.aspx?id=34908

Schreibe einen Kommentar...

Windows 8: Nach dem Start direkt zum Desktop (statt Metro-UI)

Folgende Anleitung zeigt, wie man dafür sorgen kann, dass Windows 8 nach dem Starten (bzw. Anmelden) direkt zum Desktop wechselt statt die Metro-UI anzuzeigen. Dazu wird ein kleines Script und eine neue Aufgabe in der Aufgabenplanung (=Taskplaner) benötigt.

Das Script (in meinem Fall unter C:\Users\Public\Documents\NoMetro.scf) abgespeichert, hat folgenden Inhalt:

[Shell]
Command=2
IconFile=Explorer.exe,3

[Taskbar]
Command=ToggleDesktop

Dabei ist die Endung SCF wichtig!

Nun ist eine neue Aufgabe notwendig, die dieses Script beim Anmelden ausführt:






1 Kommentar