Software Deployment

How are you going to handle vendor MSIs? When there's an actual upgrade from the vendor, will it fit in with your upgrade version schema? Unlikely...

Wouldn't it be simpler to build a script to change the SourceList using the WindowsInstaller.Installer's SourceList property?

Yes VBS that is correct if I was installing the same application just from a different location but since SMS will be handling the re-advertising/redeploying then the sourcelist only comes into action on a self repair scenario which incidently will be included/changed when my team does the rework.

What I really want to know is the easiest way to reinstall the application that may have files slightly changed to overwrite the existing files on the machine from the previos installation. Basically the msi states if the file exists with the same name/size/file hash and the attributes are set to hex 0x0690 or whatever do not overwrite.

Vendor msi's have their unique upgrade codes in the main msi, that is why you use transforms for vendor msi's with a different autogenerated upgrade cod, so the statement of "When there's an actual upgrade from the vendor, will it fit in with your upgrade version schema? Unlikely..." is actuall likely...

So again I ask if I have to install the same msi over the top of the existing msi and have the msi force the reinstall all components etc what would be the best and easiest way.

I'm not fully understanding the problem, but it looks like you're talking about udpating source location after everything has been moved so that users can repair, add features etc.

The way I see it there are 2 options, one is to simply modify the source location on the PCs in site one. using the MSI source VBscript from desktopengineer.com.
http://desktopengineer.com/msisources

The other way is to simply push a repair the MSI, as in:
msiexec.exe /fv package.msi /qn

This will recache the package and update source location on the network.

What I really want to know is the easiest way to reinstall the application that may have files slightly changed to overwrite the existing files on the machine from the previos installation. Do you think perhaps that it *might* have been useful to mention that there would be file changes associated with the move, rather than a simple change of site?

And let me thank you for the lesson about upgrades. 4000+ posts and they must have passed me by:)

EDIT:
Where does the SMS site change come into the equation, then?

Best and easiest way to ensure all components are reinstalled:

"msiexec.exe /fvamus package.msi /qn"

You can see this by going to a command prompt and typing "msiexec /?"

Repair Options
/f[p|e|c|m|s|o|d|a|u|v] <Product.msi | ProductCode>
Repairs a product
p - only if file is missing
o - if file is missing or an older version is installed (default)
e - if file is missing or an equal or older version is installed
d - if file is missing or a different version is installed
c - if file is missing or checksum does not match the calculated value
a - forces all files to be reinstalled
u - all required user-specific registry entries (default)
m - all required computer-specific registry entries (default)
s - all existing shortcuts (default)
v - runs from source and recaches local package

VBScab is right. The SMS Site doesn't really have anything to do with you actual upgrade/reinstall of the msi's. It's just the tool that your using.

2 things.

1. If you're wanting to update the sourcelist as 'everyone' is commenting on and your usign SCCM instead of SMS (whch you might be). Then SCCM has the ability to handle sourcelist and it'll redirect the reinstall of the msi to the nearest distribution point that the client is allowed to access.

2. You're wanting to reinstall MSI's with newer one's that have slightly different files. So this means that you're going to have to change each of your installations, either by creating/editing your existing captures/transforms. If you're havign to reinstall transformed msi's, you'll have to re-cache the local transform on each of your workstations. If you only replace the transform on the server install and run a repair, it will repair the app using the local copy. Look in C:\windows\installer\{%ProductCode%}\ for your cached transforms.

Sounds like a lot of work to me.

ORIGINAL: michaelnowell
VBScab is right. The SMS Site doesn't really have anything to do with you actual upgrade/reinstall of the msi's. It's just the tool that your using.
2 things.
1. If you're wanting to update the sourcelist as 'everyone' is commenting on and your usign SCCM instead of SMS (whch you might be). Then SCCM has the ability to handle sourcelist and it'll redirect the reinstall of the msi to the nearest distribution point that the client is allowed to access.

SMS 2003 also has this ability, but the downfall is that you can only do 1 GUID per package. So if all your packages are a single MSI, this works great. If not, it can be a real headache, which was the case for us. I'm hoping this functionality is improved on in the next version; would have made our upgrade to SCCM a LOT easier.
ORIGINAL: michaelnowell
2. You're wanting to reinstall MSI's with newer one's that have slightly different files. So this means that you're going to have to change each of your installations, either by creating/editing your existing captures/transforms. If you're havign to reinstall transformed msi's, you'll have to re-cache the local transform on each of your workstations.

