PM V3 Allgemeine Fragen und Erfahrungen!?

[jlies]

Hallo zusammen,
meine Kollegen nutzen seit einiger Zeit das Patchmanagement V3 und sind sehr unzufrieden!
1.) Werden diverse MS-Patches die auf Approved stehen nicht installiert.
2.) Das PM lässt sich für Drittanbieter Software z.B. Adobe nicht verwenden, weil der Deinstalltions-String durch das Patch verändert wird, und sich dadurch nicht mehr deinstallieren lässt.

Zu Punkt 1. :Ist die Frage ob es einen Konfigurationsproblem ist.
Zu Punkt 2.: Die Problematik verstehe ich aber, ich kann mir das einfach nicht vorstellen. Wenn das so wäre, dann könnte M42 doch diese Produkt so nicht auf den Markt bringen. Es würden dann alle Funktionalitäten wie Serive-Store, Buchungen, Lizenzmanagment, Assetmanagement und erst recht die Softwareverteilung nicht mehr richtig laufen.

WEnn das so wäre, will ich mein Geld zurück, kann mir das aber fast nicht vorstellen, sonst würde das ja keine einsetzen.

Kann mir einer von euch dazu bitte mal ein paar Zeilen schreiben, vielleicht ja auch einer von Matrix42 direkt, der kann mich auch gerne mal anrufen.

Vielen Dank.

[seipf]

Hi,

zu 1.) Ja, kann ein Konfig Fehler sein. Ist der Patch/ die Patches auch einer Gruppe zugeordnet? Rechtsklick auf den Patch und "Gruppenzuweisung" wählen und prüfen. Ist die Patchgruppe dann auch einem Client zugeordnet?

zu 2.) Ist etwas komplizierter:
Durch ein Update wird ein neuer RegKey vom Hersteller gesetzt. Hier ist auch der "neue" UninstallString enthalten und die Software erscheint auch mit neuer Versionsnr. etc. in der Windows Programmliste zum Deinstallieren.

Mich persönlich stört das nicht so sehr. Ich habe dafür lieber eine Software auf dem aktuellen Stand.
Wir nutzen allerdings auch nur Software Deployment und das PatchManagement.

Gerdae nochmal getestet: Es scheint auch von Software zu Software unterschiedlich zu sein: Den VLC Player konnte ich problemlos mit der "alten" Deinstallationsroutine entfernen .

Viele Grüße
Florian

[jlies]

Danke für die erste Info.
Mit den Gruppen werde ich prüfen bzw. prüfen lassen, interessant ist allerdings, dass einige Clients z.B. das Adobe-Update erhalten und andere nicht...

zu Punkt zwei: Noch die Frage wie deinstallierst du dann die Software wieder?
Gruß Jan

[seipf]

zu Punkt zwei: Noch die Frage wie deinstallierst du dann die Software wieder?
Gruß Jan

Im Prinzip: Erst mal gar nicht.
Wenn es notwendig sein sollte dann mit einem Extra Paket zum Deinstallieren. Wobei das nur ThirdParty Software betrifft.
MS Software lässt sich eigentlich immer sauber deinstallieren, trotz Updates durch PMv3 und Fachanwendungen werden nicht mit PMv3 gepatcht

Aber eine Gegenfrage: Muss ich ThirdParty Software denn überhaupt deinstallieren?
Nenn mal bitte ein paar Fallbeispiele. Vielleicht beachte ich im Moment die eine oder andere Sache noch gar nicht .

Viele Grüße
Florian

[tgrosch]

Hallo,

zu 1.:
Werden beim Client in der Konsole die entsprechenden Patche als "fehlend" dargestellt? Also Eigenschaften des Client --> Registerkarte "Patches" --> "Patch fehlt".

zu 2.:
Wir nutzen PMv3 auch nur für Microsoft und Adobe Reader (nicht Flash und auch keine anderen Hersteller). Hintergrund war / ist meiner Meinung nach, der "Updateweg" schlicht programmtechnisch nicht abgebildet werden kann. Insofern stimme ich Dir zu, dass Matrix42 ein Produkt bewirbt, was den angepriesenen Funktionsumfang garnicht abbilden kann. Es ist kein Multi-Vendor-PatchManagement.

