Zwischendurch mal wieder eine andere, trotzdem "liebgewordene" ThematiK: Während der Kurse wird ab und an die soft- und hardwaretechnische Seite der Vorbereitung angesprochen. Die Aussage, alle von Microsoft im Laufe der Zeit angebotenen Tools zu diesem Zweck eingesetzt zu haben, bescherte uns folgenden Auftrag:

Mit Einführung neuer Notebooks wurde unser Kurteilnehmer-Kollege damit beauftragt, eine Möglichkeit des Deployments für Windows 7 und je nach Arbeitplatz benötigter Softwarepakete zu finden und umzusetzen. Anfangs nur für die eigene Abteilung mit ca. 200 Notebooks gedacht wurde über Nacht daraus die Aufgabe, das Deployment weltweit umzusetzen: also verschiedene Sprachpakete und Gebietsschemen sowie die Tatsache zu berücksichtigen, dass einige Standorte nur aüßerst schmalbandig ans Firmennetz angebunden sind und nicht über einen Administrator verfügen. Neben Notebooks sollen auch verschiedene Desktop-Konfigurationen ausgerollt werden. Geschätzte Clientanzahl: 1200-1800. Diese werden nicht zeitgleich geliefert und eingerichtet, sondern in Stückzahlen zwischen fünf und 20. An eine spätere Softwareverteilung neuer Produkte und Inventarisierung wurde dabei nur perspektivisch gedacht; Updates werden per WSUS bereitgestellt und die Konfiguration der Oberflächen und Sicherheitseinstellungen erfolgt bereits zur vollsten Zufriedenheit per Gruppenrichtlinien.

Damit war der Auftrag zumindest grob umrissen.

Zwei Tage wurden für die Vor- und Nachbereitung eingeplant und drei weitere Tage, um eine Einweisung vorzunehmen, die Möglichkeiten des MDT (Microsoft Deployment Toolkit) vorzustellen und eine Abgrenzung zu ergänzenden Produkten (WDS, SCCM, USMT, MAP) vorzunehmen. Nach dem Aufbau einer MDT-Umgebung am ersten Tag und der Erfassung des tatsächlichen Bedarfes kamen wir zu der Erkenntnis, dass MDT alle Anforderungen erfüllt. Vorteilhaft ist, dass vom notwendigen Deployment-Server abgesehen keine weiteren Kosten entstehen und die Lösung später um den SCCM erweitert werden kann, der zu relativ moderaten Kosten die Softwareverteilung und Inventarisierung vornehmen kann.

Nachdem am ersten Tag des Workshops eine Deploymentumgebung auf unserem mitgebrachten Testserver eingerichtet und ausprobiert wurde, haben wir am Folgetag den später beim Kunden zu nutzenden Server aufgesetzt. Hierbei wurden schon wichtige Erkenntnisse des ersten Tages eingearbeitet und weitere gewonnen: Der Deployment-Server des Kunden arbeitet mit zwei getrennten Deployment-Shares, die übrigens beide auf NetApp-NAS-Storage abgelegt sind. Das erste Share steht dabei den Mitarbeitern in der Zentrale zur Verfügung, wo auf einer sehr schnellen (ebenfalls auf NetApp betriebenen) VMWare-Umgebung das Einrichten der Grundinstallationen und das Abziehen der später auszurollenden Images erfolgt. Hier können alle benötigten Paketierungen vorab erstellt werden. Als Treiberpaket wird lediglich der Treibersatz für die Virtualisierungsumgebung benötigt. Die Grundinstallation benötigt dabei ca. 8 min; das Abziehen eines fertigen Images je nach Größe ca. 12 bis 30 min. Dazwischen ist noch die Zeit zum Aufspielen der Softwarepakete einzuplanen (z.B. Office 2010 ca. 10 min).

Die auf diese Art und Weise sehr schnell in der Virtualisierungsumgebung erstellten Referenzsysteme werden anschließend in das zweite Share übernommen und hier für das Ausrollen angeboten. Berechtigt ist hier der Personenkreis der für die eigentliche Installation Zuständigen - nur mit Leserechten.

