In just installed a build agent and configured it with required parameters. Logged onto the dashboard and under Agents, I do not see Unauthorized tab and so not see any indication of the new build agent I configured.
I started the agent and it is running on a remote server.
Is there a reason why I do not see the Unauthorized tab? Please help!
Thank you.
Looks like a permissions issue - is it possible the user you are logged in as doesn't have the "authorize project agent" permissions?
Related
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.
I have just set up the plugin remote debugger on my CRM server as a service and I can now connect to it and debug plugins with no problem.
My question is does the user always need to be logged onto the server in order for the service to be running and working? I set it up so that it runs as LocalSystem but when the user isn't logged in and I try to debug anything it says I cannot connect to it.
So does this mean I have to keep the user on always or is there some configuration that I've missed?
You will need to be logged in to run the remote debugger- it is designed to be set up for short term debugging and turned off after you are finished debugging.
Using the PluginTool for local debugging on your workstation is another option:
Is it possible to place an org in it's own process
Hello I just enabled Legacy mode authorization in Jenkins and it seems that it has now locked me out of all the administrative privileges.
I need to create an admin account so that I can continue with Jenkins configuration. I have direct access to the server and have tried running this line from command line:
java -jar jenkins.war --argumentsRealm.passwd.jenkins=swordfish --argumentsRealm.roles.jenkins=admin Jenkins starts but I am unable to access it from the web when starting from command line.
I've also tried starting Jenkins through services.msc, which is how I typically start it, and passing it the parameters --argumentsRealm.passwd.jenkins=swordfish --argumentsRealm.roles.jenkins=admin. Jenkins starts and I am able to access it through the web, but unable to log in with the username.
Any ideas how get admin access back?
I deleted the entries related to security and authentication in the config.xml, restarted, and I am able to access again. I was able to add myself as an admin using matrix based security. Still not sure how to do it with legacy tho.
Recently, I had the same problem. I would try to login to jenkins (hosted on glassfish), and would encounter the same thing. Basically getting a glassfish error that the application was not available. If I cleared all temporary internet files from browser, browse to jenkins home page, I would be presented with the Jenkins login, and when I provided the correct userID and password, WHAMMO! Back to application not available.... This too was using matrix-based administration.
To fix:
Locate the config.xml of the userID that is experiencing problems, under "users" directory.
Deleted the "apiToken" tag under "jenkins.security.ApiTokenProperty" tag.
Bounced glassfish and was able to login again.
I'm currently 'playing' with Plastic and their (brand new) TeamCity integration plugin.
The plugin blurb says "When installing Team City on Windows systems, it normally uses the SYSTEM user account. We recommend changing the user that executes the Team City application."
The thing is, I can't work out what kind of user I should substitute: I would like to be able to access Plastic (on the server) using AD, but wouldn't that mean that TeamCity would also have to run with a network user in order to be able to access Plastic?
An alternative (for me accessing Plastic) would be user/password - but I can't make the TeamCity service run with user/password.
Am I missing something obvious, or is the paint just too wet?
I'm also using PlasticSCM and the Team city plugin, this is my configuration:
For the server: configure your PlasticSCM server with LDAP authentification and select "Active Directory" as the server type.
For the client: configure your PlasticSCM client with LDAP authentification, use your credentials and try the "Test connection" button.
The client setup will generate a "client.conf" file at "C:\Users\your_user\AppData\Local\plastic". This file is used by PlasticSCM client to authenticate with the PlasticSCM server.
So, if your TeamCity service is running with the administrator account you have to place this file in your Administrator "...\AppData\Local\plastic" directory. If you change your TeamCity service to be run with your system account you don't need to do anything, the file is in the right place.
You have another option (if you are still running the TeamCity plugin as Admin), place the "client.conf" file where your "cm.exe" file is. Because the "cm.exe" is going to try to find this file first on its own location and then in the current user "AppData\Local\plastic" directory. This option is only valid if you are the only user working with PlasticSCM in the machine.
Hope it helps!
Scenario:
I set up successfully TFS2010 webdeploy task for solution. Everything worked fine until suddendly something went wrong in the deployment task.
Solution has 2 web projects..those are configured to deploy on build and publish it to the dev-server.
Does anybody have a knowledge what is wrong in build (information below)?
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets
(3847): Web deployment task failed.
((4.8.2011 11:01:10) An error occurred when the request was processed on the remote computer.)
(4.8.2011 11:01:10) An error occurred when the request was processed on the remote computer. Unable to perform the operation. Please contact your server administrator to check authorization and delegation settings.
I can give more information if someone needs it.
I encountered the same issue when building via TFS. When I tried to manually import the website I got a more informative error: "not able to log on the user \WDeployConfigWriter".
Turns out that when you install web deploy it sets up two local accounts WDeployConfigWriter and WDeployAdmin. The passwords on these accounts are set to expire. So reset the passwords on the web server and set to "never expire". Then go to Management Service Delegation in IIS. Each of the presented rules has a UserName field. Where it is WDeployAdmin or WDeployConfigWriter right click and update the credentials to the new passwords.
A full explanation with screenshots can be found here: http://workinghardinit.wordpress.com/2011/07/18/wdeployconfigwriter-account-issues-trouble-shooting-web-deploy-2-0-with-lessons-learned/
All you have to do is re-run the script "AddDelegationRules.ps1" located in "C:\Program Files\IIS\Microsoft Web Deploy V3\Scripts\"
This is the script that is run when web deploy is first installed. It will re-create any missing delegations, re-set the passwords for both WebDeployAdmin and WebDeployConfigWriter, and add WebDeployAdmin back to the Administrators group.
You would still need to set the password on each account not to expire after re-running the script.
We had the same issue-- in our case we are only using MSDeploy (without TFS). Resetting the password for those 2 local accounts (WDeployConfigWriter and WDeployAdmin) solved the problem as their passwords had expired. We attempted to change the password policy to never expire, but only a local Administrator can do that.
run this command lusrmgr.msc
double click on user and
double click the account name, and tick "password never expires".
Done.
In my case it was a botched install of Web Deploy.
Uninstalling then re-installing Web Deploy fixed it for me -- Repairing didn't help.