Benutzerprofil-Datenträger Maximal Größe nachträglich anpassen

In einer RDS-Sammlung kann man die maximal Größe einer User Profile Disk bei der Erstellung vorgeben. Nachträgliche Änderungen sind jedoch nicht mehr möglich. Die Option „Maximale Größe“ ist ausgegraut. Man müsste die ganze Sammlung dafür eigentlich neu erstellen …

Screenshot RDS Sammlung Konfiguration, Maximale Größe der VHDX ist ausgegraut
Die Option maximal Größe ist ausgegraut

Lösung

Man muss direkt das VHDX-Template das die Sammlung bei der Erstellung anlegt bearbeiten. Das Template heisst UVHD-template.vhdx und liegt in dem in der Sammlung festgelegten Share.

Die VHDX „Festplatte“ vergrößert man am einfachsten mit DISKPART.

C:> Diskpart

DISKPART> select vdisk file="F:\vhdx\UVHD-template.vhdx"
(Datei auswählen)

DISKPART> expand vdisk maximum=20000
(Vergrößern, 20000 = 20 Gbyte)

DISKPART> attach vdisk
(vDisk mounten)

DISKPART> list volume
(Volumes auflisten)

DISKPART> select volume <VOLUME-ID>
(Auswählen des Volumes, die ID der VHDX-Partition wählen)

DISKPART> extend

DISKPART> detach vdisk

DISKPART> exit

Im Live-Betrieb sieht das dann so aus:

Leider wird die Anzeige im Windows Server-Manager dazu nie aktualisiert, der Wert bleibt im GUI auf dem erstmalig eingetragenen Wert stehen. Die Box also müsste eigentlich „Maximale Größe bei erstellung“ heißen. Da der Server-Manager aufgrund seiner Fehler und generellen Schwerfälligkeit grundsätzlich aber nicht unbedingt das Lieblingswerkzeug von Administratoren ist, kann man diese rein kosmetische Angabe dort ganz gut ignorieren.

Edge und die Seite „Neuer Tab“

Microsoft findet einfach ALLEs raus. Und dokumentiert das dann auch genau so.

Sätze wie dieser machen die Microsoft Docs so UNGLAUBLICH hilfreich 😁

vCenter 6.7 „Exception in invoking authentication handler User password expired.“

Ein vCenter mag „plötzlich“ keine root-Anmeldung mehr für das VMware Appliance Management machen.

Das kommt schon mal vor, weil Kennwort Standartmäßig in der VCSA ablaufen und es eineige Admins gibt die sich auch gerne länge mal nicht einloggen. „Warum auch, läuft doch“ 😉

Lösung

  1. Öffnen einer SSH-Sitzung auf den vCenter Server, einloggen als ‚root‘ (dort funktioniert das auch noch)
  2. Mit shell die Shell öffnen
  3. Mit passwd ein neues Kennwort vergeben (das kann auch dem alten entsprechen)

… und schon funktioniert die Anmeldung sofort wieder, ein Neustart ist nicht notwendig.

Kennwort nicht ablaufen lassen

Meist stehen „solche“ vmWare vCenter Applicances eher „isoliert“, daher kann man das Kennwort dort auch nicht ablaufen lassen. Das geht in der Weboberfläche unter Verwaltung > Einstellungen für Kennwortablauf

vSphere 7 VMware PowerCLI (v12.1+) installieren

Dies ist wieder so ein klassicher Fall von Selbst-Notiz: Nachdem ich schon wieder aus Gewohnheit das aktuellen VMware PowerCLI aus dem vMware Code Portal herunterladen wollte.

Das ist jetzt ein (NuGet) PowerShell Modul – man muss nichts mehr einzeln herunterladen. Install-Module läd das passende NuGet-Paket, sofern nicht vorhanden, auch gleich mit herunter.

PS> Install-Module -Name VMware.PowerCLI

Der native Download des NuGet-Paketes (für Offline-PCs) liegt hier:

https://psg-prod-eastus.azureedge.net/packages/vmware.powercli.12.1.0.17009493.nupkg

vCenter 6.7 Host hinzufügen schlägt fehl „Ein allgemeiner Systemfehler ist aufgetreten: Unable to push CA certificates and CRLs to host „

Das Hinzufügen eines neuen Hosts (vSphere ESX 6.7 U3) unter vCenter 6.7 schlägt mit der Meldung fehl:

Ein allgemeiner Systemfehler ist aufgetreten: Unable to push CA certificates and CRLs to host <HOSTNAME>

Lösung

Mit vSphere 6.7U3 wurde die Zertifikatssicherheit verschärft. Die Fehlermeldung ist (indirekt) darauf zurückzuführen, dass selbstsignierte Zertifikate (oder Zertifikate ohne vertraute CA) aus dem TRUSTED_ROOTS Speicher des vCenters Server beim Hinzufügen (oder Verbinden) den ESXi-Host übertragen werden sollen. Ab U3 lässt der Host das aber nicht mehr zu.

Man kann diese Verhalten aber zum Glück ändern:

  1. vSphere Host-Client des neuen hosts öffnen
  2. Verwalten -> System -> Erweiterte Einstellungen
  3. Config.HostAgent.ssl.keyStore.allowSelfSigned auf „true“ setzen

„Der ausgewählte Anschluss kann nicht entfernt werden. Dieser Vorgang wird nicht unterstützt.“ beim löschen von WSD Ports

Wenn man versucht WSD-Ports unter Windows 10 (Server 2016/2019) zu löschen, erhält man die Fehlermeldung „Der ausgewählte Anschluss kann nicht entfernt werden. Dieser Vorgang wird nicht unterstützt.“

Solange en Drucker mit dem Port verbunden ist klappt da auch mit „normalen“ Ports nicht, aber WSD-Anschlüsse lassen sich auch ungenutzt nicht entfernen.

Lösung

Erstelle einen Temporären Drucker auf genau diesem Port (Treiber egal) und lösche dann den ganzen neuen TEMP-Drucker. Der WSD-Port wird damit zusammen fehlerfrei entfernt.

Windows Server 2008R2 Windows Update Fehler 0x80092004

Windows Server 2008 R2 ist zwar schon in die Jahre gekommen, läuft aber hier und da noch und soll auch Updates bekommen. Die aktuellen Updates (zum Beispiel „2020-01 Sicherheitsupdate für .NET Framework 3.5.1, 4.5.2, 4.6, 4.6.1, 4.6.2, 4.7, 4.7.1, 4.7.2, 4.8 für Windows 7 und Server 2008 R2 für x64 (KB4534976)“ schlagen aber mit dem Fehler 0x80092004 fehl.

Grund ist die Signatur der aktuellen Patches. Der Fehlercode 0x80092004 steht für CRYPT_E_NOT_FOUND. Das Windows Update konnte einen kryptografischen Wert nicht verifizieren und lehnt das Update daher ab. Die besagten Pakete sind alle nur noch mit einem SHA2 Hash signiert – Windows 2008 R2 versteht aber kein SHA2.

Lösung

Manuell Installation des „Servicing stack update for Windows 7 SP1 and Windows Server 2008 R2 SP1: March 12, 2019“ (KB4490628) von:

http://www.catalog.update.microsoft.com/search.aspx?q=4490628

Sobald das Update SHA2ermöglichst, läuft die Installation der weiteren sofort fehlerfrei Updates durch.