Software Deployment

Hi Barbara,

The company I work for currently want the following things done in their packages:
- Tool set : Wise Package Studio, ORCA, ProcMon, ORK Toolkit, etc
- Vendor MSIs need to be edited using transforms (goes w/o saying)
- All ICE errors and warnings to be resolved except some of the usual ones like 33, 91. Vendor MSI errors can be ignored.
- All packages must be installed in C:\Program Files\<App> directory.
- Nested installations are not allowed.
- Packages must be installable in UI as well as silent modes.
- Merge modules used must be only standard ones i.e. the vendor supplied ones.
- No Upgrades and patches are used by this company. In case there is a need a new package is created for that purpose.
- Apart from these there are certain small requirements like naming conventions and list of customer specific test cases that every package has to go through.

Hope this information helps.

Cheers

Hi barbe,

It would vary from company to company depending on the environment / packaging toolset / deployment tool etc in use.. Where I'm currently working;

Packaging tool is Wise Package Studio 7 (others generally use InstallShield)
The source files are not copied locally, SMS manages the payload but it's executed from a server share
We have no call for AutoIT - any scripting is done in VB or Wise Script
We use the Wise "Setup Capture" tool to repackage legacy installers inte MSI format

Regards,
Rob.

and Procmon of course [;)]

and Procmon of course

haha - goes without saying

ORIGINAL: MSIPackager

Hi barbe,

It would vary from company to company depending on the environment / packaging toolset / deployment tool etc in use.. Where I'm currently working;

Packaging tool is Wise Package Studio 7 (others generally use InstallShield)
The source files are not copied locally, SMS manages the payload but it's executed from a server share
We have no call for AutoIT - any scripting is done in VB or Wise Script

Yay!! I agree there's no call for AutoIT, though I used it myself on one occasion which could almost be a WTF in itself. [:D] One msft employee recommended against using vbscripts but why then would they have that in the list of supported CA's if not to be used? Hmmmm......
ORIGINAL: MSIPackager
We use the Wise "Setup Capture" tool to repackage legacy installers inte MSI format

How often do you do that, these days? I'm finding that more and more, a) things come in MSI format and b) for the one offs I can usually get my hands on the application files which makes it easier to just build a package in Wise and avoid the pitfalls of setup capture. I haven't done a capture in some time. Last time I tried it was (shudder) SAP 7.1 and decided to go with sanity and do the nwsapsetup route. It's been fine so far.

How often do you do that, these days?

Certainly not as often these days although we still get the odd one through that needs capturing. Shame really, in a geeky way doing the capture / clean-up / ICE errors and getting the package working is the most appealing part about packaging!

At least app-v means we'll be kinda capturing (sequencing) everything in the future [;)]

Cheers,
Rob.

How often do you do that, these days? Where are you working these days, Owen? I'd guess that a good 40% of packages passing through my clutches at my current client (a large UK insurance company) use a non-MSI installer.

Hi Barbara,
My client standards are the same that Rajit (India_repackaging) has given.
A few more -
Legacy applications:
1. Setup capture is done
2. All ICE errors and warnings to be resolved except some of the usual ones like 33, 91.[:'(]
3. All Conflicts are resolved.[>:]
4. Merge Modules(MM) are created for all shared files. The MMs created are preferred than the Vendor provided MMs as the client has got their own standards for the MMs used.[:o]

Vendor MSIs:
1. Minimal changes like necessary customizations are done.
2. No Ice(warnings and errors) are resolved. [:)]
3. All conflicts are ignored. [:)]
3. No merge module inclusions. Shared files are retained as they are provided. [:)]

But i get close to 50% of apps as legacy applications only....[:@]

And the applications are installed from a central server.
Scripting: VB and wise scripts.
Hope this helps..........


Cheers,
Rajesh.

ORIGINAL: aogilmor
Yay!! I agree there's no call for AutoIT, though I used it myself on one occasion which could almost be a WTF in itself.

Let me put on my Nomex suit, then I'll ask:

What's wroing with Autoit?
No I don't use it as a button-pusher to run an install, but I regularly use it for scripting, partly because I'm too busy/lazy to really learn VBS.. :)

I cannot speak for others, but in our environment Microsoft OSD (and at times just SMS) failed on packages that used an AutoIt script or batch file.

