Windows Admin Center SSL-Zertifikat erneuern

14 Juli 2019

Wenn man das Windows-Admin-Center auf einem Windows-Server Rechner installiert, wird ein spezieller Gateway-Dienst installiert. Für diesen Dienst kann automatisch ein SSL-Zertifikat erstellt werden. Dies läuft allerdings nur 60-Tage. Danach muss es erneuert werden. Eine Möglichkeit dabei ist, einfach bei den installierten Programmen das Windows-Admin-Center De-Installationsprogramm aufzurufen und dann den Punkt Ändern auswählen. Nun bekommt man nochmal die Möglichkeit ein neues Zertifikat zu erstellen. Diese Methode klappt allerdings nur, wenn man zuvor das alte Zertifikat entfernt hat.

Gehen wir vom Port 8081 für das Windows-Admin-Center aus. Dann kann man mittels Admin-Commandline folgendes abrufen:

PS > netsh http show sslcert

SSL-Zertifikatbindungen:
————————-

    IP:Port                      : 0.0.0.0:8081
    Zertifikathash              : 5104877e8eae1698fea7f3445b5eb0d728e02b95
    Anwendungs-ID               : {3fbbd223-54fa-4cb6-9c95-47eebdf667f8}
    Zertifikatspeichername       : (null)
    Clientzertifikatsperre überprüfen : Enabled
    Zur Sperrüberprüfung ausschließlich zwischengespeichertes Clientzertifikat verwenden : Disabled
    Verwendungsüberprüfung                  : Enabled
    Sperraktualisierungszeit    : 0
    Zeitlimit für URL-Abruf        : 0
    Steuerelement-ID               : (null)
    Steuerelement-Speichername               : (null)
    DS-Zuordnungsverwendung              : Disabled
    Clientzertifikat aushandeln : Disabled
    Verbindungen ablehnen           : Disabled
    HTTP2 deaktivieren                : Not Set

Um das Zertifikat zu entfernen ruft man

PS C:\Users\Administrator> netsh http delete sslcert ipport=0.0.0.0:8081

Das SSL-Zertifikat wurde erfolgreich gelöscht.

auf. Nun kann man wie oben beschrieben das neue Zertifikat erstellen lassen.

Um zu prüfen, ob das neue Zertifikat wirklich das aktuelle ist, kann man z. B. so weitere Daten zum Zertifikat ermitteln, dazu wird der Zertifikatshash benötigt – der in unserem Beispiel 5104877e8eae1698fea7f3445b5eb0d728e02b95 lautet – und mittels Powershell so ausgelesen werden kann:

PS > $cert=dir cert:\ -Recurse | where thumbprint -match 5104877e8eae1698fea7f3445b5eb0d728e02b95
PS > $cert[0]|fl *

Dabei werden mehrere Zertifikate, welche aber alle das gleiche darstellen zurückgegeben, deshalb werden nur die Daten des ersten Zertifikats zurückgegeben.

Eigentlich sollte es auch möglich sein alles per Commandline zu steuern, aber meine bisherigen Versuche waren nicht von Erfolg gekrönt. Zu diesem Thema ein wichtiger Link: https://www.der-windows-papst.de/2018/06/25/windows-admin-center-honolulu-installieren/. Auch sollte dabei das Windows-Admin-Center Gateway wahrscheinlich neu gestartet werden: Restart-Service ServerManagementGateway. Half trotzdem bisher noch nichts.

Werbeanzeigen

Windows 10 Grafikdarstellung Reset

6 Juli 2019

Bei ziemlich viel, gleichzeitig geöffneten Fenstern unter Windows 10 kann es schon mal vorkommen, dass die Darstellung leidet und bestimmte Ressourcen ausgehen, so dass die benutzten Programme abstürzen. Manchmal bleibt dann am Bildschirm der Schatten der zuletzt geöffneten Fenster stehen.

Mit der Tastenkombination STRG+Shift+Win+B kann man einen Grafikkartentreiber-Reset durchführen. Der Bildschirm wird dann kurz schwarz und meldet sich dann wieder zurück. Wenn die Darstellung dann immer noch nicht korrekt sein sollte, muss noch der Windows Desktop Manager gestoppt werden. Dazu geht man einfach in den Taskmanager und killt DWM.EXE. Geht auch per Commandline. Falls es nicht klappt, hilft der Prozessexplorer von Sysinternals.

