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

Kategorie: Windows Server 2012

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 Server 2012 (R2): Disk-Performance im Taskmanager anzeigen

In Windows 8 und 8.1 zeigt der Taskmanager standardmäßig neben der Last auf CPU und RAM auch die Disk-Performance an:

diskperf1

Dies ist sehr praktisch, weil man hier u.a. die Latenz sowie die Last in Prozenten und die tatsächlichen Raten sehen kann.

Bei einem Windows Server 2012 bzw. 2012 R2 wird das standardmäßig nicht angezeigt:

diskperf2

Wenn man nun auch hier die Disk-Performance sehen möchte, dann kann man dies aktivieren.

ACHTUNG: Das Aktivieren des Disk-Performance-Counters auf einem Server hat Auswirkungen auf die I/O-Performance der Festplatte (wie stark ist allerdings mit Sicherheit situationsabhängig)

Das Aktivieren ist recht einfach und funktioniert über einen simplen Aufruf in einer Kommandozeile mit Administratoren-Rechten:

diskperf3

Für Suchmaschinen und co.: Der Aufruf lautet

diskperf –Y

Sobald man das Kommando ausgeführt hat und den Taskmanager (neu)startet, sind auch auf dem Server die Disk-Daten zu sehen:

diskperf4

Das Abschalten ist nun eher trivial:

diskperf –N

Schreibe einen Kommentar...

Windows Server 2012 R2: Einrichten eines Failover-Clusters am Beispiel Hyper-V

Ein Failover-Cluster ist eine gute Sache: Er sorgt für Hochverfügbarkeit! Damit lassen sich diverse Dienste geclustert betreiben. Mehrere Server teilen sich eine Aufgabe und die dazugehörige Last. Fällt nun einer der beteiligten sogenannten “Knoten” aus, so übernehmen die verbliebenen die Aufgabe sofort automatisch. Damit lässt sich beispielsweise auch Hyper-V bzw. die darauf laufenden virtuellen Maschinen gegen einen Ausfall absichern.

Für eine Minimal-Konfiguration werden benötigt:

  • Ein Domänencontroller
  • Zwei weitere Server als Mitglied der Domäne
  • Zentraler Speicher

Für den zentralen Speicher kämen die beiden SAN-Technologien iSCSI und FiberChannel in Frage. Optional geht seit Server 2012 auch SMB3.0 (“Scale Out File Server”). Für eine Testumgebung ist iSCSI sehr gut geeignet. Wie man ein iSCSI-Target einrichtet und den dazugehörigen Initiator nutzt habe ich in einem meiner letzten Blogartikel beschrieben (Windows Server 2012 R2: iSCSI Target und Initiator einrichten).

Der Domänencontroller sowie die beiden Member-Server laufen unter Windows Server 2012 R2.

Es werden 2 iSCSI-Targets benötigt, eines mit min. 512MB Speicher, das zweite mit ausreichend Speicher für die vorgesehenen VMs und deren VHD(X)-Dateien, in meinem Fall 40GB. Die beiden Targets müssen bereits auf beiden Knoten eingebunden sein, die beiden Datenträger online geschaltet worden sein, initialisiert und formatiert (ohne Laufwerksbuchstaben).

Weiterhin muss das Netzwerk sauber konfiguriert sein. Für eine Testumgebung reicht es, wenn die beiden Hosts über genau eine Netzwerkverbindung verfügen. Dort muss das selbe Subnetz eingerichtet sein, ebenso ein passender DNS-Server und ein Gateway. Für Produktivzwecke empfehlen sich deutlich mehr Netzwerkverbindungen, z.B. eine dedizierte für den Heartbeat (Link zwischen den Knoten), eine für die Anbindung an das Storage, eine für die Verwaltung, eine für die Anbindung an das reguläre Netzwerk und so weiter und so fort.

Als nächstes muss auf allen künftigen Knoten das Feature “Failoverclustering” installiert werden. Dazu werden auch die Verwaltungstools angeboten, die zumindest auf einem System installiert sein müssen, um den Cluster einrichten zu können:

failover1

failover2

failover3

Wenn die Installation auf beiden/allen künftigen Knoten abgeschlossen ist kann der “Failovercluster-Manager” gestartet werden, z.B. über “Tools” im Servermanager:

failover4

Dort wird durch einen Rechtsklick auf das Wort “Failovercluster-Manager” im Baum links mittels “Cluster erstellen…” der Prozess begonnen:

failover5

In den ersten Schritten sind die künftigen Knoten auszuwählen:

failover6 failover7
failover8 failover9
failover10  

Danach folgt eine Abfrage bezüglich des “Konfigurationsvalidierungstests”. Dabei werden die beteiligten Server “auf Herz und Nieren geprüft”. Dieser Test dauert ca. 10 Minuten. Man könnte ihn abschalten – verzichtet dann auber auf den Support durch Microsoft und wertvoll Hinweise zur Konfiguration. Nicht zuletzt kann der Test einem auch Fehler aufzeigen, die man bei der Vorbereitung übersehen hat. Ich würde ihn also immer laufen lassen…

failover11 failover16
failover13 failover14
failover15 failover16

Am Ende des Tests wird einem das Ergebnis angeboten (“Bericht anzeigen”):

failover17

In diesem Fall liegt nur eine Warnung vor: Es gibt nur eine Netzwerkverbindung!

Nun muss noch ein Name für den Cluster sowie eine entsprechende IP-Adresse bestimmt werden. Außerdem kann man auswählen, dass der gesamte verfügbare Speicher dem Cluster hinzugefügt werden soll:

