9
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
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
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: 485483
Url: https://administrator.de/contentid/485483
Printed on: April 24, 2024 at 23:04 o'clock
9 Comments
Latest comment
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.
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.
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.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.
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!
Was sagt denn das Log?
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.Was sagt denn das Log?
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.
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!
In der CustomAction => Wscript.Quit(0) => CA call, aber kein Error (????)
von [SYSTEMDIR] => WScript.Quit(0) => OK
Flexera! Ich liebe euch....nicht!
Was meinst Du mit "CA call, aber kein Error"?
"Quit(0)" liefert nun mal Errorlevel 0. Oder was meinst Du?
"Quit(0)" liefert nun mal Errorlevel 0. Oder was meinst Du?
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"Tja! Fehler gefunden:
In der CustomAction => Wscript.Quit(0) => CA call, aber kein Error (????)
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.
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"Tja! Fehler gefunden:
In der CustomAction => Wscript.Quit(0) => CA call, aber kein Error (????)
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 WSHgehostet 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}:
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.
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!
