Tricky Deployment
My company has a new application that was developed in house. Whenever the back end is upgraded a new version of the application MUST be deployed. It is not backwards compatible.
This will be a hassle especially with laptop users. Most users do not logoff their machines so I cannot deploy with "no user logged on" as the SCCM method. Also, this would not work with the laptop users anyway as most of them just shut the lid when done and hardly ever logoff.
How can I get a deployment that requires no user interaction? Is there a way with SCCM or a script for the application that will compare the front end .msi with the backend and then install the new version automatically? Or is that something that needs to be built into the .msi?
This will be a hassle especially with laptop users. Most users do not logoff their machines so I cannot deploy with "no user logged on" as the SCCM method. Also, this would not work with the laptop users anyway as most of them just shut the lid when done and hardly ever logoff.
How can I get a deployment that requires no user interaction? Is there a way with SCCM or a script for the application that will compare the front end .msi with the backend and then install the new version automatically? Or is that something that needs to be built into the .msi?
0 Comments
[ + ] Show comments
Answers (2)
Please log in to answer
Posted by:
anonymous_9363
13 years ago
You need to introduce the developer(s) to The Packager's Baseball Bat.
Most apps of this nature that I've encountered use a service to update the main client application. The client app requests version details from the back end and, if the two don't match, requests that the service go off and fetch the update (or downgrade).
Note also that most such apps are generally completely self-contained and require no junk in SYSTEM32 (and will thus not walk over your finely-crafted build), and have no dependency on rebooting to cleanly update.
If your develeper(s) can't cope with something as simple as that, find some competent ones.
I appreciate though that developers are a rarified bunch and will find pretty much any excuse to not put the above into practise. Thus, it falls to you to embarrass them by building something which does more or less the same thing but in, say, script.
Alter your package so that it starts a script, rather than an executable. The script will go off and divine what client version the back end requires, then which version the client is at. If a new version is required, it will retrieve the appropriate package name (from a network-located INI/INF/XML, perhaps?) and install it. After checking that the install completed successfully, it will call the executable. A competent scripter could knock up a shell in a few hours. Call it a week to add decent error-trapping/logging/reporting.
Of course, another scenario comes to mind: why not have the client run FROM the back end? Since the client must, by definition, have access to the back end's network location, what's to stop them running the client EXE from there?
Most apps of this nature that I've encountered use a service to update the main client application. The client app requests version details from the back end and, if the two don't match, requests that the service go off and fetch the update (or downgrade).
Note also that most such apps are generally completely self-contained and require no junk in SYSTEM32 (and will thus not walk over your finely-crafted build), and have no dependency on rebooting to cleanly update.
If your develeper(s) can't cope with something as simple as that, find some competent ones.
I appreciate though that developers are a rarified bunch and will find pretty much any excuse to not put the above into practise. Thus, it falls to you to embarrass them by building something which does more or less the same thing but in, say, script.
Alter your package so that it starts a script, rather than an executable. The script will go off and divine what client version the back end requires, then which version the client is at. If a new version is required, it will retrieve the appropriate package name (from a network-located INI/INF/XML, perhaps?) and install it. After checking that the install completed successfully, it will call the executable. A competent scripter could knock up a shell in a few hours. Call it a week to add decent error-trapping/logging/reporting.
Of course, another scenario comes to mind: why not have the client run FROM the back end? Since the client must, by definition, have access to the back end's network location, what's to stop them running the client EXE from there?
Posted by:
Lucid
13 years ago
If you can't do what VBScab mentions, maybe just make a collection of only your laptops and then deploy weather or not a user is logged in...You could always use a script wrapper and toss up a splash screen to the logged in laptop user if you wanted (and have it first check to make sure they aren't currently running the program)...
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.