D3DCompiler_43.dll oder ähnliche Datei fehlt Fehlermeldung unter Windows 10 bei 3D-Anwendungen

25 Juni 2019

Bei einigen 3D-Anwendungen wird die Datei D3DCompiler_43.dll benötigt um 3D-Objekte für die Darstellung oder Berechnung umzurechnen. Genauer gesagt, die Datei ist der “Direct3D HLSL Compiler”. Leider gibt es einige Programme, welche die erforderlichen DirectX-Dateien nicht in ihrer Distribution enthalten. Eigentlich ist es die Aufgabe des Betriebssystem oder des passenden .Net Frameworks dafür zu sorgen. Fakt ist aber, dass in diesem Bezug viel Chaos herrscht.

Das Problem äußert sich beim starten betreffender Anwendungen z. B. über diese Fehlermeldung:

Error: DLL D3DCompiler_43.dll Das angegebene Modul wurde nicht gefunden Ausnahme von HResult0x8007007E

Das Problem lässt sich lösen (sogar auf einem aktuellen Windows 10 1903), wenn man die Datei aus diesem Link herunterladet und startet: https://www.microsoft.com/de-DE/download/details.aspx?id=35. Dadurch wird der “DirectX-Endbenutzer-Runtimes Web Installer” gestartet, welche die fehlenden Dateien nachrüstet.

Diese Methode sorgt dafür, dass im SYSTEM32-Verzeichnis einige D3DCompiler-Dateien hinzugefügt werden:

D3DCompiler_33.dll
D3DCompiler_34.dll
D3DCompiler_35.dll
D3DCompiler_36.dll
D3DCompiler_37.dll
D3DCompiler_38.dll
D3DCompiler_39.dll
D3DCompiler_40.dll
D3DCompiler_41.dll
D3DCompiler_42.dll
D3DCompiler_43.dll
D3DCompiler_47.dll

Windows 10 hat von Haus aus eigentlich nur die D3DCompiler_47.dll an Bord.

Hier noch eine Variante wo .Net Framework-Updates geblockt werden, betrifft allerdings nur Versionen vor Windows 10: https://support.microsoft.com/de-de/help/4020302/the-net-framework-4-7-installation-is-blocked-on-windows-7-windows-ser

Qnap virtuelle Rechner per Terminal mittels virtsh verwalten

22 Juni 2019

Bei QNAP NAS-Modellen mit einem Intel Prozessor kann man virtuelle Maschinen direkt auf dem NAS mittels KVM einrichten. Die Oberfläche der Virtualization Station ist schön aufgeräumt und einfach gehalten. Aber aus genau diesem Grund findet man nicht alle Punkte, die man eigentlich so braucht.

In der aktuellen QTS 4.4.1 Version ist libvirt 1.2.19 mit Hypervisor QEMU 2.3.1 enthalten. Die Frage ist aber wie kommt man an diese Informationen? Am einfachsten man meldet sich mittels SSH am NAS an und geht mittels Busybox und dem Befehl virsh auf die Suche. Virsh ist ein mächtiges Kommandozeilen-Tool bzw. Shell zur Verwaltung von virtuellen Maschinen. Blöd nur, dass auf anhieb virsh nicht aufrufbar ist. Man muss zunächst zwei Umgebungsvariablen definieren:

export LD_LIBRARY_PATH=/QVS/usr/lib:/QVS/usr/lib64/
export PATH=$PATH:/QVS/usr/bin/:/QVS/usr/sbin/

Danach steht virsh direkt zum Aufrufen bereit, z. B. so:

virsh version

Einfachste Methode einen virtuellen Mac hochzuziehen

15 Juni 2019

Benötigt wird ein aktueller Intel-Rechner, z. B. ein Intel NUC, darauf installiert man ein aktuelles Debian, in diesem nutzt man dann QEMU um einen virtuellen Mac hochzuziehen.

Dazu benötigt man die Skripte von https://github.com/foxlet/macOS-Simple-KVM. Es werden alle nötigen Downloads direkt über Apples Wiederherstellungskonsole durchgeführt. Ein Tutorial beschreibt wie man das ganze einrichtet: https://passthroughpo.st/new-and-improved-mac-os-tutorial-part-1-the-basics/ und wie man Verfeinerungen in Bezug auf Netzwerk, Grafikkarte und Sound vornehmen kann: https://passthroughpo.st/mac-os-vm-guide-part-2-gpu-passthrough-and-tweaks/.

