Ich wollte unser Typo3 auf die neueste Version 4.6.0 updaten, aber im Gegensatz zum letzten Update ist da ziemlich was schiefgelaufen. Nun ist es mir doch noch gelungen.

Am besten macht man mit phpmyadmin eine Kopie der betroffenen Datenbank und arbeitet mit der Kopie. Ausserdem habe ich auch den ganzen Typo3 Ordner kopiert, damit ich in einer weiteren Installation testen kann ohne die aktive Installation zu “zerschiessen”.

Bei mir lag es hauptsächlich daran, dass die Datenbank nicht auf UTF-8 umgestellt war und einige Extensions nicht auf dem neuesten Stand waren.

Mit dieser Anleitung ist es mir schlussendlich gelungen, die Datenbank auf UTF-8 umzustellen und anschliessend Typo3 von 4.4 auf 4.6 upzudaten. Vielen Dank an den Ersteller.

Es zeigt sich mal wieder, dass Typo3 dem Ruf gerecht wird, kompliziert zu sein (vor allem für Nicht-Profis wie mich). Dafür bietet es auch immens viel an und man muss sich auch nicht an eine proprietäre Lösung binden. Also weiterhin empfehlenswert…

In unserem Netzwerk haben einzelne Computer begonnen, sehr lange zum Aufstarten zu benötigen. Da kommt dann einfach während Minuten der Bildschirm mit “Bitte warten…”.

Komisch ist, dass auch vom gleichen Gerätetyp nur einzelne Computer betroffen sind und gemäss Aussagen von den Benutzern tritt es auch nicht jedes Mal auf.

Man kann über eine Gruppenrichtlinie die Meldungen beim Start von Windows 7 anzeigen lassen, aber das hat mich auch nicht weitergeführt.

Also habe ich die Logfiles von betroffenen Computern durchgesehen und bin auf folgende Einträge gestossen:

Event-ID: 6005
Quelle Winlogon
Der Anmeldebenachrichtigungsabonnent <GPClient> benötigt einige Zeit, um dieses Benachrichtigungsereignis (CreateSession) zu bearbeiten.

Event-ID: 6006 
Quelle Winlogon
Der Anmeldebenachrichtigungsabonnent <GPClient> hat xxx Sekunden benötigt, um dieses Benachrichtigungsereignis (CreateSession) zu bearbeiten. 
Wobei xxx für die Anzahl Sekunden steht und von wenigen bis zu fast 10 Minuten dauern kann. 

Da findet man dann viele Hinweise, um was es sich handeln könnte, z.B. eine fehlerhafte DNS Implementierung. Habe dann das Netzwerk überprüft, aber nichts gefunden. Ein anderer Event hat mich dann weiter auf die richtige Spur gebracht.

Event-ID: 10
Quelle WMI
Ereignisfilter mit Abfrage "SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA "Win32_Processor" AND TargetInstance.LoadPercentage > 99" konnte im Namespace "//./root/CIMV2" nicht reaktiviert werden aufgrund des Fehlers 0x80041003. Ereignisse können nicht durch diesen Filter geschickt werden, bis dieses Problem gelöst ist.

Scheinbar passiert das, wenn eine WMI Abfrage nicht genügend Rechte besitzt.

Auszug aus Technet.

0x80041003 (WBEM_E_ACCESS_DENIED)
This typically results when the process trying to access the namespace does not have the required WMI privileges. The account attempting remote access should be an administrator on the target computer; in addition, the account might need to have a specific privilege enabled.
To troubleshoot this error, check the namespace security on the remote namespace to see the privileges enabled for the account.

Dann habe ich in einem Forum einen Hinweis gefunden, mit dem ich das Problem lösen konnte:

Boot into safe mode. First, open services and stop the Windows Management Instrumentation Service. Take ownership of the folder or the contents of the folder "C:\Windows\System32\wbem\Repository." Delete the contents of the folder. Reboot.

Beim Microsoft Support findet man sogar ein FixIt Knopf, um das Problem zu beheben. Dies hat aber bei einem Test bei mir nicht funktioniert. Ausserdem gibt es da noch ein VB Skript, das ich aber nicht getestet habe.

Hingegen hat es funktioniert, wenn man folgende Befehle an einer mit Administratorenrechten gestarteten Eingabeaufforderung eintippt.

Net Stop WinMgmt /y
rd %WinDir%\System32\Wbem\Repository /s /q
Net Start WinMgmt /y

Der Vorteil davon ist, dass sich das skripten und auf die betroffenen Geräte verteilen lässt.

Das Problem lässt sich also so beheben, aber ich weiss immer noch nicht, woher es kommt und daher auch nicht, ob es wieder kommen wird. Dies hinterlässt ein ungutes Gefühl.

Um dem unguten Gefühl wenigstens ein wenig entgegenzuwirken, habe ich bei betroffenen Geräten vollständige Virenscans mit mehr als einem Virenscanner durchgeführt, die aber auch nichts gefunden haben…

Nachtrag

Es scheint besser zu sein, das Repository nicht ganz zu löschen, sondern nur ein WinMgmt /resetrepository durchzuführen. Weil man manchmal noch weitere Dienste stoppen oder sogar einen Task abwürgen muss, habe ich ein Skript geschrieben (dieses muss durch einen Rechtsklick –> Als Administrator ausführen gestartet werden).

net stop ccmexec /y
TASKKILL /F /IM CcmExec.exe
net stop wscsvc /y
net stop iphlpsvc /y
Net Stop WinMgmt /y
net start winmgmt /y
winmgmt /resetrepository

Eigentlich wird nur die letzte Zeile benötigt, aber ich habe festgestellt, dass es dann oft nicht funktioniert. Wenn man aber WinMgmt stoppt und erneut startet, funktioniert es. WinMgmt lässt sich aber nicht immer einfach stoppen, da es Dienste gibt, die von ihm abhängen und auch gestoppt werden müssen. Diese waren bei mir die Dienste ccmexec, wscsvc und iphlpsvc. In einer anderen Umgebung kann es anders aussehen (einfach mal net stop winmgmt in einer Eingabeaufforderung eingeben und schauen, welche Dienste auch noch gestoppt werden müssen). Manchmal lässt sich ccmexec nicht über net stop beenden, daher auch noch die Zeile mit dem Taskkill. Viel Erfolg!

Nachtrag 2

Das WMI-Repository zurücksetzen hilft, aber das Problem tritt bei einzelnen unserer Computer nach einiger Zeit wieder auf. Es gibt einen Hotfix von Microsoft, der das beschriebene Problem adressiert und das Problem bei unseren Computern löst.