Easily done with repair switch /fv.

ORIGINAL: michaelnowell
If you only replace the transform on the server install and run a repair, it will repair the app using the local copy. Look in C:\windows\installer\{%ProductCode%}\ for your cached transforms.

Unless you use /fv, which will force the package to be run from the source on the network and recache it locally. You just need to make sure the Product Codes line up. It's not that hard, I've done it.

Unless you use /fv, which will force the package to be run from the source on the network and recache it locally. You just need to make sure the Product Codes line up. It's not that hard, I've done it.


You are correct in saying that when you use /fv it will force the msi package to run from the network and re-cache it locally.

But when you have installed your application 'using a transform'. The locally cached copy of the transform will not get re-cached when you run /fv. So you either have to uninstall/reinstall or replace the locally cached copy of the transform and run a reinstall.

ORIGINAL: michaelnowell


Unless you use /fv, which will force the package to be run from the source on the network and recache it locally. You just need to make sure the Product Codes line up. It's not that hard, I've done it.


You are correct in saying that when you use /fv it will force the msi package to run from the network and re-cache it locally.

But when you have installed your application 'using a transform'. The locally cached copy of the transform will not get re-cached when you run /fv. So you either have to uninstall/reinstall or replace the locally cached copy of the transform and run a reinstall.


Yep, that's a fact. If the MSI installation has a transform applied, the easiest way to update it is to script an uninstall/reinstall (which I agree is not convienent). I had to do that this week because the transform in one of our packages had a bad server name in it.

Firstly let me apologise to VBS. My post was not intended to sound rude or sarcastic in any form.

To try and make the issue more clear clientco has sold a part of its business and will be cutting the link from their domain. I am on the other end whereby the business part that was sold will need a new sms estate built. Thrown into that is the desktop will not be refreshed just migrated over to the new domain so the existing applications that were delivered via the old sms server will now need to be managed by the new sms server. Again not a problem if no changes were needed to the msi's but that is wishfull thinking. There will be changes made no doubt, especially if the msi has things like properties set up, entries in tables pointing to servers for example the DSN entry will need changing from server1 to server2, that sort of thing.

So the idea was to redeploy the changed application forcing all files to be reinstalled as earlier posts suggested, but as michaelnowell stated I will come into difficulties with the transforms so hence why I was thinking in the lines of using the upgrade route. And yes its a lot of work and 1300 applications globally....[&o]

ORIGINAL: mpryszlak

Firstly let me apologise to VBS. My post was not intended to sound rude or sarcastic in any form.

To try and make the issue more clear clientco has sold a part of its business and will be cutting the link from their domain. I am on the other end whereby the business part that was sold will need a new sms estate built. Thrown into that is the desktop will not be refreshed just migrated over to the new domain so the existing applications that were delivered via the old sms server will now need to be managed by the new sms server. Again not a problem if no changes were needed to the msi's but that is wishfull thinking. There will be changes made no doubt, especially if the msi has things like properties set up, entries in tables pointing to servers for example the DSN entry will need changing from server1 to server2, that sort of thing.

So the idea was to redeploy the changed application forcing all files to be reinstalled as earlier posts suggested, but as michaelnowell stated I will come into difficulties with the transforms so hence why I was thinking in the lines of using the upgrade route. And yes its a lot of work and 1300 applications globally....[&o]


Apart from the migration, I foresee a potential licensing nightmare if your company is selling all their computers and software to another company. Tread carefully, and make sure you are trued up with all licenses of all software.

If packages will need to change, you will have to push updates, it's as simple as that. If it was me, I'd definitely use upgrade codes. Sorry that it's 1300 apps, I hope they're paying you hourly.

If it's just the network source location, leverage SMS Windows Installer source management and the /fv switches to take care of business.

Apart from the migration, I foresee a potential licensing nightmare if your company is selling all their computers and software to another company. Tread carefully, and make sure you are trued up with all licenses of all software.

Licensing all sorted. This is a huge project for a global client so there are teams that have sorted all that out. I guess the upgrade option would be far the best and safest option. Thanks

Firstly let me apologise to VBS. No apology necessary. Good luck with the project. Is it just you + 1300 apps? Are they budgetarily-challenged or something?!? Holy cow...