Question

I have the following CustomAction:

<CustomAction Id="CopyToSystem32" ExeCommand="[INSTALLFOLDER]copy.bat" 
              Directory="INSTALLFOLDER" Execute="deferred" Return="asyncWait" />

<InstallExecuteSequence>
  <Custom Action="CopyToSystem32" After="InstallFiles" >NOT Installed</Custom>
</InstallExecuteSequence>

The .bat itself tries to copy some files into System32 folder. But it's not copying them. The log says the following:

CustomAction CopyToSystem32 returned actual error code 1 (note this may not be 100% accurate if translation happened inside sandbox) MSI (s) (A4:DC) [15:58:46:812]: Executing op: End(Checksum=0,ProgressTotalHDWord=0,ProgressTotalLDWord=313699) 1: CopyToSystem32 2: 1603

Why isn't my CustomAction working?

Was it helpful?

Solution

Try setting Impersonate to no on your custom action

<CustomAction Id="CopyToSystem32" ExeCommand="[INSTALLFOLDER]copy.bat"
              Directory="INSTALLFOLDER" Impersonate="no" Execute="deferred"
              Return="asyncWait" />

that will allow your deferred custom action to run with admin privileges.

OTHER TIPS

What's in the bat file? You might be asking us to debug the contents of a bat file we know nothing about. Anyway, WiX has a copyfile element that will do this without bat files, using the underlying MSI tables.

The actual error (without seeing inside the bat file) is probably the result of an assumption that the bat file is running in the same environment as if you ran it from your desktop as interactive user, but it isn't. It's being run from an msiexec.exe process that makes no assumptions about where files are located and is running with the local system account (because it's deferred).

Very few files should be copied to system32 these days. Perhaps driver files, Active X OCX files, Control Panel Applets, maybe Console Snapins, Screen Savers - all pretty unusual stuff to deploy, and I believe many of them not really necessary to deploy there at all. Are these the types of files you intend to install to system32?

Remember that there is a whole lot of protection going on in system32 via Windows File Protection on XP (replaced files reset by Windows itself) and Windows Resource Protection on Vista upwards (locked down and protected files using Windows NTFS rights). What you do there might be undone by Windows itself, so stay out of the folder if you can. And if you try to deploy runtime files from Microsoft, they should generally be deployed via Microsoft hotfixes and / or a few "still relevant" merge module runtime packages.

Deployment is not like it used to be. It is very complicated now, and many things that used to work will never work at all. It is especially important to not deploy files that are likely to be replaced by windows hotfixes. Instead, find the version of the file you depend on and set the setup to be dependent on that version or higher. See a good discussion of this here: How can I include KB2670838 in an installer with InstallShield 2013?

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top