MDT ist hier eine große Hilfe: in den Steuerfiles customersettings.ini und bootstrap.ini des Deploymentshares können sowohl die Infos zum Hinzufügen des Clients zur Domain als auch die Zugriffskennungen zum Zugriff auf das DeploymentShare "unsichtbar" hinterlegt werden. Außerdem lassen sich bestimmte Werte, die für den Bereich immer dieselben sind, vordefinieren. Dies betrifft beispielsweise Tastaturbelegung, Länderkennung, Name/Organisation und lokale Passwörter. Stellt man dem MDT noch eine SQL-Datenbank zur Verfügung, so lassen sich diese Einstellungen standortbezogen (z.B.nach Default Gateway) oder maschinenbezogen (um Treibersätze automatisch zuzuweisen) granular einstellen. Für jeden verwendeten Hardwaretyp wird mittels Treiber-CD sehr schnell ein Satz der benötigten Treiber erstellt. Das Ausrollen der Images erfolgt dann so, dass im Image keine hardware-spezifischen Treiber enthalten sind (entfernt MDT automatisch) und erst im Moment der "Image-Installation" das richtige Treiberpaket hardwarespezifisch angeboten wird. Ähnlich kann mit Sprachpaketen umgegangen werden.

Während unseres Workshops wurden verschiedene Notebooks betankt. Dabei stand ein 100MBps-Netzwerk zur Verfügung. Die Zeiten vom Anstecken des Bootmediums bis zum Abschluss der Installation incl. Verarbeitung aller Gruppenrichtlinien betrugen zwischen 40 und 60 min; auch für die Clients, die neben Office die beim Kunden benötigte Branchensoftware enthielt. Der Installierende muss nur noch den Namen des Zielrechners eingeben und hat einige Dialogfelder mit OK zu bestätigen oder per Auswahlfeld zu ändern. Damit war schon mal ein großes Ziel des Workshops erreicht.

Die Imageentwicklung und -erfassung erfolgt sehr schnell virtuell; das Ausrollen danach auf die Physik: V2P.

Der dritte Tag des Workshops widmete sich vor allem der Frage des Ausrollens in Standorten mit schlechter Netzwerkanbindung. MDT verfügt über die Möglichkeit, Offline-Medien bereitzustellen. Dabei sollten einige Dinge beachtet werden: das ursprüngliche Installationsmedium sollte immer zum Bestandteil des Offline-Images gemacht werden (damit wird das Image größer), alle nicht benötigten Pakete sollten bei Erstellung des Offline-Images deaktiviert werden (um das Image klein zu halten) und die Vorgehensweise der Erstellung eines bootfähigen USB-Laufwerks sollte bekannt sein.

- Schnellanleitung zum Anlegen eines bootfähigen USB-Devices für Windows: Device anstecken -> "diskpart" -> "list disk" zur Ermittlung der Disk-Nummer -> "select disk" [Disk-Nummer] -> "clean" um alle Daten zu löschen -> "create partition primary" -> "active" -> "format fs=ntfs quick" und anschließend den Inhalt des Offline-Installationsmediums auf das USB-Device per "robocopy [Quelle] [Ziel] /mir" oder "xcopy [Quelle] [Ziel] /s /e /f" übertragen; Zielcomputers von USB booten. -

Unsere Offline-Images waren zwischen 8 und 14 GB groß; ist man dabei unvorsichtig, so kommen auch mal über 30 GB zusammen. Das Ausrollen vom USB Device geht schneller als das übers 100 MBps-Netzwerk, es belastet das Netz nicht, benötigt jedoch Netzwerkanbindung, um den Client in die Domain aufzunehmen. Hier wurde entschieden, dass die Kosten für einige 16GB oder 32GB große USB-Sticks aufgebracht werden, um prinzipiell die Nutzung von Offline-Medien zu favorisieren.

Der MDT-Server konfiguriert sich leider nicht ganz von selbst; der Workshop wurde insgesamt als nützlich, effektiv und zielführend eingeschätzt - kein Wunder, hätte ein kurz davor vorgestelltes Drittanbietertool doch eine sechsstellige Summe gekostet bei vergleichsweise komplizierterer Handhabung.

Es gibt tatsächllich noch das Kommando nsrwatch. Und es ist in den neuen Versionen wichtig wie nie.

Den alten GUIs, egal ob Windows oder Linux/Unix hat man vertraut. Nicht so den Angaben der NMC. Mit Recht, wie sich immer wieder mal zeigt. Die Kollegen, die ihren Networker unter Linux/Unix nutz(t)en, konnten sich für eine aktuelle Bewertung der Lage oft noch mit dem Kommando 'nsrwatch' helfen. Nicht so die Kollegen der Windowsfraktion. Diese brauchten zumindest einen Client unter Linux, um nsrwatch nutzen zu können.

