We're using TeamCity server version is 7.0.1 (build 21326). We have two build agents, each on a different server, one is running Win32 (Server 2003 R2 SP2), the other Win64 (Server 2008 R2 Enterprise). Both the agents are running under the same account (let's call it "mySysUser").
On the 32bit agent, we can't access a remote drive path (accessed using full URL, say \\machine\drive , i.e. no mapped network drive eg X:) in our unit tests (run via MSTest10).
So I did some investigation if the mySysUser has access to \\machine\drive on the win32 server using a C#.NET program (DirectoryInfo.Exist() method) run from the following:
command-line in a standard "mySysUser" user session: YES
remote command-line (using psexec session for "mySysUser"): YES
my own Windows service installed at the win32 server, running under "mySysUser": YES
as a command-line build step in Team City agent's service: NO
as a MSTest build step in Team City agent's service: NO
From the above it looks like that the access problems can't be blamed on a Windows services in general, but rather the agent process (java.exe) that is used to run the build steps from on the win32 box.
So I've also looked into the differences between the two agents' setup (except for the fact that one is 32bit and the other 64bit) using the SysInternals' procexp.exe tool. The only thing that looked suspicious was that the Team City's java.exe process has the env variable USERNAME set to "SYSTEM" on the 64bit but "mySysUser" on the 32bit.
However, I don't know where this variable value comes from (registry?). The java.exe processes on both the agents run under "mySysUser" anyway.
Is this a problem of Java/TeamCity under Win32? Or is it a problem of my user's setup? Or anything else?