failover18 failover19
failover20 failover21

Danach beginnt die eigentliche Bildung des Clusters. Ist diese abgeschlossen, kann die Clusterkonfiguration verändert werden bzw. der Cluster mit Rollen ausgestattet werden. Dabei ist zum einen die Netzwerkkonfiguration zu prüfen: Wenn es einen dedizierten Link zwischen den Hosts geben soll, so ist bei dieser Netzwerkkonfiguration der Haken “Clients das Herstellen einer Verbindung…” zu entfernen. Weiterhin muss das zweite iSCSI-Target noch als “Cluster Shared Volume” (CSV) bzw. al “freigegebenes Clutservolume” hinzugefügt werden. Das sorgt dafür, dass dieses “Laufwerk” auf allen Clutserknoten unter C:\ClusterStorage eingebunden wird und dort genutzt werden kann (z.B. für die VMs und VHDs)

failover22

failover23

Abschließend können nun VMs im Cluster erzeugt werden. Dabei ist darauf zu achten, das alle relevanten Daten unter C:\ClusterStorage liegen!

failover24

failover25

failover26

failover27

Wenn die VM fertig konfiguriert ist und läuft, dann kann man ganz einfach die Funktionsfähigkeit des Clusters testen und einen einfachen Ausfall simulieren: Man zieht einfach das Netzwerkkabel aus dem Host heraus, auf dem die VM aktuell ausgeführt wird. Dann sollte sie in kurzer Zeit auf dem verbliebenen Host neu gestartet werden und dann kurz darauf wieder regulär zur Verfügung stehen!

Schreibe einen Kommentar...

Windows Server 2012 R2: iSCSI Target und Initiator einrichten

Seit dem Windows Server 2012 ist ein Software iSCSI Target mit an Board, welches früher separat beschafft und nachinstalliert werden musst. Dieses kann z.B. wunderbar für die Einrichtung eines Failover-Clusters verwendet werden, oder auch für Datensicherung “off-site”. Die Einrichtung des Targets und eines Initiators möchte ich hier beschreiben:

Das iSCSI-Target

Zu erst einmal muss das iSCSI Target auf einem Windows Server installiert werden. Dies geschieht am besten über den Server-Manager und dort über “Verwalten” / “Rollen und Features hinzufügen”. Dort ist dann in der Liste der Features der “iSCSI-Zielserver” auszuwählen:

iscsi0

Ist dies erledigt, können (ebenfalls über den Servermanager) iSCSI-Disks und –Targets eingerichtet werden. Dies geschieht im Bereich “Datei-/Speicherdienste”. Dort kann man einfach “Starten Sie den Assistenten für neue virtuelle iSCSI-Datenträger…” auswählen:

iscsi1

Auf der ersten Seite des Assistenten ist zu wählen, wo die für die iSCSI-Disk verwendete VHDX-Datei abgelegt werden soll. Man kann entweder nur das Laufwerk wählen, dann wird dort ein neuer Ordner “iSCSIVirtualDisk” angelegt, oder man wählt einen eigenen Pfad:

iscsi2

Auf der nächsten Seite ist einfach nur der Name der künftigen Disk festzulegen:

iscsi3

Im dritten Schritt kann man wählen, ob die iSCSI-VHDX eine Datei “Fester Größe”, eine “Dynamisch erweiterbare” oder eine “Differenzierende” ist. Dynamisch erweiterbar spart dabei erstmal Speicherplatz, da die Datei mit den darin abgelegten Daten mit wächst. Dafür ist hier ein kleines Delay “vorprogrammiert”, weil eben immer wieder neu Speicherplatz angefordert werden muss, wenn die Datei wachsen soll. Für Testumgebungen oder wenn der Speicherplatz sehr knapp ist kann man das aber dennoch verwenden:

iscsi4

In den nächsten Beiden Schritten kann nun gewählt werden, ob ein vorhandenes iSCSI-Target verwendet oder ein neues angelegt werden soll:

iscsi5 iscsi6

In meinem Fall habe ich ein neues Target erstellt.

Nun müssen zulässige Server für den Zugriff ausgewählt werden, die so genannten “Initiatoren”. Dies geschieht durch einen Klick auf “Hinzufügen”:

iscsi7

Die Initiatoren werden für gewöhnlich über einen sogenannten IQN identifiziert. Dieser kann ab Windows 8 und Server 2012 direkt vom Server abgefragt werden (obere Option). Hat man bereits einen IQN abgefragt, so steht dieser dann bei der mittleren Option für weitere Targets zur Verfügung. Als dritte Option kann man das Ziel über DNS, IP oder durch händische Eingabe des IQN bestimmen:

iscsi8

Ich werde hier von einem anderen WS2012R2 zugreifen, daher kann ich die obere Variante wählen:

iscsi9

iscsi11

Wenn das iSCSI-Target später für einen Failover-Cluster genutzt werden soll, dann müssen alle künftigen Knoten eingetragen werden:

iscsi12

Optional kann nun noch CHAP, das “Challenging Handshake Protocol” aktiviert werden, um etwas mehr Sicherheit zu bekommen:

iscsi13

Zum Schluss gibt es noch eine Zusammenfassung:

iscsi14

Sind die Targets eingerichtet, so tauchen diese dann künftig im Servermanager auf:

iscsi15

Der iSCSI-Initiator