Automatisch Bilder von Webseiten erstellen

1 Juni 2019

Manchmal kann es ganz nützlich sein, eine Webseite direkt als Bild speichern zu können. Chrome (ab Version 59 bzw. 60) bringt von Haus aus eine Möglichkeit mit, dies per Eingabeaufforderung zu machen.

Start chrome.exe –headless –screenshot="C:\temp\bild.png" https://www.bild.de –window-size=1024,1280

hier die passende Ausführung in Powershell:

Start-Process  chrome.exe -ArgumentList  "–headless", ‚–screenshot="C:\temp\bild.png"‘, "https://www.bild.de", "–window-size=1024,1280"

Beide Varianten führen dazu, dass im Verzeichnis C:\Temp die das Bild der Webseite in der Datei bild.png gespeichert wird.

Wer die Seite lieber als PDF-Datei speichern möchte, der verwendet diese Variante:

Start chrome.exe –headless –print-to-pdf="c:\temp\bild.pdf" https://www.bild.de –window-size=1024,1280

in Powershell also:

Start-Process  chrome.exe -ArgumentList  "–headless", ‚–print-to-pdf="c:\temp\bild.pdf"‘, "https://www.bild.de", "–window-size=1024,1280"

Weitere Infos zum Headless-Modus findet man hier: https://developers.google.com/web/updates/2017/04/headless-chrome.

COM-Schnittstelle bei Windows Remote Desktop oder Virtuellen Maschinen

24 Mai 2019

Wer eine physische COM-Schnittstelle auf einem anderen Rechner mittels Remote-Desktop verfügbar machen möchte, muss folgendes beachten.

Zuerst muss man im Remote Desktop die Optionen einblenden, um beim Register Lokale Ressourcen, unten bei “Lokale Geräte und Ressourcen”, die Weiter-Schaltfläche anklicken zu können. Dort aktiviert man nun den Eintrag Ports.
Alternativ kann man auch in der betreffenden RDP-Datei den Eintrag redirectcomports:i:0 auf 1 setzen und speichern.

Wer nun die Verbindung zum Remoterechner herstellt wird vielleicht gleich im Geräte-Manager nachschauen, ob die COM-Schnittstelle unter “Anschlüsse (COM & LPT)” auch auftaucht. Doch da herrscht gähnende Leere. Tja, der Geräte-Manager ignoriert den COM-Port großzügig.

Der Port ist aber trotzdem verfügbar und kann mittels Powershell-Eingabeaufforderung mit diesem Befehl aufgelistet werden:

[System.IO.Ports.SerialPort]::GetPortNames()

Gemeldet wird dann z. B. COM1.

Wenn man bei virtuellen Maschinen mehr machen möchte, muss man Named Pipes benutzen und kann so RS232-Hardware vom Host direkt einer virtuellen Maschine zur Verfügung stellen. Realisiert wird dies durch PipeToCOM: https://github.com/mcmlxxix/PipeToCom. Diese Lösung hat natürlich den Vorteil ohne Remote Verbindung auszukommen. Jetzt wird es aber wieder kompliziert, denn wenn man eine Generation 2 VM in einem Hyper-V hat, dann gibt es keine COM-Ports mehr. Man kann allerdings mittels Powershell und SET-VMComPort COM1 aktivieren und darüber den Pfad für die Pipe setzen.

Python unter Windows 10 Mai 2019 Update 1903 installieren

22 Mai 2019

Mit jedem Release öffnet sich Microsoft immer mehr der Open Source Welt. Neuestes Beispiel ist die nun supereinfache Installation von Python unter Windows 10 Mai 2019 Update (1903).

Gibt man Python in der Eingabeaufforderung oder bei Powershell ein, dann kommt nicht etwa diese erwartete Fehlermeldung:

C:\Users\Tester>python
Der Befehl "python" ist entweder falsch geschrieben oder
konnte nicht gefunden werden.

Statt dessen öffnet sich der Microsoft Store mit der Möglichkeit Python als App zu installieren.

Microsoft Windows [Version 10.0.18362.113]
(c) 2019 Microsoft Corporation. Alle Rechte vorbehalten.

