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

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 

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

17Mrz/140

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

11Mrz/140

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!

28Jan/140

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

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:

Toolsmenu

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.

 

9Dez/130

Hyper-V 4.0: Live Größenänderung von virtuellen Festplatten

Eine der wirklich praktischen Neuerungen im Hyper-V 4.0 unter Windows Server 2012 R2 ist die Möglichkeit, eine virtuelle Festplatte im laufenden Betrieb zu vergrößern oder zu verkleinern. Dies funktioniert, wenn:

  • Die virtuelle Festplatte das VHDX-Format verwendet und
  • Am SCSI-Controller angebunden ist

Wenn man eine virtuelle Maschine der 2.Generation (Gen2-VM) verwendet, stellt sich die Frage nach der zweiten Bedingung nicht, da hier ja ohnehin nur noch SCSI zum Einsatz kommt.

In der Abbildung ist eine Muster-VM zu sehen, die neben ihrer OS-Platte noch über eine zweite Platte (VHDX, SCSI-Controller) mit 30GB verfügt:

vhdxresize1

vhdxresize2

vhdxresize3

Nun kann diese VHDX-Festplatte im laufenden Betrieb vergrößert werden. Dazu ist nur ein Klick auf “Bearbeiten” nötig:

vhdxresize4

Der Assistent führt einen dann durch die notwendigen Schritte, bei dem schließlich auch die gewünschte neue Größe angegeben wird: (Klick auf Bild für Vergrößerung)

 

vhdxresize5 vhdxresize6
vhdxresize7 vhdxresize8

 

Am Ende steht dann eine Festplatte mit mehr Speicher zur Verfügung, bei der anschließend noch die Partition erweitert werden muss:

vhdxresize9

PS: Die VHDX lässt sich auch verkleinern, allerdings nur, wenn die Partition im Inneren kleiner ist, als der Datenträger...

Weitere Informationen: http://technet.microsoft.com/en-us/library/dn282286.aspx