Why? I can't answer that. SMS would report success codes on packages that failed using AutoIt. Once we replaced the scripts/batches with .vbs, the issues with installation and reporting would be resolved. It forced me to learn some VBScript, which is beneficial in the long run.. Re-using code rules.

What's wroing with Autoit? Not a lot, except when it's used as a kludge to push dialog buttons.

As for learning VBS, there has to be...Jeez...how many?...more examples of VBScript around than for AI plus that knowledge gives you, by default (more or less) ASP. OK, ASP may be falling out of favour slightly but probably only for new projects. While you're browsing, just check how many web sites still use it. Your CV will be enhanced by its presence in your 'Skills' section, too. Go on! Bite the bullet, you'll be glad you did.

smason I am glad you qualified your statements with too lazy ..

vbs and autoIt are so close to being the same its not funny. the way i see it is if you can code well in autoIt chances are you can code well in vbs as well ..

the main differences the way COM is called and how variables are named. other than that the syntax is quite similar.

I work at a large utility these days. I'd say probably 20-30% were/are non-MSI, BUT for some of these I was work with the developers to get an MSI or crack open the cabs or get the app files and put them in an msi. Setup capture just isn't something I work with a lot now. Of course you know the old wrap the MSI in a wrapper trick, and those I would still consider MSI installations.

Hello All
I was hoping you might be able to share some of your packaging standards and practices you perform at your business locations. In particular, I was wondering the tools you use, where do you copy the source files, do you copy the source files down to the machine and then kick off the install? Do you use AutoIt? What do you do if you need to "capture" a setup install because no switches work to make silent install. Any info would be greatly appreciated.


AutoIT??? The best tool to perform scripts...
I use it to perform multi-theards in logon script and to packaging...
AutoIT has some features that can be used to hide the command prompt, and UPX functionality to peform compression in your packages!

ah... I made a tool to manager AD... like remove old account computers/users that has pwdlastset more than 180 days... and to perform some AD reports!

www.autoitscript.com

see ya!

AutoIT it should be banned from any packaging standards - most annoying and pointless..

just come accross some packages where I am and 95% of the scripts could done as standard actions..

yup, totally agree. OT: worst script I've ever seen in an MSI, (pseudocode) was something like,
if exist c:\winnt
do something
If exist c:\windows
do something else

....I almost messed my pants when I saw that

As for autoit, might be great for freeware but I bet if Clyrigham wants to learn WMI and download ADSI scriptomatiic he could create the same tools with a toolset supported by microsoft. Imagine that! Also, if you can learn AutoIT you can learn WMI so why waste your time with the former when it's unsupported? He lost me on the MSI compression tho...um, isn't that what cabs are for?

hehehehe

These are your opinions... just yours! I have used this method to deliver packages to 2000 - 160 000 wks and I peformed login scripts based on .xml giving the opportunity to run asynchronous and synchronous scripts.

.vbs and other is just synchronous and the GUI is limited...

Guys, I had used the primalscript and so on... but TO ME is the best tool to perform scripts.

ORIGINAL: clyrigham
hehehehe
These are your opinions... just yours!

Nope, it's a fact that AutoIT is not supported by Windows.


I have used this method to deliver packages to 2000 - 160 000 wks and I peformed login scripts based on .xml giving the opportunity to run asynchronous and synchronous scripts.

Congratulations! Hope it never blows up on you...try getting support or help from Autoit if it does.


.vbs and other is just synchronous and the GUI is limited...

Oh really? You'd better inform Microsoft that this web page is wrong. As for the GUI, nobody would suggest that VBscript is a full featured GUI tool...but then again neither is AutoIT. If you want to create a GUI, download VB Express edition (free) or learn some hta as Ian (VBScab) suggests.


Guys, I had used the primalscript and so on... but TO ME is the best tool to perform scripts.

If all you've got is a hammer.....[:D]

hauahuahauhauahuahauah

Ok! you have your opinion about AutoIT. You did not understand that, I was not meanning about MS Support..
If you just use MS support stuffs... please do not install drivers out of the HCL.

I really read all about how to implement an synchronous scripts in this article, what I said is ".vbs just implements synchronous scripts". AutoIT is very usefull to perform asynchronous scripts..

