Group: Forum Members
Because of what it does and the APIs it uses, Reflect must run under an account with admin privileges, regardless of whether you're launching it interactively or running a scheduled task, so you can't use it as a standard user. If you launch Reflect interactively as a standard user, you can certainly provide alternate admin credentials at the UAC prompt, but scheduled tasks configured to run as a normal user will fail. The location of the definition file doesn't matter, because that doesn't change the user account that actually runs the task, and an admin account would be able to read the definition file basically wherever it is, unless you've gone out of your way to prevent that, but of course that wouldn't make sense. There would also be no point in reinstalling Reflect as another user. The install process itself requires admin privileges, and once Reflect is installed it's available system-wide, not restricted only to the user who installed it.
As for malware exploiting a logged-on admin account, unless you're worried about it getting information from something that's actually running in that admin session, as opposed to just gaining admin access in general, then to my knowledge, having an admin account logged on doesn't make it easier for malware to exploit than just having the admin account exist on the system. And since you always have to have at least one active admin account on the system, there will always be one for malware to attempt to exploit -- and that's before considering the existence of privilege escalation attacks that exploit flaws in OS code in order to gain admin privileges even for accounts that shouldn't have them, which is entirely separate from trying to access some other account. While running as a standard user for everyday tasks certainly isn't a bad idea (although even that's becoming less critical thanks to improvements in UAC and the Windows security framework), I wouldn't worry about having a separate admin account for Reflect on the system as long as you have a half decent password on it, and I definitely wouldn't consider myself more at risk by having that session logged on, as long as that session didn't have anything sensitive running in it that could potentially be accessed by memory mapping attacks.
Changing the scheduled task to the SYSTEM account was an idea that could potentially allow you to run Reflect tasks without having a "traditional" admin account associated with it. Basically, the SYSTEM account is built into Windows and has admin level privileges, so if you can get a Reflect scheduled task to run as SYSTEM, then Reflect will have the access it needs without you having to maintain an admin account, or at least a logged-on admin account. However, I'm skeptical that just editing the task in Windows Task Scheduler to change the user to SYSTEM and leaving the password field blank will work. And if you'll be upgrading to Reflect V7 soon anyway, then this is moot because Reflect V7 configures its scheduled tasks run under the SYSTEM account by default anyway, since V7 uses a newer version of the Windows Task Scheduler API than V6. That alleviates the need to store admin credentials with Reflect, avoids the risk of scheduled tasks breaking if that password is ever changed and you forget to update Reflect with the new password, and in your case removes the need to have an admin user actually logged on all the time, which if nothing else consumes system resources. So that might become an additional reason for you to upgrade to V7, and you wouldn't even have to wait until you upgraded to Windows 10 in order to do it since V7 works all the way back to XP. That said, if you do upgrade to V7 before upgrading Windows, I personally would uninstall and reinstall V7 after you upgrade Windows because Reflect V7 also comes with Macrium Image Guardian, but that requires at least Win7, so it wouldn't be installed if the installation occurred under Vista. Image Guardian is definitely a capability worth having, especially if you're worried about threats from online sources