Help executing from mapped drive with UAC

[anom217]

I have a custom action that calls an InstallScript function to copy files from a resource folder relative to my MSI file and place them on the target system. This custom action executes as Deferred in System Context. The system context is needed because the files will fail to be copied if UAC is enabled. However, the customer also wants to be able to install from a mapped network drive. This is a problem, because custom actions running Deferred in System Context will fail to access network shares because they are running under the SYSTEM account, (in SMB terminology a 'NULL User') which is disallowed in Windows.

So, it seems if I have my custom action run in system context, it will fail to install from a network location. If I have it as non-system, it fails due to UAC restrictions. Is there a way to satisfy both of these customer demands? (1. Install from a mapped network drive 2. Install with UAC enabled)

It seems like I've hit a catch-22 or something.

[MichaelU]

The only approach here that really works is to do both - copy to a local temporary location with the user context action, then run from the local copy in the deferred system context action. Of course then you also will want to clean up the copy...

(Technically you can read it in an immediate action and pass it through CustomActionData, but depending on the size of the file, that seems like an odd approach to me.)

[anom217]

I didn't think I could use a custom action to copy it to the local system if UAC is enabled and the action is not in system context. The reason I have it set as executing in system context is because the UAC prevented me from writing files.

Is this not true?

[TsungH]

A custom action needs to execute with elevated privilege, not necessarily in system context, to copy files to restricted parts on a machine.

Why do you want to use a custom action to copy files? Files copied in this manner will not be removed by default during uninstallation or rollback without a separate custom action. Is there any reason that these files are not in components, which Windows Installer will copy via InstallFiles action?

[anom217]

They are included alongside the MSI on the target system, so I can't use InstallFiles. However, I am now using MoveFiles to copy them. How would I get a custom action to execute with elevated privileges when specified only as Deferred? My InstallScript action fails for me when I don't have it as executing in system context.

By the way, I've noticed there seems to be some sort of stigma with using custom actions. Aside from the fact that you need to create corresponding rollback and uninstall actions (which I have easily done), is there some problem with using custom actions to programmatically accomplish a task, such as copying files? Or is it just the extra burden of manually having to ensure uninstall and rollback is taken care of properly?

[TsungH]

Deferred execution would be elevated (see Installation Mechanism). Running in system context is to run without user impersonation. You will need to determine where exactly (which line) your custom action fails.

Adding a custom action complicates installation and introduces a potential point of failure/bug, not just during installation, uninstallation and rollback. It would potentially have some effects on (minor/major) upgrade and/or patch in the future. So, for functionalities, such as file copy, that Windows Installer already provdes, it is best not to reinvent the wheel.

[anom217]

I have a custom action that fails on calling the InstallScript RegDB functions to create a registry key if UAC is enabled. If I execute it as in system context, it works.

I can't use the built-in registry editor in the IDE because it doesn't have the flexibility that is needed. My registry keys are installed under a key that is potentially shared by other apps. If my app is the first installed, it will create this common key. But what happens during uninstallation is it deletes that common key (and all the keys from other apps under it) if it created that key in the first place. I didn't see an option to prevent this behavior, so I resorted to using an IS custom action.

[TsungH]

Looks like I was wrong. Make it deferred in system context then.

Registry entries are gated by component, which is reference counted by Windows Installer. Perhaps, you can try to find a common denominator for your registry entries and group them in common component(s) which is(are) then included in the projects.