Everybody has own opinion, man...

See ya guys!

ORIGINAL: clyrigham
Ok! you have your opinion about AutoIT. You did not understand that, I was not meanning about MS Support..
If you just use MS support stuffs... please do not install drivers out of the HCL.
I really read all about how to implement an synchronous scripts in this article, what I said is ".vbs just implements synchronous scripts". AutoIT is very usefull to perform asynchronous scripts..
Everybody has own opinion, man...
See ya guys!


No, it's your OPINION that AutoIT is a good tool.
It's a FACT that vbscript is created by msft and supported by Windows OS's
Get the difference? [:D]
Oh, you're right - I did post information on synchronous scripts. Well, it turns out that vbscript does support asynchronous queries as well. Wow, it took me all of 2 seconds to find this on google. Invoking a Synchronous Query vbscript site:microsoft.com

dude, quit while you're behind. And remember, Google is your friend. [;)]

hahahahaha

Ok, you are right man and I am wrong!

Ah AutoIT is replacing the WinBat (Do you know what is WinBat?, 'cause it is a another tool like AutoIT, but is legacy...)

Thanks for your advices aogilmor!

My last comment: Please guys (not you, aogilmor) raise up your mind about new tools and techs...

ORIGINAL: clyrigham
hahahahaha
Ok, you are right man and I am wrong!
Ah AutoIT is replacing the WinBat (Do you know what is WinBat?, 'cause it is a another tool like AutoIT, but is legacy...)
Thanks for your advices aogilmor!
My last comment: Please guys (not you, aogilmor) raise up your mind about new tools and techs...

I've heard of Winbat but never used it. Don't worry we'll all have to learn new tools if we want to stay employed. [:D]
I doubt vbscript will be around much in 10 years, may be something like Powershell, or something yet to be invented. I give props to the author of AutoIT -- he's a much smarter developer than I am, I just wouldn't use it for enteqrprise rollouts because other tools that come with Windows can do the same thing. Actually some microsoft dudes recommend against vbscript custom actions altogether. There's a thread on that somewhere else.

A lot of things we are using today like a) regmon, b) filemon, c) procmon and so on... were not supported by MS in the first time, but today Mark Rus... is in the MS making a lot usefull things and all those stuffs is supported and is standard tools to package and to solve issues...

To be honest the AutoIT is a mix with script and DevEnv, I am using it, because is more intuitive and has a great env' to make own scripts.

Try to use it one time if you did not use that before. It will not hurt you [:D]

Thanks and I really like this type of discussions...

See ya!

For us, we are using batch file to do anything. In some situations, there is no command line to install unattend and we are using Winbatch to script the setup process. Personnally, I prefer winbatch to autoit. I already tried both and found winbatch better. But it is my opinion.

I really don't like the idea of packaging with Wise or Installshield.

I really don't like the idea of packaging with Wise or Installshield.

...but you like WinBatch?! Great stuff.

irony?!

The principle is easy. We don't want snapshot. What is installshield or Wise are snapshot tool.

When you snapshot any software:
1. You are no longer support by the manufacturer
2. You are stripping all "intelligence" from the setup. So if the setup is acting a way on XP Sp2 and differently on SP3 you are stripping that information.
3. Many exe contains at least 1 MSI. You should not repackage a MSI so....
4. Everyone can snapshot and create a MSI. Not everyone can create a really good MSI, you will need course and even with that...
5. A few years ago (2-3) there was a webcast on this site about to repackage or not and the conclusion was interesting.

Personnally, I think repackaging tool are for manufacturer not for company. All companys should package with MSI not at our level.

What is installshield or Wise are snapshot tool. Utter tosh.
1. You are no longer support by the manufacturer This is a BAD thing?!?!?! Most vendor support isn't worthy of the title. Does anyone who's paying for support from - for example - Adobe think that it's worth the money?
2. You are stripping all "intelligence" from the setup. The ulitmate oxymoron - "vendor" and "intelligence". As for differences between builds, that's where pre-UAT testing comes in. One tests one's packages on all flavours of your client's builds BEFORE they go to UAT.
Many exe contains at least 1 MSI Only an idiot would fail to test for that, after the first dialog appears.
4. Everyone can snapshot and create a MSI. Ya think?!?
Not everyone can create a really good MSI, you will need course and even with that... No argument there.

