Scheduled tasks run in the default user profile RRS feed

  • Question

  • I have a problem with running scheduled tasks in Windows Server 2012. I'm not sure whether it's something that has genuinely changed or whether it's something configurable. I have a task that relies on some data in its user profile (i.e. in C:\Users\USERNAME\...), but it seems that not matter what user account actually runs the scheduled task (Administrator, a regular user, or a user in the Administrators group, ...), the current user profile is always set to C:\Users\Default.

    I did a number of experiments, and it seems that the only case when it actually works is that when I'm also at the same time logged in on the server (with the same account the task runs under).

    I tested the same thing on Windows Server 2008 R2, and it behaves as expected. In fact, we have a number of scheduled tasks on 2008, and they work fine. We are currently migrating to 2012.
    Thursday, January 3, 2013 6:15 PM

All replies

  • Hi,

    The task relies on some data in its user profile? Do you mean a special user's profile or it is run for every users and reply each profile.

    As we know, only the profile owner has permissions to its user profile, so this should be the issue cause.

    I would like suggest you set scheduled task run under system account.


    Yan Li

    Cataleya Li
    TechNet Community Support

    Monday, January 7, 2013 7:08 AM
  • Yes, the task needs some data from the profile of the user it runs under.

    I created a simple task printing the content of the USERPROFILE environment variable, and it showed C:\Users\Default. On Window Server 2008 R2 it showed the expected profile.

    Also, I have not investigated it in more detail yet, but it seems some other things don't work as expected. For instance, the task does not seem to know about the Invoke-Sqlcmd PowerShell cmdlet. I don't know how this cmdlet normally gets initialized (as it's not part of the default Windows install), but it works (i.e. it is on the system) when I normally login as myself or Administrator.
    Monday, January 7, 2013 1:44 PM
  • When I run the task as SYSTEM, the APPDATA and USERPROFILE environment variables are set to the following values:


    Monday, January 7, 2013 3:46 PM
  • Have you tried logging in with the account you require to access the users profile and access the profile. You should get an error saying you don't have permissions but if you are an admin it will add the permissions for you this should then allow your task to run.


    Monday, January 7, 2013 9:18 PM
  • Yes, I have. When I login as that user, it all works as usually. I'm in the profile of that user, I see his documents, and I can write and read files as expected. Also, the two environment variables are correctly set to the expected values.

    The problem only happens when I run a scheduled task under the user credentials (but not when the user is actually also logged in in an normal interactive session).

    Tuesday, January 8, 2013 2:03 AM
  • I know it's been a while, but I was wondering if you or anyone else found a solution to this issue. I am experiencing the exact same symptoms:

    (The task scheduler on Windows Server 2012 is loading the default user profile instead of the run-as user. When that user is logged on to the machine at the same time, the task works correctly. In all other cases the default profile is used. Printing the environment variables as seen by the task, confirms the issue: USERPROFILE=C:\Users\Default, while the USERNAME variable is set correctly. The user is a domain account, and has full admin right on this machine).

    Wednesday, September 4, 2013 2:19 PM
  • We are having the exact same problem, our task depends on settings stored in the user environment folder.

    After upgrading our server to 2012, it does not work anymore.

    This is a breaking change from windows server 2008, I'm surprised nobody from Microsoft is responding.

    Friday, September 20, 2013 10:48 AM
  • Hi,
    I have the same problem.
    If the user is signed in, task runs properly.
    But when the user is signed out, USERPROFILE defined as C:\Users\Default and HOMEPATH is not defined.
    USERNAME corresponds to a user account that is set in task properties.
    Wednesday, November 13, 2013 11:45 AM
  • It's been a while again... Anyone found a solution to this problem jet?

    I am having the same problem here.

    • Edited by KenneyR Wednesday, March 12, 2014 10:48 AM
    Wednesday, March 12, 2014 10:08 AM
  • I answered on server fault: but I'll repost here:

    I reported this bug to Microsoft last year, via our 3rd party support company. They acknowledged it as a bug, but refused to fix without a high business impact - I was hacking something in development at the time.

    In my research I discovered that the correct profile will be used if you have an interactive session running as the user your scheduled task is set to run as. Microsoft suggested a workaround of running calc.exe (or some other process) prior to the scheduled task that you actually want to run. This appears to work in my case.

    I've hit the bug again with a new development, so I've asked our support company to raise it with Microsoft again and referenced this post to show that other folks are hitting the issue.

    Monday, April 7, 2014 9:58 AM
  • Add me (and some of my customers) to the list of people that this is affecting and have wasted hours trying to figure out what is going on...

    It is quite annoying that MS are aware of this bug but don't document it anywhere or think it is worth fixing any time soon.

    My website (free apps I've written for IT Pro's) : My blog:

    Friday, May 9, 2014 1:31 PM
  • I badgered Microsoft, via our 3rd party support company to document this, since they won't fix it and it's clearly causing people to waste time trying to work it out. KB article is at:

    Wednesday, June 4, 2014 7:51 AM
  • I experimented same issue (scheduled task Run_As defaulting to "default user profile") with Windows 2003, It

    looks to be a bug in Windows and looks to be an user access issue.

    Possible Solution: After making the Run-As user part of local admin group, the problem seems to be solved.

    Run-As user profile is loaded correctly at scheduled task execution time.

    Tuesday, June 10, 2014 10:59 AM
  • I couldn't get the workaround proposed in that KB article to work for me. Instead, I copied the three "set" commands from the solution posted here:

    • Proposed as answer by Philip Colmer Friday, September 5, 2014 10:44 AM
    Friday, September 5, 2014 10:44 AM
  • I've known about this problem for a while, but it's easy to forget to account for, when you're writing a script to be run at night, whether the user is logged-in or not.  In my case I just had it happen again on a Windows 8.1 Pro system, and cause files inadvertently to be written to a subfolder of C:\Users\Default, which was hidden.

    I decided to see if Microsoft might possibly have fixed this in the venerable Windows 10 Pro...

    I scheduled a job that does a "SET" command to run under my username, "Configure for" Windows 10, then logged off.  I saw these variables logged (among others): 


    It appears this may finally be fixed in Windows 10 (and presumably Server 2016).  I'm surprised this didn't make it to the master list of "huge improvements" for Windows 10 over its predecessors.


    Detailed how-to in my eBooks:  

    Configure The Windows 7 "To Work" Options
    Configure The Windows 8 "To Work" Options
    Not feeling enough love to make one for Windows 10

    Sunday, April 17, 2016 2:53 PM
  • I know you asked this question a while ago, but Microsoft has now a fix for Windows Server 2012 R2. The problem and the fix is described in KB3133689:

    I have tested this and it works for me. So no more workarounds needed.

    • Edited by Pascal de Vries Thursday, November 17, 2016 10:10 AM
    • Proposed as answer by Joshua Leisk Wednesday, February 22, 2017 7:54 AM
    Thursday, November 17, 2016 10:09 AM
  • Thanks for that link.

    Microsoft documented it as "Even though this issue is observed only in Windows Server 2012 R2, the hotfix also applies to Windows 8.1 and Windows RT 8.1."

    Without the hotfix I just ran a SET command in a scheduled job on Win 8.1 to test...


    So the documentation is correct; the hotfix is apparently not needed in Win 8.1.


    Detailed how-to in my eBooks:  

    Configure The Windows 7 "To Work" Options
    Configure The Windows 8 "To Work" Options
    Not feeling enough love to make one for Windows 10

    Friday, November 18, 2016 7:45 PM
  • Windows Server 2012 R2 is the same code base as Windows 8.1, so you can apply this hotfix to both OS's. But it looks like it has no effect on Windows 8.1 as Windows 8.1 does not have the issue in the first place.
    Monday, November 21, 2016 7:33 AM
  • How exactly do you run a "SET" command? I can't seem to figure it out...
    Saturday, December 8, 2018 11:02 AM
  • In the session you are running in you add, in a batch file, the the enviroment settings you desire. As for above APPDATA=C:\Users\NoelC\AppData\Roaming to be changed, you just type

    set APPDATA=C:\Users\NoelC\AppData\anythingyouwant

    If you oopen up a command prompt and type set, you get a list of that command prompts enviroment settings. You may alter them as you like. wit the "set" command.

    Be easy on it though....

    Who the hell is General Failure, and why is he reading drive C?

    Tuesday, October 8, 2019 5:19 AM