>>>>Will the scheduler start the application also when the server is being restarted due to a Windows upgrade, and nobody logs in?
>>>
>>>IIRC, there's an option to run the app again after a set time if the first run fails or is skipped. Another option (which I always used for unattended operation) is to run regardless of whether the user is logged in or not. So it should run when nobody's logged in. Just like many system level scheduled tasks (in some distributions) run under accounts which are actually never logged into - various system accounts, often with $ or SYS in their names.
>>
>>As Sergey pointed out it's a good idea to create an account to run a task like this, rather than tying the task to a user's account which could get disabled or deleted, have its password changed etc.
>
>Of course there's a chance that this user account may end up getting deleted during the course of a security audit (I'd seen this happen on a few occasions). To reduce the chances of this happening, it probably would be a good idea to make sure that such an account have a meaningful description (e.g. "username used by automation task for ___ application") rather than being left blank. This of course assumes that the person(s) doing security audit don't start blindly deleting user accounts that don't seem to be associated with live persons (which I have seen on at lest one occasion).

On occasion I've even included "- do not remove" in the account description ;)