Okay, 2 Probleme, 1 Lösung:

Problem 1

Seit gestern hatte ich bei mir den Fall, dass meine Lesezeichenordner und teilweise auch die Lesezeichen in den Ordnern keine Namen mehr hatten. Siehe Screenshot. Vermutlich eine fehlerhafte oder unterbrochene Synchronisation. Wobei das komisch wäre da alle Lesezeichen in einer Dictionary-Array-Struktur stehen und ein partieller oder unterbrochener Schreibvorgang eher darin resultiert hätte, dass ab einem bestimmten Lesezeichen komplett Schluss ist. Bzw. die XML dort abrupt endet und direkt unbrauchbar wird. Egal.
Durch die feine Synchronisierung war das Problem jedenfalls kurzer Hand auf all meinen Rechnern verbreitet. Also Tipp 1 wenn jemand das Problem hat: erstmal Synchronisierung stoppen damit das Problem auf dem einen PC bleibt.

Problem 2

Vor der Lösung noch Problem 2 was ebenfalls dadurch gelöst wird: das ungewollte Löschen von Lesezeichen kann sehr ärgerlich sein. Zumal Chrome einen Löschvorgang nicht bestätigt haben will sondern einfach ausführt und es auch keine „Undo“ Funktion gibt. Fälschlicherweise etwas gelöscht empfiehlt sich folgendes:

Die Lösung

Am besten schließt ihr den Chrome nicht!
Geht direkt in euer Chrome Profilordner, meistens C:\Users\[user]\AppData\Local\Google\Chrome\User Data\Default\. „Default“ ist euer Profilname, falls ihr mit unterschiedlichen Profilen arbeitet.
Kopiert euch die Dateien Bookmarks und Bookmarks.bak an einen anderen Ort.
Das Bild zeigt den Speicherort der 2 Dateien "bookmarks" und "bookmarks.bak": c:\Users\Hannes\AppData\Local\Google\Chrome\User Data\Default\

Schließt den Chrome, benennt die Bookmarks in Bookmarks_alt um und die Bookmarks.bak in Bookmarks. Damit sollte der Stand der Lesezeichen der letzten Chrome Nutzung wieder aktiv sein. Seit dem erstellte Lesezeichen sind natürlich hinüber.

Ihr könnt die Dateien auch in einem Editor öffnen und zwischen der Bookmarks, Bookmarks.bak und anderen Sicherungen, die ihr vielleicht habt, manuell rumkopieren. Aber Finger weg wenn ihr den Aufbau der Datei nicht versteht sonst geht am Ende gar nichts mehr.

.vbs und .wsf Fehler

Folgende Fehler haben mich jetzt echt lange aufgehalten:

.vbs per Doppelklick:
Skriptmodul „VBScript“ für Skript „C:\test.vbs“ wurde nicht gefunden.
Can’t find script engine „VBScript“ for script „C:\test.vbs“.

.vbs per CMD:
CScript-Fehler: Skriptmodul „VBScript“ für Skript „C:\test.vbs“ wurde nicht gefunden.

.wsf:
Immer ein Fehler in Zeile 0.


6 Lösungsmöglichkeiten!

1)
Die einfachste Lösung, die auf so ziemlich jeder Internetseite steht, ist ein Set aus 3 CMD Befehlen:

regsvr32.exe VBScript

,

regsvr32.exe jscript.dll

und/oder

regsvr32.exe jscript.dll

. Darauf folgt jeweils ein Popup, die Komponente sei erfolgreich registriert werden o.Ä.

2)
Von diesen 6 hier präsentierten Lösungsmöglichkeiten hat nur dieser hier bei mir funktioniert, also, lesen!
In der Registry wurde dieser Schlüssel

HKEY_CLASSES_ROOT\CLSID\{B54F3741-5B07-11cf-A4B0-00AA004A55E8}\InprocServer32

von einem Antivirensystem modifiziert.

Dem (Standard) Key wurde folgender Wert zugewiesen:

C:\\Program Files\\Common Files\\McAfee\\SystemCore\\ScriptSn.20110513152421.dll

