Haikos Blog – Seite 22 – Blog von Haiko Hertes zu allen Themen rund um Microsoft, Cloud und Datacenter

SCOM 2012 R2 – Auto-Defragmentierung

Veröffentlicht 15. Mai 2014

Wenn man den Operations Manager 2012 nutzt, dann wird man vermutlich auch schon einmal über eine Meldung gestolpert sein, die darauf hinweist, dass ein logisches Laufwerk zu stark fragmentiert ist („Fragmentierungsgrad des logischen Datenträgers ist hoch“ / „Logical Disk Fragmentation Level is High“). Wenn man viele Server überwacht, dann wird man diese Meldung auch sehr oft sehen – ganz speziell am Montag Morgen (das liegt daran, dass die Standardeinstellung dieses Monitor dafür sorgt, dass der Test immer Samstag 03:00 Uhr läuft).

Nun hat man im Wesentlichen 3 Optionen:

Meldung hinnehmen und von Hand auflösen – bedeutet u.U. sehr viel Aufwand
Meldung ignorieren oder gar mittels Override deaktivieren – löst aber nicht die Ursache auf
Meldung nutzen, um nicht nur die Meldung selbst (=Wirkung), sondern auch den Zustand (=Ursache) selbst aufzulösen

Die Möglichkeit, die Defragmentierung zu automatisieren ist auch im Wissensdantenbank-Artikel des Monitors erwähnt:

Wie das genau geht, hat Cameron Fuller, MVP für SCOM, in seinem Blogartikel beschrieben:

http://tinyurl.com/OMAutodefrag

Ein großartiger Artikel!

Update: Es gibt auch einen etwas einfacheren Weg – man kann das selbe Ziel auch mit einem einfachen Override erreichen, somit ist auch kein weiteres MP nötig… Wie genau das funktioniert, werde ich zeitnah nachreichen.

Schreibe einen Kommentar...

BranchCache mit Windows Server 2012 R2 und Windows 8.1

Veröffentlicht 5. Mai 2014

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:

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.
Der Dateiserver überträgt den Hash zum Client1 (Der Hash wurde vom Dateiserver generiert, dieser ist ebenfalls durch eine GPO entsprechend konfiguriert)
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
Client1 fragt nun noch einmal beim Dateiserver an; dieses Mal jedoch direkt nach der Datei statt nach deren Hash
Die Datei wird zum Client1 übertragen und dort geöffnet
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
Der Dateiserver überträgt den Hash an Client2
Client2 fragt per Broadcast in seinem Subnetz nach dem Hash
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:

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

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”:

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

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:

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

Innerhalb der Client-Policy sind etwas mehr Einstellungen vorzunehmen:

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:

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:

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:

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

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:

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):

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

