[WiX-users] XP Install Error 0x80070001 Access is denied

Discussion:

Gerry Reno

2014-02-06 22:41:53 UTC

I now have this half-way working.

Installing on Windows 7 w/UAC succeeds
Installing on Windows XP fails

In .wxs:
InstallScope="perMachine"
InstallPrivileges="elevated"

CopyFile is setup in an immediate property and then executed deferred without impersonation.

XP Install Log Error:

Executing op:
CustomActionSchedule(Action=CopyFile,ActionType=3073,Source=BinaryData,Target=CAQuietExec,CustomActionData="cmd.exe" /c
copy "C:\Program Files\OURCOMPANY\OURPRODUCT\OURFILE.exe" "C:\OURSTUFF\ADIRECTORY\\")
MSI (s) (88:B8) [17:22:38:307]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI5B4C.tmp, Entrypoint:
CAQuietExec
CAQuietExec: Access is denied.
CAQuietExec: 0 file(s) copied.
CAQuietExec: Error 0x80070001: Command line returned an error.
CAQuietExec: Error 0x80070001: CAQuietExec Failed
Action ended 17:22:38: InstallFinalize. Return value 3.
MSI (s) (88:68) [17:22:38:447]: User policy value 'DisableRollback' is 0

Is there something else I need to do for the Windows XP installs?

Gerry Reno

2014-02-07 01:35:18 UTC

Permalink

Ok, after some experiments:

The copy file is like this:
CustomActionSchedule(Action=CopyFile,ActionType=3073,Source=BinaryData,Target=CAQuietExec,CustomActionData="cmd.exe" /c
copy "C:\Program Files\OURCOMPANY\OURPRODUCT\OURFILE.exe" "C:\OURSTUFF\[LogonUser]\ADIRECTORY\\")

And now since I added InstallScope="perMachine" the LogonUser on XP gets set to SYSTEM instead of the user name. And
this is why things fail on XP.

On Win 7 this is not a problem. The LogonUser stays as the user name.

How to fix this?

Post by Gerry Reno
I now have this half-way working.
Installing on Windows 7 w/UAC succeeds
Installing on Windows XP fails
InstallScope="perMachine"
InstallPrivileges="elevated"
CopyFile is setup in an immediate property and then executed deferred without impersonation.
CustomActionSchedule(Action=CopyFile,ActionType=3073,Source=BinaryData,Target=CAQuietExec,CustomActionData="cmd.exe" /c
copy "C:\Program Files\OURCOMPANY\OURPRODUCT\OURFILE.exe" "C:\OURSTUFF\ADIRECTORY\\")
CAQuietExec
CAQuietExec: Access is denied.
CAQuietExec: 0 file(s) copied.
CAQuietExec: Error 0x80070001: Command line returned an error.
CAQuietExec: Error 0x80070001: CAQuietExec Failed
Action ended 17:22:38: InstallFinalize. Return value 3.
MSI (s) (88:68) [17:22:38:447]: User policy value 'DisableRollback' is 0
Is there something else I need to do for the Windows XP installs?
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
_______________________________________________
WiX-users mailing list
https://lists.sourceforge.net/lists/listinfo/wix-users

David Connet

2014-02-07 02:42:27 UTC

Permalink

I have to wonder, why in the world are you using cmd.exe in a custom
action to copy a file? (**twitch** **twitch**)

<CopyFile> is much easier and msi knows about it (hence handles
uninstall, rollback, upgrade, etc).

Dave

Post by Gerry Reno
CustomActionSchedule(Action=CopyFile,ActionType=3073,Source=BinaryData,Target=CAQuietExec,CustomActionData="cmd.exe" /c
copy "C:\Program Files\OURCOMPANY\OURPRODUCT\OURFILE.exe" "C:\OURSTUFF\[LogonUser]\ADIRECTORY\\")
And now since I added InstallScope="perMachine" the LogonUser on XP gets set to SYSTEM instead of the user name. And
this is why things fail on XP.
On Win 7 this is not a problem. The LogonUser stays as the user name.
How to fix this?

Gerry Reno

2014-02-07 03:25:08 UTC

Permalink

It knows about our custom actions as well and they rollback just fine.

Post by David Connet
I have to wonder, why in the world are you using cmd.exe in a custom
action to copy a file? (**twitch** **twitch**)
<CopyFile> is much easier and msi knows about it (hence handles
uninstall, rollback, upgrade, etc).
Dave

------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
_______________________________________________
WiX-users mailing list
https://lists.sourceforge.net/lists/listinfo/wix-users

Phil Wilson

2014-02-07 18:59:16 UTC

Permalink

I don't know for a fact because there is a CA processes firing off a
process firing off a process but..... if any of the things in that
chain are a ShellExecute type of process initiation then there will
not be any transfer of privilege into the process and you'll see
access denied. That's why CopyFile is better. There is less
obfuscation about what's actually happening.

Note that you're referring to the 64-bit Program Files folder, so be
sure that's the right one - that's the native 64-bit folder.
---------------
Phil Wilson

Post by Gerry Reno
It knows about our custom actions as well and they rollback just fine.

Gerry Reno

2014-02-07 20:28:32 UTC

Permalink

If I take out the InstallScope then the install succeeds on XP (of course Win 7 w/UAC then fails).

If I leave in the InstallScope then the reverse is true.

