Guten Morgen Zusammen,
wir haben den Matrix42 ServiceStore im Einsatz und nutzen dort auch Katalog in dem wir Software anbieten.
Die Verwaltung des Stores liegt nicht direkt in meiner Hand.
Der Kollege der diesen Verwaltung muss bei einer Aktualisierung einer Software im Katalog immer die ID des Softwarepakets anpassen.
Kann ich über eine Pipline irgendwie eine Mail mit dieser versenden lassen?
Gruß
Michael
Hallo Michael,
man hat die Möglichkeit ein Powershellscript in die Pipelines einzubinden, das dann die Emails über SMTP verschickt.
Vielleicht haben die ESM Kollegen von uns auch noch eine Idee, weswegen ich diese mal intern angetriggert habe.
Viele Grüße
Michael
Hallo Michael,
das Versenden von Mails aus einer Pipeline ist in Arbeit. Bis dahin ist erstmal Powershell der Weg.
Viele Grüße
Andreas
Guten Morgen Michael,
alternativ wäre es auch eine Möglichkeit, dass ihr das Add-on neo42 SoftwareDeploymentForEmpirum für die „Bestellung“ von Software über das SelfServicePortal der Enterprise Servicemanagement Plattform nutzt.
Wir bieten hier die Möglichkeit Versions-unspezifisch Softwarepakete in Empirum zuzuweisen. Das Ganze wird in diesem Video auf Youtube auch kurz gezeigt: https://youtu.be/WhmQ9Wokgzc?si=k1FX3UNFVGrmYgIB
Wir haben das Addon im Einsatz, seitdem sind die Aktualisierungen auch deutlich einfacher. Ebenso muss der User die Software nicht neu bestellen und freigeben lassen.
Hi, danke für das Feedback.
Hattet ihr vorher auch den Kalatog ohne das Addon im Einsatz? Wie gut lief der Wechsel?
Und gibt es Nachteile durch das Addon die ich noch nicht sehe?
Gruß
MIchael
Es muss gar nicht so kompliziert sein und man braucht auch eigentlich keine AddOns ohne irgendwelche Doings im Service Store für das Handling mit Updates.
Ich gehe in der Regel so vor:
Für jedes Software Paket lege ich in Empirum eine Produktiv-Version und ggf. eine Test-Version an indem ich in den Paketeigenschaften aus dem Text und aus dem Namen die Versionsnummer entferne.
In den Prüfeigenschaften wird die Version ohnehin inzwischen durch %Version% als Variable ersetzt.
Bei Google Chrome x64 heißt es also statt
Name: Google\Chrome x64\124.0.6367.156 => Google\Chrome x64\produktiv
Text: Google Chrome x64 124.0.6367.156 => Google Chrome x64
In der Eigenschaft „Version“ bleibt natürlich 124.0.6367.156 stehen.
Dadurch bekommt der Service Catalog ein Software Paket, das keine Version im Namen hat.
Dieses Produktiv- bzw. Test-Paket weise ich entsprechend in Empirum zu oder nutze es im Service Catalog.
Bei einem Update passiert folgendes:
Ich importiere die neue Version des Pakets (alle Eigenschaften bleiben wie gehabt).
(Ich lasse alle Pakete erstmal auch mit Version im System um ggf. gezielt eine Version zu installieren.)
Dann setze ich im Produktiv- bzw. Test-Paket die Eigenschaft Version auf die aktuellste, gerade importierte, Version.
Fertig.
Jeder Client mit aktiver Zuweisung prüft automatisch für sich die Version der zugewiesenen Pakete und stellt fest, dass das Chrome Produktiv-Paket plötzlich eine höhere Version hat und beginnt das automatische Update durch Empirum.
Ich muss nirgends eine ID ändern, ich muss nirgends eine Zuweisung austauschen und ich muss keinen einzigen Client neu aktivieren.
Das klingt auch nach einer guten Methode.
@Sven
Aber ist es nicht so, dass die Statusanzeigen der Rechner alle gelb sind, da das Mapping zwischen inventarisierten Paketen und zugewiesenen Paketen nicht passt?
Die Statusanzeige konnte ich nie so richtig ernst nehmen, weil sie rein auf das Log bezieht. Die Pakete sind so lange grün, bis ein Update gelaufen ist.
Und ich meine der Vorgang „Update“ ist halt total legitim, er wird ja auch so in den Logs angezeigt. Deshalb verstehe ich nicht, wieso der Status nur nach Log-Einträgen vom Typ „Installation“ sucht…
Rein von der Handhabung und vom Handling her, war es für mich so die logischste Methode. Und so glaube ich für mich, dass es vielleicht sogar in der Vergangenheit mal so gedacht war…
Neue Paket Version einspielen, Version des Pakets hochsetzen, fertig. Keine Nacharbeiten im Service Catalog, kein rumschieben in Gruppen und kein neues Aktivieren von Clients. Das ist für mich ein Mehrwert, da kann ich auf das Statusfenster gerne verzichten 
Der Status bezieht nicht nur das Log ein.
Im ersten Step wird geprüft ob das Log auf Success geht, im zweiten Step wird über das Inventory geprüft ob das Paket ordnungsgemäß installiert ist. Taucht das Paket im Inventory nicht auf, wird der Status zurück auf gelb gesetzt.
Da vom Paket der Maschinekey <Softwarename><Version> gesetzt wird, das Paket in der DB aber <Softwarename>\Produktiv heißt, wird der Status auf gelb gesetzt.
Der Status funktioniert eigentlich recht zuverlässig, wenn man die beschriebene Abfolge beachtet. Matrix42 Dokumentation
Dies ist einer der Gründe, weswegen wir unseren, bereits beschriebenen Weg gehen.
Viele Grüße
Michael Deitermann
Danke für die Info.
Das bedeutet aber, dass der UPDATE Mechanismus nur für die Revision funktioniert, da ich für jede neuere Version ein ganz neues Paket benötige?
Nichts destotrotz bleibt es eine Geschmacksfrage. Niemand bei uns schaut auf den Status in Empirum. Der Nutzen, nicht mit Paketen, Gruppen und Services im Service Catalog rumjonglieren zu müssen, überwiegt für uns bei weitem und hat das System erst richtig komfortabel gemacht.
