Archive for the ‘Problemlöser’ Category

Batchdatei als Administrator ausführen funktioniert nicht und was dies mit dem &-Zeichen im Benutzernamen zu tun hat

27 Februar 2015

Windows hat so seine Eigenheiten. Aktuell bin ich mal wieder über eine solche gestolpert, wo man sich fragt: Was geht da ab? Kurz zur Geschichte, ein Kunde hatte Probleme mit dem Adobe Reader Update: https://newyear2006.wordpress.com/2014/07/03/adobe-reader-installation-meldet-umgltiges-laufwerk-und-bricht-die-installation-ab/. Meine Antwort darauf war, eine Batchdatei anzulegen und diese mit Adminrechten auszuführen. Nur funktionierte die Variante nicht. Nach einigem hin und her wurde es dann klar, dass keinerlei Batchdatei des Kunden, welche über den Windows Explorer mit rechter Maustaste und “Als Administrator ausführen” angefordert wurde, klappte.

Dazu wurde eine einfach Test.BAT-Batchdatei im Benutzer-Verzeichnis C:\USERS\M&M geschrieben:

@ECHO Hallo
PAUSE

Also nichts weltbewegendes. Führt man diese Batchdatei in der Commandline aus, funktioniert alles wie gewünscht, ob mit oder ohne Adminrechte. Führt man die Batchdatei jedoch im Windows Explorer aus, funktioniert nur die Variante ohne Adminrechte. Bei der Variante mit den Adminrechten wird zwar nach dem Zulassen von CONSENT.EXE mit dem bekannten UAC-Dialog gefragt aber es wird effektiv nichts ausgeführt.

Bei der näheren Analyse mittels Procmon.EXE fiel dann folgendes auf, der Punkt  wo der CMD.EXE-Prozess erzeugt wird, wird die richtige Commandline übergeben:

Parent PID: 1996, Command line: "C:\Windows\System32\cmd.exe" /C "C:\Users\M&M\Test.bat" , …

Einige Zeilen später, wo die .BAT-Datei auf Vorhandensein geprüft wird, findet sich auf einmal diese Zeile:

QueryDirectory  C:\Users\M.*

Wo doch der Benutzer M&M heißt und nicht M.*!!

Und genau da entsteht nun das Problem, so dass wieder einige Zeilen später, der Versuch die Batchdatei zu lesen ins Leere läuft:

CreateFile C:\Windows\system32\M\Test.bat PATH NOT FOUND

Echt interessant! D. h. hier wird der Pfadname quasi in zwei Teile aufgelöst, einmal in C:\Users\M und einmal in M\Test.Bat, was eigentlich C:\Users\M&M\Test.Bat lauten sollte.

Dies bedeutet, dass keine Batchdatei des Benutzers M&M als Administrator ausgeführt werden kann! Sobald man aber hergeht und z. B. ein Verzeichnis C:\TestDir anlegt, dort die Test.BAT-Datei ablegt und diese als Administrator ausführt klappt wieder alles.

Was lernen wir daraus: Verwende unter Windows niemals einen Benutzernamen mit einem &-Zeichen!

Dieses Phänomen tritt von Windows 7 bis Windows 10 auf, wahrscheinlich sind aber generell auch ältere Versionen davon betroffen. Man könnte es zwar durch Escapen des &-Zeichen lösen aber im Punkt bei “Ausführen als Administrator” sind einem die Hände gebunden. Hier wird das Escapen beschrieben: http://www.robvanderwoude.com/escapechars.php.

Probleme beim Drucker umbenennen unter Windows

22 Januar 2015

Bei einem Kunden mit Windows 8.1 gab es beim Umbenennen eines Druckers folgende Meldung:

[Window Title]
Druckereigenschaften

[Main Instruction]
Die Druckereinstellungen konnten nicht gespeichert werden.

Es ist bereits ein Drucker oder eine Druckerfreigabe mit diesem Namen vorhanden. Verwenden Sie einen anderen Namen für den Drucker.

[OK]

Wenn man aber bei den Druckern geschaut hat, war nix von einem Drucker mit diesem Namen zu sehen. Es war allerdings davor ein Drucker mit diesem Namen da, denn dieser wurde zuvor gelöscht. Blöd war nur, dass in dessen Druckerwarteschlange noch ein kaputter Druckvorgang war und somit scheinbar der Druckvorgang nicht abgeschlossen werden konnte. Wie ich auf diese gewagte These komme?

