Rjtd is correct regarding UpgradePath. If acceptable to have two instances of the package on the clients, the old package and the new version but in different paths, the package.ini parameter UpgradePath could indeed be used.
If you specify an UpgradePath= to a location where your user/users have modify rights and at the same time they do not have modify permissions to the original package we will still upgrade the package with AppSync but you will end up with something looking like this:
C:\Program Files (x86)\Application A\Application A.exe
C:\UpdatedThinApps\Application A.1
You will in other words use AppSync to deliver an in-place update (integer update or side-by-side updates. We have called it many different things over time).
AppSync is and has always been targeting updating applications on unmanaged PC, which is quite hard to accomplish. That is why we do not have all features you could which for. I think it is important to keep in mind what headache a feature is supposed to solve. AppSync is capable of updating an application you manage but on clients you have no management right to. Everything runs as the logged on user, which must be considered secure in the scoop of what it is doing. No locally installed agent/service is required. In order to deploy updates to managed PC is there many other methods to choose from and ESD is often what customers tend to use.
You can use AppSync in other scenarios of course, but you might think it lacks some functionality. Other functionality often being requested is reporting (who has which version) and the possibility to date stamp an update (decide when the update will be made active on the clients).
