Hallo zusammen, danke @MAJ für die Bestätigung und vielen Dank an @jf-0606 für den entscheidenden Hinweis! Dadurch habe ich mir die Registry-Einträge etwas genauer angeschaut. Tatsächlich werden speziell MSI-Einträge (WindowsInstaller=1), die gleichzeitig als Systemkomponente markiert sind (SystemComponent=1), nicht gelistet. Das ist grundsätzlich auch nachvollziehbar, da es sich dabei häufig nur um Abhängigkeiten oder Komponenten handelt, die zusammen mit einem "Hauptprogramm" verwaltet werden. Ein gutes Beispiel, wo das korrekt umgesetzt ist, ist das DATEV-Sicherheitspaket (SiPa compact). Dort existieren die eigentlichen MSI-Komponenten zwar ebenfalls als WindowsInstaller=1 und SystemComponent=1, zusätzlich gibt es aber einen separaten sichtbaren Bundle-/EXE-Eintrag: Sicherheitspaket compact x64 WindowsInstaller : 1 SystemComponent : 1 --> nicht gelistet Sicherheitspaket compact WindowsInstaller : 1 SystemComponent : 1 --> nicht gelistet Sicherheitspaket compact WindowsInstaller : SystemComponent : UninstallString : "...SiPacompact.exe" /uninstall --> GELISTET! Beim Belegtransfer existiert unter HKLM dagegen zunächst nur der versteckte MSI-Eintrag: DATEV Belegtransfer V.5.5 WindowsInstaller : 1 SystemComponent : 1 --> nicht gelistet Die eigentliche Ursache scheint zu sein, dass bei einer systemweiten Installation der sichtbare Bundle-/EXE-Eintrag nicht nach HKLM geschrieben wird, sondern in das aktuelle Benutzerprofil. Läuft die Installation im SYSTEM-Kontext, landet dieser Eintrag entsprechend unter: HKEY_USERS\S-1-5-18 also im Systemprofil. DisplayName : DATEV Belegtransfer V.5.5 WindowsInstaller : SystemComponent : UninstallString : "...systemprofile...\BTTSetup.exe" /uninstall Ursprünglich wollte ich einfach per Skript SystemComponent auf 0 setzen. Auffällig war allerdings, dass der Belegtransfer bei einer Benutzerinstallation korrekt angezeigt wurde. Dadurch, zusammen mit dem Tipp hier, kam ich erst auf die eigentliche Ursache, nämlich dass der sichtbare Uninstall-Eintrag offenbar immer im aktuellen Benutzerkontext angelegt wird. Als Workaround habe ich mir daher ein Skript gebaut. Es prüft zunächst, ob bereits ein sichtbarer HKLM-Eintrag für den Belegtransfer existiert. Falls nicht, sucht es in den Benutzer-Hives nach dem passenden Bundle-/EXE-Eintrag. Wird dieser gefunden, wird er nach HKLM übernommen. Existieren dabei ältere sichtbare Einträge einer anderen Version, werden diese vorher entfernt. Falls kein passender Bundle-Eintrag gefunden wird, setzt das Skript als Fallback beim MSI-Eintrag SystemComponent=0. Dadurch bleibt der eigentliche MSI-Eintrag unverändert, sofern der korrekte Bundle-Eintrag vorhanden ist. Sollte DATEV das Problem künftig beheben und den Eintrag direkt korrekt unter HKLM anlegen, macht das Skript automatisch nichts mehr. Nicht die schönste Lösung, aber damit stimmen Anzeige und Versionsinformation wieder, Ninja inventarisiert die Software korrekt und die Lösung bleibt auch für zukünftige Versionen kompatibel.
... Mehr anzeigen
