Understanding force run & workstation association

[jmcfadyen]

Craig,

I think perhaps we are looking at very different aspects of self healing, I understand your comments and although I am relatively limited in my experience with Zenworks I think I have a solid understanding of what it is attempting to do.

My comments are aimed at this question as I am seeking similar answers to the OP as I believe our current strategies are somewhat limited in the requirements coverage.

Now as for the self healing aspect I refer to I am particularly interested in user profile fixup side of self healing. So where an application requires HKCU and or files deployed into the users profile.

The way I view zenworks there are some limitation and some aspects which need to be understood particularly in light of this question.

An example is macromedia products which deploy the serial number (in form of .dat) file into the user profile. No file means application will not start.

So you need to rely on self healing to get that file to the user.

As such when we deploy as "workstation group as user" the issue is somewhat limited as MSI's are executed for each user as part of the NAL launching. The requirement for advertised shortcuts is negated from this aspect alone (perhaps why the design choice by Novell)

However if we deploy in "workstation as workstation" and maintain stripping the shortcuts with preference of NAL window shortcuts we have an issue.

When deploying as Workstation the MSI only installs once per machine not once per user profile.

This in turn means that we now have the issue of the file required to start our macromedia application being not present. As we now also have no entry points into the application we have no way to get the file there (other than verify options in the nal).

So to answers the OP's question we have

as workstation = run in local system context and single MSI deployment
as user = run in user context an multiple deployments of MSI

so if your organisation has stripped shortcuts from MSI's the former can be potentially problematic as the user profile self healing may not be present

if your not stripping shortcuts and using standard MSI shortcuts then as workstation can be an acceptable solution as self healing will still handle profile fix up.

if your stripping shortcuts and running in user mode then you have no self heal issues but you have the multiple installations of an application (desired or not)

so that latter two options offer workable solutions, however which one suits the environment may be debately to the environment.

now additional to this what you need to understand is that "as user" launches the MSI in the users context.

"as workstation" launched the msi in the local system context.

from a purist MSI perspective the deferred phase is the only phase which is elevated which means that changes to the system should be done during the deferred phase.

If however the MSI is constructed poorly and has Custom Actions running in the immediate phase which attempt the modify the system those custom actions are likely to fail under "as user" because the launching user is user (which may or may not have access).

so now your in the boat of

1) as workstation doesnt fail install, but may fail user profile fix up
2) as user may fail install but always repairs user state (even if it is a full reinstall of product)

catch 22 neither are perfect which is why i am here ! ;-) to see what others are doin.