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

10Jan/170

Active Directory: Benutzer GPOs mit Sicherheitsfilterung funktionieren nicht

Ja, ich weiß, ich erzähle jetzt hier nichts brandneues mehr. Aber vielleicht geht es anderen so wie mir diese Woche, daher also dieser Artikel. Aber erst mal von Anfang an:

Ich habe diese Woche in unserer ActiveDirectory Umgebung eine neue GPO angelegt. Mein Ziel war, damit eine neue Mailsignatur an alle Benutzer auszurollen. Die nötigen Einstellungen befinden sich im Benutzer-Zweig der GPOs, daher spreche ich gerne von einer “Benutzer-GPO”, was man bei mir auch immer im Namen sieht. Um das Ganze erstmal sinnvoll testen zu können, habe ich auf die Sicherheitsfilterung zurückgegriffen. Ihr wisst schon, damit kann man die GPO statt auf die gesamte verknüpfte OU auf einzelne Benutzer oder Gruppen anwenden. Also habe ich die “Authentifizierten Benutzer” entfernt, und stattdessen mich und einen weiteren Kollegen dort eingetragen:

gpo1

Das Problem

Leider wirkte sich die GPO dann nicht wie gewünscht aus. Auffällig war aber, dass ich plötzlich auch das Verzeichnis, in dem sich die GPO-Daten und damit auch das Skript, dass die GPO ausführen sollte, befanden, nicht mehr lesen konnte. Selbst mit einem Domänen-Admin-Konto nicht! Sobald ich die “Authentifizierten Benutzer” bzw. in meinem Fall “Authenticated Users” wieder hinzugefügt hatte, konnte ich die Dateien wieder lesen. Natürlich hätte ich damit aber auch die GPO für die gesamte GPO ausgerollt.

Die Ursache

Ein bisschen Recherche im Internet brachte mich dann auf die Ursache des Problems und damit auch auf dessen Lösung:

Microsoft hatte durch ein Update, dass bereits im Juni 2016 erschienen war, eine wesentliche Arbeitsweise von GPOs geändert:

Bisher war es so, dass für das Wirksamwerden von Computer-GPOs das Computerkonto für die GPO das Lesen-Recht haben musste und bei Benutzer-GPOs das Benutzerkonto. Das Ganze passte auch zur Logik, dass Computer-Richtlinien nur auf Computerkonten wirken und Benutzer-Richtlinien nur auf Benutzerkonten (Ausnahme: Loopback-Verarbeitung). Das hat man auch nicht geändert. Was allerdings geändert wurde ist, dass auch bei Benutzer-Richtlinien das Computerkonto die Leserechte auf die GPO braucht.

Wenn man entweder keine Benutzer-GPOs benutzt oder bei diesen immer die “Authenticated Users” in der “Security Filtering” drin lässt (womit dann faktisch nur noch eine Steuerung über die verknüpfte OU oder über WMI-Filter möglich wird, wenn man nicht vom “verweigern” der Berechtigungen Gebrauch machen will) ändert sich für einen selbst nichts.

Wenn man aber so wie ich gerne mal auch bei Benutzer-GPOs auf die Gruppen- oder Benutzerkonten-bezogene Filterung zurückgreift, dann muss man diese Änderung unbedingt kennen!

Die Lösung

Die Lösung des Problem ist eigentlich recht einfach – wenn man die Ursache kennt. Das Computerkonto des Computers, an dem der jeweilige Benutzer arbeitet muss also in die Lage versetzt werden, die GPO zu lesen. Da man nicht immer weiß, wer gerade wo arbeitet und sich das ja auch täglich ändern könnte, bleibt fast nur, den “Domänen-Computern” das Leserecht zu geben. Und das funktioniert über den Reiter “Delegation” bzw. “Delegierung”:

gpo2

Hier findet ihr noch den Blog-Artikel bei Microsoft, der mich zum Problem und dessen Lösung brachte:

https://blogs.technet.microsoft.com/askpfeplat/2016/07/05/who-broke-my-user-gpos/

14Dez/161

Hyper-V auf Windows Server 2012 R2 / 2016: VMs mittels Kerberos verschieben