C:\Users\Tester>python
C:\Users\Tester>

Man bekommt also keine Fehlermeldung mehr, sondern die Möglichkeit das fehlende Programm zu installieren.

Dabei handelt es sich um Python Version 3.7. Python 2.7 macht keinen Sinn denn Python 2.7 wird 2020 eh Geschichte sein: https://www.heise.de/developer/artikel/Die-Tage-sind-gezaehlt-End-of-Life-fuer-Python-2-4427023.html.

Man könnte nun den Errorlevel abragen, ob dieser gesetzt ist und in Batchdateien oder Skripten darauf reagieren. Wir nehmen dazu wie immer Powershell, damit kann man die betreffenden Werte einfacher abfragen:

PS C:\Users\Tester> $LASTEXITCODE
PS C:\Users\Tester> python
PS C:\Users\Tester> $LASTEXITCODE
9009
PS C:\Users\Tester>

Wir sehen also, dass der Errorlevel als 9009 zurückgegeben wird und keine Fehlermeldung erfolgt. Die Fehlermeldung müsste normalerweise lauten:

python : Die Benennung "python" wurde nicht als Name eines Cmdlet, einer Funktion, einer Skriptdatei oder eines
ausführbaren Programms erkannt. Überprüfen Sie die Schreibweise des Namens, oder ob der Pfad korrekt ist (sofern
enthalten), und wiederholen Sie den Vorgang.
In Zeile:1 Zeichen:1
+ python
+ ~~~~~
    + CategoryInfo          : ObjectNotFound: (python:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

Es gibt aber eine Besonderheit die es zu beachten gilt. Der Microsoft Store wird nur bei einer interaktiven Eingabe aufgemacht, sollte man die Abfrage nach dem Errorlevel nun Skripten wollen, dann kann man ewig warten. Aus diesem Grund hier ein kleines Powershell-Skript welches das Vorhandensein von Python prüft, gegebenenfalls den Storelink aufmacht und auf dessen Installation wartet:

$v=python –version
if ($v -eq $null) {
  start ‚ms-windows-store://pdp/?ProductId=9NJ46SX7X90P‘
};
do {
  $v=python –version
} until (($LASTEXITCODE -ne 9009) –or ($v -ne $null) )

An dieser Stelle kann man nun davon ausgehen, dass man Python auf dem Rechner hat. Zumindest für den aktuellen Benutzer, denn die Apps über den Store werden in der Regel pro Benutzer installiert. Dies verdeutlich sich auch bei der Suche nach den betreffenden Dateien. So sah es vor der Installation aus:

C:\Users\Tester>dir python.* /s
Volume in Laufwerk C: hat keine Bezeichnung.
Volumeseriennummer: 6247-3F6E

Verzeichnis von C:\Users\Tester\AppData\Local\Microsoft\WindowsApps

08.05.2019  00:16                 0 python.exe
               1 Datei(en),              0 Bytes

Verzeichnis von C:\Users\Tester\AppData\Local\Microsoft\WindowsApps\Microsoft.
DesktopAppInstaller_8wekyb3d8bbwe

08.05.2019  00:16                 0 python.exe
               1 Datei(en),              0 Bytes

Es gibt also eine Python.exe mit 0 Bytes, wenn man nach Python3.exe sucht wird man ebenfalls fündig.

Nach der Installation aus dem App Store gesellt sich ein weiteres Verzeichnis hinzu:

C:\Users\Tester\AppData\Local\Microsoft\WindowsApps\Python
SoftwareFoundation.Python.3.7_qbz5n2kfra8p0

In diesem Verzeichnis befinden sich nun weitere 0 Byte EXE-Dateien:

22.05.2019  07:48    <DIR>          .
22.05.2019  07:48    <DIR>          ..
22.05.2019  07:48                 0 idle.exe
22.05.2019  07:48                 0 idle3.7.exe
22.05.2019  07:48                 0 idle3.exe
22.05.2019  07:48                 0 pip.exe
22.05.2019  07:48                 0 pip3.7.exe
22.05.2019  07:48                 0 pip3.exe
22.05.2019  07:48                 0 python.exe
22.05.2019  07:48                 0 python3.7.exe
22.05.2019  07:48                 0 python3.exe
22.05.2019  07:48                 0 pythonw.exe
22.05.2019  07:48                 0 pythonw3.7.exe
22.05.2019  07:48                 0 pythonw3.exe

Man bekommt also durch die Installation des Python Pakets alle relevanten Python-Zusatzprogramme frei Haus geliefert.

Neben dem paketspezifischen Verzeichnis finden oben aufgeführte Pythonprogramme auch Einzug in das Verzeichnis C:\Users\Tester\AppData\Local\Microsoft\WindowsApps. Der Hintergrund dürfte sein, dass sich C:\Users\Tester\AppData\Local\Microsoft\WindowsApps bei den Umgebungsvariablen für die automatische Suche nach Programm also PATH aufgeführt wird. D. h. durch diese Vorgehensweise erreicht man, dass das Programm automatisch gestartet werden kann, egal wo man sich befindet. Gesagt getan:

C:\>python
Python 3.7.3 (tags/v3.7.3:ef4ec6ed12, Mar 25 2019, 22:05:12) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> quit()

Klappt also tatsächlich. Und wie verhält es sich mit anderen Programmen?

C:\>pip list
You are using pip version 19.0.3, however version 19.1.1 is available.
You should consider upgrading via the ‚python -m pip install –upgrade pip‘ command.

Klappt also auch, wobei, wenn man ein aktuelles Paket bezogen hat muss man nochmal Hand anlegen um PIP auf den aktuellen Stand zu bekommen? Tja ist leider so. Auch bei TAR, SSH und CURL geht Microsoft äußert konservativ vor und langt einmal hinzugefügte Programme nicht mehr an. Ob dies bei Python auch zutrifft werden wir sehen.

Aber die spannende Frage ist, kann ich pip trotzdem updaten?

C:\>python -m pip install –upgrade pip
Collecting pip
  Downloading https://files.pythonhosted.org/packages/5c/e0/be401c003291b
56efc55aeba6a80ab790d3d4cece2778288d65323009420/pip-19.1.1-py2.py3-none-any.whl
(1.4MB)
    100% |████████████████████████████████| 1.4MB 468kB/s
Installing collected packages: pip
  Found existing installation: pip 19.0.3
    Uninstalling pip-19.0.3:
Could not install packages due to an EnvironmentError: [WinError 5] Zugriff verweigert: ‚c:\\program files\\windowsapps\\pythonsoftwarefoundation.python.3.7_3.7.
1008.0_x64__qbz5n2kfra8p0\\lib\\site-packages\\pip-19.0.3.dist-info\\entry_points.txt‘
Consider using the `–user` option or check the permissions.

You are using pip version 19.0.3, however version 19.1.1 is available.
You should consider upgrading via the ‚python -m pip install –upgrade pip‘ command.

Also der erste Versuch ging schief aber ist auch nachvollziehbar, denn das Python-Paket würde dem Benutzer zugeordnet, mal sehen, ob es mit dem passenden Parameter klappt:

C:\>python -m pip install –upgrade pip –user
Collecting pip
  Using cached https://files.pythonhosted.org/packages/5c/e0/be401c003291b
56efc55aeba6a80ab790d3d4cece2778288d65323009420/pip-19.1.1-py2.py3-none-any.whl

Installing collected packages: pip
Successfully installed pip-19.1.1
You are using pip version 19.0.3, however version 19.1.1 is available.
You should consider upgrading via the ‚python -m pip install –upgrade pip‘ command.

Das sieht ja schon mal nicht schlecht aus:

C:\>pip list
Package Version
——- ——-
pip     19.1.1

Also man hat nun eine recht schnelle, einfache Methode Python auf seinen Rechner zu bekommen.

Soweit so gut! Allerdings, wie so oft gibt es einen Pferdefuß und der wird wahrscheinlich erst mit Python 3.8 oder 3.9 aus der Welt geschafft. Denn möchte man wirklich produktiv mit Python arbeiten, dann sollten solche Dinge nicht passieren:

C:>pip install flask

Installing collected packages: Werkzeug, MarkupSafe, Jinja2, click, itsdangerous, flask
  WARNING: The script flask.exe is installed in ‚C:\Users\Tester\AppData\Local\Packages\PythonSoftwareFoundation.
Python.3.7_qbz5n2kfra8p0\LocalCache\local-packages\Python37\Scripts‘ which is not on PATH.
  Consider adding this directory to PATH or, if you prefer to suppress this warning, use –no-warn-script-location.
Successfully installed Jinja2-2.10.1 MarkupSafe-1.1.1 Werkzeug-0.15.4 click-7.0 flask-1.0.3 itsdangerous-1.1.0

D. h. ein einfacher Aufruf von “flask run” ist später nicht möglich. Als Lösung gibt es zwei Möglichkeiten, entweder man ruft

C:\Users\Tester\AppData\Local\Packages\PythonSoftwareFoundation.
Python.3.7_qbz5n2kfra8p0\LocalCache\local-packages\Python37\Scripts\flask.exe run

direkt auf oder man fügt den Pfad der Umgebungsvariablen PATH manuell hinzu:

set path=%path%;C:\Users\Tester\AppData\Local\Packages\PythonSoftware
Foundation.Python.3.7_qbz5n2kfra8p0\LocalCache\local-packages\Python37\Scripts

Hier der Link zum Aufhängerartikel: https://devblogs.microsoft.com/python/python-in-the-windows-10-may-2019-update/

Möglich Probleme beim Erkennen ob Python installiert ist: https://github.com/Microsoft/PTVS/issues/5189, die Lösung ist das Beachten der PATH-Umgebungsvariablen.

Noch der Link zum Store: ms-windows-store://pdp/?ProductId=9NJ46SX7X90P sowie die Publisher-ID: qbz5n2kfra8p0

Thunderbird als Standard-E-Mail-Programm

14 Mai 2019

Bei einem aktuellen Thunderbird 60.6.1 unter Windows 7 wurde bei jedem Start nachgefragt, ob Thunderbird sich als Standard-E-Mail-Programm registrieren soll. Unabhängig was man auswählte, er war sowieso das Standard-E-Mailprogramm. Ein Aufruf aus einer anderen Anwendung funktionierte per SimpleMAPI also zuverlässig. Blöd war halt die Meldung. Aber gut. Die einfachste Lösung war einfach in den Thunderbirdeinstellungen das Häkchen für die Überprüfung wegzunehmen. Alles andere funktionierte trotzdem.

Links zum Thema:

https://bugzilla.mozilla.org/show_bug.cgi?id=1509918
https://support.mozilla.org/en-US/kb/make-thunderbird-default-mail-client
http://kb.mozillazine.org/Default_mail_client#Windows

VirtualBox auf Mac installieren und Fehlermeldungen wegen Kernel Extensions

10 Mai 2019

Auf einem aktuellen High Sierra 10.13.6 Mac OS System sollte VirtualBox 6.0.6 installiert werden. Bereits bei der Installation von VirtualBox gab es eine Fehlermeldung, mit dem Hinweis in den Systemeinstellungen unter Sicherheit das Laden der Oracle America Treiber zuzulassen. Nur leider funktionierte die Vorgehensweise nicht. Nach mehreren Versuchen mit De- und jeweils Neuinstallation von VirtualBox lief es immer noch nicht. Man konnte zwar VirtualBox aufrufen allerdings beim Start einer neu eingerichteten VM bekam man die Fehlermeldung “Systemerweiterung wurde blockiert” rc=-1908.

Nach einigem Suchen wurde ich auf diesen Eintrag aufmerksam: https://forums.virtualbox.org/viewtopic.php?f=8&t=84092. Da wird das Problem mit möglichen Lösungswegen beschrieben. Am Ende hat aber erst dieser Artikel die Lösung gebracht: https://ilgthegeek.wordpress.com/2018/01/27/macos-install-oracle-virtualbox-on-10-13/. Apple Dokument was abläuft: https://developer.apple.com/library/archive/technotes/tn2459/_index.html.

Kurz zusammengefasst:

  1. Mac herunterfahren
  2. Mit Command-R die Wiederherstellungskonsole aufrufen
  3. Im Dienstprogrammemenü das Terminal auswählen
  4. “spctl kext-consent add VB5E2TV963” ausführen
  5. Mac neu starten

Wie kommt man an das VB5E2TV963, welches die Entwicker-ID-Signatur darstellt? Bei der Installation von VirtualBox gibt es im Installationsassistenten oben rechts ein Schlosssymbol, klickt man dieses an, erhält man die nötige Info.