Archive for 28. Juli 2014

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.

DCOM Fehlermeldungen 10010 in Ereignisanzeige mit BF6C1E47-86EC-4194-9CE5-13C15DCB2001 und 1B1F472E-3221-4826-97DB-2C2324D389AE bei Windows 8.1

28 Juli 2014

Die Anfänger von Microsoft haben mal wieder zugeschlagen und beglücken die Welt mit sinnlosen Fehlermeldungen. Wenn man in der Ereignisanzeige eines Windows 8.1 Rechners diese beiden Meldungen findet:

Der Server "{1B1F472E-3221-4826-97DB-2C2324D389AE}" konnte innerhalb des angegebenen Zeitabschnitts mit DCOM nicht registriert werden.

Der Server "{BF6C1E47-86EC-4194-9CE5-13C15DCB2001}" konnte innerhalb des angegebenen Zeitabschnitts mit DCOM nicht registriert werden.

Dann hat dies mit einem Problem mit Skydrive bzw. Onedrive zu tun. Flankiert werden die Meldungen von der Ereignis-ID 10010 mit der Quelle DistributedCOM.

Da Microsoft erwiesenermaßen keine Ahnung von COM und von DCOM hat, werden wahrscheinlich aktuell viele Windows 8.1 Rechner mit dieser Fehlermeldung beglückt. Kommt mir gerade die Frage in den Sinn: Wer hat COM und DCOM nur erfunden? Mmhh.

Aufgrund dieses Threads http://answers.microsoft.com/en-us/windows/forum/windows8_1-performance/event-error-10010/69540cfb-a90c-47e1-b8a5-0b51eb0302d5 war schnell klar, dass es sich um ein Problem mit Skydrive handelt. Die Härte sind mal wieder Aussagen eines MVPs, man solle die Fehler einfach ignorieren. Gehts noch? OK, wenn schon ignorieren, dann am besten dadurch, dass man MS Produkte ignoriert. Das wäre die passendere Aussage gewesen.

Man kann zwar nun in der Aufgabenplanung hergehen und den “Idle Sync Maintenance Task” und den “Routine Maintenance Task” deaktivieren aber der Beweis, dass diese beiden Aufgaben tatsächlich etwas damit zu tun haben steht noch aus. Denn bei den Aktionen des jeweiligen Tasks ist jeweils nur ein “Benutzerdefinierter Handler” hinterlegt. Sehr aussagekräftig. Allerdings deutet auch der Hinweis bei “Ergebnis der letzten Ausführung” mit der Meldung “Starten des Servers fehlgeschlagen (0x80080005)” auf ein Problem hin. Hier eine kleine Abhandlung zum Fehler 0x80080005: http://blogs.msdn.com/b/adioltean/archive/2005/06/24/432519.aspx.

Aber zum Glück gibt es Powershell. Um die Sache etwas zu verdeutlichen ein kleines Powershell-Skript:

$t=Get-ScheduledTask -TaskPath \microsoft\windows\skydrive\
$t.Actions
$t.actions | select ClassId, Data

Wichtig ist der \ am Ende bei Skydrive! Sonst gibts einen Fehler:

Get-ScheduledTask : Es wurden keine MSFT_ScheduledTask-Objekte gefunden, bei denen die TaskPath-Eigenschaft gleich "\microsoft\windows\skydrive" ist. Überprüfen Sie den Wert der
Eigenschaft, und versuchen Sie es erneut…

Als Ausgabe erhält man:

ClassId                                Data
——-                                —-
{BF6C1E47-86EC-4194-9CE5-13C15DCB2001} IdleSyncMaintenance
{1B1F472E-3221-4826-97DB-2C2324D389AE} RoutineMaintenance

Dies sind genau die oben aufgeführten ClassIDs bei den Fehlermeldungen aus der Ereignisanzeige.

Um diese nun also zu deaktiveren, führt man als Admin noch dies aus:

$t | Disable-ScheduledTask

OK, nun ist man einen Schritt weiter aber wie lange? Funktioniert nun Onedrive nicht mehr? Abwarten und beobachten…