Aber auch das brachte den Admin nicht weiter, wenn die Informationen, die er brauchte, wegen Platzmangel nicht oder nicht mehr angezeigt wurden. Viele Laufwerke, viele Sicherungen.

Mit der NetWorker Version 7.6SP2 und 7.5SP4 liefert EMC nun ein völlig neues 'nsrwatch' aus, das nun sogar unter Windows läuft. Siehe unten.

Das neue 'nsrwatch' ermöglicht nun mit den Tasten d, g, s, m und p den entsprechenden Bereich (dEVICES, gROUPS, sESSIONS, mESSAGES, pENDING) ein- und ausschalten.
Hat man mit Hilfe der Tab-Taste einen Bereich markiert, lassen diese Bereiche sich mit den Cursor-Tasten vertikal und horizontal scrollen. Das klappt unter Linux/Unix wie unter Windows.

So haben also nicht nur die Windows-Admins was von der Neuerung, sondern auch die Admins größerer Unix/Linux-Umgebungen.

Bei der Auseinandersetzung mit dem Thema, Windows-Systeme mittels Networker-NMM - also der konsequent auf VSS-Snapshots basierenden Sicherung via Networker - zu sichern, bin ich auf die Aussage gestoßen, dass die in den Windows-Servern implementierte VSS-Unterstützung stets zuerst eventuell vorhandene VSS-Hardware-Provider zu nutzen versucht und bei Notwendigkeit anschließend den Microsoft Software Shadow Copy Provider mit der Erstellung des Snapshots beauftragt. Nun gut, eine Regelung muss es ja geben. Sinnvoll ist sie außerdem: erst mal versuchen, zu delegieren, dann doch selber machen ...

Auf die Konsequenzen aus diesem Verhalten wurde ich kürzlich aufmerksam: Ein Zwei-Node MSCS-Activ-Activ-Cluster (Windows 2003) nutzt per SnapDrive den Storage einer NetApp. Für die in den virtuellen Servern installierte (und nicht weit verbreitete) Applikation gibt es keinen SnapManager, der beim Backup Unterstützung liefert. Die Betreiber des Clusters waren beunruhigt über Fehlermeldungen des Servers, die auf massive Probleme des Volume Shadow Copy Service (VSS) hinwiesen. Außerdem würden in unregelmäßigen Abständen Laufwerke an den Clusternodes angezeigt, deren Herkunft sich niemand erklären konnte. Wichtig war der Hinweis, dass beide Phänomene im zeitlichen Zusammenhang mit der nächtlich ausgeführten Networker-Sicherung zu stehen scheinen.

Apropos NetWorker Sicherung, wie würde ich vorgehen?
Nun, ich würde in diesem Fall die auf shared LUNs abgelegten Daten aus dem letzten (oder einem anderen) Snapshots des Volumes, in dem die LUN liegt, per SnapDrive zugänglich machen, die NetWorker-Sicherung ausführen und anschließend den Clone der LUN wieder entfernen. Also die Networker-Sicherung mit vor- und nachgeschalteten Befehlen "abrunden".

Aber das Vorhandensein eines NetWorker-Savesets "ALL" ist wohl zu verlockend: es kümmert sich um alles und wird es schon richten. Das dies spätestens beim Einsatz des vom Konzept her genialen NMM überhaupt nicht mehr funktioniert, habe ich in einem früheren Beitrag bereits dargelegt. Die Nodes des MSCS waren beide für die Sicherung per Saveset ALL eingerichtet, wobei die durch die virtuellen Server genutzen Laufwerke sowie die Quorum-Disk aus der Sicherung ausgeschlossen wurden oder ausgeschlossen werden sollten.

Gesichert werden sollte also nicht ALL, sondern der "Systemstate" und die Dateien des Betriebssytemlaufwerkes (C:\). Eine in diesem Umfang testhalber ausgeführte Sicherung war die erste auf diesen Systemen überhaupt, die völlig ohne Warnungen oder gar Fehler ausgeführt werden konnte.

Was war also passiert: Der Networker beauftragt seinen Client, doch erst mal das System klar zu machen dafür, "ALL"es zu sichern, denn später kann er ja immer noch darauf verzichten, auch alle Daten "abzuholen".

Da standardmäßig der für Datenkonsistenz  sorgende Weg über VSS-Backups gegangen wird, geht der Auftrag an alle VSS-Writer raus, die VSS-Sicherung "auf breiter Front" (Saveset ALL !) vorzubereiten, was von diesen auch problemlos quittiert werden kann. Nun sind die VSS-Provider an der Reihe, die Snapshots zu erstellen: der in SnapDrive implementierte NetApp-VSS-Hardwareprovider zuerst, dann der Microsoft-Software-Provider.