In the 'x' years I've been doing this stuff, I can count on the fingers of one hand the number of vendor stubs which I have allowed to be used "as is".

Here we go ... [:)]

Normally I work with AdminStudio to perform a MST file... and I used WinBatch and now AutoIT to put MSI and MST in one .exe file so I can perform a package to be deliver in SMS 2k3 or SCCM 2k7 and this .exe file can be put in a ftp or Intranet to be downloaded... So I can provide a different ways to the end-user installs the package, making sure it is the same package installed.

If the user do not have permissions to installs I can provide in the AutoIT code to elevate it if he want to install using User Context (if is a SMS adv') or if the user is downloading/installing from ftp or intraweb.

... [8|]

You have your opinion. I have mine. I don't want a debate.
I created myself hundreads of package (probably like you) and most are batch files. When needs, I created MST and sometimes winbatch.

I think there is place for everything (winbatch, autoit, batch, wise, installshield), you should just take the good tool for the each problem. It is a mistake thinking a single tool is the best solution for all problems.

I never said I was allowing a manufacturer installation with nothing else done. With batch file, you can let the manufacturer setup run and after taht changing a registry key value or anything else you need. This is not the point.

You can also create a MSI and use it as a wrapper :)

It is true that manufacturers are frequently creating poor setup. But the manufacturer "know" what he wants to be done during the setup process. Not you. So if he is doing sothing bad and you MSI is just taking a snapshot then it is possible you create a bias on another bias. What is good with batch is let the setup run and then correct what is wrong.

I think there is place for everything (winbatch, autoit, batch, wise, installshield), you should just take the good tool for the each problem. It is a mistake thinking a single tool is the best solution for all problems.

That maybe true and if you are happy using Winbatch or whatever to deploy software using vendor setup routines then great. I think you are forgetting a number of key features of using Windows installer accross the board.. for starters:

1) OS integrated / elevated install rights
2) Standard logging capabilities
3) Failed installation rollback
4) Advertising / Install on demand
5) Conflict management
6) Standard installation footprint
7) Custom actions
8) Reliable uninstall

Regards,
Rob.

yeah i hear the new ver of autoit is better...but same thing applies, there are probably other tools to do the same thing which are more part of the OS.
point taken re: procmon, regmon etc. HOWEVER, these were/are diagnostic tools rather than dev tools. If MSFT left a huge hole in dev tools I could see using something else, but they have provided very rich tool sets as part of the OS. what can you do with auto-it that you can't with one of these other tools?

Good question!

I was waiting for it:

1 - I can do a package that can be postpone for the user, if the user chose it I can put a systray and show a ballon every x time to the user nagging that the time is expiring to install the package;

2 - I can do it the same way to reboot. If the package require a reboot at the end of the installation, I can give the user an opportunity to postpone the reboot, passed x time (that was set in the AutoIT code) the systray will nag the user and if the time expire an OK button will be show to user forcing the reboot.

3 - one specific way was a wireless connection client that I needed to get all configuration put in the memory in a specific array and uninstall the old package, install the new one and rebuild all configuration of the client retrieving from the memory.

PS: the client do not have the option to preserve the configuration. [:'(]

4 - Some spec applications cannot be installs during the I.E opens. To detect and close the IE if the user is using before the installation is easy, but what you do if the user start the IE during the installation?
Yes, I can lock, the iexplore.exe during the installation and if the user try to call the IE I show a message to him - "hey man do not use IE during this installation..."

To be honest I never tried to code those (examples above) with vbscript, because the AutoIT is very intuitive raising my productive, but these are some of examples I made... There is a lot of more!

I hope this can answer your question... [:D]

see ya!

http://twitter.com/appdeploy/statuses/1524746201


1) OS integrated / elevated install rights
2) Standard logging capabilities
3) Failed installation rollback
4) Advertising / Install on demand
5) Conflict management
6) Standard installation footprint
7) Custom actions
8) Reliable uninstall

