Bents Blog

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.

Die sogenannten Krypto- bzw. Erpressungstrojaner existieren bereits seit geraumer Zeit, ihr Auftreten steigt aber mit dem Angebot von „Trojaner-Baukästen“ für Laien mit kriminellen Absichten in ungeahnte Höhen. Dabei wird mit jeder neuen Version eines solchen Trojaners auch die Signatur (sprich der Hash-Wert des eigentlichen Schadcodes) geändert bzw. neu kreiert – demnach besteht keine Chance für Virenscanner, diese frühzeitig zu erkennen. Doch wie kann man sich wirksam dagegen schützen? Der folgende Beitrag soll ein Beispiel für eine korrekt konfigurierte Datensicherung eines Windows-Systems auf  Basis des Veeam Agent for Windows sein.

Problem

Wie bereits im Vorwort erwähnt, sorgen die Erpressungstrojaner immer wieder für Schlagzeilen. Dabei sind nicht nur private Anwender sondern auch Firmen betroffen, wie ich aus meiner Erfahrung berichten kann. Hat ein Trojaner einmal „Fuß gefasst“ – ist also zur Ausführung gekommen – verschlüsselt er jede Datei, auf die der Benutzer (in dessem Kontext der Trojaner ausgeführt wird) schreibenden Zugriff besitzt. Für diese Routine werden alle Laufwerke, also lokale Laufwerk und Netzlaufwerke, verwendet. Das eigentliche Problem ist wie so oft: der Anwender. Ein Trojaner befällt kein System, er muss durch eine bestimmte Aktion ausgeführt werden. Beitrag weiterlesen …

In meinem Artikel über Probleme mit Offlinedateien bei aktiviertem FastBoot berichtete ich vor einiger Zeit über das merkwürdige Verhalten der Offlinedateisynchronisation in Windows 10. Nach dem kürzlich durchgeführten Fall Creators Update (Version 1709, Build 16299.15) wunderte ich mich nun erneut über die Unzuverlässigkeit der Offlinedateien. Beitrag weiterlesen …