und keine Änderungen waren ohne Weiteres erlaubt. Deswegen konnte regsvr32 diesen Key nicht updaten.

Also Rechtsklick auf InprocServer32 -> Berechtigungen und dem aktuellem Nutzer oder Jeder Vollzugriff geben. Den Wert auf

C:\Windows\system32\vbscript.dll

setzen und die Berechtigungen wieder normalisieren.

Fertig! Ein Hoch auf die einzigen 2 Webseiten im Netz auf denen ich diesen Lösungsansatz gefunden habe: 1 und 2 !

3)
Schaut in eurem Windows\system32\ Ordner nach der vbscript.dll. Merkt euch Dateigröße; die exakte Größe in Bytes(!) findet ihr in den Eigenschaften der Datei. Schaut auf einem Vergleichssystem (selbes OS, funktionierendes VBScript) nach dieser Datei und vergleicht Größe und Daten. Wenn sie auffällig unterschiedlich sind ersetzt ihr die Datei auf dem fehlerhaften System mit der Datei auf dem fehlerfreien System (selber OS!). Wiederholt Schritt 1).
Downloadet euch alternativ Windows Script 5.7, entpackt die .exe und nutzt die darin enthaltenen .dll Dateien. Allerdings ist der Download nur für Windows XP Systeme, keine Garantie, dass das funktioniert!

4)
In den Internet Optionen kann man im Scripting Bereich noch die 2 Einstellungen von Active Scripting and Java Applets überprüfen, sollten beide Enabled sein.

5)
Mir fiel noch ein Tool aus meinem vorletzten Windows 7 Seminar ein: sfc.exe! Das System File Checker Programm scannt alle wichtigen Systemdateien nach Änderungen und kann korrupte Dateien auf den Standard wiederherstellen. Dafür nutzt es die Windows Resource Protection, die Änderungen an Systemdateien mit speziellen DACLs und ACLs erkennt.
Also:

sfc.exe /scannow

und abwarten. Möglicherweise werden keine „Integritätsverletzungen“ festgestellt, möglicherweise wurden welche festgestellt und konnten behoben werden, vielleicht wurden auch welche festgestellt und konnten nicht behoben werden.
Dann hilft der Befehl

findstr /c:"[SR]" %windir%\logs\cbs\cbs.log >sfcdetails.txt

um alle nicht reparierbaren Fälle in eine neue .txt Datei zu filtern.

Mehr zu sfc

6)
Windows XP User können testweise Windows Script neu installieren. „Windows Script 5.7“ für Windows XP gibt es hier als Download. Windows Vista/7 Nutzer brauchen es gar nicht erst zu probieren, die Installation lässt sich auch mit Kompatibilitätseinstellungen nicht durchführen.
Aber die .exe kann man mit fähigen Programmen entpacken. Enthalten sind viele wichtige .dll und .exe Dateien, die nützlich sein könnten.

Ich hoffe einer dieser Tipps hat für euch funktioniert und eure .vbs und .wsf Scripte funktionieren wieder. Bei mir hat Punk 3) zumindest für beide Scripttypen die Lösung gebracht.

Windows 7 kann meine Aufgaben nicht ausführen… versteh‘ ich nicht.
Glücklicherweise gibt’s Hilfe: „Fehlerwert: 2147943645“ („Error Value: 2147943645“) meldet die Aufgabenplanung. Aha! Hauptsache keine kurze Fehlermeldung sondern komische Codes.

ERROR_NOT_LOGGED_ON: not logged on to the network. The specified service does not exist.“ wäre auch zu informativ gewesen, bloß nicht da reinschreiben.

ERROR_NOT_LOGGED_ON hilft uns aber den Fehler zu finden. Am Computer ist nämlich immer ein eingeschränkter Nutzer angemeldet, der nie ausgeloggt wird. Die Aufgabe soll aber als Administrator ausgeführt werden, weil nur dieser die Rechte dafür hat. Logischerweise kann der eingeloggte User nicht einfach so eine Aufgabe des Administrators starten.