Yes it is true. Goood Marketing.
Would you really create a MSI for a allusers shortcut? A batch would be easier!
If a program just need to be copy inside program files (no registry or ini) then a batch file would do the job too.
Not sure it would be a good idea of repackage complex software like Oracle Developper Suite or Oracle WareHouse Builder.
Not sure it is a great idea of repackage IIS.

In fact there are many situation where the best solution is something else than creating a MSI.
About customs actions, you can code it in a batch file.
Batch file is OS integrated too.

I still believe repakaging should be mandatory for manufacturers and for us just creating MST should be enough.

hahahauhauahauhauahauhahaauhauh

That's was wonderfull ... [:D]

What was wonderful?!

IIS - no one is suggesting that you would even contemplate packaging up the install as an MSI... that's what sysocmgr.exe is for.

I'm not saying you need to use MSI for everything, Oracle clients are an example of where you are probably best to use the vendor setup tools. As for an single exe to program files with a shortcut, I'd still package it up every time.

I don't need to sell the technology to anyone, it's up to you what you use - luckily I don't work on your support desk or have to foot the bill [;)]

Cheers,
Rob.

he he he!

I am thinking everybody is hate me (EveryBody hate Cris...) hahahahah

Rob I was mentioning about bkelly's comment ... about twitter post...

Please next time, take a look in the parentheses in the end of the each post. In mine is write (in reply to bkelly)...

hehehehe

Have a good day my friend!

Oh OK, sorry I never look at that :-)

Can't get to twitter from here.. phew.

Have a good day yourself, I certainly don't hate you. Just dislike (joke)

ORIGINAL: MSIPackager
I don't need to sell the technology to anyone, it's up to you what you use - luckily I don't work on your support desk or have to foot the bill [;)]


Oooooh, SNAP! [:D]

What happened to Barbe in this whole communication :)
May be Information overload for her -
Listen Barbe, go through these documents
http://www.symantec.com/connect/downloads/packagingqc-process-generic-template
http://www.symantec.com/connect/forums/pre-application-packaging-information-gather

What happened to Barbe in this whole communication :)She's using the padded room when I'm not in there.

Our standard is Wise Packaging Studio 5.x (still working on the 7.x upgrade).

While we don't modify the MSIs directory (we use transforms), we wrap all installations within Wise regardless of what format it's in. It gets delivered through SMS, extracts its source to the workstation, and launches whatever native installer it has (if posssible) and we use custom Wise scripts change any settings that need to be changed. We also add specialized settings within the packages themselves to the registry to keep track of installation history, etc. Also, we build in uninstalls for the software that can be called up via command-line switch in the same package.

Snapshoting is frowed upon and is used only as a 'have to' method.

[font="times new roman"]Hi Folks,

Can anybody helps me to sortuot the problem with the silent installation. Application works fine with the user interface but fails to install with the silent installation.
any info would be greatly appreciated.

- This subject has been covered many times in the forum. Please use the 'Search' facility before posting. In this case, search for 'InstallUISequence' and/or 'InstallExecuteSequence'.
- It would be appreciated if you did not hijack threads, particularly old, irrelevant ones.

It is a mistake thinking a single tool is the best solution for all problems.

I believe the conversation here is more about standards rather than tools. If I have 350 software installations, you can bet I'm not going to switch packaging methods between apps. Hopping from native MSI, to Winbatch, to AutoIt, to VBS would be asinine, and whoever came after you would probably want to wring your neck. For myself, unless something absolutely can't be done, I usually stick to MSI + VBS for all my installation needs, but the important thing overall is to stick to some standards.

Also, to stoke the fires a little more, there's a very good reason some people like to stick to AutoIT and some people like vbscript. AutoIT is really, at its core, just a vbscript engine with a whole bunch of classes precoded into it. The syntax is very similar, and the functionality is very similar. What's different about it is the extra layer of abstraction that it provides from the language. That layer makes it easier to build functional scripts (prebuilt classes for things that are somewhat difficult in native vbscript) but also robs you of some understanding of what you're working with.

I, and I'm sure the other people on the vbscript side of the camp, prefer VBS because we like not only creating functional code, but also learning all the little dark secrets that come with working directly with the operating system. I would imagine for the AutoIT side of the crowd, having a fast, functional end product is the only goal, which is what makes it preferable.

EDIT: Wow, this is an old thread. I got necro'd :\