Na ganz einfach so: Mittels dieses Artikels https://newyear2006.wordpress.com/2014/07/09/gruppierung-bei-windows-druckern-aufheben/ über diesen Punkt

shell:::{2227A280-3AEA-1069-A2DE-08002B30309D}

die Ansicht geändert, dass alle Druckertreiber einzeln dargestellt wurden. Dabei war aber noch nichts vom Ghost-Druckertreiber zu sehen. Nun aber die versteckten Dateien eingeblendet. Also ALT-Taste gedrückt, damit das Menü “Datei Bearbeiten Ansicht Extras” erscheint und dort bei Extras die Ordneroptionen aufgerufen. Hier wiederum das Register Ansicht ausgewählt und den Punkt “Ausgeblendete Dateien, Ordner und Laufwerke anzeigen” aktiviert. Schwups war der Ghostdruckertreiber zu sehen und konnte nun entfernt werden. Denkste!

Beim Versuch den Druckertreiber zu löschen erschien diese Fehlermeldung:

[Window Title]
Druckereigenschaften

[Main Instruction]
Die Druckereigenschaften können nicht angezeigt werden.

Überprüfen Sie den Druckernamen, und stellen Sie sicher, dass der Drucker mit dem Netzwerk verbunden ist.

[OK]

Was jetzt? Logischerweise Neustart des Rechners oder vielleicht nur Neustart der Druckerwarteschlange, dann ist der Ghost-Druckertreiber weg und das Umbenennen des ursprünglichen Druckertreibers ist möglich.

Wenn sich mal wieder die BIOS Einstellungen nicht speichern lassen

30 Dezember 2014

Nur für künftige Aktionen, damit ich das nächste Mal nicht unnötig Batterien verbrenne. Wenn das BIOS die Meldung:

CMOS Settings Wrong
CMOS Date/Time Not Set
Press F1 to run SETUP

erscheint, so sollte man die Motherboard-Batterie austauschen, wenn es danach aber immer noch nicht klappt, hilft ein CMOS-Reset! Scheinbar war es dem NVRAM davor nicht möglich die Daten ordentlich zu speichern, obwohl beim Verlassen des BIOS keine negative Meldung angezeigt wurde, dass die Daten nicht gespeichert werden konnten.

Mit den BIOS Einstellungen kann man viel Spaß haben: https://newyear2006.wordpress.com/2012/11/27/rechner-geht-einfach-nach-anzeige-von-starting-windows-aus/

Erweitertes Bootmenü bei Start von Windowsrechnern anzeigen

28 Dezember 2014

Bei neueren Rechnern und optimalen Bios bzw. UEFI-Einstellungen ist es manchmal recht schwer bzw. unmöglich beim Starten des Rechners das erweiterte Bootmenü mittels F8 zu aktivieren.

Wenn der Rechner bereits hochgefahren ist, kann man sich aber behelfen, indem man einen speziellen Parameter mittels BCDEDIT.EXE setzt. Dadurch wird das erweiterte Bootmenü immer angezeigt, bis es wieder explizit abgeschaltet wird:

bcdedit /set {bootmgr} displaybootmenu yes

Zum Ausschalten verwendet man dann später wieder:

bcdedit /set {bootmgr} displaybootmenu no

Nun kann man zwischen den Bootvorgängen in aller Ruhe das passende Auswählen. Hier noch eine bebilderte Anleitung: http://support2.microsoft.com/kb/2809468/en.

Die Variante klappt übrigens auch bei Windows 7. Besonders wertvoll ist es auch bei Verwendung von virtuellen Maschinen, wo man oft noch nicht den passenden Tastaturfokus hat.

Hier die aktuellste Beschreibung von BCDEDIT /set und die möglichen Parameter: http://msdn.microsoft.com/en-us/library/windows/hardware/ff542202(v=vs.85).aspx.

Eine kurze Erklärung zu {bootmgr} erhält man über:

bcdedit /? ID

Hier noch der Link zur offiziellen BCDEDIT-Befehlszeilenreferenz: http://technet.microsoft.com/en-us/library/cc731662.aspx. Leider wie so oft ziemlich unbrauchbar.

Unter Windows 8 und Server 2012 bzw. dessen Nachfolger kann man mittels

bcdedit /set {current} onetimeadvancedoptions on 

das Menü auch nur einmalig für den nächsten Bootvorgang aktivieren.

