I'm trying to work around a problem with my Self-hosted Azure Pipeline agent. One of the workarounds listed here is to make the agent log on as myself, (instead of as the current, "Network Service" account it uses).
So I tried that. I went to the Services app, edited the "Azure Pipelines Agent" service and changed the user to be myself.
Windows then tells me that I'll need to stop the service and restart it. But when I do that, I get an error dialog with Error 1069: "The service did not start due to a logon failure"
I have tried to use both my Windows 10 Logon PIN (that I type to login when I sit down at the machine) as the password as well as my Azure AD password for our organization that lets me log on to all our resources. Neither one works.
I know I have the correct account. I don't have any other organization passwords that I know of. What am I doing wrong?
Change the logon user on DevOps agent services won't work.
If you'd like to run the agent with specific account, you need to uninstall the agent(config.cmd remove), then reconfigure the DevOps agent, type your account as below during the configuration.
You can validate the user account in DevOps pipeline with below task:
pool: self2
- script: whoami
Currently, I am starting a container with bamboo remote agent on it and every time I need to manually approve the bamboo agent on the bamboo server. The idea is to automate the whole process starting with running a container which launches a bamboo remote agent and performs the build and then to kill the container. Since bamboo server expects manual approval, this is posing as a challenge. So I am looking for a way to auto approve the agent to register it.
Thank you!
I don't think there's an option to automatically auto-approve agents. Agent approval requirement is an security feature so auto approving any remote agent wouldn't be a security feature anyhow.
That being said, there's an option to disable agent authentication which will effectively mean that any new agent is approved right away -> actually what you're asking for.
You can disable agent authentication by visiting Bamboo administration pages
I'm running functional tests(selenium) on remote test machines.
Sadly when i started using multiple test machines i get Windows Security prompt for credentials while Run Functional Tests step is performed on remote machine.
When i enter credentials set for Test Agent, functional tests starts but after restarting the test machine...
This prompt occurs each time when i start build with functional tests.
I tried to add/remove credentials in Credential Manager but each time new Credential for PersonalAccessToken is added.
I thought that setting same account name with same password on each machine may be the reason, but i changed it and this still occurs.
Anyone faced this problem before?
The account that you use in the Test Agent deployment step needs to have access to TFS.
This is not authenticated using PAS but AD credentials, the same ones that are used to run the service.
Teamcity build agent in disconnected state (Agent has unregistered (will upgrade)) on the server UI.
The build agent service was in hung state tried reboot but still didn't work so manually upgraded the TC build agent with the version server had. Rebooted the build agent service. Still disconnected. Please suggest.
I ran into this issue and found a solution, but I'm going to make a few assumptions about your setup.
This fixed an issue I had with a TeamCity build agent on Windows and running as a user account (as opposed to a System Account).
Stopped the TeamCity service and changed the account to a System Account
Started the TeamCity service and waited about 10 minutes for the upgrade to complete. The build agent showed up in the "Connected" agents tab indicating a successful upgrade.
Stopped the TeamCity service and switched back to the user account
Started the TeamCity service
The other option is to grant the user account permissions to start/stop services, but I went this route instead. See this article for those steps.
Old question but someone might find my comments useful. If you cant read the upgrade logs, check the buildAgent/update/ folder, If files and files sizes are changing in this particular folder then It means that the Agent is updating and you only need to wait. If this is not the case but you still see Agent has unregistered (will upgrade) in Team city under Agents --> Disconnected then the agent is either hung or there is some problem with it. Stop the agent from the services and then by running the agent.bat(Windows) and agent.sh (nix) by giving stop argument and then start it from the same script using start argument. You can also see the status of the agent using status argument. If this also does not work then you will have to read all the logs.
This worked for me:
In the Agents tab, I removed the build agent by clicking "Remove Agent".
I restarted the service.
I refreshed the Agents tab and it the build agent appeared in the Unauthorized Agents.
I authorized the agent and it's now connected.
For the one who kept restarting build agent service and see the "Agent has unregistered(will upgrade)", please check the log under BuildAgent/logs to see the upgrade process and wait.
I just encountered this problem too on Ubuntu Linux 19.10 and it is related to systemd. My TeamCity agents are started and stopped using a systemd script and apparently this is what prevents them from upgrading. When I stopped teamcity systemd services and started agents manually with agent.sh start agents successfully updated and worked just fine since that.
It could be the permissions on the account under which the agent is running. In BuildAgent\Logs\Upgrade.txt, you may find this
Upgrade failed: Failed to stop TeamCity build agent service. Please check TeamCity build agent service user have enough permissions to stop and start the service.
java.io.IOException: Failed to stop TeamCity build agent service. Please check TeamCity build agent service user have enough permissions to stop and start the service.
Although the service appears to be running fine on the machine (windows in my case), it produces the error in it's log rather than event viewer or failing to start, and disconnects from TeamCity on upgrade.
I gave higher privileges and it started to work. +1 to Lemtronix's way if you do not want to restrict permissions of your service account.
I had the same issue. I triggered a build and the agent was automatically changed to connected status.
Looks like the agent tries to upgrade itself, but if your Windows service is set up running from non-admin account, it fails.
Options are:
Temporary change service account to System as proposed by #Lemtronix
Add user to administrators group and restart service.
I resolved this issue with TeamCity 2019.2.4 on Windows Server 2016 by completing the following steps listed below:
Stop the TeamCity Build Agent service.
Stop the TeamCity Server service.
Start the TeamCity Server service.
Start the TeamCity Build Agent service.
Refresh the TeamCity UI tab in your browser window, and wait a few moments for the status to reflect Connected in green.
Changing the service user did not fix the issue for me :
but this method worked (Windows, with Teamcity server and agents on the same machine).
Stop these services : Teamcity server, all the Teamcity agents.
Open a cmd.exe instance as Administrator.
Run these (adapt to you own paths / number of agents). It will start Teamcity server and agents as simple processes (i.e. not as services) :
cd C:\Teamcity\bin
.\runAll.bat start
cd C:\Teamcity\BuildAgent1\bin
.\agent.bat start
cd C:\Teamcity\BuildAgent2\bin
.\agent.bat start
cd C:\Teamcity\BuildAgent3\bin
.\agent.bat start
Check in the UI that the agents have registered again.
Kill the processes created in 3. ; and start the Teamcity services again.
We use rackspace as our cloud provider and spin up new build agents as and when needed from existing server images.
Team city then detects the build agent image but does not authorise it automatically.
Can you tell me how to authorise the build agents without the need to manually go to team city and click authorise as these servers can spin up different flavors, each with different config.
Do I just need to write the correct authorisation key to the build agent config file or is there a better approach to using team city with cloud servers?
In TeamCity 10 you can use the REST API to authorise the agent on startup using an admin username/password:
curl -sS -X PUT --data "true" -H "Content-Type:text/plain" -u ${TEAMCITY_SERVER_USERNAME}:${TEAMCITY_SERVER_PASSWORD} ${TEAMCITY_SERVER_URL}/httpAuth/app/rest/agents/${TEAMCITY_AGENT_NAME}/authorized
If you tail the BuildAgent/logs/teamcity-agent.log file you will see a Registered message and then after that you can run the above command.
The approach that worked for me was to store the unique authorisation code that is written to the build agent config file and then pass this into the team city build step. The build step then updates the build agent config file using powershell and the build agent is authorised, when it next communicates with the team city server.