mayho33
Goto Top

Flexera Installshield Basic MSI Shortcut für jeden User anlegen und löschen

Hi @ All

MSIs zu erstellen ist ein wichtiger Bestandteil bei uns im Unternehmen. Leider nicht immer einfach und manche Lösungen sind eher holprig als elegant.

Leider auch die, zu der ich eine Frage an euch habe. Ich hoffe auf fachkundige Unterstützung.

Doing:
Ich habe jeweils in einer Custom Action (MSi Type Numper 38) ein VBScript hinterlegt das für jeden User der bereits einmal am Client angemeldet war, bei der Installation ein Shortcut unter SendTo anlegt und bei der Deinstallation wieder löscht. Für alle neuen User gibt es ein ActiveSetup.

Das Problem:
Das funktioniert wunderbar, wenn man die MSI mit administrativen Rechten im User-Kontext ausführt, aber nicht, wenn man die Installation im SYSTEM-Kontext durchführt was bei Massendeployments via SCCM usus ist. Auch nicht, wenn ich die In-Script-Execution auf Deferred in System Context umstelle (MSI Type 3110).

Ich habe das zwar so gelöst, dass ich beide Scripte nun in die SupportFiles ausgelagert habe und in der CA via Type 3106 (New Exe; Path referencing an directory) ausführe, frage mich aber warum es nicht direkt in der CustomAction funktioniert.

Beide Scripte laufen unabhängig zur MSI was Properties usw. angeht, holen sich alle notwendigen Pfade usw. selbständig aus der Registry usw. und legen die Shortcuts an der gewünschten Stelle ab bzw. löschen diese.

Frage:
Was habe ich nicht verstanden?
Warum funktionieren die Scripte von SUPPORTDIR aus aber nicht in der CA?

Danke für eure Hilfe!

Grüße!

Mayho

Content-Key: 485483

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

Printed on: May 18, 2024 at 06:05 o'clock

Member: emeriks
emeriks Aug 15, 2019 at 14:22:38 (UTC)
Goto Top
Hi,
ich kann Deine konkrete Frage nicht beantworten.

Aber mal was anderes:
Warum nicht ein MSI erstellen, welches "per Benutzer" installiert und nur diese Shortcuts für nur den aktuellen Benutzer anlegt. Dann dieses MSI per GPO unter "Benutzerkonfiguration" verteilen.

E.
Member: mayho33
mayho33 Aug 15, 2019 updated at 18:44:21 (UTC)
Goto Top
Zitat von @emeriks:

Hi,
ich kann Deine konkrete Frage nicht beantworten.

Aber mal was anderes:
Warum nicht ein MSI erstellen, welches "per Benutzer" installiert und nur diese Shortcuts für nur den aktuellen Benutzer anlegt. Dann dieses MSI per GPO unter "Benutzerkonfiguration" verteilen.

Das macht eh das Active Setup (wie oben beschrieben). Dafür ist halt ein Neustart, mindestens ein LogOff/LogOn notwendig. Das will ich umgehen, weil der Kunde (oje wieder ein Kunde :D) Neustarts so gering wie möglich halten will.

Wie gesagt: Es funktioniert via SUPPORTDIR und Type 3106 auch im SYSTEM-Kontext. Das Warum bleibt.

Eine extra MSI ist natürlich eine Möglichkeit, schaut aber auch nicht schön aus, wenn das x MSIs rumgurken die sich alle gleich oder ähnlich nennen

Bei uns ist SCCM das führende System was Deploynemt angeht. Hat klare Vorteile was Monitoring angeht.

Grüße, Mayho!
Mitglied: 140777
140777 Aug 16, 2019 updated at 07:04:28 (UTC)
Goto Top
Was sagt denn das Log?
Member: mayho33
mayho33 Aug 16, 2019 at 08:18:37 (UTC)
Goto Top
Zitat von @140777:

Was sagt denn das Log?
Das log sagt, dass die CA gestartet und erfolgreich beendet wurde. Nur wurde der Code wie es scheint nicht ausgeführt.
Mitglied: 140777
Solution 140777 Aug 16, 2019 updated at 09:23:19 (UTC)
Goto Top
Nur wurde der Code wie es scheint nicht ausgeführt.
Hast du das überprüft?
Lass mal im VBS Code detailliert loggen ob dort überhaupt was ausgeführt wird.
Member: mayho33
mayho33 Aug 16, 2019 at 15:17:05 (UTC)
Goto Top
Tja! Fehler gefunden:

In der CustomAction => Wscript.Quit(0) => CA call, aber kein Error (????)
von [SYSTEMDIR] => WScript.Quit(0) => OK

Flexera! Ich liebe euch....nicht!
Member: emeriks
emeriks Aug 16, 2019 at 15:19:51 (UTC)
Goto Top
Zitat von @mayho33:
In der CustomAction => Wscript.Quit(0) => CA call, aber kein Error (????)
Was meinst Du mit "CA call, aber kein Error"?
"Quit(0)" liefert nun mal Errorlevel 0. Oder was meinst Du?
Mitglied: 140777
140777 Aug 16, 2019 updated at 15:45:32 (UTC)
Goto Top
Zitat von @mayho33:

Tja! Fehler gefunden:

In der CustomAction => Wscript.Quit(0) => CA call, aber kein Error (????)
? Wenn du 0 zurück gibst bdeutet das doch "no problem"
von [SYSTEMDIR] => WScript.Quit(0) => OK
Hmm, war das nicht so das innerhalb von MSIs ausgeführt es das WScript Object gar nicht von Haus aus gibt weil es nicht über den WSH gehostet ausgeführt wird ?! Also wird diese Zeile immer zu einem Fehler führen wenn du es nicht explizit vorher erstellt hast.

Quelle: https://docs.microsoft.com/en-us/windows/win32/msi/scripts
The installer runs script custom actions directly and does not use the Windows Script Host. The WScript object cannot be used inside a script custom action because this object is provided by the Windows Script Host. Objects in the Windows Script Host object model can only be used in custom actions if Windows Script Host is installed on the computer by creating new instances of the object, with a call to CreateObject, and providing the ProgId of the object (for example "WScript.Shell"). Depending on the type of script custom action, access to some objects and methods of the Windows Script Host object model may be denied for security reasons.
Member: mayho33
mayho33 Aug 16, 2019 at 15:48:35 (UTC)
Goto Top
Zitat von @140777:

Zitat von @mayho33:

Tja! Fehler gefunden:

In der CustomAction => Wscript.Quit(0) => CA call, aber kein Error (????)
? Wenn du 0 zurück gibst bdeutet das doch "no problem"

So sollte es sein. Da der Process aber (laut Beschreibung in deinem Kommentar) innerhalb der MSI, also als interner Process ausgefürt wird, Kannste Wscript.Quit(x) knicken.

von [SYSTEMDIR] => WScript.Quit(0) => OK
Hmm, war das nicht so das innerhalb von MSIs ausgeführt es das WScript Object gar nicht von Haus aus gibt weil es nicht über den WSH
gehostet ausgeführt wird ?! Also wird diese Zeile immer zu einem Fehler führen.

Hier wird das VB zwar von der MSI ausgeführt, wird aber als externer Process gewertet, weil aus %tmp%\{xy}:
ca

Quelle: https://docs.microsoft.com/en-us/windows/win32/msi/scripts
The installer runs script custom actions directly and does not use the Windows Script Host. The WScript object cannot be used inside a script >> custom action because this object is provided by the Windows Script Host. Objects in the Windows Script Host object model can only be used >> in custom actions if Windows Script Host is installed on the computer by creating new instances of the object, with a call to CreateObject, and
providing the ProgId of the object (for example "WScript.Shell"). Depending on the type of script custom action, access to some objects and
methods of the Windows Script Host object model may be denied for security reasons.

Na dann: MS! Ich liebe euch...nicht!