Für den Server- oder Clientseitigen Zugriff auf das eingerichtete iSCSI-Target wird der iSCSI-Initiator verwendet, welcher standardmäßig bei den moderneren Client- und Serverbetriebssystemen dabei ist:

iscsi1_0

Beim ersten Start kommt eine Abfrage bezüglich des Dienstes. Diese muss mit “Ja” beantwortet werden. Danach können Ziele eingerichtet werden, in dem die Adresse oder der Hostname des Target-Servers in das oberste Feld eingetragen wird und dann auf “Schnell verbinden” geklickt wird:

iscsi2

Wenn das Zielsystem sauber kontaktiert werden konnte, dann sollte man nun die eingerichteten Targets sehen können:

iscsi3

Entweder man klickt hier direkt auf “Verbinden” oder erst einmal auf “Fertig” (dann kann man später noch Multipath aktivieren).

Nun sollten die Ziele in etwa so aufgelistet sein:

iscsi4

Wenn man nun eines auswählt und auf “Verbinden” klickt, kann die Verbindung (unter Nutzung von Multipfad) hergestellt werden:

iscsi5

Am Ende sollten die Targets so im Initiator auftauchen:

iscsi6

Nun kann über [WIN]+[X] die Datenträgerverwaltung geöffnet werden:

iscsi7

Dort tauchen die Laufwerke nun auf und können partitioniert und formatiert werden. Das wäre es dann auch schon gewesen…

iscsi8

iscsi9

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

Problem bei der Installation des DHCP-Servers unter Windows Server 2012, Fehler 0x800f0922

Ein Kollege bat mich, mir ein Problem bei einem DHCP-Server anzusehen. Dieser ließ sich nicht mehr starten und auch ein Entfernen der Rolle brachte insofern keine Abhilfe, da sich die Rolle nicht mehr neu installieren ließ. Es wurde immer der Fehler 0x800f0922 gemeldet:

dhcp-error1

Der Fehler ließ sich auch nicht durch eine Reparatur des Komponentenspeichers mittels “dism /Online /Cleanup-Image /RestoreHealth” beheben.

Eine genauere Analyse zeigte schließlich, dass der Ordner “C:\Windows\System32\DHCP” einen Teil seiner NTFS-ACLs verloren hatte (Vollzugriff bestand nur für eine unbekannte SID statt für “DHCPServer”).

dhcp-error2

Nachdem dies korrigiert war, konnte der Ordner gelöscht werden und schlussendlich ließ sich dann auch die DHCP-Rolle wieder sauber installieren!

So sollten dann die ACLs für den DHCP-Folder aussehen:

dchp-error3

Schreibe einen Kommentar...

Daten-Deduplizierung in Windows Server 2012

Eine unglaublich praktische und einfach zu nutzende Neuerung im Windows Server 2012 ist die Daten-Deduplizierung der Dateiserver-Rolle. Diese Funktion ermöglicht es, je nach Zusammensetzung der Dateien, sehr viel Speicherplatz auf einem Dateiserver zu sparen.

Die Deduplizierung arbeitet dabei nicht wie bei anderen Produkten auf Dateibasis, sondern blockbasiert. Alle Dateien eines Volumes, bei dem die Deduplizierung aktiviert ist, werden nach mehrfach vorkommenden “Chunks” durchsucht. Chunks sind variable Einheiten zwischen 32 und 128 Kilobyte (Dateien kleiner als 32kB werden nicht betrachtet). Die Chunks selber werden zusätzlich komprimiert. Kommt nun ein Chunk mehrfach vor, muss er nur einmal gespeichert werden.

Weitere Eigenschaften der Deduplizierung:

  • Transparent (Der Anwender sieht seine Files weiterhin wie bisher)
  • On-Schedule statt On-Access (Deduplizierung findet nicht beim Schreiben statt, sondern “später” laut Zeitplan)
  • Alters-basiert (Dateien werden erst ab einem gewissen Alter dedupliziert; Dateien, die sich jeden Tag ändern sind eher ungeeignet für die Deduplizierung)
  • Ressourcenschonend
  • Redundanz (Wenn ein Chunk von min. 100 Dateien referenziert wird, wird er mehrfach abgespeichert)

Was geht mit der Deduplizierung NICHT bzw. welche Einschränkungen gelten:

  • Lässt sich nicht auf dem Betriebssystem-Volume nutzen
  • Nur für NTFS-Volumes verfügbar (auch nicht für ReFS!)
  • Laufende VMs (bzw. deren VHDs) lassen sich nicht deduplizieren
  • Cluster Shared Volumes können nicht dedupliuziert werden

Wie lässt sich die Deuplizierung nun verwenden? Als erstes muss der Rollendienst installiert werden. Dies geht z.B. per Servermanager:

dedup1

Hinzufügen der Rollen & Features via Servermanager

dedup2

Rollenbasierte Installation

dedup3

Auswahl des gewünschten Zielservers

dedup4

Auswahl des Rollendienstes “Datendeduplizierung” in der Rolle “Datei- und Speicherdienste”

dedup5

Features werden keine benötigt

dedup6

Zusammenfassung der Auswahl, Start der Installation

dedup7

Abschluss der Installation

Nach Abschluss der Installation muss nun noch die Deduplizierung konfiguriert werden. Dies geschieht ebenfalls über den Servermanager, dort über die “Datei-/Speicherdienste”:

dedup8

Dann wird die Deduplizierung für das gewünschte Volume konfiguriert/aktiviert:

dedup9

