It's Time to put on the Big Boy Pants...
For the past year I have been working for a company, that when I started with them, had a very crude Wisescript that was used to Wrap all installs being deployed. At the time they were strictly XP.. Since I came on board I initially tried to get them to adopt a 90 to 95% MSI based rule for all installs being deployed. When that fell on deaf ears, I proceeded to create a more comprehensive Wrapper script for us to use that would ad in faster delivery of packages, as well as add in troubleshooting when problems arose. I have grown this wrapper so that it would address all of the following possible sceneros...
- Uninstalls
- Checks for Current and Previous Versions
- Check for current running process, warning users to save before continuing install
- Checks and calls for Required PreReq Installs by parsing an INI file with appname and Product codes
- Creating Logs for everything installed (all Prereqs, vendors install, as well as a Log file for the Wrapper itself)
- Checks for 64 bit OS, so a different install could be run if necessary
- and of course capturing the Exit Code from the main vendors installs to pass along to SCCM
It has grown quite complex, expecially when we switched over to Windows 7. However, in the back of my mind I continue to be nagged by all of its shortcomings. For starters, Wisescript is 32 bit only, and running it on a 64 bit OS has a few challengers, another is the fact that in some cases the Wrapper actually gets in the way of some of the vendor's created MSI's logic. Lastly anytime we are trying to run a Vendor's EXE within the wrapper, you get popups warning the users. So either you create an Environment Variable SEE_MASK_NOZONECHECKS=1 so that Exe's can be run from the network, or you can copy all source media to the pc and then run it. We choose the EnvVar route.
I said all that to say, I want to scrape the Wrapper idea entirely and create 2 or 3 MST/MSI Templates that handle the following situations...
- MST with all of our logic that can be applied to Vendor MSI's
- IST template that can be applied if required to create a Setup Capture
- ISM or WSI file to handle all Vendor's EXE installs (basically use a Custom Action to run the exe from binary or installed files)
Does anyone have any suggestions to migrate some of our logic over to a strictly MSI based install method of deployment?
One last thing... We have a banner that runs on top of the desktop that runs the entire time the install is running until its complete. Users have grown accustom to this being there so they know that when its gone, the install is done. Is it possible to Create a dialog that has Variablized text that can popup and stay above all other windows, but not allow vendors dialogs to display? For instance we run all MSI's with /qb! so they at least see progress, but our banner is actually running as a different process that is killed at the end of the script. This is easy with Wisescript but I dont know how to do this with MSI Dialogs. I tried to run our banner process from a Custom Action, but I cant pass the Text Variables. It just displays the variable and does not resolve it.
For the curious, our Wisescript commandline is...
VendorAppVersion and StrReboot are variables inside script. We also have a completely different message for Uninstalls.
So either I try and create a dialog that runs within our Wrapper MSI, or I try to get our current Banner.exe to run and then kick off the vendors install.
All suggestions would be greatly appreciated for either getting banner to work, or in migrating Wisescript to MSI.
Thanks in advance.
Randy
Answers (0)
Be the first to answer this question
If you want to abandon WiseScript, you could build an HTA or, at worst, a VBScript that uses IE as a dialog "helper". There's quite a nice VBS class knocking about somewhere for that.
I presume that you're not using a "proper" deployment system e.g. SCCM? If you are, why not just let it do its thing in the background? Do users *really* need to see an installation's progress? Just push it out to their machines. Equally, if you're pure MSI, you could do worse than use Group Policy deployment. They'd sure see *that* in progress!! The downside with GP, of course, is that those deployments happening during start-up/user log-in so your users wouldn't be able to work until they're complete. For those of us who have deployed something like Business Objects via GP, it's not as good way to be popular with your user base!
Lastly, I want to know *exactly* what's happening to my workstations so there is no way I'd be letting vendor EXEs loose on my estate! - anonymous_9363 11 years ago
Also since your moving to Windows 7, its a good chance to get away from all the legacy stuff. If you use SCCM, take advanatage of all its feats, it has great logging, reporting. other things I dont even know about. - rileyz 11 years ago
As far as users wanting to see a banner when app is running... The reason being is 90% of all apps in our environment are installed via RunAdvertisedPrograms. So it is essentially an install on demand by the users, once they are in the appropriate collection that is. So if they start the install, they should see something. All other shops I have worked in, we just pushed it to their pc silently.
On the vendor EXE topic, it depends what kind we are dealing with, if it contains MSI's, we normally extract them, if it has a ton of logic and is setup to run unattended, like Autocad for instance, we use the vendors deployment tool to create the MST, but inside of the INI we redirect all logs of all prereqs to our log file folder.
In some cases we create a response file for Install and Uninstall, and Pre Install all of the required PreReqs via the script prior to install being kicked off.
I started playing around creating a template MSI / ISM and I was able to get our banner process to work using Custom Actions.. Setting Properties, starting the Banner EXE. However the previous way we use to get a new line in the banner was %CRLF% but that does not work.. I looked thru the Help files and they reference \r\n for Carriage Return, and then New Line. So i'm about to test that.
drose23
I cant post the whole Script, but what are some of the areas that plague ya, I could post those if we have encountered something similar. Also, what did I initially posted that peaked your interest?
Is there a place on itninja.com where i can post code? - ekgcorp 11 years ago
Checks for Current and Previous Versions
Check for current running process, warning users to save before continuing install
Checks and calls for Required PreReq Installs by parsing an INI file with appname and Product codes
Creating Logs for everything installed (all Prereqs, vendors install, as well as a Log file for the Wrapper itself)
Checks for 64 bit OS, so a different install could be run if necessary
and of course capturing the Exit Code from the main vendors installs to pass along to SCCM"
why not use SCCM Task Sequence if you want to do these and you can have it show a progress bar on screen - sparky86 11 years ago
Can they also do logic like a script where it checks the pc for 64/32 os and then installs a different install depending on the outcome? - ekgcorp 11 years ago