Software Deployment

Hi,
I’m *really* confused by what you what to do and why. What's your batch file doing and why don’t you use a custom action it?

Charlie

Not a problem Charlie -- it's kinda hard to explain, so I figured someone would be confused [:)]

So here is the situation...

We use Blackberry's here (some on Sprint network) and Sprint has a software package that you can install to 'tether' the Blackberry and use it as a wireless modem.

Not a big deal, packaging it is easy. There is an option which is a checkbox to Automatically check for updates once per month -- for obvious reasons, we want to disable that.

So I found it is a registry entry under HKCU.

So I went about the way of going down the route to have the MSI self-repair and write the registry entry to disable the setting.

This works great -- as long as the user is on the LAN for the first time they run the program. (it is being deployed via GPO and software is hosted on a fileserver).

So, if a user waits to open the program for the first time while off the network, they will see the self-repair work, then an error box saying it cannot find the original MSI file to do the repair (this is true because it is back on the LAN on a fileserver). And 99% of the users will wait until they are *off* the network to open the program.

So -- how to get around this by automatically starting the program one time after the user logs in for the first time??

I thought I could do it through the registry RunOnce key -- but this does not work, as a user must have delete rights on the key (all users are restricted)

I thought I could write a simple batch script that just opens the shortcut and deletes itself and place it in the StartUp folder under \Docs&Settings\All Users\Start Menu\Programs\Startup -- this does not work since a restricted user cannot delete anything from the 'All Users' section of Docs&Settings

So, what I am trying to achieve is to have the program run once to perform the self-healing while the user is still on the local network so they have access to the hosted MSI file.

Hope this clears it up :)

Hi,
Hummm…. You could copy the package locally install it from a local copy of the MSI, that way the app can repair when the machine is off the network. To be honest if it’s a mobile PC you should be installing your apps from a local cached copy anyway IMHO.

Or install your package with a script that launches first Msiexec then the program.

Or use active setup to install the HKCU stuff when the user logs in for the first time after the install. If you force a reboot then its likely that the user will log in again after the install. Its a nasty solution - dont do it!

The choice is yours, but I would want to cache my package locally.

Fuz

Thanks for the suggestions, Charlie.

I agree, it seems no matter which way, it's going to be nasty.

I'm interested in the caching the MSI locally -- is this a property or switch somewhere to enable this? Or is it physically copying the MSI, then running a script to call the local MSI?

Thanks again :)

You’re just going to have to copy the entire package locally I’m afraid.

C

Hi folks,
that's the perfect task for an Active Setup entry.
Include 3 lines to the registry table of this app to do it.
Something like this:
RegHKLM1 2 SOFTWARE\Microsoft\Active Setup\Installed Components\[ProductCode] Stubpath msiexec /i [ProductCode] /fu /qn YourComponenthere
RegHKLM2 2 SOFTWARE\Microsoft\Active Setup\Installed Components\[ProductCode] Version 1,0 YourComponenthere
RegHKLM3 2 SOFTWARE\Microsoft\Active Setup\Installed Components\[ProductCode] [ProductName] User Setup YourComponenthere

You did not mention it, but if the app needs to copy files to the users profiles, the best approach would be to rework the MSI and use the DuplicateFile or MoveFile table to do it.
Read this post from John McFadyen carefully:
http://itninja.com/question/how-do-you-roll-out-new-machines?4146&mpage=1&key=active%2Csetup幺
This gives you the knowledge to solve the issue.
Regards, Nick

Nick,

Thanks for the quick explanation and link -- I'll be sure to read up and give it a shot [:)]

Thanks again!

Nick,

I just got around to reading that link (a few times) and everything sounds great and makes sense.

My only problem is this;

When a user goes to startup the application, there is a huge chance (+/-99%) that they will be off the network, and not accessible to the source msi which is hosted on an internal fileserver -- which would lead to the application self-repair failing (since it doesn't have access to the source msi)

I may have been misreading and misunderstanding, but from that forum post by John, it sounds like the client will need access to the source MSI to perform a repair (and then making my registry change update in HKCU)??

I'm not sure of a way to achieve this in a completely remote environment that does not have access to the source msi?

The source msi is only required if self-healing is reparing files, not registry as this will be read from the cached msi.
The source msi may be required in some cases not related just to self-healing.
Have a look at this thread at the Altiris forum for a short discussion regarding this: http://forums.altiris.com/messageview.aspx?catid=19&threadid=42733&enterthread=y

Hi JdotQ,
that's why i was making you read John's post.
Please go through it a few times again.
John exactly shows there, how you can overcome the need for the source file when repairing user settings.
Regards, Nick

What John is telling everyone is how to solve an unaccessible source during repair which is done by installing all files/folders that should go into the users profile to a common place, ex. ProgramFiles\MyVendor\MyPackage\UserProfile. Then take a copy of this UserProfile structure and add it again but under windows\profile which in this case will have the file source from the MyPackage\UserProfile instead of the original installation source. So when the profile-fix (self-heal) is triggered when the user is launching the app for the first time it will not fail the repair.