Und SnapDrive reagiert so, wie es von SnapDrive erwartet wird: von allen angeschlossenen LUNs wird ein Snapshot erstellt. Stimmt natürlich nicht: das Snapshot wird jeweils von dem Volume erstellt, in dem sich die LUN befindet. Und um sicherzugehen, dass das auch funktioniert hat, prüft SnapDrive den Zugiff auf die LUN im gerade erstellten Snapshot und greift kurzzeitig auf eine *.rws - LUN zu. Diese Snapshots werden aber gar nicht benötigt, da die LUN-Inhalte ja extra "excluded" wurden. Jetzt haben wir ein Snapshot, dass keiner haben wollte und niemend braucht - und fast zeitgleich legt der Software-Provider los, und will nun seinerseits von "ALL"em Datenbestand eine Schattenkopie anlegen; mitunter wohl auch von der zwecks Test nur kurzzeitig gemounteten LUN im Snapshot (die im nächsten Moment aber schon wieder "weg" sein kann, wenn dann die Daten abgeholt werden könnten). Fallen diese Zugriffe zeitlich "unglücklich" zusammen, dann sorgt der Zugriff auf die temporäre LUN dafür, dass SnapDrive diese nicht wieder entfernen kann. Damit sind sowohl die sporadisch "aus dem Nichts" auftauchenden Disks als auch die massiven Probleme im VSS-Bereich erklärt.

Die von mir oben beschriebene Methode für das Networker-Backup aus dem letzten Snapshot heraus werde ich die nächsten Tage einrichten und damit für ein System sorgen, in dessen Ereignisanzeige weder gelbe noch rote Hinweise auftauchen.

Nach und nach gibt es immer mehr Situationen, in denen Networker-Saveset ALL nicht eingesetzt werden kann: bereiten wir uns auf den Abschied vom Networker Saveset ALL vor !

Die Anfrage, einen Kunden bei der Umstellung eines Windows 2003 MSCS Fileservers auf 2008 R2 Failover-Cluster "begleitend zu unterstützen", hörte sich einfach und simpel an. Da die Anreise von der Entfernung und Streckenführung per Motorrad möglich war, versprach es auch ein schöner Samstag zu werden.

Aber der Teufel liegt im Detail. Eine Hürde bestand in dem Wunsch, die Datenträger (irgendein per FCP angebundenes SAN) von MBR-Format auf GPT umzustellen. Geht bei Microsoft - wenn die Datenträger leer sind. Der Wunsch impliziert jedoch Datenmengen im TB-Bereich. Aber es gibt Tools, mit denen man das auch im Betrieb vornehmen kann - letztlich wurden die Datenträger kurz an ein Linux-System gemountet und mit diesem der Wandel vorgenommen.

Die größere Hürde lag jedoch an anderer Stelle: Auf dem alten Cluster wurde intensiv das schon zu NT-Zeiten verfügbare Feature "automatische Freigabe untergeordneter Ordner" - bei NetApp leicht abgewandelt als Auto-Home-Sharing implementiert - genutzt. Unter den sichtbaren vier -fünf Shares versteckten sich somit über 6000 Shares, mit denen natürlich auch unter dem 2008er Fileservercluster weitergearbeitet werden sollte. Also doch in die Vorbereitung der Umstellung Zeit investieren: eine tiefgehendere Auseinandersetzung mit dem eigentlich einfach zu handhabenden und schnell und zuverlässig arbeitendem Failover-Cluster. Die Clusterinformationen werden in der Registry gespeichert - einmal pro Node und zusätzlich auf dem aktiven Node. Mit diesem Wissen gelang die Umstellung. Allerdings: man hat nur "einen Schuss frei" - hier hat sich gerächt, dass die Berechtigungen des Filesystems von Version zu Version mitgenommen worden sind und teils noch auf Versionen von Windows 2000 oder älter standen. Dort ist das "System" nicht in der ACL-Liste enthalten - und ohne dieses Recht darf das System keinen Share auf den Ordner legen. Die notwendigen Korrekturen haben dann mehr Zeit als geplant benötigt; am Montag nach der Umstellung wurden auch fünf -sechs vergessene Shares entdeckt (also 0,1%).

Gepasst hat es trotzdem: mit dem Motorrad durch den Sonenuntergang nach Hause ...