That's it. Plain and simple.
The first step in my pipeline is to remove services that are no longer supported. To do that I need to use Connect-ServiceFabricCluster to connect to the cluster. But that requires a certificate installed on the local machine. I won't have a local machine in a hosted pipeline and I have a problem with installing the certificate on the hosted VM for security reasons.
So how do I connect?
1,
Dont know if you tried azure cli sfctl cluster select which allows you to specify a certificate, check here for more information.
In order to use the certificate in your pipeline. You need to go to the Library under Pipelines and click secure files and add your certificate from local. Make sure Authorize for use in all pipelines is checked when adding your certificate.
Then you can add a Download secure file task to download your certificate in your pipeline.
Then you can consume it in your next task by referring to the download location "$(Agent.TempDirectory)\yourcertificatefilename", check here for more information
sfctl cluster select --endpoint https://testsecurecluster.com:19080 --cert "$(Agent.TempDirectory)\yourcertificatefilename" --key ./keyfile.key
2,
If above sfctl cluster select is not working, You can install the certificate which is already uploaded with a powershell task to the hosted agent
Import-Certificate -FilePath ""$(Agent.TempDirectory)\yourcertificatefilename"" -CertStoreLocation cert:\LocalMachine\Root
3,
If the hosted agent has security concern. You can create your own self-hosted agent on your local machine. You can then install the certificate in your on-premises agent.
To create self-hosted agent.
You need to get a PAT and assign the scope to Agent Pool. click here for detailed steps. You will need the PAT to config your self-hosted agent later.
Then go to Project setting, select Agent Pools under Pipelines, Create a self-defined agent pool if you donot have one, Then select your agent pool, click new agent, and follow the steps to create your own agent.
Hope above can be helpful to you!
Related
Is it possible to install a self-hosted agent using a managed service account (MSA)?
Or is password input required when setting the service account?
You couldn’t directly connect an azure devops agent to Azure Devops Service with MSA.
Azure Devops Service supports to use PAT or Alternate Credentials (‘alt’ authentication method).
Azure Devops On-premise also supports ‘negotiate’ authentication method (Kerberos or NTLM).
It could be useful to know that the PAT token is only used during the initial configuration of the agent.
When the PAT expires or needs to be renewed, the agent will remain connected without issues.
If the agent runs as service mode, you could also configure the “logon account” in local service or re-configure the agent.
Here is a doc about the agent auth-type.
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'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
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.
I am using VSTS (Visual Studio Team Services, formerly known as Visual Studio Onine) for continuous deployment to an Azure VM using an Azure File Copy task in my build definition.
The problem I am having is that I have an ACL setup on the Azure VM that is only allowing connections from my office for Remote Powershell.
With the ACL in place, the Azure File Copy task fails with an error like "WinRM cannot complete the operation. Verify that the specified computer name is valid, that the computer is accessible over the network, and that the firewall exception for the WinRM service is enabled and allows access from this computer." With the ACL removed, everything works.
To be clear, this is not a problem with WinRM configuration or firewalls or anything like that. It is specifically the ACL on the VM that is blocking the activity.
So the question is, how can I get this to work without completely removing the ACL from my VM? I don't want to open up the VM Powershell endpoint to the world, but I need to be able to have the Azure File Copy task of my build succeed.
You can have an on-premises build agent that lives within your office's network and configure things so that the build only uses that agent.
https://msdn.microsoft.com/library/vs/alm/release/getting-started/configure-agents#installing
Azure File Copy Task need to use WinRM Https Protocol, so when you enable the ACL, the Hosted Build Agent won't be able access to the WinRM on Azure VM and that will cause Azure File Copy Task fail.
When copying the files from the blob container to the Azure VMs,
Windows Remote Management (WinRM) HTTPS protocol is used. This
requires that the WinRM HTTPS service is properly setup on the VMs and
a certificate is also installed on the VMs.
There isn't any easy workaround for this as I know. I would recommend you to setup your own build agent in your network that can access to Azure VM WinRM.