5
GUID von einem Windows Update herausfinden
Ich möchte die {GUID} eines Windows Updates (KB2539581) herausfinden!
Hallo Community,
letztens hat unser WSUS Server 2 spezielle Office Updates installiert, die jetzt im Netzwerk Probleme machen:
KB2539581 - Office 2003 Update
KB2501584 - Office File Validation Add-In
Daher möchte ich jetzt auf allen PCs die Updates deinstallieren. Ich kam spontan auf den msiexec /x {GUID} Befehl.
Letzteres ist eher eine eigenständige Software und ich konnte in der Registry die GUID mit Hilfe dieser zwei Artikel schnell finden.
Allerdings finde ich nicht die GUID des ersten Patches heraus. Er ist nicht in der Registry auffindbar, steht nicht in der Patch .MSP (.exe extrahiert und mit Orca betrachtet) und auch die Umformung des Keys 95C411710F1E8A440AA10B3C4A062107 (HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Patches\95C411710F1E8A440AA10B3C4A062107 = "Office2003Patch;Office 2003 Patch 15170" des Pakets "RICHED20.MSP") nach der hier im gelben Kasten beschriebenen Methode in {17114C59-E1F0-44A8-A01A-B0C3A4601270} ist nicht erfolgreich.
Gibt es ein Tool, in dem man das Update (es steht brav unter Programme -> installierte Updates) auswählen kann und die GUID zurückgeliefert bekommt?
Hallo Community,
letztens hat unser WSUS Server 2 spezielle Office Updates installiert, die jetzt im Netzwerk Probleme machen:
KB2539581 - Office 2003 Update
KB2501584 - Office File Validation Add-In
Daher möchte ich jetzt auf allen PCs die Updates deinstallieren. Ich kam spontan auf den msiexec /x {GUID} Befehl.
Letzteres ist eher eine eigenständige Software und ich konnte in der Registry die GUID mit Hilfe dieser zwei Artikel schnell finden.
Allerdings finde ich nicht die GUID des ersten Patches heraus. Er ist nicht in der Registry auffindbar, steht nicht in der Patch .MSP (.exe extrahiert und mit Orca betrachtet) und auch die Umformung des Keys 95C411710F1E8A440AA10B3C4A062107 (HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Patches\95C411710F1E8A440AA10B3C4A062107 = "Office2003Patch;Office 2003 Patch 15170" des Pakets "RICHED20.MSP") nach der hier im gelben Kasten beschriebenen Methode in {17114C59-E1F0-44A8-A01A-B0C3A4601270} ist nicht erfolgreich.
Gibt es ein Tool, in dem man das Update (es steht brav unter Programme -> installierte Updates) auswählen kann und die GUID zurückgeliefert bekommt?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 169177
Url: https://administrator.de/contentid/169177
Ausgedruckt am: 21.11.2024 um 19:11 Uhr
5 Kommentare
Neuester Kommentar
kann man das nicht via WSUS wieder deinstallieren?
Ich bin leider kein WSUS Crack aber meine ersten Recherchen ergaben, dass die meisten Updates eine Deinstallation durch den WSUS Server nicht unterstützen, man kann sie nur ablehnen. So ist es auch bei diesem Update, siehe Screenshot.
Hallo,
Das Update:
KB2501584 - Office File Validation Add-In
Kann ebenfalls Nicht deinstalliert werden, weder über WSUS noch auf dem Client.
Das steht aber auch beim Update dabei wenn man es freischaltet möchte für die Clients.
So war es z.B. bei Mir die Tage der Fall als ich das Update ausrollen ließ.
Mfg.
Das Update:
KB2501584 - Office File Validation Add-In
Kann ebenfalls Nicht deinstalliert werden, weder über WSUS noch auf dem Client.
Das steht aber auch beim Update dabei wenn man es freischaltet möchte für die Clients.
So war es z.B. bei Mir die Tage der Fall als ich das Update ausrollen ließ.
Mfg.
Hi,
das File Validation Add-in kann sehr wohl deinstalliert werden.
Sowohl im Programme Menü der Syssteuerung als auch per CMD: msiexec /x {90140000-2005-0000-0000-0000000FF1CE} /qb
Mir gehts, wie im ersten Post auch steht, um das andere Update. Das KB2539581
das File Validation Add-in kann sehr wohl deinstalliert werden.
Sowohl im Programme Menü der Syssteuerung als auch per CMD: msiexec /x {90140000-2005-0000-0000-0000000FF1CE} /qb
Mir gehts, wie im ersten Post auch steht, um das andere Update. Das KB2539581
Ich habe mittlerweile erkannt, dass das Update KB2539581 nicht die Ursache für die Office Fehlkonfiguration war. Automatische Deinstallation habe ich bis jetzt noch nicht hinbekommen, kann ich jetzt aber auch sein lassen.
Stattdessen deinstalliere ich das File Validation Add-In (aufgrund enormer Performanceprobleme bei großen Dateien von Netzlaufwerken) und repariere danach Office 2010 silent per Kommandozeile.
Office 2010 per Kommandozeile unbemerkt repaieren:
setup.exe /repair "ProPlus" /config "SilentRepairConfig.xml"
Pfad zur .exe und zur .xml angeben, Produktnamen "ProPlus" ggf. duch das vorhandene Produkt (steht in der setup.xml Zeile 3 am Anfang) ersetzen.
Setup.exe Parameter
SilentRepairConfig.xml erstellen, wenn im Ordner ProPlus.WW nicht vorhanden:
XML Elemente
Ganz wichtig ist das Element Setting, mit dem sich viele wichtige Dinge wie Reboot steuern lassen: Setup/Setting Properties
Grundlegende Batch:
Warum die ganze errorlevel-Reboot-Problematik?
Bei einigen Office Repairs verhält sich Office 2010 anders. Mal startet es neu, mal nicht. Ich hatte <setting Id="SETUP_REBOOT" Value="Never" /> in die .xml genommen damit der Rechner nie neu gestartet wird. Das resultiert bei diesen einigen Rechnern im Fehlercode 3010, ein Neustart wird benötigt:
Mögliche Errorlevel
Einfach <setting Id="SETUP_REBOOT" Value="Never" /> aus der .xml zu löschen würde den Computer direkt nach dem Repair-Vorgang neustarten, die Batch würde <strong>nicht zu Ende ausgeführt!</strong>
Stattdessen deinstalliere ich das File Validation Add-In (aufgrund enormer Performanceprobleme bei großen Dateien von Netzlaufwerken) und repariere danach Office 2010 silent per Kommandozeile.
Office 2010 per Kommandozeile unbemerkt repaieren:
setup.exe /repair "ProPlus" /config "SilentRepairConfig.xml"
Pfad zur .exe und zur .xml angeben, Produktnamen "ProPlus" ggf. duch das vorhandene Produkt (steht in der setup.xml Zeile 3 am Anfang) ersetzen.
Setup.exe Parameter
SilentRepairConfig.xml erstellen, wenn im Ordner ProPlus.WW nicht vorhanden:
<Configuration Product="ProPlus">
<Display Level="none" CompletionNotice="no" SuppressModal="yes" AcceptEula="yes" />
<USERINITIALS Value="IQB" />
<USERNAME Value="IQB" />
<Setting Id="SETUP_REBOOT" Value="Never" />
</Configuration>XML Elemente
Ganz wichtig ist das Element Setting, mit dem sich viele wichtige Dinge wie Reboot steuern lassen: Setup/Setting Properties
Grundlegende Batch:
set o2k10=\\server\pfad\Office2010
set log="\\server\pfad\Logs\%computername%.txt"
if exist %windows%\checks\repairo2k10 goto end
echo Repariere Office 2010...
%o2k10%\setup.exe /repair ProPlus /config %o2k10%\ProPlus.WW\SilentRepairConfig.xml
set repairerrorlevel=%errorlevel%
REM weitere Befehle...
echo %date% %time% - Office repariert, errorlevel: %repairerrorlevel% >> %log%
REM weitere Befehle...
md %windows%\checks\repairo2k10
:end
if %repairerrorlevel%==1030 shutdown -r -f -t 120 -c "Um die Office Reperatur erfolgreich abzuschliessen muss der Computer neugestartet werden. Der Computer wird in 120 Sekunden neugestartet!" Warum die ganze errorlevel-Reboot-Problematik?
Bei einigen Office Repairs verhält sich Office 2010 anders. Mal startet es neu, mal nicht. Ich hatte <setting Id="SETUP_REBOOT" Value="Never" /> in die .xml genommen damit der Rechner nie neu gestartet wird. Das resultiert bei diesen einigen Rechnern im Fehlercode 3010, ein Neustart wird benötigt:
Mögliche Errorlevel
Einfach <setting Id="SETUP_REBOOT" Value="Never" /> aus der .xml zu löschen würde den Computer direkt nach dem Repair-Vorgang neustarten, die Batch würde <strong>nicht zu Ende ausgeführt!</strong>
