I run a daily Powershell script via Windows Scheduler under a service account that updates a local svn working copy and commits changes. The svn client is sliksvn and is run by command line only. When run manually, the Powershell script works as expected and the svn authentication works using cached credentials.
When I give the service account the necessary rights and create the scheduled task as the service account, everything works fine. However, when I create the scheduled task using my admin account and set run as service account, the svn authentication fails. I used Sysinternals procmon to monitor the authentication process and found that in this case, the process tries to find the svn credentials in
C:\Users\Default\AppData\Roaming\Subversion\auth\svn.simple\
(which does not exist) instead of
C:\Users\ServiceAccount\AppData\Roaming\Subversion\auth\svn.simple\
where the cached credentials are actually stored and where it looks in the successful cases.
Why does svn try to look for the default user's cached credentials instead of the ones of the user running the task?
EDIT: I found the solution. It is this bug in Windows Task Scheduler: https://support.microsoft.com/en-us/kb/2968540
EDIT: ...which can now be fixed (in Server 2012 R2) by this hotfix: https://support.microsoft.com/en-us/kb/3133689
