uridium69
Goto Top

MSI Ersteller

Hallo

Ich bin auf der Suche nach einem MSI ersteller, damit man eine Software welcher aus einer EXE-Datei besteht sauber installieren kann mit allen Optionen bzw. für den Benutzer schlussendlich komplett silent, und es am ende ein reines MSI Packet wäre, wer kennt da ein sehr gutes Programm ? Es darf auch was kosten und muss nicht zwingend Freeware sein, mit dem SCCM welches wir haben (Stand Server 2012 R2) kann man leider nicht jede Software problemlos paketieren manchmal klappt es bei anderen wieder nicht oder dann klappt wohl die Installation aber nicht die Deinstallation (obwohl wenn man alles manuellinstalliert es keine Probleme gibt)

Content-ID: 9274899180

Url: https://administrator.de/contentid/9274899180

Ausgedruckt am: 28.09.2024 um 16:09 Uhr

kpunkt
kpunkt 24.06.2024 um 12:54:50 Uhr
Goto Top
MacLeod
MacLeod 24.06.2024 um 12:59:40 Uhr
Goto Top
departure69
departure69 24.06.2024 um 14:37:27 Uhr
Goto Top
Hallo.

Scalable Package Manager (oder so ähnlich).

Viele Grüße
user217
user217 24.06.2024 um 14:53:15 Uhr
Goto Top
emco remote installer
ThePinky777
ThePinky777 24.06.2024 aktualisiert um 17:59:02 Uhr
Goto Top
Zitat von @uridium69:

Hallo

Ich bin auf der Suche nach einem MSI ersteller, damit man eine Software welcher aus einer EXE-Datei besteht sauber installieren kann mit allen Optionen bzw. für den Benutzer schlussendlich komplett silent, und es am ende ein reines MSI Packet wäre, wer kennt da ein sehr gutes Programm ? Es darf auch was kosten und muss nicht zwingend Freeware sein, mit dem SCCM welches wir haben (Stand Server 2012 R2) kann man leider nicht jede Software problemlos paketieren manchmal klappt es bei anderen wieder nicht oder dann klappt wohl die Installation aber nicht die Deinstallation (obwohl wenn man alles manuellinstalliert es keine Probleme gibt)

Ich muss dir sagen kurz mal lernen wie man MSI richtig baut ist nicht mal in paar mausklicks erledigt.
Das beherrschen nicht mal die meisten Anbieter korrekt, um konkret zu sein ausser Microsoft sind alle zu dämlich.

Aus Erfahrung in einem Netzwerk ca. 9000 Clients mit SCCM muss ich dir sagen 1% Fehler hast du IMMER.
Ich behaupte auch frech die User sind oft schuld, oder die Hardware der Clients.

Also egal langer Rede kurzer Sinn, im SCCM kannst du auch per Script Dinge installieren und deinstallieren.
Wenn dann fehler vorkommen, liegt es oft einfach nur daran das man nicht eventualitäten einplant.
Beispiel bei dir, du willst nur ne Exe Lokal ins Programm verzeichnis setzen.
Installieren dürfte nicht das problem sein, aber nun kommen wir zum updaten oder deinstallieren.
hast du beachtet das man den Task der Exe vorher killen muss falls er auf ist, den nur dann wirst du das File löschen können, oder ersetzen können, und so zieht sich das quer beet bei vielen Applikationen.
Weitere beliebte Fehlerquelle, keine Dynamischen Pfade in den Scripts eingebaut, z.B. hast du mehrer Distribution POints dann muss das script ja dynamisch ausführbar sein, von egal wo... Dann kommen wir auch gleich auf Pfad Probleme mit Leerzeichen drin, werden die Pfade im Script berücksichtigt.

Und hier hilft es sich Scripts zu standardtisieren.
Und als Vorlagen zu verwenden damit man Fehler minimiert.

HIer mal ein Beispiel für DOS

@echo off

set WORKINGDIR=%~dp0

REM msiexec /i "%WORKINGDIR%INSTALL.msi" TRANSFORMS="%WORKINGDIR%Transform.mst" REBOOT=ReallySupress /qb! /Lv "%windir%\log\PAKET_LOGDATEI.log"  
REM cscript.exe "%WORKINGDIR%Update.vbs"  
REM "%WORKINGDIR%setup.exe" /S  
REM "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -executionpolicy Unrestricted -File "%WORKINGDIR%PowerShellScript.ps1"  

Damit hat man eine Vorlage egal ob man ein .msi installieren, .vbs oder .ps1 script starten will oder eben ne ordinäre .exe mit Parametern.

und durch steige weiter entwicklung definiert man so einen funktionierenden standard und vermeidet fehler.

Das ganze kann man auch in scripts machen, z.B. .vbs eine funktion am ende des Scripts welche das Working Dir ermittelt

function WorkingDir()
	Dim sWorkingDir
	Dim sLeftString
	Dim sLenString

	sWorkingDir = WScript.ScriptFullName
	sLeftString = Right(sWorkingDir,1)

	Do Until sLeftString = "\"  
		sLenString = Len(sWorkingDir)-1
		sWorkingDir = Left(sWorkingDir,sLenString)
		sLeftString = Right(sWorkingDir,1)
	Loop

	WorkingDir = sWorkingDir