Wenn Maus und Tastatur an einem Windows Rechner nicht mehr reagieren

14 Dezember 2014

Ein Kunde hatte ein Problem mit seinem Windows 7 Rechner. Das interessante daran war, dass Tastatur und Maus nicht mehr funktionierten, wenn Windows hochgefahren war. Er hatte die Passworteingabe beim Hochfahren deaktiviert, so dass der Rechner immer bis zum Desktop bootete. So konnte man schon beobachten, dass alles sauber geladen wurde nur am Ende war keinerlei Maus und Tastatureingabe möglich. Der Mauszeiger konnte nicht einmal bewegt werden.

Der Rechner konnte problemlos durch drücken des Ausschaltknopf sauber heruntergefahren werden. Die Maus und Tastatur konnten an anderen Ports eingesteckt werden und es erschien die Meldung, dass Treiber installiert werden und dass das Gerät nun benutzt werden kann. Jedoch war dies nie möglich.

Bei weiteren Versuchen stellte es sich heraus, dass auch eine PS/2-Tastatur nicht funktionierte. Ein generelles Hardwareproblem konnte aber ausgeschlossen werden, da Maus und Tastatur problemlos unter WindowsPE oder im BIOS funktionierten. Ein weiterer Aspekt war, dass Multimediatasten wie E-Mail, Calculator usw. einer Multimediatastatur auch funktionierten.

Ein Starten des Rechners im abgesicherten Modus brachte leider auch nichts.

Also alles neu installieren? Nein.

Zwei Dinge helfen:
Die Verwendung der erweiterten Startoptionen und Aufruf von Computer reparieren. http://windows.microsoft.com/de-de/windows/advanced-startup-options-including-safe-mode#1TC=windows-7. Hier kann man die Systemwiederherstellung aufrufen, damit ein früherer Zustand aktiviert werden kann, der funktionierte – soweit vorhanden.

Die zweite Lösung wäre das entfernen von Kaspersky Maus und Tastaturtreibern. Dazu musste man nur in der Registrierung unter Upperfilters nach klkbdflt und klmouflt suchen und diese entfernen. Detailliert hier beschrieben: http://support.kaspersky.com/general/products/10663#block7. Diese Lösung funktionierte, weil der Kunde davor versucht hatte Kaspersky zu installieren und dabei scheinbar etwas schiefgegangen war. Hat man die Kaspersky-Treiber entfernt, stehen nur noch kbdclass und mouclass in der Registrierung. Übrigens muss man nicht zwingend die Kaspersky Rescue Disk verwenden, sondern kann auch mit einem WinPE oder Windows Bootmedium booten und die Registrierungseinträge darüber ändern.

Fehlermeldung von Windows Fax und Scan wegen fehlendem Faxkonto bei Druck über Faxserver

26 November 2014

Bekommt man an einem Windows Client beim Druck über einen Faxserver folgende Fehlermeldung an den Latz geknallt:

—————————

Windows-Fax und -Scan

—————————

Sie müssen erst ein Faxkonto erstellen, um Faxe mit dem ausgewählten Drucker senden zu können. Suchen Sie nach "Computer zum Senden und Empfangen von Faxen einrichten" in Hilfe und Support", um weitere Informationen zu erhalten.

—————————

OK  

—————————

 

So kann man sich behelfen, indem man zunächst bei Windows Fax und Scan im Menü unter Extras->Faxkonten den bestehenden Eintrag entfernt. Anschließend das Programm zumachen und noch bei Drucker und Faxgeräten den betreffenden Druckertreiber, der fürs Faxen über den Server eingerichtet war, über “Gerät entfernen” loswerden.

 

Nun wieder über Windows Fax und Scan über das Extra-Menü Faxkonten aufrufen, Hinzufügen anklicken und “Verbindung mit einem Faxserver im Netzwerk herstellen” auswählen. Dann den Servernamen eingeben usw. Danach sollte es ohne obige Fehlermeldung klappen.

SBS2003 Server machte nach Internetproviderumstellung Probleme mit DNS-Namensauflösungsanfragen

2 August 2014

Nachdem bei einem Kunden der Internetprovider gewechselt wurde, kam es zu massiven Problemen bei den Clientrechnern. Bei Zugriffen, vor allem auf kompliziertere oder mittels HTTPS verschlüsselten Seiten wie bahn.de, ebay.de, mobile.de usw. gab es teilweise ewige Verzögerungen und am Ende sogar Timeouts, so dass die Seiten nicht korrekt dargestellt wurden.