Wichtig ist, dass hier einerseits die Deduplizierung aktiviert wird, das Mindestalter für zu deduplizierende Dateien festgelegt wird und der Zeitplan festgelegt wird.

dedup10

Zusätzlich könnte man hier noch Dateierweiterungen ausschließen oder sogar ganze Speicherorte (Ordner).

Beim Zeitplan ist grundsätzlich die Hintergrundoptimierung aktiv, die wirksam wird, wenn der Server gerade nichts zu tun hat. Dazu kann man dann bis zu 2 Zeitpläne für die Durchsatzoptimierung festlegen, bevorzugt zu Zeiten, in denen der Server regulär keine Last hat. (Hintergrundoptimierung kann bei VMs mitunter schwierig sein, weil sich der IO auf dem Storage nicht von einer einzelnen VM bewerten lässt).

dedup11

Nun noch eine kleine “Demo”: Ich habe auf einem Volume einige Beispieldaten vorbereitet:

dedup12

Hier liegen also 50 Dateien (Inhaltlich identisch, ist aber natürlich kein Muss). Diese belegen zusammen etwa 5GB.

Nach der Deduplizierung sieht es dann so aus:

dedup13

Hier ergibt sich also eine extrem hohe Einsparung: 200 Kilobyte statt 5 Gigabyte! Wäre die Blockgröße auf dem Volume noch kleiner, wäre noch weniger belegt, denn die 200kB ergeben sich aus 50 Files x 4kB Blocksize. Jedes der 50 Files belegt nur noch 4 Kilobyte, also insgesamt ist schon jedes File für sich kleiner als vorher!

(Dieses Beispiel ist etwas konstruiert. Die Dateien enthalten jede die Zeichenkette “0123456789” so oft, bis sich 100MB ergeben. Dadurch ist auch innerhalb der Dateien eine gute Deduplizierung möglich)

Im Servermanager wird dies nun auch noch entsprechend angezeigt:

dedup15

Interessant ist jetzt noch ein Blick in das Ereignisprotokoll:

dedup16

Hier sieht man u.a., dass der gesamte Vorgang in meinem Beispiel nur 54 Sekunden gedauert hat! (Und zwar auf einer einzelnen, klassischen (Nicht-SSD) Notebook-Festplatte, also weder schnelles RAID noch SAN oder so und in einer Hyper-V-VM)

Schreibe einen Kommentar...

Walk-Through: Bereitstellen einer IPAM-Umgebung unter Windows Server 2012

Mit dem Windows Server 2012 hält auch ein neues Werkzeug Einzug in den Administrations-Alltag: Der IP-Adress-Verwaltungsserver, kurz IPAM. Dieses Werkzeug ist in der Lage, die gewachsenen IP-Address-Strukturen zu verwalten, zu analysieren und auch abzufragen. Dabei greift er auf folgende Quellen zu:

  • Domänen-Controller
  • DHCP-Server
  • DNS-Server
  • NPS-Server

Damit bietet er die Möglichkeit, die IP-Address-Verwaltung per Excel-Tabelle durch ein modernes, leistungsfähiges Werkzeug zu ersetzen.

Leider ist die Installation bzw. Einrichtung nicht ganz trivial, daher möchte ich diese hier Schritt für Schritt erläutern.

Bereits vorbereitet für dieses “Walk-through” ist eine kleine Demo-Umgebung bestehend aus einem Domänencontroller samt DNS (DC.hertes.lab), ein DHCP-Server samt Scope (DHCP.hertes.lab) sowie ein Member-Server für die künftig Aufgabe als IPAM (IPAM.hertes.lab).

WICHTIG: IPAM darf nicht auf einem Domänencontroller installiert werden. Das TechNet liefert hierfür zwar keine Erklärung, ich vermute aber, dass dies an der nötigen Datenbank (hier: Windows Internal Database, WID) liegt. Ab Server 2012 R2 ist auch ein “richtiger” SQL-Server möglich.

Als erstes muss der IPAM als Feature auf dem entsprechenden Server installiert werden. Dies geschieht über den Servermanager (alternativ per PowerShell):

ipam1

ipam2

ipam3

ipam4

ipam5

ipam6

Die benötigten, abhängigen Komponenten wie eben die WID oder auch die GPO-Verwaltung, werden automatisch mit installiert:

ipam7

ipam8

ipam9

ipam10

ipam11

Ein Neustart nach der Installation ist im Allgemeinen nicht erforderlich. Selbst wenn man den Haken für den automatischen Reboot gesetzt hat, wird nur neugestartet, wenn dies nötig ist.

Nach der Installation erfolgt die Einrichtung des IPAMs durch den entsprechenden Bereich im Servermanager (ein eigenständiges Werkzeug oder MMC-SnapIn existiert nicht). Die Administration inkl. Einrichtung kann auch remote erfolgen. Dazu ist über die Remoteserververwaltungstools (Feature) der IP-Adressverwaltungsclient zu installieren:

ipam_rsat

Die Einrichtung selber besteht aus 6 (bzw. eigentlich 7) Schritten, welche in einer Art Assistenten im Servermanager (links im Menü unter “IPAM”) abzuarbeiten sind:

  1. Verbindung mit IPAM-Server herstellen
  2. IPAM-Server bereitstellen
  3. Serverermittlung konfigurieren
  4. Serverermittlung starten
  5. Server zum Verwalten und Überprüfen des IPAM-Zugriffs auswählen oder hinzufügen
  6. Daten von verwalteten Servern abrufen

