Bents Blog

Bei einem größeren Kunden, den ich seit einigen Jahren betreue, wurde ich am Ende des vergangenen Jahres mit einem merkwürdigem Phänomen konfrontiert, welches ich so noch nie erlebt habe. Im Rahmen eines größeren Projektes, bei dem sämtliche File-Services verschiedener Bereiche zentralisiert und homogenisiert werden, meldete ein Administrator eines Bereiches ein ungeklärtes Verhalten bei der Arbeit mit dem Terminalserver.

Seit ich mein Firmen-Notebook auf die Windows-Version 1903 aktualisiert hatte, begann sporadisch der Lüfter meines HP Elitebooks derart aufzuheulen, dass man den Eindruck bekommen konnte, das Gerät fliegt jeden Moment davon. Dazu kam, dass dieses Verhalten von recht langer Dauer war – in Situationen beim Kunden ungünstig, da man da eben keine „eigenen Probleme“ löst.

Bei der Bereitstellung einer OVA Vorlage im VMware vCenter (VCSA) hatte ich kürzlich das unerklärliche Problem, dass jeder Versuch eine neue virtuelle Maschine bereitzustellen, mit dem folgenden Fehler quittiert wurde:

Da die Fehlermeldung

Transfer failed: Invalid response code: 500

nur bedingt aussagekräftig ist, habe ich verschiedene Versuche unternommen, zunächst die Ursache zu finden und das Problem zu beheben. Die Umgebung hat die folgenden Parameter:

• VMware vSphere 6.5 und 6.7
• OVA Vorlage von CISCO (Identity Service Engine), ca. 12 GByte
• Internet Explorer 11

Sowohl der Versuch der Bereitstellung mit dem HTML5 Client (/ui) als auch mit dem vSphere Web Client (/vsphere-client) schlugen während des Bereitstellungsprozesses etwa bei 40 Prozent fehl. Dieses Verhalten änderte sich auch nicht bei der Umwandlung der OVA-Vorlage in eine OVF.

Lösung

Ursache für das Problem ist tatsächlich der Internet Explorer 11. Dieser hat, wie im folgenden KB-Artikel beschrieben, ein Upload-Limit von 4 GByte. Dies gilt im Übrigen auch für den Mozialla Firefox. Mit Chrome war die Aktion problemlos möglich, da dieser über keine Beschränkung von Datei-Uploads verfügt – sogar unter Verwendung des HTML5 Clients.

Durch Richtlinien erzwungene, wechselnde Kennwörter sind in Active Directory Umgebungen ein probates Mittel, um den Kennwort-Hash eines Benutzers zyklisch zu ändern. Arbeitet man in vielen unterschiedlichen Umgebungen – bspw. im Support für Kunden – so entsteht oftmals die Frage, wie lange das eigene Kennwort eigentlich noch gültig ist.

Der folgende PowerShell-Befehl löst dieses Rätsel in kürzester Zeit. Dabei wird das Attribut msDS-UserPasswordExpiryTimeComputed des Benutzer-Objektes ausgelesen und die verbleibende Gültigkeit in Tagen berechnet:

([System.Security.Principal.WindowsIdentity]::GetCurrent().User).Value | get-aduser -Properties Displayname,PasswordLastSet,msDS-UserPasswordExpiryTimeComputed | Select-Object -Property Displayname,SamAccountName,PasswordLastSet,@{Name="ExpirationDate";Expression={[datetime]::FromFileTime($_."msDS-UserPasswordExpiryTimeComputed")}},@{Name="Duration";Expression={$(New-TimeSpan -Start $(Get-Date) -End $([datetime]::FromFileTime($_."msDS-UserPasswordExpiryTimeComputed"))).ToString("%d")+" days"}}

Das Ergebnis der Abfrage sieht dann in etwa so aus:

Mit dem aufgeführten PowerShell-Kommando kommt man relativ zügig zum gewünschten Ergebnis. Wer mag, kann den Befehl auch in Anmelde-Skripten integrieren, um dem Benutzer eine etwas vorausschauendere Information über das Kennwortalter zu geben.

Mit dem folgenden Kommando kann die Information im Übrigen ebenfalls einfach abgerufen werden:

net user %username% /domain

Virtual Based Security (VBS) ist ein Sicherheitsfeature von VMware, welches seit VMware vSphere 6.7 für die Gastbetriebssysteme Windows 10 und Windows Server 2016 aktiviert werden kann. 

Dazu sind zunächst auf Seiten der Virtual Machine Configuration ein paar notwendige Einstellungen zu treffen. Im zweiten Schritt müssen dann auch die nachfolgenden Gruppenrichtlinieneinstellungen innerhalb des Betriebssystems angewendet werden.