With the InstallScope, on XP the LogonUser ends up being SYSTEM whereas without InstallScope it is the logged on user.

This is what is causing the problem. Not CopyFile, not CopyFile, etc.

Post by Phil Wilson
I don't know for a fact because there is a CA processes firing off a
process firing off a process but..... if any of the things in that
chain are a ShellExecute type of process initiation then there will
not be any transfer of privilege into the process and you'll see
access denied. That's why CopyFile is better. There is less
obfuscation about what's actually happening.
Note that you're referring to the 64-bit Program Files folder, so be
sure that's the right one - that's the native 64-bit folder.
---------------
Phil Wilson

Post by Gerry Reno
It knows about our custom actions as well and they rollback just fine.

Phil Wilson

2014-02-09 19:43:22 UTC

Permalink

Some rambling comments:

First thing: it's already been said but this whole thing of running
cmd.exe is a bad idea, especially when there is an alternative, the
WiX copyfile element . You should be using it, that's the point being
made, the built-in MSI capability of copying files, table driven, not
a custom action of any kind.

So in the absence of InstallScope your XP install is running as per
user, and this will typically work on an XP system where user custom
actions are elevated. It will fail on a UAC box because custom
actions must run with the system account to be elevated, but it fails
on XP with the system account.

So the common issue appears to be that your custom action fails when
run with the system account, but it needs to run with system to be
elevated on a UAC box. I don't know why that's failing because a)
Nobody uses a CA like that to do a copy, so there's no user experience
of it and b) It's a nasty Windows issue related to cmd.exe being
initiated under the local system account and things as basic as
whether privileges are transferred and if there's even a cmd.exe
available for the system account - why does the system account need
access to cmd.exe, an interactive command processor? At this point
it's no longer about WiX or MSI.

I don't know if anyone has other ideas, but to use a dumb simile, it's
like being in a homebuilder's forum and asking about the best glue to
stick together the walls of your paper house. They'll tell you not to
do it and you won't get many replies because it's not something anyone
actually does.

---------------
Phil Wilson

Post by Gerry Reno
If I take out the InstallScope then the install succeeds on XP (of course Win 7 w/UAC then fails).
If I leave in the InstallScope then the reverse is true.
With the InstallScope, on XP the LogonUser ends up being SYSTEM whereas without InstallScope it is the logged on user.
This is what is causing the problem. Not CopyFile, not CopyFile, etc.

Post by Gerry Reno
It knows about our custom actions as well and they rollback just fine.

Gerry Reno

2014-02-09 23:13:21 UTC

Permalink

Could I please have a straightforward answer as to why WiX is changing the LogonUser from the logged on user to SYSTEM
when InstallScope is set to perMachine on XP installs? On Win7 the LogonUser remains the logged on user.

Thank you.

Post by Phil Wilson
First thing: it's already been said but this whole thing of running
cmd.exe is a bad idea, especially when there is an alternative, the
WiX copyfile element . You should be using it, that's the point being
made, the built-in MSI capability of copying files, table driven, not
a custom action of any kind.
So in the absence of InstallScope your XP install is running as per
user, and this will typically work on an XP system where user custom
actions are elevated. It will fail on a UAC box because custom
actions must run with the system account to be elevated, but it fails
on XP with the system account.
So the common issue appears to be that your custom action fails when
run with the system account, but it needs to run with system to be
elevated on a UAC box. I don't know why that's failing because a)
Nobody uses a CA like that to do a copy, so there's no user experience
of it and b) It's a nasty Windows issue related to cmd.exe being
initiated under the local system account and things as basic as
whether privileges are transferred and if there's even a cmd.exe
available for the system account - why does the system account need
access to cmd.exe, an interactive command processor? At this point
it's no longer about WiX or MSI.
I don't know if anyone has other ideas, but to use a dumb simile, it's
like being in a homebuilder's forum and asking about the best glue to
stick together the walls of your paper house. They'll tell you not to
do it and you won't get many replies because it's not something anyone
actually does.
---------------
Phil Wilson

Post by Gerry Reno
It knows about our custom actions as well and they rollback just fine.

David Connet

2014-02-10 04:26:36 UTC

Permalink

It's not Wix, it's MSI.

A detailed install log might show when the user is set.

Dave

Post by Gerry Reno
________________________________
Sent: Sunday, February 9, 2014 3:13 PM
Subject: Re: [WiX-users] XP Install Error 0x80070001 Access is denied
Could I please have a straightforward answer as to why WiX is changing the LogonUser from the logged on user to SYSTEM
when InstallScope is set to perMachine on XP installs? On Win7 the LogonUser remains the logged on user.
Thank you.

Post by Gerry Reno
It knows about our custom actions as well and they rollback just fine.

Phil Wilson

2014-02-10 18:09:32 UTC

Permalink

A log would very useful yes.

Your custom action type is no impersonation, that means it will run
with the system account on a per-machine install. So the XP case looks
normal to me, assuming I've untangled all the details in this thread
correctly. The anomaly is Windows 7 because, all other things being
equal, the CA should also run with the system account. If you are sure
that Windows 7 is running the deferred CA with the interactive user's
credentials, then the install must have reverted to a per-user
install. IIRC that's the only time deferred CAs run with the
interactive user's credentials. That's why logs would be useful.
---------------
Phil Wilson

Post by David Connet
It's not Wix, it's MSI.
A detailed install log might show when the user is set.
Dave