Im Windows Server 2012 R2 und 2016 steckt ja nun schon seit einer Weile die so genannte “Shared Nothing Live Migration”, die es möglich macht, VMs zwischen Hyper-V-Hosts zu verschieben (auch im laufenden Betrieb), ohne, dass die VM auf einem Hyper-V-Cluster laufen muss, entsprechend ist hier auch kein Storage nötig.

Für die Shared Nothing Migration gibt es zwei Protokolle zur Authentifizierung: CredSSP und Kerberos.

CredSSP ist an sich sehr einfach in der Benutzung, bedarf es doch keiner echten Einrichtung. Lediglich den richtigen Radio-Button auswählen, einmal ab- und wieder anmelden und das war’s. Aber die Sache hat einen Haken: Bei CredSSP kann man nur dann eine VM verschieben, wenn man (lokal oder z.B. per RDP) an dem Hyper-V-Host angemeldet ist, von dem man die VM weg-verschieben will. MMC-Remoting mit dem Hyper-V-Manager geht hier nicht! Versucht man es doch, bekommt man folgende Fehlermeldung:

kerberos00

Im Wortlaut: “Failed to establish a connection with host HOSTNAME. The credentials supplied to the package were not recognized (0x8009030D).”

Insbesondere bei Core-Servern, auf denen es keinen Hyper-V-Manager gibt, wird das Verschieben also einigen Administratoren schwer fallen (wenngleich PowerShell eine nutzbare Lösung wäre).

Auch wenn man jetzt einfach im Hyper-V-Manager auf Kerberos umstellt:

kerberos7

..kommt es immer noch zu einem Fehler:

kerberos0

Im Wortlaut: “The Virtual Machine Management Service failed to authenticate the connection for a Virtual Machine migration at the source host: The specified target is unknown or unreachable (0x80090303).”

Was hier fehlt ist die sogenannte “Constrained Delegation”. Diese einzurichten ist an sich nicht kompliziert, bei steigender Host-Anzahl aber etwas aufwändiger (eine einfachere PowerShell-Lösung versuche ich zeitnah nachzuliefern).

Zur Einrichtung benötigt man Schreibrechte auf den Computer-Objekten der Hyper-V-Hosts im Active Directory oder einfacher gleich einen Domain-Admin-Account.

Über die “Active Directory Users and Computers” öffnet man sich nun der Reihe nach die Computerkonten aller Hyper-V-Hosts und führt dort folgende Einstellung durch:

kerberos1kerberos2kerberos3

kerberos4kerberos5

Im Ergebnis muss es auf jedem Host so aussehen:

kerberos6

Jeder Host muss jedem anderen bei den Diensten “cifs” und “Microsoft Virtual System Migration Service” vertrauen. Kerberos alleine genügt.

Danach muss man natürlich die Hyper-V-Hosts auf Kerberos-Migration umstellen (oder dies zumindest noch einmal überprüfen!)

kerberos7

Das war’s dann schon! Jetzt kann man von jedem Client oder Server aus mittels Hyper-V-Manager auf die Hosts zugreifen und eine Verschiebung initiieren. Viel Spaß dabei!

16Mrz/152

SCCM + WSUS + SCUP: Updates für 3rd-Party-Anwendungen mit Hilfe des Update Publishers über SCCM verteilen

Mit Hilfe des System Center Configuration Manager 2012 / 2012 R2 ist es sehr einfach möglich, Windows- und Microsoft-Updates an die Clients und Server des eigenen Netzwerkes zu verteilen. Im Hintergrund arbeitet hierzu der bekannte WSUS-Dienst, welcher wiederum mit Microsoft kommuniziert, um die Updates von dort zu beziehen.

Wäre es nicht auch gut, wenn man auf ähnliche Weise auch Anwendungen von anderen Herstellern patchen könnte? JA! Und man kann!

Das einzige was man neben WSUS und dem SCCM braucht, ist der System Center Update Publisher, kurz SCUP. Mit diesem kann man Updates anderer Hersteller aus “externen Katalogen” beziehen. Und das beste: SCUP ist kostenlos!

