Agent running as Windows Service Limitations

When a TeamCity build agent is installed as a Windows service, there may appear various "Permission denied" or "Access denied" errors during the build process, see details below.

Security-related issues

The user account used by the service is required to have sufficient permissions to perform the build and manage the service. If you run the TeamCity agent service under the SYSTEM account, do the following:

1. Change SYSTEM for a usual user account with necessary permissions granted.
2. Restart the service.

Windows service limitations

As a Windows service, the TeamCity agent and the build processes are not able to access network shares and mapped drives.

To overcome these restrictions, run TeamCity agent via console.

Issues with automated GUI and browser testing

These problems include errors running tests headless, issues with the interaction of the TeamCity agent with the Windows desktop, etc.

To resolve/ avoid these:

1. Run TeamCity agent via console.
2. Configure the build agent machine not to launch a screensaver locking the desktop.

 You may want to configure the TeamCity agent to start automatically (e.g. configure an automatic user logon on Windows start and then configure the TeamCity agent start (via agent.bat start) on the user logon).

It is recommended to run automated GUI and browser tests on a virtual machine isolated from corporate network resources, since a computer with a running desktop permanently logged into a user session might be considered a network security threat.

Early start of the service before other resources are initialized

To handle this, consider using the Automatic (Delayed Start) option of the service settings or configure service dependencies.