Display progress messages to the Interactive User
Add your rating:
I've been wondering about this problem for some time now and was wondering if anyone else has been inspired to tackle this via a scripted solution.
We typically distribute our packages in Altiris via Software Delivery using the local System account with "User interaction required" disabled. This typically hides all output from the installation, including custom action command prompt windows, progress messages, dialogs, etc. I would like to be able to display progress messages to the Interactive User to show warnings, status, etc. without enabling "User interaction required."
I have some idea how I might accomplish this, but the idea I have in mind is somewhat kludgey and less than ideal. I was hoping someone might have an elegant solution to this. Anyone have any suggestions?
If you have any reasons not to try this, please let me know. :)
Thanks.
We typically distribute our packages in Altiris via Software Delivery using the local System account with "User interaction required" disabled. This typically hides all output from the installation, including custom action command prompt windows, progress messages, dialogs, etc. I would like to be able to display progress messages to the Interactive User to show warnings, status, etc. without enabling "User interaction required."
I have some idea how I might accomplish this, but the idea I have in mind is somewhat kludgey and less than ideal. I was hoping someone might have an elegant solution to this. Anyone have any suggestions?
If you have any reasons not to try this, please let me know. :)
Thanks.
0 Comments
[ + ] Show comments
Answers (4)
Please log in to answer
Posted by:
pjgeutjens
13 years ago
Joshua,
without going into too much detail (I was not the one who coded this solution), I can tell you what we built at my current site is a service that runs in the background on each client PC, keeping an eye on the event system, combined with a function in our deployment scripts to send out said system events (application name, type of message, text, etc...). So the service catches the system events coming from the installation scripts and shows the corresponding messages in a nice little bubble on the bottom right of the screen, bypassing the 'no interaction allowed' limitation of, in our case, SCCM.
Rgds,
PJ
without going into too much detail (I was not the one who coded this solution), I can tell you what we built at my current site is a service that runs in the background on each client PC, keeping an eye on the event system, combined with a function in our deployment scripts to send out said system events (application name, type of message, text, etc...). So the service catches the system events coming from the installation scripts and shows the corresponding messages in a nice little bubble on the bottom right of the screen, bypassing the 'no interaction allowed' limitation of, in our case, SCCM.
Rgds,
PJ
Posted by:
mazessj
13 years ago
PJ,
I was thinking of something along those lines -- something that passes messages from the installation to a sleeping process that displays the passed messages. However, I was hoping to figure out something simpler -- something that doesn't require a background process running all the time. I was hoping to be able to somehow directly open some kind of message box or progress dialog on the Interactive User's desktop. This article gives the impression that this is possible.
Thanks.
I was thinking of something along those lines -- something that passes messages from the installation to a sleeping process that displays the passed messages. However, I was hoping to figure out something simpler -- something that doesn't require a background process running all the time. I was hoping to be able to somehow directly open some kind of message box or progress dialog on the Interactive User's desktop. This article gives the impression that this is possible.
Thanks.
Posted by:
pjgeutjens
13 years ago
Posted by:
mazessj
13 years ago
Hmm... Come to think of it, the examples that I've seen of this -- InstallShield script engine's IDriver and Sophos Anti-Virus's AutoUpdate iMonitor -- seem to follow the same "message passing" philosophy. IDriver and Sophos iMonitor have AppIDs configured to run as the Interactive User. They're able to interact with the logged on user even if they're installing/running from a non-interactive session.
Microsoft has a statement in the above mentioned article that says, "We recommend that the [author] use a client/server technology such as remote procedure call (RPC), sockets, named pipes or COM to interact with the logged-on user." I believe the above InstallShield and Sophos examples are using COM. As I have little experience working with COM objects or the other technologies suggested by Microsoft, it appears that this may be beyond my current skill level.
Microsoft has a statement in the above mentioned article that says, "We recommend that the [author] use a client/server technology such as remote procedure call (RPC), sockets, named pipes or COM to interact with the logged-on user." I believe the above InstallShield and Sophos examples are using COM. As I have little experience working with COM objects or the other technologies suggested by Microsoft, it appears that this may be beyond my current skill level.
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
so that the conversation will remain readable.