How to run Build Agent from different account (not SYSTEM)

We are using TeamCity Build Server on a Windows 7 machine that uses a Build Agent which runs as a Windows Service.

As our build script is facing access problems (when trying to read from an Excel sheet), we tracked that issue down to a problem with privileges when we run that script from the BuildAgent Service using the default SYSTEM account. (= when we run it locally on our USER1 account with administrator privileges, it executes just fine).

The problem is very much like what is described at http://confluence.jetbrains.net/display/TCD6/Known+Issues#KnownIssues-AgentrunningasWindowsServiceLimitations, Section "Agent running as Windows Service Limitations"

Therefore, my question comes down to "how to run build agent as a different user"?

What we tried so far:
- we opened the Services dialog in windows (Administrative Tools - Services), and changed the "Logon As" property for "TeamCity BuildAgent" Service and "TeamCity Web Server" service from SYSTEM to our USER1. That didn't help though :-(

When I open the Build Agent Parameters in the web management view, I noticed that "user.name" says "SYSTEM". Can that be the problem's cause? Where could I change that value?

Appreciate any help!

Thanks!

11 comments
Comment actions Permalink

This is exactly what we do.  We specify the logon user for the service to our user and it works.  After making the change, did you stop/restart the service?

If you bring up task manager and show all processes, you should see a java process running as the user account which is the TC agent.  You can also  SysInternals process explorer to look at the java process to verify that it's the TC agent java process and it's running as the correct user.

0
Comment actions Permalink

Well, that's strange. The java process of the Build Agent really runs with the correct local USER1 account (and not SYSTEM), as I doublechecked in the task manager. I also restarted the service of course.

Still, the problem persists. However, when I run the Build Agent from command line (and not as a Service), it works just fine.

Anything else I could have set up wrong? What about my other observation from before:
When I open the Build Agent Parameters in the web management view, I noticed that "user.name" says "SYSTEM". Can that be the problem's cause? Where could I change that value?

0
Comment actions Permalink

Hello,

Thanks for the report. It's a known issue, please refer to http://youtrack.jetbrains.net/issue/TW-5527. You can try the the workaround described in comments.

Hope this help,
Marina


0
Comment actions Permalink

Marina, thanks for the information.

However, I tried both suggested workarounds:
(1) I deleted the 'USERNAME' key from HKLM\SYSTEM\\CurrentControlSet\\Control\\Session Manager\\Environment\\ in registry

As that didn't help, I also tried the suggestion from this related thread (http://devnet.jetbrains.net/message/5291093):
(2) I added system.user.name=USER1 to the buildAgent.properties file
..then of course restarted the build agent service - but the permission-problem persists.

The only thing that helped so far was starting the buildAgent from command line (and not as a Service).

Any other workarounds/solutions?

0
Comment actions Permalink

We're running Windows 2003 or Unix for all of our agents.  I will be adding some Windows 2008 & Windows 7 agents later this week.

Are you sure that your issue is a permission issue?  I would suggest trying something simple like having your build script create a file. Then you can check the properties of the file to verify it was created by USER1 and not SYSTEM.

One problem we've had with services is that the agent does not seem to use the SYSTEM path.  Normally when you have a service or you logon to a machine, your PATH consists of SYSTEM path followed by user PATH.  The TC agent seems to use only the user path.  So we found things missing from PATH that we expected to be there.  So we've had to modify the PATH property for the build script to include the values we need.  Could your issue really be a PATH issue?

0
Comment actions Permalink

Bill,

thx for following up.

However, our issue isn't path-related - I copied the paths both from System to User path, plus to the Environment variable PATH in Build Agent settings, just to make sure. Same behavior though.

I also tried to create a file. (To be precise, I copied the problematic file that had no access before.). The owner of the new copied file is USER1 if I start the script locally, but when it is start by the Service, the owner is "Administrators" (so not exactly the same as User1, but Administrators sounds as if it would have permission to access it?).

Either way - As I posted earlier, the only remedy to my problem so far is to use the buildAgent-commandLine instead of the service. Not sure what the significant difference is so that only this one works :-/

0
Comment actions Permalink

Please check your build does not use mapped drives or network shares that may not be accessible from the user.

0
Comment actions Permalink

Yeah, thanks for the input. But my files are all located on a local drive where the user should have full access permissions.

0
Comment actions Permalink

I had some what of the same issue. I had the IT admins create a "service account" with the necessary permissions. Changed the "TeamCity Build Agent Service" log on to that service account. And add that service account user to the local "Administrators" group to the Server/s the build would be affecting. This should fix all Access Denied issues.

Hope this Helps.

0
Comment actions Permalink

If you are running using the command line this mean it is using your account to authenticate and not the system, most likely why it worked. Check the security logs on the server where the script is trying to make modifications to the Excel and look for "Failure Audit". This should give you an indication of which user the agent is trying to authenticate with.

0
Comment actions Permalink

Hi

Need to clarify, here are two independent issues discussed - problems running Excel under Windows service, and displaying actual service account in TeamCity UI.
The workaround to modify registry is for second issue only, and will not help for the original problem with Excel. For me it sounds risky, and we'll discuss it with colleagues once again.

I suspect those Excel problems caused not by permissions, but because Microsoft Office automation is not officially supported to work under services. See KB257757 for details.
Also here is a related thread in Microsoft forums.

Michael

0

Please sign in to leave a comment.