PMv3 prüft z.B. nicht ab, ob der Browser geöffnet ist, sondern installiert gnadenlos Flash neu.

Man muss natürlich sagen, dass viele Anwendungen keine "normale Updateroutine" haben. Adobe Reader oder auch Acrobat haben MSP-Dateien, der VLCplayer hat m.E. gar keine Updatefunktion, da gibt es nur eine Vollversion, die aktualisiert wird. Folglich kann ich sowas nicht über PatchManagement ausrollen. Bei Flash ist es im Prinzip genauso, da stellt Adobe auch nur Vollversionen bereit.

Da wir die PackageCloud (oder den PackageStore) ohnehin abonniert haben, ziehen wir dort aktuelle Pakete für Flash, Java, ... herunter und weisen die neuen Pakete zu.

Ich habe darüber bei verschiedenen Gelegenheiten mit Herrn Voigt vom Produktmanagement gesprochen. Matrix wollte eine Möglichkeit schaffen, dass vor der Installation geprüft wird, ob ein bestimmter Prozess läuft. Damit hätte man das o,g, Problem gelöst. Vielleicht ist das inzwischen implementiert. Auf die Schnelle habe ich in den Best Practises nichts gefunden. Da wir wir eingangs erwähnt das Problem als Workaround über den PackageStore lösen, habe ich das nicht weiter verfolgt. Wir haben aber auch überlegt, den Bereich PatchManagement im Wartungsvertrag zu kündigen und stattdessen wieder zu W-SUS zurückzugehen.

Positiv muss man noch die recht umfangreiche Doku erwähnen, dort gibt es viele Punkte zum Thema Troubleshooting. Aber wie gesagt, das Produkt kann m.E. nicht das, was es angibt zu können.

[jlies]

Unglaublich, dass kann doch nicht sein, kann sich da nicht mal einer von Matrix42 zu äußern!!!!!

[Viper9000]

Hallo,

ich hatte mal in einem anderen Beitrag schon einen Ansatz zu deiner zweiten Frage aufgezeigt. Wir verwenden übrigens kein PM3 sondern WSUS. Nichtsdestotrotz basiert meines Wissens das PM3 auf einem OEM Produkt. Darin werden die Original Hersteller Update Commands vorgehalten. Diese sind nun nicht unbedingt auf MSI Pakete ausgelegt.

Das ursächliche Problem ist meiner Meinung nicht das PM, sondern das Verhalten des MSI Installer Dienstes. Das PM installiert nur neuere MSPs/MSI über eine bestehende Installation und verdreht dabei den von Empirum gesetzten Quellpfad. Somit funktioniert der Uninstallstring bei der Empirum-gestützten Deinstallation für MSI Pakete nicht mehr.

Meiner Meinung lässt sich das Problem ziemlich einfach lösen. Wir haben dazu unser MSI Template Inf modifiziert. Hier der Auszug aus meinem alten Beitrag am Beispiel des Adobe Readers:

OriginalPost: viewtopic.php?f=3&t=12873&p=51921#p51921


------------------------------------------------------------------------------------------------
Ich könnte mir aber vorstellen, dass beim Einspielen eines Reader Patches (MSP File) das lokal installierte Adobe Reader MSI geprüft wird. Dies erfolgt automatisch durch den MSI Installer Dienst auf dem Client. Sind die Quellen, wie in eurem Fall nicht vorhanden, passt es nicht mehr. Sofern die Clients zur Laufzeit der Patchinstallation an eurem Firmennetzwerk hängen, würde ich euch raten folgende Regkeys für die Adobe Reader MSI (Ursprungsversion) zu setzen:

HKCR,"Installer\Products\%V_MSIInstallerID%\Sourcelist\Net","2",0x00020000,"\\%%EmpirumServer%%\Configurator$\Packages\%DeveloperName%\%ProductName%\%Version%\"

HKCR,"Installer\Products\%V_MSIInstallerID%\Sourcelist\Net","3",0x00020000,"\\Empirummasterdepot.company.de\Configurator$\Packages\%DeveloperName%\%ProductName%\%Version%\"