Im Folgenden möchte ich die Installation und Einrichtung von SCUP zeigen. Ausgangslage ist ein installierter SCCM mit einer einzigen Primary Site (stand-alone), einem installierten WSUS und einem darauf laufenden Software Update Point (SUP).

Installation SCUP

Als erstes muss SCUP heruntergeladen werden. Dies geht über diese Quellen:

https://technet.microsoft.com/de-de/systemcenter/bb741049.aspx

bzw.

https://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=11940

Nach dem Download kann die Installation durchgeführt werden, welche jedoch Admin-Rechte benötigt:

scup2 scup3 scup4

Wenn es sich bei dem WSUS-Server um einen Windows Server 2008 R2 oder älter handelt, dan ist die Installation eines Patches nötig, der während des SCUP-Setup angeboten wird:

 scup5

Auf einem Windows Server 2012 / 2012 R2 ist dieses Patch nicht nötig – hier läuft WSUS 4.0!

scup6

Konfiguration WSUS-Berechtigungen

Um nun überhaupt Updates via SCUP auf dem WSUS veröffentlichen zu können, ist noch etwas Vorarbeit nötig. Diese Vorgänge sind etwas genauer hier dokumentiert (dies betrifft idR nur den Windows Server 2012 / 2012 R2):

https://technet.microsoft.com/en-us/library/hh134747.aspx#PublishToServer2012

Folgende Schritte sind im Wesentlichen nötig:

Regedit.exe, dort bis HKEY_CLASSES_ROOT\AppID\{8F5D3447-9CCE-455C-BAEF-55D42420143B} durchhangeln und dann den Eigentümer von diesem Pfad ändern sowie für “SYSTEM” und die “Administratoren” den Vollzugriff vergeben (Durch einen Klick auf die Bilder werden diese in größerer Auflösung gezeigt):

scup10  scup11 scup12 scup13 scup14

 

Einrichtung SCUP

Nun kann der “System Center Update Publisher” über das Startmenü gestartet werden – dies sollte aber “Als Administrator” geschehen, da es sonst später zu einem Fehler kommt / kommen kann.

scup7

Dieser Fehler tritt später auf, wenn man die SCUP-Konsole ohne die nötigen Rechte startet:

scup9

Als erstes sind die Optionen zu öffnen:

scup8

Dort muss nun die Verbindung zum WSUS-Server konfiguriert werden (dabei Port beachten – WSUS 4.0 läuft auf 8530 (non-SSL) bzw. 8531 (SSL)):

scup16

Nun fehlt noch ein Zertifikat zum signieren der Updates. Hier kann auch ein selbstsigniertes Zertifikat erzeugt und verwendet werden. Dies geschieht über den “Create”-Button:

scup16b

Dieses Zertifikat muss später noch weiter “behandelt” werden. Als nächster Step wird im SCUP die Verbindung zum SCCM definiert:

scup17

Zertifikat passend einbinden

Das WSUS-/SCUP-Zertifikat muss nun in die “Trusted Publishers” (Vertrauenswürdige Herausgeber) und die “Trusted Root Certificates” (Vertrauenswürdige Stammzertifizierungsstellen) des Computer-Kontos (WSUS/SCUP-Server) importiert werden, vorher muss es natürlich exportiert werden:

scup18 scup18b scup19 scup20

Updates über SCUP an den WSUS veröffentlichen

Nun können die ersten Updates über den SCUP veröffentlicht werden. Dazu muss zunächst ein Katalog hinzugefügt werden:

scup21

Beispielhaft verwende ich hier den “Adobe Reader X” Katalog:

scup22

Danach können die Updates aus diesem Katalog in den SCUP importiert werden:

scup23

scup24

scup25

scup26

scup27

Nun können die neuen Updates zu einer neuen Veröffentlichung hinzugefügt werden:

scup28

scup29

Diese neue Veröffentlichung (Bei mir heißt sie “März 2015”) kann nun veröffentlicht werden. Dazu wird sie unter “Publications” ausgewählt, die jeweiligen Updates markiert und dann auf “Publish” geklickt.

scup30

Dabei sollten die Updates vom SCUP signiert werden:

