Software Deployment

Active setup?

Francois - I just Google'd Active Setup and found what appears to be a good article on how it works.

Thanks for the tip!!!

You should be using native MSI repair functionality to deliver HKCU keys. As long as your required CU reg keys belong to a component with a proper keypath and you have an advertised shortcut then they will get written for each user who runs the shortcut.

Active Setup is a handy tool but should be used sparingly - for example if you have a package with no shortcuts with which to instigate a self repair. AS will run for every user that logs on, regardless of whether they use the app in question. If you keep adding stuff via active setup your logon times will get longer and longer - this will particularly effect logons with new user accounts.

You will learn more and benefit in the long run if you do it properly...

Cheers,
Rob.

Rob,

I will check into that as well for other packages. For this package there are no shortcuts utilized so AS sound like my best option.

Thanks,
Ted...

ORIGINAL: MSIPackager
AS will run for every user that logs on, regardless of whether they use the app in question. Will it? Surely only if there's mismatch between a specific HKLM and HKCU registry key? As ever, I'm happy to be corrected but my understanding - and certainly the way I've used it in the past - is that a package would add the HKLM part, normally using the Product Code as the registry key. Then, when AS runs, it 'sees' that there's no corresponding HKCU part and executes the command line in StubPath.

Thus, that part of AS will only run for users to whom the package has been deployed.

Maybe I didn't write that as well as I should have. I meant will run once for every user - which is why I highlighted the effect on new user accounts.

AS will run for anyone who logs on (regardless of how it's deployed) given that as you say it looks for mismatches between HKLM and HKCU keys. For example if a new package has just been installed on a machine which writes HLKM AS keys, that stub path will be run for me if I logon at that station - whether I use want to use that software or not... Depending on what that stub path does and how long it takes to execute, it could be an inconvenience / annoyance to users - especially if it's not necessary for them.

I was just trying to say don't use Active Setup as the easy way out as it's not the most efficient way of delivering CU components. In Ted’s case it is suitable as he has no shortcuts to instigate a self repair…

Does this make sense?

Cheers,
Rob.

Yes, yes...to me it does. I just wanted to clarify the implication that AS would run for all packages which I think, between, we have corrected. :)

One note:
If you're planning to use the package within Terminal Server environment, Active Setup may be the path you'll have to take, notwithstanding the obvious drawbacks.

I just completed testing and everything now works...[:D]

This will be utilized in a Terminal Server environment as well so I will use AS in that mst if necessary.

Thank you all for your assistance!

Ted...

This will be utilized in a Terminal Server environment as well so I will use AS in that mst if necessary.

Beware that if you plan to use this solution from a terminal server environment - AS will only be processed if you publish a full desktop...