Die einfachen Prozentwerte musst du durch die tatsächlichen Werte (siehe Adobe Reader setup.inf) ändern. Wir haben in jedem Paket, welches MSI verwendet diese Zeilen drin. Damit passiert folgendes: Ist der Ort der Ursprungsquellen (normalerweise lokaler Cache des Agents) nicht mehr vorhanden, dann prüft der MSI Installer, ob die Quellen auf dem %EmpirumServer%\configurator$ noch da sind. Wenn ja nimmt er diese von dort. Ansonsten würde er auf den dritten Quellenpfad prüfen. Der steht bei uns nur vorsorglich drin. For future use. Dort müsstest du Company.de durch eurer DNS Suffix ersetzen (und die einfachen Prozentwerte).

Stell mal den ersten Regkey auf einem Client ein. Dann sollte das PM drüber gehen und die Originalquellen ohne Recaching finden.

Gruß Viper

PS: Heißt im Idealfall nur ein Regkey zum nachpflegen.
--------------------------------------



Baut in eure MSI Inf einfach diese Werte pauschal ein und es gibt immer eine Option die MSI Pakete über Netzwerk nachzuziehen, sofern der Empirum Server erreichbar ist.

Gruß Viper

[DCosta]

Hallo

@Viper9000
So wie ich das verstehe müsste für eure Lösung die MSI jeder Software, die eventuell installiert sein könnte, noch auf dem Server/Depot vorhanden sein um diese ggf. deinstallieren zu können. Aber würde das nicht dann nur bei Programmen funktionieren deren UninstallString bei einem Update nicht verändert wird, z.B. Adobe Reader oder andere Software die MSP benutzt?

Ich sehe das Problem eher in Java, Flash, Chrome usw. deren UninstallString sich mit jeder Version verändert. Das Bedeutet ich kann diese Software nicht mehr über Empirum deinstallieren. Eine Idee war hier den UninstallString in der Setup.inf durch eine Variable zu ersetzen deren Inhalt der aus der Registry ausgelesene UninstallString ist. Ob das das Problem mit dem Lizenzmanagement lösen würde weiß ich nicht.

Ich muss die Software zwar vielleicht nicht aus Lizenzgründen deinstallieren, jedoch ggf. wegen etwas Anderem. PM3 zerschießt gerne mal übermittelte Einstellungen wie z.B. die Sprachdatei für ImgBurn oder PDFCreator und dann kann ich die noch nicht mal automatisiert deinstallieren lassen.

[Viper9000]

Hallo,

@Dcosta:

Es funktioniert nur für MSI Pakete.
Es funktioniert für MSI Pakete ,wo der Sourcelist Eintrag 1 (HKCR,"Installer\Products\%V_MSIInstallerID%\Sourcelist\Net","1",) durch eine beliebige MSI Installation (MSP, MSI (sofern ProductCode gleich ist)) modifiziert wurde und die Quelldateien dort nicht mehr liegen. Dann greift der Installerdienst automatisch auf die anderen Sourcelisteinträge zurück. Diese tun nie weh, weil sie nur greifen, wenn der erste Eintrag nicht mehr erreichbar ist. Vorteil man hat immer eine Fallbackoption, sonst hat man gar keine. Aus diesem Grund ist es bei uns Standard in jeder MSI Inf. Dabei ist unerheblich, ob PM3 im Einsatz ist oder nicht. Natürlich müssen die Quellpakete in diesem Fall auf dem Netzwerk zur Verfügung stehen.


Wir extrahieren MSI für Java und verteilen immer nur native MSIs. Flash wird als MSI von Adobe heruntergeladen. Ich kann aber nicht sagen, wie das Update Command in PM3 für die Software Pakete ist. Sofern dort auch nur die MSI Pakete (auch im Hintergrund aus dem exe Wrapper) sollte es gehen.

zwei Verständnisfragen von mir, da wir kein PM3 nutzen:
Verändert das PM3 den MSI Uninstallstring oder den Empirum Paket Uninstallstring?

Meine persönliche Meinung:
Microsoft native Updates via WSUS oder PM3
Alle anderen via Empirum natives Softwaremanagement durch Revisions-/Versionsupdate und nutzen von Askuninstalledold

Ist stabil und es kommen sich nicht zwei unterschiedliche Installationsmechanismen in die Quere. Machen wir seit Jahren so und kennen diese Probleme seitdem nicht mehr.

Gruß