Blank Component GUID: Guid="" is this something you set recently? This will, I believe, set a blank GUID for the component, meaning that it will be installed on first install and never touched or upgraded afterwards (unless you have found some trick to reinstall the component on upgrade) – and it won’t be uninstalled either as far as I recall.
Late REP: The above (blank GUID) does not seem like what you intend. You just want the component to not uninstall on major upgrade, in which case what you generally would do would be to move RemoveExistingProducts late in the InstallExecuteSequence – something which requires you to follow all component rules to the letter. This is very complicated runtime behavior, but a simple concept. Essentially your new version will install as a patch – overwriting files without uninstalling them first – allowing your service credentials to be preserved since the component hosting the service is never uninstalled.
Early REP: Just for the record, the common way to do major upgrades is to schedule RemoveExistingProducts early in the InstallExecuteSequence meaning that all files are uninstalled, and then reinstalled. This approach is used because it allows sloppy component referencing. It is reknown for wiping out user data such as license keys, service credentials, etc…
Permanent Component: Another approach would be to set the hosting component to be permanent. Then it will never be uninstalled during a major upgrade (even if you user early REP), but not during a regular uninstall either, hence stranding the file(s) in question on the system (unless you add your own, custom cleanup features – which can be very error-prone).
Custom Action Backup Mechanism: Others rely on their own custom actions (example) to back up the data that gets wiped out during upgrade and then reapply them after the upgrade is complete. A very error-prone approach in my view.
Service Only MSI: You can also put the service installation in its own MSI to make its update more controllable for you – or in case the main setup can’t be made to respect the component rules. This is also somewhat complicated, but better than custom actions in my view.
Minor Upgrade: If you can use minor upgrades to install upgrades, you can avoid this service credential problem. I will just link to another answer which describes this: Restarting windows service during WIX upgrade.
(Managed) Service Accounts: You could use a regular service account without (about service accounts) credentials to run the service – such as LocalService, LocalSystem or NetworkService (which obviously is not possible for you I would presume). Or the newer concepts of managed service accounts, group managed service accounts or virtual accounts step-by-step info (concepts that I do not know enough about).
Other Approaches: There are no doubt other approaches as well. I suppose you could keep the service configuration out of the MSI and apply it via a script. I wouldn’t recommend it. I know that some people toggle between using services and scheduled tasks depending on the nature of the task at hand (essentially switching to scheduled tasks if it is a task that runs only once in a while). Though risky, I suppose you could postpone the service configuration to an elevated EXE that the user launches after installation (the user must be admin in this case, obviously) which could then set up the config with some interactivity (error and status messages directly to the user – and not just hidden in logs) which can sometimes help to get people going. Not my recommended approach though – elevated actions is what a setup is for. Any non-elevated configuration I like to do in the application.
Common Real-World MSI Problems: I wrote about some of the common problems seen in practical application of MSI a while back, and here it is: How do I avoid common design flaws in my WiX / MSI deployment solution? It is not great. I am not very happy with it – it is lacking in more ways than one – but there it is, in case it can help. It was best effort in the time available. Please take it for what it is: an unfinished dump of real-world problems with a few pointers here and there for what you can try to deal with the problem.
Links: