I have Basic MSI setup where the requirements is to place some files beside setup itself (some files that can be customized after the kit was built).
During installation I have to copy these files from the location where setup runs to the proper location in the target machine. To do this I added a InstallShield Install Script CA in the Execute sequence.
This CA run fine if it is not a deferred CA. If I made this CA deferred in system context, then it works fine only if the setup runs from local machine. If it runs from a network path, XCopyFile fails with error code: -2147024894 (System cannot find the file specified). All paths are obtained correct in deferred CA (I see this in the logs and one point is that it works fine from local machine) so this is not the issue.
The issue is that the XCopyFile cannot access the network path. Trying ChangeDirectory to the network path also fails.
From the docs I read deferred CA can runs with different credentials as the rest of the setup. Is this true? It can explain my problem.
Is there anybody that can suggest me a solution/workaround and keeping this CA as deferred in system context?
A possible workaround is to copy these files in the %TEMP% folder with an immediate CA and delete them at the end of install. What do you think?
That is correct - the "system context" deferred actions are generally run with different privileges and identities than the rest of the actions in an msi. I think the last option you mention is the only real way to handle this (short of getting network access to the system context), but you may want to tweak your implementation so that it copies to a temp folder from a deferred (not in system context) custom action just before the deferred (in system context) action copies it into the right place. You could make the second copy just move it, and then all you would need is a rollback action which would also delete it (as the commit case has been handled by the move).
If my deferred CA set as "in system context" runs as deferred (not in system context), then is there any chance to encounter problems with the installation (Vista, etc.)? I ask this because I want to avoid double copy same files, saving time.
As additional information, the setup runs only with administrator privileges (only administrators can run setup), installation is per-machine and the files copied are simple copied (not registered) and they are application specific files.
The real question here is not so much whether they need to be registered, but what privileges the non-system context has. If you're guaranteed to have lauched the MSI from an elevated (administrator privileges) context, then the privileges for both these contexts are nearly identical, and it would be possible to do a direct copy (as well as any registration, if it were necessary). If the MSI can be launched as a non-administrator, and only acquires administrative privileges at the execute sequence, then actions which aren't in system context will execute with the original non-administrator privileges, and you would need to do a staged double copy. Don't forget that maintenance and removal are likely to launch this way, so if maintenance can install (or repair) these files from source, it may be necessary to go this route for Vista.
One more thing to check out is the DuplicateFiles or MoveFiles table (and of course the RemoveFiles table for the uninstall case). If the particular files which need to be copied can be described this way, then perhaps Windows Installer itself can figure out which context to use to read them, and you might avoid writing custom code. I've not tried a case like this myself, though, so no guarantees. 🙂
