I'm trying to remove a VSTS agent from a system, but I no longer possess the Personal Access Token (PAT) originally used during setup. An answer on this thread states that I can just delete the agent from the VSTS web UI, but I don't see that option besides nuking the entire agent pool (which is not a great option for us).
When I try to run config.cmd remove, these are my results:
PS C:\agent> .\config.cmd remove
Removing agent from the server
Enter authentication type (press enter for PAT) >
Enter personal access token >
Enter personal access token > Exiting...
First, it’s better to remove VSTS agent through config.cmd remove command and the PAT is required, you don’t need to use original PAT, you can apply a new PAT with Agent Pools (read, manage) scope and use it to remove agent.
Secondly, without PAT:
Deleting agent from server:
Deleting agent service in local system through sc command if it is running as service: sc delete [service name].
After that, you can delete the agent files.
Dears, I've another use case; I've been using Azure DevOps on-prem server.
I deleted the agent from the devops server 'Website,' However this's wont help me out when I tried to reinstall the agent it tells me:
Cannot configure the agent because it is already configured. To
reconfigure the agent, run 'config.cmd remove' or './config.sh remove'
first.
However, I've solve it when typing the below:
resolved
Related
The user from whose PAT a self hosted agent was configured is leaving the organization.
Once the users leaves the org, his account would be deleted from Azure AD and hence his PAT would be expired.
How should one take over the self hosted agent or update the PAT with other users account?
I was unable to see any MSFT docs w.r.t PAT updates.
Is uninstalling and reinstalling the only option in this scenario?
You do not need to update PAT. Check the documentation: https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/v2-windows?view=azure-devops
Inside the install directory of the agent (in my case it was C:\agent), you will find some files including
config.cmd
run.cmd
You can reconfigure your agent without uninstalling by running config.cmd editing the values and then run the agent again with run.cmd. You will be prompted to provide the PAT and also the agent pool. You can change only the values that you need.
I have a python script that execute an automation script on remote SUT. and given that the script is working when execute locally with user tester and password xxx.
when I build the DevOps Azure pipeline I have checkout from GIT the project into the agent and then try to execute the code from the command line .
cd .\MatrixPro\TestFramework
python .\main.py -t profaund_tests.matrix_pro_rf_energy_across_impedances
this code gave me an error
E PermissionError: [WinError 5] Access is denied:
'//192.168.1.100\c$\'
seems that this script try to create report file on the SUT and doesn't have permission.
more over that the azure user agent have admin permission but I suspect that I need to change into the local user before execute the command.
note: I'm working on windows 10 .
what is the right method to solve this issue ? how can I figure out way this error occur ?
is their a simple way to change the pipeline permmision to work on local agent with local user and password?
When you run the build pipeline on Azure DevOps.
It's actually the build service account which is running the script. You should make sure the build service account have sufficient permission to Access: '//192.168.1.100\c$\'
To change the identity of the build agent, just go into Windows Services and change the identity of related Build service (service name is " Azure Pipelines Agent").
In the Services pane, right-click Azure Pipelines Agent.
Under Service Status, click Stop.
Click the Log On tab.
Specify the account you want to use for the service in the This
account text box.
Type the new password in the Password text box, and then type the
new password again in the Confirm password text box.
Under Service Status, click Start.
You should use a user to remote to that the server hold build agent and manually run the script to perform the deploy process. If that user is able to deploy succeed without any permission issue. Simply use this user as your build service account of Azure DevOps agent.
Hope this helps.
When does a Deployment Group stop working due to expiration or regeneration of the Personal Access Token (PAT) that it was configured with?
If I regenerate the PAT, do I need to update the deployed agents, e.g. reconfigure them with the new PAT?
What happens if I just edit the PAT, update the Expiration date, but don't do anything else, e.g. do not regenerate the PAT or do any changes at the configured deployment agent? Will it stop it from expiring and the configured deployment agent still work?
We have Azure DevOps pipeline, along with a deployment group configured to install the solution to one server.
We have a service account, which we use have generated a PAT and used that token to configure the Deployment Group.
I have tried to regenerate the token, which gave me a new PAT. I have not tried to configure the server with the new PAT. However, deployments still seem to work just fine hours from regenerating the PAT.
What is the proper way to update the PAT so that it does not expire and my deployment agents do not stop working?
From the official Microsoft docs:
To register an agent, you need to be a member of the administrator
role in the agent pool. The identity of agent pool administrator is
needed only at the time of registration and is not persisted on the
agent, and is not used in any subsequent communication between the
agent and Azure Pipelines or TFS. In addition, you must be a local
administrator on the server in order to configure the agent.
Your
agent can authenticate to Azure Pipelines or TFS using one of the
following methods: Personal Access Token (PAT): Generate and use a PAT
to connect an agent with Azure Pipelines or TFS 2017 and newer. PAT is
the only scheme that works with Azure Pipelines. Also, as explained
above, this PAT is used only at the time of registering the agent, and
not for subsequent communication.
So, if you remove or re-generate the PAT the agents will keep working without any issues.
You can do two things:
You can Edit token and change expiration date, this is the easiest way
You can Regenerate token, this will create new token, and you will have to:
2.1. Write down your agent user capabilites, name, service user account etc.! Because once you remove the configuration this information will be lost
2.2 Remove agent's configuration (in agent's folder), run ".\config.cmd remove"
2.3 Configure agent with new PAT (in agent's folder), run ".\config.cmd"
I am using visualstudio.com Teams Services to build and deploy an ASP.NET website to two Azure VMs.
I have a build which on completion triggers a release to my two servers in a deployment group. When you configure a Deployment Group for Visual Studio Team Services you create an agent that by default runs as NT AUTHORITY\SYSTEM.
If I publish my build artifacts to Azure (the server option) then everything works fine and deployment succeeds to both my VMS. However when using a file-drop I get the following error:
The artifact directory does not exist:
\\MACHINE1\drop\RRStore\20170517.20. It can happen if the password of
the account NT AUTHORITY\SYSTEM is changed recently and is not updated
for the agent.
This is basically saying MACHINE2 cannot access \\MACHINE1\drop due to permissions. In windows I can bring up this folder just fine, but since the agent is running as NT AUTHORITY\SYSTEM it cannot access it.
I want to use a filedrop because my website is about 250MB (although in the meantime I am using the 'publish to server' option and deploying via team services.)
I am unclear how to give permissions to the file drop though as the agent is running as SYSTEM. I am running as a WORKGROUP and giving permissions to 'Everyone' does not seem to work.
What is the correct way to configure access to a VSTS drop folder so that the deployment agent can access it?
Few possible options:
Set up a domain (I tried doing this but then I need a new network interface and it sounds klunky)
Continue using teamservices to deploy the artifacts (or reduce the website size!)
Save to a storage account, but again I'm not sure how to configure that.
Run as a different user account
I have similar problems when deploying with VSTS. Instead I chose to:
Run VSTS agent on the deployment group VM as a local user with limited access.
Impersonate the account on the deployment group VM to test its access to the drop folder.
Save/cache a different credential to access the drop folder if applicable.
(So the sensitive information stays on the VM.)
The cached credentials can be a different local user account created on the drop server just for this purpose.
Grant the local user access to various parts of the file system explicitly to limit access permission of this VSTS agent service runner account.
This should work in most cases. In fact, this same way is used in my VSTS, Jenkins and TFS instances. This should prevent you from setting up a domain to solve this problem.
This may not be the best practice, but at least it should get you started in the right direction.
In VSTS I have a release definition, which needs to run a PowerShell script as administrator.
The release agent is configured to run as an account, which is a local administrator and has the required permissions, but UAC is restricting those permissions, unless PowerShell is executed "as administrator".
Can I run PS as admin from VSTS without disabling UAC completely on the server?
I don't think there is a way to do that using PS task. Can you try "Run PS on target servers" and provide admin creds. You will need to provide the machine name of the agent (so this is not ideal) as an input to the task. That might not require UAC. We will file this as a feature request.
I ran into this same problem. To fix it I did this (YMMV):
I uninstalled the Azure DevOps agent
Verified that the agent user was an admin
Reinstalled the Azure DevOps agent
When I originally installed the agent, the user the agent was running as was not an admin (I added that user to the Builtin\Administrators group after I installed the agent). I'm not sure if that caused a problem, but uninstalling/reinstalling solved it for me.
I do not think that the Inline or Path options are the issue. Maybe installing an Agent in the Deployment Environment Machine, assigning in the installation process the credentials of a user you are sure has administrative privileges on the SharePoint farm could help you. Then in VSTS verify that the agent is Online and working in the Deployment Group Section.
We got around not being able to use elevated Powershell commands by creating a light .Netcore Worker service with http request capability running in an elevated service privilege state. You can send a Invoke-RestMethod command from a regular Powershell YML task and it will trigger your custom logic on the other end of the ASP controller. We use it to remove Appx packages before re-installing for our Unit tests. The repo is located at, AzureAdmin