scup31

scup32 scup33

Updates über SCCM verteilen

Nun kann im SCCM eine erste Synchronisierung durchgeführt werden. Diese ist nötig, damit der SUP (SCCM) “erfährt”, dass es nun auch Adobe als neuen Hersteller und Adobe Reader als Produkt gibt:

scup34 Um den Vorgang zu beobachten bietet der SCCM ein eigenes Werkzeug, alternativ würde auch CMTrace gegen die WSyncMgr.log funktionieren:

scup35 scup36 scup37scup38

Die letzte Meldung zeigt an, dass die Synchronisierung abgeschlossen ist. Nun kann das neue Produkt (in meinem Fall der Adobe Reader) für die Verteilung durch den SUP aktiviert werden:

scup39 scup40

Dabei ist auch der Reiter “Klassifizierungen” zu beachten – wenn das gewünschte Update ein “Sicherheitsupdate” ist, SUP aber nur “Wichtige Updates” synchronisiert, dann wird man nicht zu einem positiven Ergebnis kommen.

Nun ist noch einmal eine Synchronisierung des SUP nötig, damit dieser die bekannten Updates vom WSUS “kennenlernt”.

scup34

Danach stehen die Updates, in meinem Fall für den Adobe Reader, im SCCM wie ein reguläres Windows Update zur Verfügung und können verteilt und bereitgestellt werden:

scup41

Viel Spaß damit!

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.

19Jan/150

Stand-alone DHCP-Server plus DHCP-Server in Domäne gleich Problem?!

Wenn man einen DHCP-Server betreibt, dann sollte dies bevorzugter Weise in einer Domäne geschehen – also mit dem DHCP-Server als Mitglied des Active Directory. Dort benötigt dieser eine Autorisierung, welche dafür sorgt, dass dieser Server dann auf eingehende Anfragen (DHCP Request) reagiert. Solange er nicht autorisiert ist, vergibt er auch keine Adressen. Soweit so gut.

Wenn man einen DHCP-Server NICHT in Active Directory integriert, kann man ihn auch nicht autorisieren, er verrichtet dennoch seine Dienste – bis er auf einen autorisierten Server trifft!

Dann nämlich wird der nicht autorisierte Server (der nicht Mitglied der Domäne ist) seinen Dienst einstellen und selbst wenn man ihn wieder manuell aktiviert sich sofort wieder abschalten.

dhcp_rogue_2

dhcp_rogue_1

Damit ist es also nicht so ohne Weiteres möglich, zwei DHCP-Server im selben Netz zu betreiben. Nun kann es aber sein, dass genau das gewünscht ist – weil die Server z.B. Adressen für unterschiedliche MAC-Adressen verteilen. Hier muss man also eingreifen und den nicht-autorisierten DHCP Server daran hindern, sich abzuschalten.

Das “Zauberwort” hier heißt “Rogue Detection” – und genau die muss deaktiviert werden.

Dies geht nicht über eine GUI, sondern muss über eine Registrierungswert geändert werden. Dieser heisst

KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCPServer\Parameters
\DisableRogueDetection

dhcp_rogue_3

Mittels des folgenden Aufrufs lässt sich der Eintrag recht schnell anlegen:

reg add HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\DHCPServer\Parameters /v DisableRogueDetection /t REG_DWORD /d 1

Dieser Schlüssel ist sehr oberflächlich in folgendem KB-Artikel bei Microsoft beschrieben:

https://support.microsoft.com/kb/949530

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 

13Aug/140

Windows Server 2012 R2: Storage Pools mit SSD-Tiering

EDIT: Ich habe wie versprochen die Benchmark-Ergebnisse als Tabelle am Ende des Artikels eingefügt!

Seit dem Windows Server 2012 beherrschen die Microsoft-Server-Systeme die Möglichkeit, so genannte “Storage Pools” (Speicherpools) zu bilden. Dabei handelt es sich um einen Zusammenschluss verschiedener lokal angebundener oder als LUN eingebundener Datenträger, z.B. via SAS, SATA oder auch USB. Bei den LUNs stehen iSCSI und FiberChannel zur Verfügung.

