UPDATE: I just discovered that this is an old question, I'll leave in what I have written anyway.
I think this relates to the larger, general issue of "deployment of user profile files" - which has always been problematic as described in this little summary: Create folder and file on Current user profile, from Admin Profile.
Of particular importance is the potential for the Windows 10 ransomware protection feature to cause problems for user-profile deployment of files altogether. Other security software could also interfere.
Suggested Answer
Following from the "discussion" in the link above, can your application create this file on launch instead? Your application can copy it from a template installed somewhere in INSTALLDIR - once for every user of your application. No other deployment issues to worry about.
This should be a much more reliable solution than adding a lot of custom logic to your setup, since your application can perform better checking and exception handling than what is available in an installer and you will be running in a predictable impersonation context and sequence (an MSI installer has complex conditioning, sequencing and impersonation issues to deal with).
Further, the launch sequence of your application is easier to debug and manage overall - it is just one more source file in your familiar development language - and again, no sequencing or impersonation issues - just your familiar development tool and debugger. In my view: a piece of cake for you - the world of installers may be unknown for you, and maybe a nuisance to deal with?
Below are some more generic comments to point out some Windows Installer pitfalls you might want to avoid. The above is the "real suggested, answer".
Deployment's Conspiratory Complexity
Though not the worst field of complexity, installers and deployment feature a "conspiratory complexity" that is not immediately obvious (gotchas that suddenly surface - you can't upgrade properly, uninstall doesn't work, patching fails, settings are overwritten during upgrades, etc...). Deployment is complex when it comes down to it, here is a summary: What is the benefit and real purpose of program installation?. And there are many common problems seen by developers making their first installers: How do I avoid common design flaws in my WiX / MSI deployment solution?
Make Deployment Simpler and Simpler and Simpler and...
Further: IMHO installers should be made "dumber" (just copy files and prepare app for first launch) and your application "smarter" (perform actual application configuration, crucially for each user). The rationale for all this can be found in the link at the top of the answer, but in general MSI installers are too vulnerable due to their unusual complexity and because of the ever present stream of Windows design changes that may make "smart setups" fall over in unpredictable ways.
As a concrete example: MSI files writing directly to the user profile may face runtime errors because of the new ransomware protection feature added in Windows 10 (which protects the user's data folders from writing by "unknown" applications). This protection feature is currently not on by default, but may become a big problem if Microsoft decides to switch it on by default. At that point they may have sorted out these MSI interference issues though. Still, see the linked answer above on user profile deployment for more such "gotcha-issues" that are hard to predict and foresee. Several Windows patches have caused weird deployment problems. Simple installers rarely fall into these bear traps. It is mostly setups with lots of custom actions that trigger unusual problems. But there are no guarantees - I again refer to deployment's complexity and unpredictability - you never know what state the system you hit is in. To make this complexity more concrete, you can check the "The Complexity of Deployment" section here (a bit down the page): Windows Installer and the creation of WiX. Please give it a quick skim to grasp why we warn against "smart setups" - if they are not needed (sometimes there is no other option - and then QA and real-world testing are paramount issues).