(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: Automatische Sperre verhindern

Veröffentlicht 23. April 2014

Im Gegensatz zu seinen Vorgängern sperrt der Windows Server 2012 R2 seine Oberfläche nach 10 Minuten Inaktivität. Dies ist aus Sicherheitsgründen sicherlich nützlich, oft aber einfach nur störend, z.B. wenn man einen Prozess längere Zeit beobachten will oder vor allem in Test- und Demoumgebungen.

Selbstverständlich lässt sich dieses Verhalten abschalten, allerdings etwas versteckt.

Das Ganze geschieht über die Energieeinstellungen und dort in den jeweiligen Energiesparplaneinstellungen:

Systemsteuerung / Hardware / Energieoptionen (oder direkt im Startmenü “Energieoptionen” eingeben. Dort werden als erstes die Energiesparplaneinstellungen des aktuellen Energiesparplanes geöffnet.

Hier muss dann über “Erweiterte Energieeinstellungen ändern” die GUI für die Energieoptionen geöffnet werden.

Allerdings hat die notwendige Option einen eher unerwarteten Namen:

Das was hier an der deutschen Oberfläche als “Bildschirm ausschalten nach” bezeichnet wird, betrifft auch das Sperren der Sitzung. Standardmäßig sind hier 10 Minuten eingetragen. Ein Herabsetzen auf den Wert “0” deaktiviert diese Funktion komplett.

Schreibe einen Kommentar...

Exchange 2007 lässt sich nicht via Windows Server Sicherung sichern

Veröffentlicht 18. März 2014

Hinweis: Bei meinen Recherchen zu dem Thema habe ich festgestellt, dass dieses Problem scheinbar auch bei Exchange 2010 auftritt!

Bei einem Exchange Server 2007 mit LCR trat seit längerem das Problem auf, dass sich dieser nicht sauber (auf Anwendungsebene) sichern ließ. Die Windows Server Sicherung meldete immer

“Abgeschlossen mit Warnungen – Die Anwendung kann aus dieser Sicherung nicht wiederhergestellt werden […]”

Kurz nach Start der Sicherung findet sich im Ereignisprotokoll folgender Eintrag:

Anwendungsprotokoll / Ereignis 565 / Quelle Backup / “Fehler bei der Konsistenzprüfung für die Komponente […]”

Eine Überprüfung der Postfachdatenbank sowie der Datenbank für die öffentlichen Ordner und aller Logs mit Hilfe von ESEUtil brachte keinerlei Fehler oder sonstige Probleme.

Als Lösung des Problemes habe ich den Exchange VSS-Writer per Registry deaktiviert.

Dazu ist unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\Replay\Parameters ein neuer DWORD-Schlüssel anzulegen, der den Namen “EnableVSSWriter” und den Wert 0 bekommt.

Danach funktioniert das nächtliche Backup wieder ohne Probleme:

Schreibe einen Kommentar...

Windows Server 2012 (R2): Disk-Performance im Taskmanager anzeigen

Veröffentlicht 17. März 2014

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

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:

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:

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:

Das Abschalten ist nun eher trivial:

diskperf –N

Schreibe einen Kommentar...

SCVMM 2012 R2: Tastatur-Layout einer VM-Vorlage ändern

Veröffentlicht 11. März 2014

Das Problem

Wenn man im SCVMM 2012 R2 (gilt auch für “R1”) eine VM mit Hilfe einer VM-Vorlage (engl. “Template”) erzeugt, dann bekommt diese neue VM (und zwar unabhängig von dem bereits vorhandenen Betriebssystem in der eingesetzten VHD) alle Regionaleinstellungen auf “en-US”, dazu gehören u.a.:

Tastaturlayout
User-Locale
System-Locale
UILanguage

Die einzige Einstellung bezüglich der Region lässt sich für die Zeitzone einrichten:

Selbst wenn man mit Hilfe einer eigenen Antwortdatei andere Werte setzt, werden diese weitgehend ignoriert, da am Ende in der resultierenden Antwortdatei (Eigene Inhalte + im SCVMM gesetzte Einstellungen + SCVMM-Defaults) die SCVMM-Defaults am weitesten oben stehen und daher Vorrang bekommen.

Dieses Verhalten ist bei Microsoft bekannt und in dem folgenden KB-Artikel beschrieben:

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

Lösung des Problems

Als Workarround ist folgendes Vorgehen möglich:

SCVMM-Konsole starten
In den “Einstellungen”-Bereich wechseln
Dort die PowerShell über den Button in der Ribbon-Leiste öffnen
Ein angepasstes Script nach folgendem Schema ausführen

PowerShell-Script:

$Vorlage = Get-SCVMtemplate | where {$_.Name  -eq "Template_Name"}             
$Einstellungen = $Vorlage.UnattendSettings;            
$Einstellungen.add("oobeSystem/Microsoft-Windows-International-Core/UserLocale","de-DE");            
$Einstellungen.add("oobeSystem/Microsoft-Windows-International-Core/SystemLocale","de-DE");            
$Einstellungen.add("oobeSystem/Microsoft-Windows-International-Core/UILanguage","de-DE");            
$Einstellungen.add("oobeSystem/Microsoft-Windows-International-Core/InputLocale","0407:00000407");            
Set-SCVMTemplate -VMTemplate $Vorlage -UnattendSettings $Einstellungen

“Template_Name” muss hier natürlich durch den Namen der eigenen VM-Vorlage ausgetauscht werden. Das ganze sollte dann so aussehen:

Nun ist die VM-Vorlage entsprechend angepasst, was man per PowerShell abfragen kann:

(Get-SCVMtemplate | where {$_.Name -eq "Name_der_Vorlage"}).UnattendSettings

Schreibe einen Kommentar...

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

Veröffentlicht 11. März 2014

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:

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

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

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

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…

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

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:

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)

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

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

Veröffentlicht 2. März 2014

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:

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:

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:

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

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:

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

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”:

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:

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

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

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

Zum Schluss gibt es noch eine Zusammenfassung:

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

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:

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:

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

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:

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

Am Ende sollten die Targets so im Initiator auftauchen:

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

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

Schreibe einen Kommentar...

Windows Server 2012 (R2): Wie man das „Tools“-Menü im Servermanager anpasst

Veröffentlicht 28. Januar 2014

Microsoft Premier Field Engineer Michael Hildebrand beschreibt in seinem Blog, wie man die Tools-Leiste oben rechts im Servermanager anpassen und um weitere Einträge ergänzen kann:

http://blogs.technet.com/b/askpfeplat/archive/2014/01/27/how-to-customize-server-manager-in-windows-server-2012-and-2012-r2-get-creative.aspx

Kern des Ganzen ist der Ordner „C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Administrative Tools\“

Dort kann man entsprechende Verknüpfungen ablegen:

Das funktioniert sogar mit Ordnern, um besser strukturieren zu können! Einzig die Icons, die von anderen Systemen abgelegt worden sollte man nicht verändern, weil es sonst u.U. zu Problemen kommt, etwa beim entfernen der jeweiligen Funktion.

Schreibe einen Kommentar...

SCCM: Laufwerk C:\ auf CAS läuft wegen SCCMContenLib voll

Veröffentlicht 15. Januar 2014

Erst kürzlich bekam ich von unserem SCCM-System eine E-Mail mit folgendem Betreff:

Warnung: Warnung: Nicht genügend Speicherplatz für Datenbank an Standort "CAS" vorhanden

Als ich der Sache auf den Grund ging, stellte ich fest, dass der Ordner C:\SCCMContentLib ziemlich groß geworden ist:

Der Grund hierfür ist, dass auch auf einer CAS – wo kein DP vorhanden ist – Daten für die Verteilung abgelegt werden, wenn dieser Content auf der CAS angelegt wurde, was im Sinne einer zentralen Verteilung sicher oft gemacht wird. Da aber nun kein DP vorhanden ist, kann man das Laufwerk nicht beeinflussen, auf dem diese Daten abgelegt werden sollen. Daher wird standardmäßig das Laufwerk verwendet, welches über den meisten freien Speicherplatz verfügt (zum Zeitpunkt der Installation der CAS).

Dies hätte man verhindern können, wenn man vor der Installation der ContentLibrary auf der CAS ein leeres File mit dem Namen “no_sms_on_drive.sms” im Laufwerks-Root des Laufwerkes ablegt, auf dem keine SCCM-Daten liegen sollen.

Um nun aber nachträglich die Daten von einem Laufwerk auf ein anderes zu bekommen, ist das Tool “ContenLibraryTransfer” gedacht, welches sich im Configuration Manager Toolkit befindet.

Neben diesem Tool sind dort auch noch weitere enthalten:

Hinweis: Es wird immer nur die aktuellste Version von Microsoft angeboten – also aktuell 2012 R2. Diese Version funktioniert auch z.B. auf einem SCCM 2012 SP1!

Die Benutzung ist relativ einfach:

C:\Program Files (x86)\ConfigMgr 2012 Toolkit R2\ServerTools\ContentLibraryTransfer.exe –SourceDrive <AktuellesLaufwerk> –TargetDrive <ZielLaufwerk>

Das Tool kopiert dann die Inhalte auf das Ziellaufwerk und sorgt dafür, dass alle internen Verweise entsprechend geändert werden. Außerdem wird anschließend auf dem Quelllaufwerk eine NO_SMS_ON_DRIVE.SMS angelegt.

Am Ende sollte es dann so aussehen:

3 Comments

Haikos Blog Posts

Das Problem

Lösung des Problems

Das iSCSI-Target

Der iSCSI-Initiator