Nach dem Schritt 3 ist ein weiterer Schritt nötig, der hier nicht aufgeführt wird und nur per PowerShell erledigt werden kann. Darauf gehe ich später gesondert ein.

Die GUI zeigt die 6 Schritte. Der erste Schritt wird automatisch ausgeführt, wenn die IPAM-Konsole auf dem IPAM-Server selber gestartet wird.

ipam13

Ansonsten ist durch einen Klick auf den ersten Punkt eine Verbindung mit dem gewünschten IPAM-Server herzustellen:

ipam14

Als nächstes wird der IPAM-Server bereitgestellt. Dies kann manuell (nicht zu empfehlen) oder per GPO (sehr komfortabel) erfolgen. Bei der GPO-Variante ist nur ein Präfix anzugeben, der den künftigen drei GPOs namentlich vorangestellt wird:

ipam14-2

ipam15

ipam16

ipam17

ipam18

Nach diesem Schritt existieren die GPOs nur auf dem IPAM-Server, noch nicht auf dem Domänencontroller. Dazu kommen wir gleich…

In Schritt 3 werden die zu verwaltenden Domänen und Server ausgewählt:

ipam19

ipam20

Hier findet sich auch – etwas unglücklich platziert – der Hinweis auf den (zwingend nötigen) “siebten Schritt”: Das Schreiben der GPOs auf den DC mittels PowerShell-Cmdlet “Invoke-IpamGpoProvisioning”:

ipam20a

ipam20b

Schickt man den Befehl ohne Parameter ab, werden diese danach automatisch abgefragt.

Wichtig: Das Ausführen dieses Cmdlets muss (interaktiv) auf dem IPAM-Server erfolgen. Es funktioniert weder per Enter-PSSession noch per Invoke-Command!

Im Schritt 4 werden nun die Server der ausgewählten Umgebung ermittelt:

ipam21

Dabei wird eine “IP-Adress-Verwaltungsaufgabe” gestartet, deren Fertigstellung man abwarten muss:

ipam22

ipam23

Nun können im Schritt 5 die zu verwaltenden Server ausgewählten werden. Dabei werden diese jeweils in den Zustand “Verwaltet” gesetzt.

ipam24

ipam25

ipam26

ipam27

Dies muss für jeden Server separat erfolgen. Ist dies abgeschlossen, stehen die Server auf “Blockiert”. Die Blockierung wird aufgehoben, sobald die erzeugten und nun auch per Sicherheitsfilterung für die jeweiligen Server geltenden GPOs wirken. Am einfachsten kann man dies durch ein GPUpdate forcieren.

ipam-gpo

Sobald die GPOs wirken, kann man durch einen Rechtsklick den “Status des Serverzugriffs aktualisieren”. Dies muss wieder für alle Server einzeln und nacheinander erfolgen.

ipam-serverzugriff

Wenn diese Aufgabe erledigt ist, kann man die Ansicht aktualisieren (Kringel / Kreisel oben rechts). Nun sollten alle Server “grün” sein:

Falls nicht, hilft etwas warten bzw. müssen die jeweiligen Server evtl. noch einmal mit GPUpdate aktualisiert werden. Alternativ hilft “Invoke-GPUpdate SRVNAME –RandomDelayInMinutes 0 –Force”.

invoke-gpupdate

ipam28

Nun darf man den Schritt 6 nicht vergessen! Dieser ruft schließlich (einmalig manuell, später automatisch) die jeweiligen Daten von den verwalteten Servern ab.

ipam29

Auch hier muss man wieder auf Fertigstellung der IP-Adressverwaltungsaufgabe warten.

Ist der Schritt 6 fertiggestellt, kann man sich nun den verschiedenen Möglichkeiten im Baum auf der linken Seite widmen.

Unter IP-ADRESSRAUM / IP-Adressblöcke kann man z.B. den/die DHCP-Scope(s) sehen:

ipam30

Durch einen Rechtsklick auf diesen lässt sich die nächstfreie IP-Adresse suchen und zordnen:

ipam31

ipam32

Hier kann man beispielsweise einen Eintrag in DNS oder auch eine DHCP-Reservierung vornehmen. Allerdings werden diese Daten vorerst nur am IPAM-Server gespeichert. Möchte man die Informationen auch auf die jeweiligen Server übertragen, so ist dies unter “IP-Adressbestand” möglich:

ipam33

 

In der Rubrik “Überwachen und Verwalten” kann man u.a. den Zustand der involvierten Server und DHCP-Scopes sehen.

Im Ereigniskatalog werden einerseits Konfigurationsereignisse angezeigt, andererseits kann man gezielt nach IP-Adressen, MAC-Adressen, Hostnamen und Benutzernamen suchen, um damit verbundene Vorgänge (DHCP-Lese-Generation, –Renewal, DC-Authentifizierung, …) zu finden:

ipam34ipam35

Da der IPAM seine Daten in einer Datenbank ablegt, kann man hier auch Daten der Vergangenheit abrufen. Die Daten werden 3 Jahre lang in der Datenbank vorgehalten.

Schreibe einen Kommentar...

Walk-Through: DHCP-Failover mit Windows Server 2012

Der Windows Server 2012 bringt eine Funktion mit sich, auf die man bisher nur über die Umwege eines Clusters und den damit verbundenen höheren Anforderungen (Server 2008 Enterprise-Edition, shared Storage, …) nutzen konnte. Die Rede ist von DHCP-Failover, welches im Windows Server unabhängig von der verwendeten Edition und vollkommen ohne Cluster genutzt werden kann. Notwendig sind lediglich zwei Windows Server 2012 mit aktivierter DHCP-Server-Rolle. Auf einem der beiden Server sollte bereits ein Bereich (“Scope”) eingerichtet sein, beide Server müssen im AD autorisiert sein.