Die grundsätzliche Idee ist hier, eine Art Storage abzubilden, quasi eine “Storage-Virtualisierung”. Aus einem gebildeten Storage-Pool können anschließend logische Laufwerke, sogenannte “Speicherplätze” (Storage Spaces), gebildet werden. Dabei kann die Organisation des Speichers gewählt werden. Zur Verfügung stehen “Simple” (eine Art RAID0, keine Datensicherheit, aber eine Erhöhung des Durchsatzes durch die gleichzeitige Nutzung aller beteiligter Festplatten), “Mirror” (Eine Art RAID1 mit einfacher oder doppelter Spiegelung der Blöcke um ein Erhalten der Daten auch bei Ausfall einer Festplatte sicherzustellen) und “Parity” (Funktioniert wie RAID5; Paritätsdaten, die ein Wiederherstellen der Daten bei Ausfall einer Festplatte möglich machen, werden über alle beteiligten Datenträger verteilt). Dabei spielen Größe, Hersteller, Bus-Typ und co. der Festplatten nahezu keine Rolle – ein Faktor, der die Storage Pools deutlich von klassischen RAID-Controllern unterscheidet.

spool7b2

Ein weiterer Faktor, der Storage-Pools von üblichen “lokalen” Speichertechnologien abgrenzt ist die Möglichkeit, nachträglich Festplatten hinzuzufügen oder durch größere auszutauschen, um den zur Verfügung stehenden Speicherplatz zu erhöhen.

Seit dem zweiten Release des Server 2012 wird diese Technologie noch erweitert: Der Windows Server 2012 R2 beherrscht das sogenannte “SSD-Tiering” (Speicherebenen). Hierbei werden klassische HDDs und SSDs gemeinsam in einem Pool genutzt und die häufig gelesenen Daten auf die SSD verschoben, die seltener genutzten Daten bleiben auf der HDD. Alternativ kann man SSDs auch als Write-Back-Cache einsetzen.

spool6b

(Eine Anleitung, wie das genau eingerichtet werden kann, werde ich in kürze ebenfalls veröffentlichen.)

Diese Möglichkeit – sowie Speicherpools insgesamt – sind in meinen Augen vor allem für kleinere und mittlere IT-Landschaften interessant, in denen keine “ausgewachsenen” SANs zum Einsatz kommen (können). Daher war für mich interessant, wie gut diese Technologie funktioniert und welche Geschwindigkeits-Vorteile hierbei erzielt werden können. Daher habe ich diverse Test-Messungen unternommen, welche ich nun hier auswerten möchte. Zum Einsatz kam ein Fujitsu-Siemens-Server mit einem 4-Kern-Xeon-Prozessor und 8GB RAM, dazu 2 SATA-Festplatten von Western Digital und 2 SATA-SSDs von Crucial, jeweils mit etwa 250GB Speicher.

Zuerst habe ich die Festplatten einzeln getestet, um Vergleichswerte zu haben:

CrystalDiskMark_Pool_einzelne_HDD CrystalDiskMark_Pool_einzelne_SSD
hdtach_einzelne_HDD hdtach_einzelne_SSD

Hier ist natürlich zu erkennen, dass die SSD (rechts) deutlich schneller als die HDD (links) ist – und zwar in allen Disziplinen.

Weiterhin habe ich den Server-eigenen LSI RAID-Controller getestet (jeweils im RAID0, links 2x HDD, rechts 2x SSD):

CrystalDiskMark_2xHDD_RAID0_Controller CrystalDiskMark_2xSSD_RAID0_Controller
hdtach_2xHDD_RAID0_Controller hdtach_2xSSD_RAID0_Controller

Beim Lesen schafft der Controller sogar etwa doppelt so schnelle Werte – beim Schreiben brechen die Werte dafür dann recht ordentlich ein, der Betrieb ist also langsamer als eine einzelne Platte!

Und nun im direkten Vergleich ein Betrieb via Storage-Pool im “Simple”-Modus (links) und im “Mirror”-Modus (rechts):

