A year or so ago I started working on a project to set up a job to run a stored procedure. I've now come back to this to finish it off. When I run the job I get an error that he job is running under the 'build' user (this is a valid account on our system).

However I've no idea why it is doing this. I'm logged in as my own userID (keith.miller) and I cant see anything on the job. Here are the salient parts of my job creation SQL:

EXEC msdb.dbo.sp_add_job @job_name=N'Restore Database', 
        @description=N'No description available.', 
        @category_name=N'[Uncategorized (Local)]', 
        @owner_login_name=N'XXX\Keith.Miller', @job_id = @jobId OUTPUT

EXEC msdb.dbo.sp_add_jobstep @job_id=@jobId, @step_name=N'Restore', 
        @os_run_priority=0, @subsystem=N'TSQL', 
        @command=N'EXEC dbo.spRestoreDatabase', 

Would this happen if I created the job when logged in as 'build'? Is there a way I can check this or is there somewhere else I can look to see why the build user is being used?

  • 1
    Can you please paste the exact error message or the error code? Did you try with another (SQL Server) account?
    – kesadae11
    May 23 at 10:54
  • Is the RESTORE DATABASE command running as the build user?
    – SE1986
    May 23 at 11:39
  • what is the user that's actually running the sql agent in windows? By default SQL Agent jobs run as that user. Additionally, check the procedure to see if it has an "execute as" line in it, which is another possibility. May 23 at 12:03
  • @JonathanFite thanks Jonathon - that jogged my memory. I changed SQL Agent in the config manager to use that user. This was on my development server so it has gone unnoticed. If you want to post that as an answer I'll mark it as accepted. May 23 at 12:13

1 Answer 1


If you aren't using a proxy (as the job step script shows that you are not) then there are two possibilities that I can think of. I typically only see proxies used for job steps that touch the world outside of SQL (file system operations and the like), so probably not this.

First, check the account that is running the SQL Agent service in the operating system (SQL Configuration Manager / Services.msc). By default, the Agent runs as this user.

Second and rarer possibility is that the procedure itself has an Execute As command in it that is changing who the procedure executes as. This is harder to setup and even rarer to see it setup properly so that it's secure, so I'm pretty sure that this is not the case.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.