Der SBS hat bekanntlich noch zwei Netzwerkkarten. Davon wird eine für den lokalen Netzwerkverkehr verwendet und die zweite ist das Gateway nach außen. Der neue Internetprovider hatte ein Gerät installiert, wo ein anderer IP-Adressbereich hinterlegt war. Demzufolge musste beim SBS in den Netzwerkkarteneinstellungen die neue IP-Adresse für die Kommunikation mit dem externen Router hinterlegt werden. Damit fingen die Probleme an.

Am SBS-Server war ein gewohnt schneller Zugriff auf alle Seiten möglich. Allerdings war auf den Clientrechnern eben obige Aussetzer zu beobachten. Auch ein Test mit Googles-DNS-Server-Adresse 8.8.8.8 auf dem Client brachte die übliche Geschwindigkeit. Was tun? Zunächst mittels Ping und NSlookUp versucht der Sache auf die schliche zu kommen. Nach vielen Tests und einigem hin- und her hatte es sich herausgestellt, dass am SBS noch ein DNS-Forward eingestellt werden sollte.

Mittels

dnscmd /info

kann man verschiedene Infos zum DNS abfragen:


  Aging Configuration:
        ScavengingInterval           = 0
        DefaultAgingState            = 0
        DefaultRefreshInterval       = 168
        DefaultNoRefreshInterval     = 168
  ServerAddresses:
Addr Count = 2
                Addr[0] => 192.168.60.1
                Addr[1] => 192.168.10.2
  ListenAddresses:
Addr Count = 1
                Addr[0] => 192.168.60.1
  Forwarders:
Addr Count = 1
                Addr[0] => 192.168.1.1
        forward timeout  = 5
        slave            = 0
Command completed successfully.

Hier sieht man sehr schön, dass zwar die IP-Adresse der zweiten Netzwerkkarte Addr[1] passend zum neuen Router gesetzt wurde aber die Adresse Addr[0] des Forwarders noch auf den alten IP-Bereich eingestellt ist. Wichtig dabei ist nun auch der Timeout=5, was 5 Sekunden entspricht.

Wenn man es weiß, ist nun die Sache schnell erledigt:

dnscmd . /ResetForwarders 192.168.10.1 /TimeOut 5 /Slave

Damit wurde Addr[0] des Forwarders auf die korrekte Adresse.

Interessant an der Geschichte ist vor allem, dass Seiten mit Subdomains massive Probleme bekamen. Ist irgendwie logisch denn für jede Subdomainanfrage kam der Timeout mit 5 Sekunden zu tragen.

So führte ein einfacher Aufruf von ebay.de und das klicken auf Einloggen zu zig Domainabfragen, hier einige davon:

www.ebay.de
secureir.ebaystatic.com
ir.ebaystatic.com
securepics.ebaystatic.com
srx.de.ebayrtm.com
cors.api.paypal.com
thumbs2.ebaystatic.com
thumbs3.ebaystatic.com
thumbs4.ebaystatic.com
p.ebaystatic.com
www.paypalobjects.com
b.stats.ebay.com
314797b0qxk.stats.ebay.com
signin.ebay.de
phx.stats.paypal.com
src.ebay-us.com
sofe.ebay.de
rover.ebay.de
rtm.ebaystatic.com
pics.ebaystatic.com
secureir.ebaystatic.com
pages.ebay.de
i.ebayimg.com

Was für eine Auflistung! Über 20 DNS-Abfragen werden benötigt um die Start- und dann die Loginseite aufzurufen. Pech, wenn man sowas unterwegs in einem Edge- oder noch besser GPRS-Handynetz macht, wo jede Anfrage ca. 200 Millisekunden und mehr dauert…

Ereignisanzeige Protokollnamen für Powershell übersetzen

28 Juli 2014

Durch den vorhergehenden Blogeintrag https://newyear2006.wordpress.com/2014/07/28/windows-store-konnte-die-computerlizenzen-nicht-synchronisieren-ergebniscode-0x80070490/ bin ich wieder mal über ein Problem gestolpert, dem ich schon häufiger begegnet bin, deshalb dieses Mal fürs löchrige Gehirn etwas ausführlicher.

Es ging um ein Problem, welches in der Ereignisanzeige mit dem Protokollnamen "Microsoft-Windows-Store-Licensing/Admin" erfasst ist. Möchte man nun diesen Event per Powershell ermitteln, passiert folgendes:

PS>Get-WinEvent -LogName Microsoft-Windows-Store-Licensing/Admin
Get-WinEvent : Auf dem Computer "localhost" wurde kein Ereignisprotokoll gefunden, das
"Microsoft-Windows-Store-Licensing/Admin" entspricht.
In Zeile:1 Zeichen:1
+ Get-WinEvent -LogName Microsoft-Windows-Store-Licensing/Admin
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (Microsoft-Windows-Store-Licensing/Admin:String) [Get-WinEvent], Excepti
   on
    + FullyQualifiedErrorId : NoMatchingLogsFound,Microsoft.PowerShell.Commands.GetWinEventCommand

Gut, vielleicht kann man es auch mit Anführungsstrichen probieren? Leider bringt dies auch nichts. Microsoft-Windows-Store-Licensing steht jetzt auch nicht im Verdacht in der falschen Sprache angegeben zu sein oder?

Nächster Versuch, man könnte ja alles mit Namen *Licen* auflisten lassen:

PS> Get-WinEvent -ListProvider *licen*

Name     : Microsoft-Windows-Kernel-LicensingSqm
LogLinks : {}
Opcodes  : {}
Tasks    : {}

Name     : Microsoft-WS-Licensing
LogLinks : {Microsoft-WS-Licensing/Diagnostic, Microsoft-WS-Licensing/Debug, Microsoft-WS-Licensing/Admin}
Opcodes  : {win:Start, win:Stop}
Tasks    : {Service_Init, Service_Stop, Service_Init_LicenseStore, Service_Init_HwidCollect…}

Name     : Microsoft-Windows-Kernel-Licensing-StartServiceTrigger
LogLinks : {}
Opcodes  : {}
Tasks    : {}

Sieht auch nicht sehr ergiebig aus. Wobei Microsoft-WS-Licensing geht ja in die Richtung, wenn WS für Windows Store stehen würde:

PS > (Get-WinEvent -ListProvider *licen*).Loglinks

LogName                          IsImported DisplayNam
——-                           ———- ———
Microsoft-WS-Licensing/Diagnostic      False
Microsoft-WS-Licensing/Debug           False
Microsoft-WS-Licensing/Admin           False

OK, es ist kein Displayname eingetragen, also wird es das auch nicht sein. Oder vielleicht doch? Ich bin ja immer noch der Meinung, WS steht für Windows Store. Da Powershell teilweise immer etwas Daten vor einem verheimlicht, lasse ich mir alle Daten zu einem Objekt ausgeben:

Get-WinEvent -ListProvider *licen*| fl *

Siehe da, hier gibt es auch ein Displayname Feld. Also mal dieses ausgeben lassen:

PS> (Get-WinEvent -ListProvider *licen*).displayname
Microsoft-Windows-Store-Licensing
Microsoft-Windows-LicensingStartServiceTrigger

Ah da isses ja. Der gesuchte Microsoft-Windows-Store-Licensing-Protokollname. Deutlicher wird es damit:

PS C:\Windows\system32> (Get-WinEvent -ListProvider *licen*)| select displayname, providername| fl

DisplayName  :
ProviderName : Microsoft-Windows-Kernel-LicensingSqm

DisplayName  : Microsoft-Windows-Store-Licensing
ProviderName : Microsoft-WS-Licensing

DisplayName  : Microsoft-Windows-LicensingStartServiceTrigger
ProviderName : Microsoft-Windows-Kernel-Licensing-StartServiceTrigger

Es geht halt nichts über eine ordentliche Übersetzung! Übrigens wäre es auch noch einfacher gegangen. Einmal über die GUI-Methode, indem man beim betreffenden Protokolleintrag sich die Details anzeigen lässt und dann System erweitert. Dort taucht dann unter Provider ebenso wieder “Microsoft-WS-Licensing” auf.

Man kann nun also mittels

Get-WinEvent -LogName Microsoft-WS-Licensing/Admin -MaxEvents 10

eine schöne Auflistung der Fehler erhalten.

Windows Store konnte die Computerlizenzen nicht synchronisieren. Ergebniscode: 0x80070490

28 Juli 2014

Weil es so schön ist und auch diese Meldung einem regelmäßig in den Eventlogs der Windows 8.1-Rechner entgegenfliegt:

Windows Store konnte die Computerlizenzen nicht synchronisieren. Ergebniscode: 0x80070490