Aufgabe öffnen, „Unabhängig von der Benutzeranmeldung ausführen“ auswählen, [OK] und Nutzerdaten eingeben.

Fertig!


Error Value: 2147943726

Dieser Fehlerwert (auch wenn es nicht mehr zur eigentlichen Überschrift passt) zeigt an, dass es Probleme mit den Benutzerdaten des Tasks gibt.
Also nochmal einen Blick in den „Allgemein“ Tab der Aufgabe geworfen. Ich hatte z.B. mal den Computernamen eines PCs geändert und alle Aufgaben, die mit Computername\Administrator gestartet wurden, fanden natürlich den Administrator nicht mehr, den Computernamen gab es ja nicht mehr.
Also Benutzer korrekt wählen, „Unabhängig von der Benutzeranmeldung ausführen“ wenn gewollt, [OK] und Passwort eingeben.

Ich bin vielleicht nicht der einzige und letzte Admin, der GIMP im Netzwerk silent, mit Logs via Batch installieren möchte. Also halte ich das hier kurz fest.

Ziel:

GIMP 2.6.11 soll in einer Domäne via Batch Startscript installiert werden, ohne dass der Nutzer etwas davon mitbekommt und diese Installation beeinflussen (z.B. verhindern) kann. Dabei sollen Logs erstellt werden. Für jeden ausführenden Computer wird eine Logdatei erstellt und falls auf einem Computer die Installation fehlschlägt wird zusätzlich eine ausführliche Logdatei der GIMP Installation zur Verfügung stehen.
Zusätzlich wird die Verteilung mit Hilfe von Clientfiltern gesteuert (natürlich optional).

Zuerst die coolste Info:

gimp-installer.exe /?

Die GIMP Entwickler haben eine Dokumentation zu Parametern, Fehlercodes und anderen Optionen in den Installer gepackt. Daraus lässt sich eine zuverlässige Installation basteln.

Die installer.bat:

@echo off
cls
title GIMP Installer
set wd=\\huiqb38c.user.hu-berlin.de\IQBInstitut\System\Sonstiges\GIMP
set chkd=\\huiqb38c.user.hu-berlin.de\IQBInstitut\System\Sonstiges\GIMP\checkdirs\%computername%
set log=\\huiqb38c.user.hu-berlin.de\IQBInstitut\System\Sonstiges\GIMP\logs\%computername%.txt
:: predef vars
set done=0
set gimpel=9999
set /a run=0

if exist %chkd% set done=1 & goto end

REM Clientfilter: nur die Computer aus der allowedPCs.txt dürfen installieren
for /f %%f in (%wd%\allowedPCs.txt) do if "%computername%"=="%%f" goto install
goto end

REM Clientfilter: die Computer aus der deniedPCs.txt dürfen nicht installieren
::for /f %%f in (%wd%\deniedPCs.txt) do if "%computername%"=="%%f" goto end

:install
set /a run=%run%+1
if "%run%"=="2" echo %date% %time% - Zweiter Versuch >> %log%
echo %date% %time% - Installation startet >> %log%
%wd%\gimp2611.exe /verysilent /norestart /nocancel /suppressmsgboxes /restartexitcode=3010 /log="%log%.log" /mergetasks="!desktopicon"
set gimpel=%errorlevel%

if "%gimpel%"=="0" md %chkd% & del /f /q %log%.log & echo %date% %time% - Installation erfolgreich abgeschlossen >> %log%
:: if "%gimpel%"=="3010" md %chkd% & del /f /q %log%.log & shutdown -r -f -t 120 -c "Um die GIMP Installation erfolgreich abzuschliessen muss der Computer neugestartet werden. Der Computer wird in 120 Sekunden neugestartet!"
if "%gimpel%"=="3010" md %chkd% & del /f /q %log%.log & echo %date% %time% - Installation abgeschlossen, 3010 - Restart eigentlich notwendig. >> %log%
if "%run%"=="2" echo %date% %time% # 2. Installationsversuch ebenfalls fehlgeschlagen, Fehlercode %gimpel% >> %log% & goto end
if "%gimpel%"=="1" echo %date% %time% # EL 1 - Initialisierung fehlgeschlagen, warte 600 Sekunden... >>%log% & ping 127.0.0.1 -n 600 >>nul & goto install
if "%gimpel%"=="2" echo %date% %time% # EL 2 - Abbruch durch den User, warte 600 Sekunden... >>%log% & ping 127.0.0.1 -n 600 >>nul & goto install
if "%gimpel%"=="4" echo %date% %time% # EL 4 - Install Error, warte 600 Sekunden... >>%log% & ping 127.0.0.1 -n 600 >>nul & goto install
if "%gimpel%"=="5" echo %date% %time% # EL 5 - Install Error, warte 600 Sekunden... >>%log% & ping 127.0.0.1 -n 600 >>nul & goto install
if "%gimpel%"=="9999" echo %date% %time% # hier ist etwas schief gelaufen... >> %log%

