Möchte man nun ein paar ältere physikalische Systeme mit einem Windows-XP (OEM) virtualisieren hat es mich schon den ein oder anderen Nerv gekostet…
Problem: Die Aktivierung. Mir ist es noch nicht gelungen ein OEM-Windows innerhalb einer VM erneut zu aktivieren.
Dennoch ist es machbar ohne eine komplette Neuinstallation das System zum Rennen zu bekommen.
Lösung: Windows XP (VL) Version also .iso in die VM-Mounten und davon booten.
Zusätzlich die Vmware SCSI Treiber per (virtuelles) Floppy Laufwerk einbinden. (Siehe: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006956)
Von CD-Booten, direkt zu begin F6 drücken um den Vmware SCSI Treiber zu laden. Dann Z drücken und diesen auswählen.
Mit Enter geht es dann ganz normal im Menü weiter….
Nach der Erkennung der Windows-Installationen nun das Laufwerk auswählen und mit R eine erneute Installation durchführen.
Dies funktioniert wie eine Reperatur-Installation und ersetzt nur Systemdateien. Danach ist euer System so wie vorher inkl. aller Programme & Dateien. Lediglich die Version hat sich von OEM auf VL geändert.
Gruß
Constey
Monat: Februar 2012
Vmware Update Manager (Fehler nach SSL-Update)
Nachdem ich heute mal wieder ein paar SSL-Zertifikate aktualisiert hatte, wollte der Update Manager nicht mehr so recht.
Er spuckte folgende Fehlermeldung aus:
update manager vim.fault.invalidlogin
Im Log (C:\ProgramData\VMware\VMware Update Manager\Logs) machte das sich so deutlich:
[05036 warning 'Libs'] SSLVerifyIsEnabled: failed to read registry value. Falling back to default behavior: verification off. LastError = -2146885628
Mh komisch, google hat auch nicht wirklich geholfen – die Registry Einträge die angeblich unter:
HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware Infrastructure\Update Manager liegen sollen existieren nicht….. (Scheint, dass ab Version 5 diese nicht mehr existieren? Verbessert mich ggf.)
Also kurzerhand den Update Manager neu installiert, und dabei bin ich auch direkt auf den Fehler des Problems gestoßen.
Das Zertifikat war logischerweise auf den FQDN ausgestellt. Beim Setup des UPDMGR kann man auswählen wie sich dieser identifizieren soll: a) Durch die IP oder b) durch den FQDN….
Hier hatte ich bei der Installation die IP angegeben, weshalb das Zertifikat logischerweise nicht gültig war.
Plesk neustarten (Ubuntu)
Die Befehle habe ich letztens schon mal gesucht, hier mal aufgehoben:
/etc/init.d/xinetd stop
/etc/init.d/psa stop
/etc/init.d/xinetd start
/etc/init.d/psa start