That's very odd that the situation would change day to day. There seems to indicate that there is a change in the environment that is conditional. Maybe another program running in the background that was only running one of those days. Or maybe there's
a helper service that should have been running but wasn't.
In any case, if it is working now I suppose I won't recommend any actions that would break the situation.
However, I want to point out that many times with software that was originally built to "expect" administrative privileges, it would have problems when running on newer operating systems like Vista/7 onward (Windows) or Mac OS X onward (Apple). New operating
systems block programs from doing "admin" things, even when you the user are logged in as admin. This is because anything running while you're logged in can do anything you can do. Thus, programs running while people were logged on as administrators is what
causes the ransomware attacks we see today. Since that person has access to the files, any malware has access also. So in modern operating systems, even administrators can't readily modify system file locations or shared places like temp files.
Two things you can try:
- While logged in with the "problem" user account [Paul], try to right-click and Run as Administrator for the program.
and/or
2. Uninstall the program completely and reboot. Then, go to the installer setup.exe file and right-click that and run-as-admin. This is different because the installer routines itself will now be able to properly perform all the installer commands that may
not complete successfully without the 'assumed access' to perform the admin tasks.
If both still fail, it can be beneficial to run the installer setup file in "compatibility mode" which you can do from the same right-click menu on the setup icon.