:end
if "%done%"=="1" echo %date% %time% - Bereits installiert >> %log%

Anpassungen:

In Zeile 4-6 natürlich die Serverpfade anpassen.
Der Clientfilter (siehe Zeile 14 bis 19) ist natürlich optional. Aktiviert Zeile 15 und 16 oder Zeile 19 für den gewünschten Effekt.
Je nach Clientfilter ist noch eine allowedPCs.txt oder eine deniedPCs.txt nötig. In dieser steht pro Zeile 1 Computername.
Die Parameter des Installers in Zeile 25 können selbstverständlich den eigenen Bedürfnissen angepasst werden. Siehe dazu die

installer.exe /?

Dokumentation (siehe oben).
Zeile 29 und 30 behandeln den Fall, wenn der Installer nach der Installation neustarten möchte. Zeile 29 startet den Rechner dann nach 2 Minuten automatisch neu und zeigt vorher eine Meldung an. Zeile 30 ignoriert das Verhalten und trägt es nur vollständigkeitshalber in die Logdatei ein.

Logs und Checkdirs:

Der Installer legt im Ordner \logs\ für jeden ausführenden Computer 1 Logdatei ab. Diese enthält bei einer erfolgreichen Installation beispielsweise folgenden Inhalt:
01.08.2011 18:14:01,26 – Installation startet
01.08.2011 18:15:26,59 – Installation erfolgreich abgeschlossen

Schlägt die Installation fehl wird in diesem Ordner eine zusätzliche Datei [computername].txt.log zur Verfügung stehen, in der ausführliche Debug Informationen des Installers gelistet sind. Zusätzlich steht in der [computername].txt eine Kurzbeschreibung des Fehlers.

Anhand des Checkdirs erkennt das Script, ob es bereits ausgeführt wurde. Dieses leere Verzeichnis wird nur bei den Fehlercodes 0 (erfolgreich) und 3010 (erfolgreich mit Neustart) erstellt.

Sowohl für die Logs als auch für die Checkdirs muss das ausführende Objekt Schreibzugriff auf diesen Serverordner haben. Beim Startscript das Computerobjekt, beim manuellen Ausführen das Benutzerobjekt.

Mit Total Commander alle Ordner und Dateien, die ein Leerzeichen enthalten, suchen und anzeigen:
In der erweiterten Suche (ALT+F7) „suchen nach“:

"* *.*"

(mit den “ „) und los!

Und nur Verzeichnisse anzeigen, die ein Leerzeichen enthalten:
Die oben beschriebene Suche im „Erweitert“ Tab mit dem Attribut „Verzeichnis“ erweitern. Ein Häkchen setzen, alle anderen Attribute auf „nicht berücksichtigen“ (blaues Kästchen) setzen.

Ebenso werden nur Dateien angezeigt, wenn das Attribut „Verzeichnis“ keinen Haken gesetzt hat.

Der meistbesuchteste Beitrag meines Blog ist praktisch seit Anbeginn des Posts: „Windows XP inkl. SATA Treiber erstellen – XP ISO Builder
Auch jetzt noch erreicht er fast täglich die meisten Besucherzahlen.

Auch ich habe am Wochenende mit meinem Beitrag gearbeitet. Auf meinem Tisch stand ein Thinkpad T60. Dieser sollte mit Windows XP bespielt werden und damit es – wie so oft im Leben – nicht zu einfach wird kam bei der Windows Installation natürlich dieser Output:

Es konnten keine installierten Festplattenlaufwerke gefunden werden.
Stellen Sie sicher, dass alle Festplattenlaufwerke eingeschaltet und richtig mit dem Computer verbunden sind
[…]“

Na gut, dann wollen wir mal.

Diesen Thinkpad T60 neugestartet, Windows XP CD in eingelegt, Winfuture XP ISO Builder heruntergeladen, Windows CD eingelesen (wird lokal kopiert) und die einzelnen Schritte durchgegangen.

Wichtig wird es jetzt bei den Controllertreibern, die bei der Windows XP Installation die Festplatten erkennen sollen. Benötigt wird eine txtsetup.oem, die irgendwelche Treiber enthält.
Okay, auf der Thinkpad Support Seite des Thinkpad T60 Models gibt es im „Hard Drive“ Bereich einen „Intel Matrix Storage Manager“. Dieser wird bestimmt alle Festplattentreiber beinhalten.
Heruntergeladen, entpackt, tatsächlich eine txtsetup.oem enthalten. Zusätzlich dazu habe ich noch den Festplattentyp des T60 herausgefunden und auf der Herstellerseite noch ein 2. Paket geladen und ebenfalls hinzugefügt.
Resultat:

Treiber rein, Winfuture Update Pack rein, Windows Einstellungen gemacht, das ganze HickHack halt. ISO erstellt, gebrannt und rein in den T60.

Reboot und:

Eine Windows XP mit Treibern, Einstellungen und Updates. Mal wieder erweist sich der XP ISO Builder als ein Wundertool!

Ich fasse es nicht, seit langer Zeit nutze ich Batch und wusste nicht, dass man mehrere Befehle verknüpfen kann!

Solche Strukturen:

:install
msiexec /i test.msi
if %errorlevel%==1 goto wait
:wait
ping 127.0.0.1 -n 300 >>nul
echo retry >> %log%
goto install

lassen sich viel kürzer realisieren. Befehle lassen sich mit

&

verknüpfen! Statt für 2, 3 Befehle einen eigenen goto-Block zu erstellen könnte ich das auch so lösen:

:install
msiexec /i test.msi
if %errorlevel%==1 ping 127.0.0.1 -n 300 >>nul & echo retry >>%log% & goto install

In Batch Programmen mit mehreren hundert Zeilen entfallen dadurch dutzende kleinere Befehlsblöcke mit nur 2-5 Befehlen und der Code lässt sich viel leichter lesen!

Hinweise: (alles Vermutungen, die ich während meiner Tests bemerkt habe)

  • Vor und nach dem
    &

    Zeichen ein Leerzeichen, reduziert mögliche Fehler.

  • Vor Umleitungen (mit
    >

    oder

    >>

    ) immer ein Leerzeichen, danach keins.
    Statt

    echo test>> %log% &

    unbedingt

    echo test >>%log% &

    , sonst wird die Befehlskombination nicht korrekt ausgeführt.

  • Keine mathematischen Operationen mit set /a in einer Befehlskombi verwenden, wird ignoriert.
  • Maximal 1 if-Abfrage möglich und diese muss ans Ende der Befehlskette! Nach einer if-Abfrage werden weitere Befehle nicht ausgeführt (logischerweise…).
    echo install %loop% & if %loop%==3 echo fehler & echo %loop%

    gibt also install x aus, prüft die if Abfrage und führt alle folgenden Verkettungen nur aus, wenn die if-Abfrage true ist. Siehe Screenshot:

Mit anderen Worten: Es können einige Probleme bei der Verkettung von komplexeren Strukturen auftreten. Besser vorher einzelne Befehlskombinationen testen. Bisher funktionierten alle einfacheren 2er und 3er Verknüpfungen auf Arbeit. Je komplexer und länger die kombinierten Befehle, desto wahrscheinlicher ist aber ein fehlerhaftes Abarbeiten der Befehle.