We too are experiencing this issue. It's currently the oldest ticket in our queue with a start date of 2017-06-21.
Applying 516-Andrew's "fix" is a non-starter. Every single "solution" in the article is a way for an end user to bypass cryptolocker/ransomware prevention and to leave it permanently disabled on the system. To quote from the aforementioned solution: "When the computer boots up, if the Software Restriction Policy was enabled, it will no longer be in effect so you should be able to successfully launch and run all affected programs." The cure does more harm than the problem at hand!
Conceptually, I can't disagree with the way the installer works. Writing to a temp directory during installation and then cleaning up afterwards is proper. However, given the interest that this thread has generated, it might be prudent to add some logic to the installer to try a different folder if execution is disabled from appdata. Perhaps you could extract to, mark hidden, and run from the current folder if the target folder is restricted. Obviously the .exe is running in the current folder because otherwise your code wouldn't be running in the first place.
It's doubtful that we'll see some type of additional logic put into the installer after more than a year, so the next best option is to whitelist the path. Elsewhere in this thread it was mentioned that the paths have changed and the filenames have changed over time. This makes it difficult to manage when dealing with multiple domains if we have to change each and every policy every time the launcher has an update.
To echo another user's concerns, we too are actively looking at other options because GoToAssist is only usable for break/fix clients at this point, and our company is focusing on supporting only the managed ones.
