9
Winget statt custom script?
Hi,
wir nutzen SCCM/MECM/MCM on-premise u.a. zur Verteilung von Anwendungen.
PS-Script pro Anwendung. Teilweise einfach der Installer, oft auch kleine Anpassung und selten größere.
Kollege meinte jetzt winget ist so toll und im internet sieht man gefühlt auch immer mehr Videos dazu.
Installation ist ja nett. Aber für Anpassungen braucht man erst wieder ein extra Script und grad die größeren, aufwendigeren Tools(CAD, Grafik,...) gibt es nicht direkt mit winget.
Außerdem zieht dann jeder Client den installer aus dem Internet und nicht vom lokalen Cache Server.
Vorteile sehe ich ev. bei neuen Tools, bis man alle Eigenheiten im Script angepasst hat, kann manchmal dauern - das sind aber grob gesehen, meist die Tools die nicht bei winget verfügbar sind.
Nutzt ihr winget mit SCCM oder anderen deployment tools? Übersehe ich das killerfeature?
Sg Dirm
wir nutzen SCCM/MECM/MCM on-premise u.a. zur Verteilung von Anwendungen.
PS-Script pro Anwendung. Teilweise einfach der Installer, oft auch kleine Anpassung und selten größere.
Kollege meinte jetzt winget ist so toll und im internet sieht man gefühlt auch immer mehr Videos dazu.
Installation ist ja nett. Aber für Anpassungen braucht man erst wieder ein extra Script und grad die größeren, aufwendigeren Tools(CAD, Grafik,...) gibt es nicht direkt mit winget.
Außerdem zieht dann jeder Client den installer aus dem Internet und nicht vom lokalen Cache Server.
Vorteile sehe ich ev. bei neuen Tools, bis man alle Eigenheiten im Script angepasst hat, kann manchmal dauern - das sind aber grob gesehen, meist die Tools die nicht bei winget verfügbar sind.
Nutzt ihr winget mit SCCM oder anderen deployment tools? Übersehe ich das killerfeature?
Sg Dirm
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 81182523632
Url: https://administrator.de/contentid/81182523632
Printed on: April 27, 2024 at 10:04 o'clock
9 Comments
Latest comment
Hi,
Ich mache schon seit 16 mit SCCM, aka MECM. Meine Empfehlung ist das selbst mit einer guten Scriptvorlage zu machen. Maximal 20% aller Packages und Applications kommen ohne Anpassungen aus, seien es RegKeys, Shorcuts, oder sonst was und maximal 60% aller Packages bestehen aus nur 1 Setup oder nur 1 MSI und sonst nichts
.
Ich habe das damals mit einer VBScript-Vorlage gelöst und als Powershell erstmals mit kam - war es mit XP oder Vista? - habe ich auf Powershell umgesattelt und einige CmdLets dafür gebaut. Funktioniert bestens und kostet keinen Cent. Weiterentwicklung jederzeit möglich und keine Wartezeit bei Anpassungen.
Investiert lieber etwas Zeit in die Entwicklung eines PS-Scripts.
Grüße
Ich mache schon seit 16 mit SCCM, aka MECM. Meine Empfehlung ist das selbst mit einer guten Scriptvorlage zu machen. Maximal 20% aller Packages und Applications kommen ohne Anpassungen aus, seien es RegKeys, Shorcuts, oder sonst was und maximal 60% aller Packages bestehen aus nur 1 Setup oder nur 1 MSI und sonst nichts
.
Ich habe das damals mit einer VBScript-Vorlage gelöst und als Powershell erstmals mit kam - war es mit XP oder Vista? - habe ich auf Powershell umgesattelt und einige CmdLets dafür gebaut. Funktioniert bestens und kostet keinen Cent. Weiterentwicklung jederzeit möglich und keine Wartezeit bei Anpassungen.
Investiert lieber etwas Zeit in die Entwicklung eines PS-Scripts.
Grüße
2
Moin,
kommt ein bisschen darauf an, was Du wills bzw. worauf Du verzichten kannst.
Die Anwendungen in winget kommen schon mal fertig "paketiert" an und falls Ihr keine Anpassungen an der Installation vornehmen wollt, ist das ja schon mal eine schöne Sache. Allerdings kümmert sich winget nicht um Abhängigkeiten, deshalb liegt der Vorteil von winget hauptsächlich darin, dass man recht vernünftige Installationsroutinen erhält.
Falls Ihr mehrere Standorte habt, liegen allerdings Eure DPs brach, es sei denn, man konfiguriert die winget-Repos auf den Clients passend und kümmert sich um deren Inhalt/Software-Stand.
Und - je nach Installationsart der winget-Anwendung oder Eurer Art, wie die Kommandozeile letzten Endes auf dem Client ausgeführt wird, läuft der Source List Updater u.U. ins Leere.
Ein weiterer Faktor könnten kompliziertere Installationsabläufe sein, in denen mal ein Reboot erfolgen kann oder auch nicht (wenn z.B. irgendeine Kommandozeile im Zuge der Installation mal 3010 meldet, oder auch nicht) - hat man seine Routine/Scripts nicht daraufhin optimiert, kann das beim Ablauf zu nervigen Fehlern bzw. einem Abbruch der Gesamt-Installation führen.
Falls man das Ganze ernsthaft betreiben will und von allen Vorzügen von SCCM profitieren will/muss, kommt man IMHO nicht am Windows Installer - und damit MSIs/MSIX - vorbei; Reboots und das Weiterlaufen der Installation nach Diesen kann der SCCM-Client bzw. der Windows Installer dann out-of-the-box und man muss das Rad beim Scripten nicht neu erfinden (Wiedereinstieg in die Installations-Routine nach einem Neustart) - außerdem ist's charmant bei Reparaturen von Installationen.
Will man während der (De-)Installation zus. Kommandozeilen ausführen (Reg-Keys setzen, Shortcuts erzeugen, etc.), so landen die als Custom Action in der MST. MSTs lassen sich easy per Code erzeugen/ändern und die Kontrolle des Ablaufs liegt dann nicht in "irgendeinem" Script, sondern brav bei Windows/SCCM und es kann seine Magie sauber entfalten.
Falls Ihr nur einen Standort/MP/DP habt und keine allzu großen Anforderungen an die Anpassung der Standard-Installation habt, würde ich sagen, nimm ruhig winget - Ihr scheint ja keinen Wert darauf zu legen, dass Ihr die volle Kontrolle über Versionsstände/Paketquellen habt; nimmt Einem einiges an Arbeit ab - mit den aufgeführten Negativa. Und selbst M$ torpediert den Windows Installer mit so 'nem Sch*** wie click-to-run, wo mangels "richtiger" MSI Product ID kein Source List Update möglich ist und die Quellen auf einem zentralen Share liegen mögen - *grrr*
Viel Erfolg
NullReferenceException
kommt ein bisschen darauf an, was Du wills bzw. worauf Du verzichten kannst.
Die Anwendungen in winget kommen schon mal fertig "paketiert" an und falls Ihr keine Anpassungen an der Installation vornehmen wollt, ist das ja schon mal eine schöne Sache. Allerdings kümmert sich winget nicht um Abhängigkeiten, deshalb liegt der Vorteil von winget hauptsächlich darin, dass man recht vernünftige Installationsroutinen erhält.
Falls Ihr mehrere Standorte habt, liegen allerdings Eure DPs brach, es sei denn, man konfiguriert die winget-Repos auf den Clients passend und kümmert sich um deren Inhalt/Software-Stand.
Und - je nach Installationsart der winget-Anwendung oder Eurer Art, wie die Kommandozeile letzten Endes auf dem Client ausgeführt wird, läuft der Source List Updater u.U. ins Leere.
Ein weiterer Faktor könnten kompliziertere Installationsabläufe sein, in denen mal ein Reboot erfolgen kann oder auch nicht (wenn z.B. irgendeine Kommandozeile im Zuge der Installation mal 3010 meldet, oder auch nicht) - hat man seine Routine/Scripts nicht daraufhin optimiert, kann das beim Ablauf zu nervigen Fehlern bzw. einem Abbruch der Gesamt-Installation führen.
Falls man das Ganze ernsthaft betreiben will und von allen Vorzügen von SCCM profitieren will/muss, kommt man IMHO nicht am Windows Installer - und damit MSIs/MSIX - vorbei; Reboots und das Weiterlaufen der Installation nach Diesen kann der SCCM-Client bzw. der Windows Installer dann out-of-the-box und man muss das Rad beim Scripten nicht neu erfinden (Wiedereinstieg in die Installations-Routine nach einem Neustart) - außerdem ist's charmant bei Reparaturen von Installationen.
Will man während der (De-)Installation zus. Kommandozeilen ausführen (Reg-Keys setzen, Shortcuts erzeugen, etc.), so landen die als Custom Action in der MST. MSTs lassen sich easy per Code erzeugen/ändern und die Kontrolle des Ablaufs liegt dann nicht in "irgendeinem" Script, sondern brav bei Windows/SCCM und es kann seine Magie sauber entfalten.
Falls Ihr nur einen Standort/MP/DP habt und keine allzu großen Anforderungen an die Anpassung der Standard-Installation habt, würde ich sagen, nimm ruhig winget - Ihr scheint ja keinen Wert darauf zu legen, dass Ihr die volle Kontrolle über Versionsstände/Paketquellen habt; nimmt Einem einiges an Arbeit ab - mit den aufgeführten Negativa. Und selbst M$ torpediert den Windows Installer mit so 'nem Sch*** wie click-to-run, wo mangels "richtiger" MSI Product ID kein Source List Update möglich ist und die Quellen auf einem zentralen Share liegen mögen - *grrr*
Viel Erfolg
NullReferenceException
1
Hi @Dirmhirn,
stimme @mayho33 zu bzw. meine Empfehlung geht ebenfalls Richtung SCCM ...
winget klingt zuerst ziemlich interessant und vielversprechend - aber gibt es immer wieder Probleme mit diversen Apps wo sich nicht "Systemweit" installieren lassen sondern sich dann ins Userprofil installieren. Des Weiteren "musst" du dich auf das Repository verlassen können und davon ausgehen, dass A) hier die aktuellen Versionen vorhanden sind und B) diese auch sauber sind (was auch nicht immer 100% der Fall ist) und C) musst du dich darauf verlassen können, dass die XML im Hintergrund sauber gepflegt sind, damit du auch eventuell ein Update von vorhandener Software machen kannst - bei Adobe Reader zum Beispiel klappt das seit Jahren nicht und wird im Netz breit diskutiert.
Schöne Grüße
@kontext
stimme @mayho33 zu bzw. meine Empfehlung geht ebenfalls Richtung SCCM ...
winget klingt zuerst ziemlich interessant und vielversprechend - aber gibt es immer wieder Probleme mit diversen Apps wo sich nicht "Systemweit" installieren lassen sondern sich dann ins Userprofil installieren. Des Weiteren "musst" du dich auf das Repository verlassen können und davon ausgehen, dass A) hier die aktuellen Versionen vorhanden sind und B) diese auch sauber sind (was auch nicht immer 100% der Fall ist) und C) musst du dich darauf verlassen können, dass die XML im Hintergrund sauber gepflegt sind, damit du auch eventuell ein Update von vorhandener Software machen kannst - bei Adobe Reader zum Beispiel klappt das seit Jahren nicht und wird im Netz breit diskutiert.
Schöne Grüße
@kontext
1Zitat von @5388706050:
Und selbst M$ torpediert den Windows Installer mit so 'nem Sch*** wie click-to-run, wo mangels "richtiger" MSI Product ID kein Source List Update möglich ist und die Quellen auf einem zentralen Share liegen mögen - *grrr*
Und selbst M$ torpediert den Windows Installer mit so 'nem Sch*** wie click-to-run, wo mangels "richtiger" MSI Product ID kein Source List Update möglich ist und die Quellen auf einem zentralen Share liegen mögen - *grrr*
@5388706050:
Dies und alles was du davor geschrieben hast. Damit hast du 100%ig den Nagel auf den Kopf getroffen 👍
@kontext:
Oh ja! Diese unsäglichen Apps die sich unbedingt in den User-Hive reinrotzen müssen, aber ganz bestimmt administrative Rechte brauchen, weil ein klein wenig in HKLM herummalen muss schon sein 😡🤬🤦♂️.
Immer mehr Linux-Entwickler wollen unbedingt auf Windows ...und haben dabei offensichtlich keine Ahnung wie Windows funktioniert oder Windows Installer. Ich persönlich bekomme da sooooo nen Hals.
Habe schon einige solcher Apps captured und in ein MSI umgebaut. Andernfalls nicht verwaltbar.
Winget zähle ich schon fast dazu zu den NoGo-Tools. Als wäre jeder UseCase in eine simple Form passend...
Guten Morgen,
auch ich stimme @mayho33 zu. Mit einer Softwareverteilung ist das Thema entspannter. Wir nutzen Baramundi für die Softwareverteilung.
Ja es gibt ein Paketierungsteam, welche die Softwarepakete erstellt und bereitstellt.
Wermutstropfen: Manche Pakete werden nicht aktualisiert bzw. nicht häufig genug. Ich habe schon so oft via Ticket reklamiert.
Gruss Penny.
auch ich stimme @mayho33 zu. Mit einer Softwareverteilung ist das Thema entspannter. Wir nutzen Baramundi für die Softwareverteilung.
Ja es gibt ein Paketierungsteam, welche die Softwarepakete erstellt und bereitstellt.
Wermutstropfen: Manche Pakete werden nicht aktualisiert bzw. nicht häufig genug. Ich habe schon so oft via Ticket reklamiert.
Gruss Penny.
Zitat von @Penny.Cilin:
Guten Morgen,
auch ich stimme @mayho33 zu. Mit einer Softwareverteilung ist das Thema entspannter. Wir nutzen Baramundi für die Softwareverteilung.
Ja es gibt ein Paketierungsteam, welche die Softwarepakete erstellt und bereitstellt.
Ahh. Das liebe alte Baramundi! Alt, weil es echt schon alt ist und lieb, weil mein damaliger Vorgesetzter immer getröstet hatte mit den Worten: "Wir bekommen eh bald SCCM!"Guten Morgen,
auch ich stimme @mayho33 zu. Mit einer Softwareverteilung ist das Thema entspannter. Wir nutzen Baramundi für die Softwareverteilung.
Ja es gibt ein Paketierungsteam, welche die Softwarepakete erstellt und bereitstellt.
Wermutstropfen: Manche Pakete werden nicht aktualisiert bzw. nicht häufig genug. Ich habe schon so oft via Ticket reklamiert.
Na, das hat man auf SCCM aber auch. Kommt darauf an welche Produkte gemeint sind. Alles was sich Office, Edge, Adobe nennt kann via einer sogenannten ADR (Automatic Deployment Rule) ganz einfach auf Stand gehalten werden.In unserem Fall sind weit über 1000 Produkte (ja! Tausend) im Spiel. Viele davon sind ein Packager-Alptraum, weil die Hersteller einfach nicht daran denken, dass es vielleicht einen Silent-Switch geben sollte oder nicht mal wissen was der Begriff "MassDeployment" bedeutet und irgendwelchen Sch..ß aufführen.
Sowas wird dann oft von mir captured und in einer "richtigen" MSI verdröselt. Sowas wie M$ das ursprünglich entwickelt hat, aber nun selbst mit den WiX-Tools verwässert und verschlimmbessert. Beim Capturing ist der Aufwand aber auch extrem hoch, weil das einfach super ungenau ist. 🤷♂️🤷♂️
Es ist also nicht immer einfach ein Produkt auf Stand zu halten. Nicht nur, weil es den Hersteller vielleicht gar nich mehr gibt oder weil er einfach keine Updates raus haut sondern auch, weil vielleicht zu wenige Mitarbeiter da sind das zu machen. 🤷♂️
Keine Ahnung, auf welchem Releasestand bei uns Baramundi hat. Nicht meine Baustelle. Wenn ich dann sehe, welchen Releasestand manche Pakete haben. Und nie aktualisiert werden, dann bekomme ich einen dicken Hals, wenn ich die fadenscheinigen Ausreden höre.
Auch bei uns geht es um eine vierstellige Anzahl an Softwareprodukten.
Gruss Penny.
Auch bei uns geht es um eine vierstellige Anzahl an Softwareprodukten.
Gruss Penny.
Danke für eure Inputs. Dann ist winget nicht die Eierlegendewollmilchsau für uns. Der Eindruck, dass es für lokal ganz nett ist, aber nicht mehr, passt also.
Wir haben DPs und MPs gloal verteilt. Paketieren läuft auch ganz gut, nzr haben wir dafür nur "0.5 Ressourcen". Lieber Azubis verheizen, zum händisch installieren.
Sg Dirm
Wir haben DPs und MPs gloal verteilt. Paketieren läuft auch ganz gut, nzr haben wir dafür nur "0.5 Ressourcen". Lieber Azubis verheizen, zum händisch installieren.
Sg Dirm
Zitat von @Dirmhirn:
Paketieren läuft auch ganz gut, nzr haben wir dafür nur "0.5 Ressourcen". Lieber Azubis verheizen, zum händisch installieren.
Oje! Ja! Damit raufe ich auch rum. Würde gerne alles automatisieren, aber Cheffchen verbietet es, wenn nicht mindestens 20 Needs pro Software vorhanden sind. Und deswegen hetzen sich die Turnschuhe fast zu tode, obwohl ein neues Package anlegen mit Testen im Optimalfall nur ~1 Stunde dauert. Oft weniger. Mit eventueller Korrektur und Nacharbeiten vielleicht 3 oder 4 Stunden...Paketieren läuft auch ganz gut, nzr haben wir dafür nur "0.5 Ressourcen". Lieber Azubis verheizen, zum händisch installieren.
Die größten Zeitfressen sind mAn unklare Angaben bei den Anforderungen. Hatte schon Fälle da musste ich 15x neu paketieren oder abändern weil immer wieder was vergessen wurde anzufordern. 🤦♂️🤷♂️
Zitat von @Penny.Cilin:
Keine Ahnung, auf welchem Releasestand bei uns Baramundi hat. Nicht meine Baustelle. Wenn ich dann sehe, welchen Releasestand manche Pakete haben. Und nie aktualisiert werden, dann bekomme ich einen dicken Hals, wenn ich die fadenscheinigen Ausreden höre.
Hm... Vielleicht liegts auch am Mangel an guten Dokus. Habe schon einige Arbeitsweisen gesehen und bei vielen mochte ich einfach nur abkotzen, weil riesen Saustall mit 0 Konventionen. Jeder kochte sein eigenes Süppchen und mit jeden neuen Package wurde das Scripting-Rad neu und noch unnötig komplexer erfunden mit kilometerlangen Batchscrips usw. Wie es auf den Shares ausgesehen hat war oft schlimmer wie in Messi-Wohnnungen. Da ist der Überblick natürluch scnell weg und alles wird mühsan.Keine Ahnung, auf welchem Releasestand bei uns Baramundi hat. Nicht meine Baustelle. Wenn ich dann sehe, welchen Releasestand manche Pakete haben. Und nie aktualisiert werden, dann bekomme ich einen dicken Hals, wenn ich die fadenscheinigen Ausreden höre.
Auch bei uns geht es um eine vierstellige Anzahl an Softwareprodukten.
Na dann denke ich du hast bestimmt eine Vorstellung davon wie schwer es sein kann. Wenn dann vielleicht auch kein richtiges Ablage-System vorhanden ist, tun sich neue Mitarbeiter entsprechend schwer und hauen schnell den Hut drauf und langjährige Mitarbeiter sind gefrustet.