CrystalDiskMark_Pool_mitSSD_Tearing_RAID0 CrystalDiskMark_Pool_mitSSD_Tearing_RAID1
hdtach_Pool_mitSSD_Tearing_RAID0 hdtach_Pool_mitSSD_Tearing_RAID1

Hier sieht man zunächst (CrystalDiskMark) etwa folgende Ergebnisse:

- Im Simple-Modus erreicht der Pool fast die Lese-Raten des RAID0 aus 2x SSD am Controller, übertrifft die Schreibraten aber deutlich

- Auch bei den wahlfreien Zugriffen sind durchweg bessere Werte zu sehen als beim RAID0 oder den einzelnen Platten

- Beim Mirror-Modus sind die Leseraten in etwa so wie beim Simple-Modus, beim Schreiben dafür aber nur etwa halb so hoch

- Insgesamt ist der Mirror-Modus aber besser als die beiden SSDs im RAID0 des Controllers

Wenn man nun aber noch HD Tach mit betrachtet, dann sieht man recht deutlich, dass die hohen Raten nur anfänglich erreicht werden (nämlich bis zu der Stelle, an der zwischen denn SSDs und den HDDs gewechselt wird, hier etwa bei der Hälfte. Dennoch sind die Daten im “HDD-Bereich” recht gut!

Ich denke diese Ergebnisse zeigen, dass die Technologie zu hohen Geschwindigkeiten fähig ist, die selbst mit (zumindest einfacheren) RAID-Controllern nicht erreicht werden. Ich werde zeitnah noch eine tabellarische Gegenüberstellung der Werte ausarbeiten.

So, hier nun noch die Benchmarks in einer tabellarischen Übersicht zusammengefasst (Klick zum Vergrößern):

Benchmark-Ergebnisse

Zusammenfassend kann man hier nun also sehen:

  • In den lesenden Disziplinen ist ein “echtes” RAID0 mittels RAID-Controller und den beiden SSDs am schnellsten
  • In den schreibenden Disziplinen ist der Storage-Pool mit einem Simple-Laufwerk am LSI-Controller am besten – dabei auch deutlich schneller als das controllereigene RAID0 von LSI und HP mit den SSDs
  • Der direkte Vergleich zwischen den Storage-Pools am HP-Controller und am LSI-Controller geht erstaunlicherweise zu Gunsten des LSI-Controllers aus und dies auch durchweg, obwohl der LSI-Controller (im Gegensatz zum HP-Controller) über keinen eigenen Cache verfügt (mit aktiviertem BBWC würde der HP-Controller wohl beim Schreiben noch deutlich besser werden)
  • Geht es um Datenredundanz (hier also RAID1 o.ä.), dann ist der Storage-Pool im Mirror-Modus mit der Kombination HDD plus SSD am besten!
  • Ein Storage-Pool mit 2 HDDs im Mirror-Mode ist fast genau so gut (oder genau so schlecht) wie die RAID1-Implementierung des HP- oder des LSI-Controllers
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

2Jul/140

Windows Server 2012 R2: Datei nach Dedeplizierung nur noch 0 Byte groß

In einem früheren Artikel habe ich beschrieben, wie man auf einem Windows Server 2012 die Datendeduplizierung (Data-Deduplication) konfiguriert und nutzt. Dort war in einem einfachen Beispiel zu sehen, dass die Datei nach der Deduplizierung noch genau 4KB belegt hat, also die verwendete Blockgröße (“Größe der Zuordnungseinheit”

dedup_2012r2_1

Das liegt daran, weil die nach der Deduplizierung die verwendeten Chunks nicht mehr beim betroffenen File liegen. Die Datei ist also tatsächlich 0 Byte groß – belegt aber eigentlich an einer anderen Stelle Speicherplatz.

Mit Hilfe des PowerShell-Cmdlets “Measure-DedupFileMetadata” lässt sich die tatsächlich belegte SPeichermenge ermitteln:

dedup_2012r2_2

Hier belegt die SizeOnDisk nur noch die zu erwartenden 4KB…

Die eigentlichen Chunks liegen im Ordner “System Volume Information”, an dessen Inhalt man aber nicht ohne Weiteres herankommt.

dedup_2012r2_3