Eingeführt mit dem Update auf Windows 8.1 erscheint diese Meldung jeden Tag einmal. Die Ereginis-ID lautet 512 und die Quelle ist Store-Licensing.

Klickt man den Onlinehilfelink an, erscheint:

image

Man beachte 9871 von 39506 Leute fanden diese Seite gut!

Microsoft hat im Zuge der Nokiaübernahme gerade 18000 Leute entlassen, davon sind auch mehrere tausend Microsoftmitarbeiter betroffen, hier einer davon: https://www.youtube.com/watch?v=lRV6PXB6QLk. Der Mann im Video stellt sich die berechtige Frage, wie man Windows am Laufen halten möchte? Die letzten Jahre mangelt es bereits an Dokumentation und vor allem an Supportdokumenten und dann hauen die auch noch zig tausend Leute raus. Die hätten besser die Leute behalten und zu 12 Monaten Zwangsdokumentation schreiben und Bugfixing verdonnern sollen.

Aber zurück zum Thema. Über diesen Thread bin ich an den passenden Eintrag gekommen: http://www.eightforums.com/general-support/50300-windows-store-failed-sync-machine-licenses-0x80070490.html. Wie so oft gibt es ja keinen offiziellen Knowledge Base Eintrag dazu. Wozu fehlende Dokumentation und unnütze Fehler  führen können, zeigt sich an diesem Thread: http://answers.microsoft.com/en-us/windows/forum/windows8_1-windows_store/w81-update-1-windows-store-failed-to-sync-machine/2ea6a4b8-c50c-444f-a4ef-f7ee7705f1ae.

Also nun mittels Powershell mal wieder rumgebastelt und die These überprüft. Wenn man diesen Befehl eingibt:

Get-ScheduledTask WSRefreshBannedAppsListTask | Start-ScheduledTask

Dann wird der betreffende Task erneut gestartet. In diesem Fall wird wieder der Eventeintrag generiert, diesen kann man nun mittels

Get-WinEvent -LogName "Microsoft-WS-Licensing/Admin" -MaxEvents 1| select id,timecreated,message | fl

abfragen und erhält:

Id          : 512
TimeCreated : 28.07.2014 16:33:36
Message     : Windows Store konnte die Computerlizenzen nicht synchronisieren. Ergebniscode: 0x80070490

Um also die nervige Protokollierung der Fehlereinträge aus den Eventlogs weg zu bekommen, ruft man

Get-ScheduledTask WSRefreshBannedAppsListTask | Disable-ScheduledTask

auf. Damit wird der Dienst deaktiviert.

Da leider keine Dokumentation verfügbar ist, was die Aufgabe des Tasks genau ist, ist die Frage, ob man sich durch das Deaktivieren irgendwelche Negativeffekte einhandelt. Die Zeit wird es zeigen…

Hyper-V-VMMS Ereignisanzeige Fehler 19510 Problem mit Installationsdatenträger für die Integrationsdienste und Fehler 0x80070020

28 Juli 2014

Wer einen Hyper-V Server am Laufen hat, dem könnte diese wie immer vielsagende Fehlermeldung über den Weg laufen:


Das Image des Installationsdatenträgers für die Integrationsdienste konnte nicht aktualisiert werden: Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird. (0x80070020).

Alles klar? Ich klicke auf Onlinehilfe und bekomme:

—————————
Ereignisanzeige
—————————
Die Onlinehilfe des Ereignisprotokolls kann nicht angezeigt werden, da der Standardbrowser nicht gestartet werden konnte.Klasse nicht registriert
—————————
OK  
—————————

Wird halt immer besser! Saftladen.

Powershell angeworfen und dieses angeschaut, man hat ja einen Riecher:

(get-vm).dvddrives

und dies bekommen:

VMName       Path
——       —-
AndroidX86   C:\Users\XXX\Downloads\android-x86-4.3-20130725.iso
AndroidX86-2 C:\Users\XXX\Downloads\android-x86-4.3-20130725.iso
Test
UbuntuTest
VistaTest    C:\WINDOWS\system32\vmguest.iso
W2K12R2Core

OK, ausgehend von der obigen Meldung mit den Integrationsdiensten macht es Sinn. Denn scheinbar will der Rechner die VMGUEST.ISO aktualisieren, kann es aber nicht, weil diese gerade bei einer VM in Benutzung ist. Dieser Fehler dürfte in Client-Hyper-V Umgebungen sicherlich häufiger auftreten.


Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.