Im Folgenden möchte ich die Einrichtung des Failovers im Modus “Load-Sharing” erläutern und Schritt für Schritt mit Bildern darstellen. Neben diesem Modus, welcher sich insbesondere dann eignet, wenn die beiden Server in der selben physischen Lokation stehen, steht als zweite Option die Variante “Hot Standby” zur Verfügung. Dieser Modus eignet sich z.B. dann, wenn im Fehlerfall ein DHCP-Server von einem anderen Standort den Standort des ausgefallenen DHCP-Servers versorgen soll.

Eine potentielle Fehlerquelle beim Einrichten der Failover-Beziehung ist die Zeit. Diese muss auf beiden Partnern synchron sein. Eine Abweichung von mehr als 60 Sekunden sorgt beim Einrichten für einen kritischen Fehler. Diese Tolleranz darf auch im täglichen Betrieb nicht überschritten werden.

Nun zur eigentlichen Anleitung:

Bereits vorbereitet sind hier zwei installierte DHCP-Server “SRV1” und “SRV2”, welche beide bereits im AD autorisiert sind. Auf dem ersten Server “SRV1” wurde bereits ein Bereich für das Subnetz 192.168.200.0/24 angelegt:

dhcp1

Das Failover erfolgt immer Bereichs-weise und kann durch einen Rechtsklick auf den gewünschten Bereich eingerichtet werden:

dhcp2

Im ersten Schritt des sich nun öffnenden Assistenten werden nochmal die bzw. der DHCP-Bereich abgefragt, welcher im Failover-Betrieb verwendet werden soll:

dhcp3

Im zweiten Schritte muss der Partnerserver bestimmt werden. Dabei fällt auf, dass pro Bereich nur ein Partner-Server zulässig ist. Wenn es bereits früher eine Failover-Beziehung zwischen den beiden gewählten Servern gab, so könnte man diese wieder “reaktivieren”:

dhcp4

Im nächsten Schritt sind die weiteren Parameter der Failover-Beziehung festzulegen:

dhcp5

Hierbei können festgelegt werden:

  • Der Name der Beziehung – ist eigentlich klar
  • Die “Maximale Clientvorlaufzeit” (Maximum Client Lead Time)
    • Dieser Wert gibt die vorübergehende Lease-Dauer an, die für Leases gilt, welche im Failover-Fall (“Partner down”) vom Partner-Server vergeben werden; nach dem diese Zeit verstrichen ist, übernimmt der Partnerserver den Bereich vollständig. Standardwert ist eine Stunde, kann aber z.B. auch auf 0 gesetzt werden
  • Modus
    • “Lastenausgleich” oder “Hot Standby” wie bereits oben beschrieben
    • Beim Lastenausgleich-Modus kann die Verteilung der Last auf die beiden Server festgelegt werden; Standard ist 50/50
    • Beim Modus “Hot Standby” ist hier stattdessen festzulegen, welche Rolle der Partnerserver übernimmt (“Aktiv” oder “Standby”) sowie der Anteil der für den Standby-Server reservierten Adressen (Standard: 5%). Dieser Anteil wird während der “Maximalen Clientvorlaufzeit” verwendet, bis der Standby-Server die volle Kontrolle übernommen hat
  • Intervall für Zustands-Switchover
    • Hier kann man festlegen, wie viel Zeit nach einem Wechsel in den Zustand “Communication interrupted” (Verbindung zwischen den beiden Partnern unterbrochen) vergehen soll, ehe zum Zustand “Partner down” übergegangen werden soll; standardmäßig ist dieser automatische Übergange abgeschalten, so dass der Administrator den Zustand “Partner down” händisch einleiten muss
  • Nachrichtenauthentifizierung aktivieren
    • Wenn diese Option eingeschalten ist, werden die Kommunikationen zwischen den beiden Partnern mit Hilfe von SHA-256 verschlüsselt. Zusätzlich wird eine Authentifizierung auf Basis von SHA-2 durchgeführt, um sicherzustellen, das kein unberechtigter Dritter Daten abfängt oder einschleust.
    • Wenn diese Option aktiviert ist, muss in der untersten Eingabezeile ein “Gemeinsamer geheimer Schlüssel” festgelegt werden, welcher vom Assistenten an beide Server gesendet wird und später nirgendwo erneut eingegeben werden muss

Als letzter Schritt folgt eine Zusammenfassung der gesetzten Einstellungen:

dhcp6

Nach einem Klick auf “Fertig stellen” wird die Failover-Beziehung eingerichtet und zum Schluss erscheint eine Erfolgs-Meldung:

dhcp7

Wenn man nun die GUI des DHCP-Tools aktualisiert, kann man beim SRV2 ebenso den bereits auf dem SRV1 eingerichteten Bereich sehen, in dem auch alle bereits vergebenen Leases und Reservierungen vorhanden sind:

dhcp8

Die Eigenschaften der verschiedenen Failover-Beziehungen lassen sich nachträglich in den Eigenschaften des jeweiligen Protokolls (“IPv4” bzw. “IPv6”) einsehen und ändern:

dhcp9

dhcp10

