Software Deployment

ORIGINAL: VBScab

there is also an option to run the MSI with reduced interface (/qr)....except in the corporate environment, where MSIs are almost always deployed via some deployment system (e.g. SCCM/SMS, Group Policy, Tivoli) where they're run with no UI.

We strive to have all installations passive since users seems to turn off/undock the computers in the middle of the installations otherwise, it's amazing how they always manage to do that.

We strive to have all installations passive since users seems to turn off/undock the computers in the middle of the installations otherwise, it's amazing how they always manage to do that.

hell, for the really big installs (Office, Deployment agents, AV) we change their backgrounds and if they're normal users we block their keyboard and mouse and disable system shutdown, just to be safe ...

users eh....[:)]

Any deployment system worthy of the name can handle unexpected events like a power-off or re-start.

We have a three strikes-n-you’re out system. If you mess up your computer in general or any given application three times, your computer is withdrawn and you’re handed a typewriter instead.

Yeh...let 'em try and surf the web with an IBM Golfball...

Yeah, users aren't too pleased these days when they have to type up the HTTP request with their typewriter, put it in an envelope and forward it to the right division and wait for an envelope in reply with a printed copy of the HTTP request. It's especially annoying for the user if the site in question is down at the exact moment of the HTTP request leaving them with a printed version of the 404 - not found error.

For the really desperate, there's always the Streptopelia decaocto option.

ORIGINAL: VBScab

Any deployment system worthy of the name can handle unexpected events like a power-off or re-start.



Well, it's also up to the application that you try to install.
There are companys that don't use MSI installations, and as we all know, there are companies that can't create proper MSI installations.

And then we have SCCM...

there are companies that won't create proper MSI installations.

fixed that for you... In today's market i.m.o it's not a matter of capability anymore, it's a matter of willingness.

I think it's often a case of inertia. The vendor has an automated process which works: changing it would cost time and money. They're thinking, "If it ain't broke..."

The answers in as far is I know them

1) Package code defines a package, i.e. one msi file, the product code defines a product. For example if you deploy an Acrobat Reader 9, your packages will all have productcode X, which indicate you're installing Acrobat Reader version 9.X.X. if however you make different packages for the application, say with different settings, they will all have different package codes.

2) that's bull, there's no "shouldn't" here, the only thing you need to verify is that your vendor MSI doesn't have any custom actions that it only executes in the UI execution, and nowhere else, because when suppressing the dialogs, they won't be executed, which might result in failed/different installations

3) If you mean what I think you mean (incorporating a patch's changes into an installation) it's msiexec /a <msi-package> /p <msp package>
this will create an administrative install point and change it according to what the patch changes.

Slipstreaming normally means incorporating a Service Pack into a deployment e.g. creating a slipstream release of XP SP3 but some people use the term for creating a patched Administrative Installation Point (AIP).

Strictly speaking, Pieter's response to 3) requires clarification, since the command line shown only applies a patch to an existing AIP. One would create the AIP first:msiexec /a <msi-package>and then patch itmsiexec /a <msi-package> /p <msp package>The AIP's version of the MSI gets updated and installs would then be run from that MSI. Being paranoid, I typically make pre-patching backup copies of any AIP but YMMV.

Strictly speaking, Pieter's response to 3) requires clarification, since the command line shown only applies a patch to an existing AIP. One would create the AIP first:

Thanks for clarifying that Ian, didn't know that myself, but then I have a profound dislike of msp's [;)]

2) that's bull, there's no "shouldn't" here, the only thing you need to verify is that your vendor MSI doesn't have any custom actions that it only executes in the UI execution, and nowhere else, because when suppressing the dialogs, they won't be executed, which might result in failed/different installations
If CAs only run in UI and you cannot fix this there is also an option to run the MSI with reduced interface (/qr). This will show all dialogs but the MSI still will be installed fully unattended.

Thx for answes..

But in case of MSI, MST & MSP...

msp will apply to msi or mst....???

ORIGINAL: skt
But in case of MSI, MST & MSP...

msp will apply to msi or mst....???

Create an admin install (AIP; Admin Installation Point)
Apply patch on AIP
Create a transform for the msi located in the AIP

there is also an option to run the MSI with reduced interface (/qr)....except in the corporate environment, where MSIs are almost always deployed via some deployment system (e.g. SCCM/SMS, Group Policy, Tivoli) where they're run with no UI.