end function

usw.. usf....

Und in Powershell das gleiche in Grün und somit kann man alles abdecken.

Phylosophisch rate ich davon ab selbst MSI Dateien zu bauen.
warum?

Man pfuscht einfach in die Setups der Hesteller. Hast du dann mal ein ernstes Problem, dann wird dir der Hersteller sagen >> viel spass hast du selbst verpfuscht.

Daher neigten wir dazu möglichst unmodifizierte Hersteller Setups in Scripte einzubinden, und bei msi hält dich ja keiner davon ein ein .mst file zu erstellen für transfomationen (anpassen der Variablen) an deine bedürfnisse. Aber das Hersteller .msi anfassen war tabu.

Das einzige wozu selbst .msi erstellen top war, was wir genutzt haben, ist wenn der hersteller perse zu doof war sein Produkt richtig konfigurieren zu lassen. z.B. Adobe Reader installiert sich eigentlich durchs .msi mehr als Maschinen Programm, dennoch werden dann User Settings gemacht die dann im user profil landen, man hat aber da von hersteller seite keine konfig möglichkeiten eingeplant.
Also haben wir einen Userteil_AdobeReader.msi gebaut welche lediglich ein vbs Script starten und User settings korrigiert, und zwar mit der Active Setup technologie von .msi. Bedeutet es wird nur einmalig die settings beim user gesetzte nach der ersten anmeldung nach der installation.
Beim deinstallieren musste man halt dann 2 mal .msi deinstallieren, unseres und das von adobe...

Hoffe das bringt dich weiter und auf die richtige lösung die du brauchst.

Und wenn man es Grafisch witzig machen will nutze .hta face-smile
Ist ne art VBS Script gespickt mit html... kann man prima Setupfenster damit bauen die aufpoppen mit Firmenlogo und daraus wie aus jedem .vbs dann entsprechende Scripts starten.
Wobei ich nicht sicher bin wie lange MS noch .hta unterstützen wird.. face-smile

Noch ein Endwort: ich hab noch nie verspürt ein extra .msi bauen zu müssen. ausser oben erwähnte aktiv setup userteil .msi files... und das bis zur grössenordnung 9000 Clients. Ja ich weiss manche machen das, aber wie gesagt das birgt enorme risiken mit sich, und nur der optik wegen finde ich das nicht vertretbar. Alles andere kann man scripten.

Wir haben von InstallShield das Produkt verwendet um .msi Files zu erstellen, hat damals ca. 5000,-/Jahr gekostet die Lizenz.
Epixc0re
Epixc0re 24.06.2024 um 23:39:17 Uhr
Goto Top
Salut,

https://www.silentinstall.org/
mit dem hab ich gute Erfahrungen gemacht bisher.

LG Stefan
Dirmhirn
Dirmhirn 25.06.2024 um 08:49:22 Uhr
Goto Top
Hi,

auch etwas OT, aber wieso SCCM 2012 R2?
Mit der aktuellen Version gibt es fast keine Probleme mit Installern (von SCCM Seite)
Einzig, wenn du ehrere GB und tausende an files hast, dann ist es besser die Dateien zu zippen.

Ein Vorteil an Scripts ist auch die Versionierung und das testen abseits von SCCM.

Sg Dirm
ThePinky777
ThePinky777 26.06.2024 aktualisiert um 09:09:25 Uhr
Goto Top
Zitat von @Dirmhirn:

Hi,

auch etwas OT, aber wieso SCCM 2012 R2?

hm wir setzen hier aktuell SCCM 2309 ein, aber ich habe damals auch mit SCCM 2012 R2 gearbeitet und
ich fand das deutlich besser, beim 2309 biste finde ich teilweise im Blindflug, ja es funktioniert aber du siehst nicht so viel wie damals.

Bedeutet beim 2012 haste ein Paket gemacht distribution points gesetzt ud konntest klar die Verionen sehen auf den distribution points ohne gefühlt tausend menüs aufzuklappen.

dann haste Progams erstellt also synonym zu Deployment Types heute.

dann heute erstellst das Deployment, aber das ist finde ich VOLL unübersichtlich. im SCCM 2012 konntest du da die eigenschaften ansehen und sehen wieviel clients bereits angeschossen wurden und wie viele nicht und wieviele schon gelaufen sind etc... das fehlt mir im neuen SCCM komplet, da biste irgendwie halb blind finde ich.
Man kann sich bissl behelfen mit Tricks aber das ist nicht das selbe.

Auch die Collection steuerung fand ich damals viel besser... also settings anpassen usw...

was ich im neuen SCCM gut finde ist das CMPivot feature um live abfragen zu machen, das ist echt ein pluspunkt vom neuen SCCM.

Und im neuen ist es auch einfacher per PXE Betriebssysteme auszurollen und die Treiber Einbindung, das war damals deutlich komplexer.