Für die Failover-Konfiguration ist im DHCP-Standard ein Austausch der Leases vorgesehen – nicht aber eine stetige Synchronisierung der Konfigurationen. Da aber beide Server einer Failover-Beziehung identisch konfiguriert sein sollten, ist nach einer Konfigurationsänderung ein Abgleich nötig:

dhcp11

Dabei kann entweder nur der gewählte Bereich abgeglichen werden (“Bereich replizieren…”) oder aber alle Bereiche, die in dieser Failover-Beziehung existieren (“Beziehung replizieren…”)

Wenn nun einer der beiden Kommunikationspartner ausgefallen ist, so wird dies durch Symbolik im DHCP-Manager angezeigt und ist auch in den Eigenschaften des Protokolles zu sehen:

dhcp12

Außerdem wird ein Eintrag im Ereignisprotokoll mit der ID 20252 angelegt:

dhcp13

In den Eigenschaften der Failover-Beziehung kann nun der Zustand von “Datenübertragung unterbrochen” auf “Partner nicht verfügbar” manuell geändert werden:

dhcp14

dhcp15

Ist der ausgefallene Server wieder verfügbar, geht die Verbindung in den Zustand “Wiederherstellen (warten)” über:

dhcp16

2 Comments

Walk-Through: Dynamic Access Control praktisch angewendet

 

Der Windows Server 2012 bringt eine neue Funktion mit, welche die Bereiche Active Directory und Fileserver betrifft. Die Rede ist von “Dynamic Access Control“ (DAC) bzw. der “Dynamischen Zugriffssteuerung”.

 

Bisher wurden in der Praxis Zugriffsrechte auf Ressourcen eines Fileserver auf einzelne Benutzerkonten (schlecht) oder auf Active Directory Gruppen (besser) vergeben. Ist der Benutzer Mitglied der Gruppe, so hat er den Zugriff; andernfalls nicht. Diese Konstruktion ist aber sehr statisch und macht den Zugriff einzig vom Benutzer bzw. seiner Gruppenmitgliedschaft abhängig.

 

Dynamic Access Control hingegen ermöglicht es, den Zugriff auch von anderen Faktoren abhängig zu machen, z.B. von Eigenschaften der Dateien oder auch vom Computer, von dem aus der Zugriff erfolgt. Dadurch ist beispielsweise möglich, dem Benutzer den Zugriff von seiner Workstation zu gestatten, vom Notebook aus aber zu verbieten, um somit dem Datendiebstahl vorzubeugen.

 

Diese etwas abstrakte Technik möchte ich im Folgenden an einem praktischen Beispiel illustrieren. Dabei soll es darum gehen, den Zugriff auf Dateien und Ordner eines Fileservers so zu gestalten, dass es abhängig ist von der Abteilung des Benutzers (“department” ist eines der AD-Attribute, welches standardmäßig vorhanden ist).

Für die folgende Demonstration wird ein (virtueller) Windows Server 2012 verwendet, welcher bereits als Domänencontroller inkl. Verwaltungswerkzeugen konfiguriert ist. Eine separate Rolle oder ein Feature ist hierzu nicht notwendig, allerdings muss innerhalb der ohnehin vorhanden “Datei- und Speicherdienste”-Rolle der “Ressourcen-Manager für Dateiserver” aktiviert werden.

Zuerst werden sogenannte “Anspruchstypen” (“Claims”) benötigt. Das sind die Attribute, von denen wir später den Zugriff abhängig machen wollen. Das anlegen der Claims erfolgt wie auch ein Großteil der restlichen Konfiguration über das grafisch aufgewertete “Active Directory Verwaltungscenter” (ADAC):

dac1

Hier sind bereits die im AD bekannten Attribute der Benutzerklasse sowie der Computerklasse (nach Setzen der Checkbox) zu finden. In unserem konkreten Beispiel verwende ich das Attribut “department”:

dac2

Als nächstes sind nun Eigenschaften unserer späteren Ressourcen nötig. Hier werde ich eine Eigenschaft verwenden, die ebenfalls “department” heißt, um später eine Regel in der Form zu gestalten:

WENN Benutzer.Abteilung == Ressource.Abteilung DANN Zugriff_gewährt

Diese Eigenschaften heißen “Ressource Properties” (auch in der Deutschen GUI) und es sind bereits einige nützliche Eigenschaften vorhanden, die nur noch aktiviert werden müssen:

dac3

Diese Eigenschaft “department” hat bereits einige vorgeschlagene Werte eingetragen, die bei Bedarf geändert bzw. angepasst werden können:

dac4

Da ich eine bereits vorhandene Eigenschaft verwende, ist diese bereits auf der “Global Ressource Property List” – andernfalls müsste Sie dort noch hinzugefügt werden:

dac5

Nun müssen noch eine “Zentrale Zugriffsregel” (“Central Access Rule”) sowie eine “Zentrale Zugriffsrichtlinie” (“Central Access Policy”) angelegt werden. Als erstes legen wir hierzu eine Regel („Rule”) an. Diese regelt später den Zugriff auf die Ressourcen.

Unter “Zielressourcen” ist hier default “Alle Ressourcen” eingetragen. Das könnte aber später dazu führen, dass NIEMAND auf eine Datei zugreifen kann, beispielsweise dann, wenn diese GAR KEINE Abteilung als Eigenschaft besitzt.Daher ändere ich diesen Eintrag dahingehend, dass diese Regel nur auf Ressourcen abzielt, die die Eigenschaft “department” haben:

dac6

Bei den Berechtigungen hat man zwei Möglichkeiten: Man kann die im Folgenden konfigurierten Berechtigungen als “vorgesehene Berechtigungen” oder als “aktuelle Berechtigungen” (“tatsächliche” trifft es besser) verwenden:

dac7

Die erste Option ist insbesondere für Erprobungs- und Protokollierungszwecke nütze, wohingegen die zweite Option die kommenden Einstellungen direkt “scharf schaltet”.

In den Berechtigungen kann man nun über “Bearbeiten” die eigentlichen Einstellungen festlegen:

dac8

“Prinzipal” ist die Benutzergruppe, auf die die kommenden EInstellungen wirken sollen, in meinem Fall die “Domänen-Benutzer”. Dann folgt die eigentliche Berechtigung, in meinem Beispiel wähle ich das “Ändern”-Recht, welches Lesen und Schreiben beinhaltet. Ganz unten folgen hier die Bedingungen, in meinem Fall eben “Benutzer.Department == Ressource.Department”. Diese kann man bequem per Dropdown-Liste wählen:

dac9

Man könnte hier auch mehrere Bedingungen kombinieren. So könnte man eben auch fordern, dass der Computer, von dem aus der Zugriff erfolgt, in einer bestimmten AD-Gruppe enthalten sein muss.

Am Ende sieht die Regel dann in etwa so aus:

dac10

Nun ist noch eine Policy nötig, welche die angelegte Regel enthält:

dac11

Damit sind die Schritte im “Active Directory Verwaltungscenter” abgeschlossen. Nun sind noch zwei Einstellungen nötig, die man am besten per Gruppenrichtlinie setzt. Da in meinem einfachen Beispiel der Domänencontroller gleichzeitig der Fileserver ist, genügt hier ein GPO:

dac12

Die nötigen Einstellungen sind:

  • Computerkonfigurationen / Richtlinien / Windows-Einstellungen / Sicherheitseinstellungen / Dateisystem / Zentrale Zugriffsrichtlinie
    • Hier muss die angelegte Policy aktiviert werden
    • Gilt für den Dateiserver
  • Computerkonfigurationen / Richtlinien / Administrative Vorlagen / System / KDC / Unterstützung des Kerberos-Domänencontrollers für  Ansprüche…
    • Muss aktiviert werden
    • Gilt für den/die Domänencontroller

Spätestens nach einem GPUpdate sollten die gesetzten Einstellungen auf die betreffenden Systeme wirken, vorausgesetzt, das GPO wurde korrekt verknüpft. Dabei sollte im “Ressourcenmanager für Dateiserver” geprüft werden, ob die “Ressource Property” dort unter “Klassifizierungsverwaltung / Klassifizierungseigenschaften” auftaucht. Notfalls muss rechts “Aktualisieren” gedrückt werden:

dac15

Nun lege ich 2 Test-Benutzer im Active Directory an. Karl Auer ist hierbei Mitarbeiter der Marketing-Abteilung, Franz Iskaner arbeitet für die Sales-Abteilung:

dac13

Weiterhin lege ich ein Verzeichnis “Abteilungen” und darin je einen Ordner für “Sales” und für “Marketing” an. Den Ordner “Abteilungen” gebe ich im Netzwerk frei. An der Freigabe bekommen “Authentifizierte Benutzer” das Recht “Ändern”. In den erweiterten Sicherheitseinstellungen des Abteilungs-Ordners aktiviere ich die Abteilungs-Policy:

dac14

Nun werden noch die beiden Unterordner entsprechend klassifiziert. Dies geschieht über die Eigenschaften des jeweiligen Ordners. Dabei stehen mir die vorgeschlagene Werte der “Ressource Proptery” zur Verfügung:

dac16

Legt man nun beispielsweise im Marketing-Ordner eine neue Datei an, wird diese automatisch als “department: Marketing” klassifiziert. Diese Klassifizierung bleibt auch dann erhalten, wenn man das Dokument später z.B. an einen anderen Ort verschiebt. Bei den klassischen NTFS-ACL-Konstrukten wäre dies ander: Da würde das Dokument u.U. am Zielort andere Berechtigungen erben. Dabei wäre es z.B. denkbar, dass ein Benutzer, der auf beide Abteilungs-Ordner Zugriff hat, eine Marketing-Datei in den Sales-Ordner verschiebt. Bei den klassischen ACLs hätten nun die Sales-Benutzer Zugriff auf dieses Marketing-Dokument, was allerdings gar nicht gewünscht ist. Da die Klassifizierung sich beim Verschieben nicht verändert, haben die Sales-Benutzer hier auch dann keinen Zugriff, selbst wenn das Marketing-Dokument in “ihrem” Abteilungsverzeichnis landet.

dac17

dac18

Wenn man sich nun die Berechtigungen auf diesem Marketing-Dokument (im Sales-Ordner) ansieht, dann erkennt man, dass Karl Auer als Marketing-Mitarbeiter Zugriff hat, Franz Iskaner als Sales-Mitarbeiter hingegen nicht:

dac19

dac20

Genau so soll es auch sein!

Dynamic Access Control lässt sich für viele weitere Szenarien einsetzen. So kann man beispielsweise auch den “Ressourcen Manager für Dateiserver” nutzen, um Dateien automatisch zu klassifizieren, z.B. abhängig vom Inhalt. Denkbar wäre, Dokumente als “geheim” einzustufen, wenn diese das Wort “geheim” mindestens drei mal enthalten und dann nur noch einer gewissen AD-Gruppe den Zugriff auf geheime Dokumente zu gewähren.

Schreibe einen Kommentar...