TFS Build Agent Pool Setup Error:
I am trying to setup an agent pool on a server on a domain to connect to the TFS which in another domain,
Expected:
A prompt appear to enter the Authentication for the user name & Password for the TFS
What Happen: Error:
Error Connecting The Server, An error occurred while sending the request.
The PowerShell Script:
PS C:\agent> .\ConfigureAgent
An existing configuration file was detected. This will update the local agent settings. Do you want to also replace th
e server registration (default is N)? n
Enter the name for this agent (default is Agent-UKWTSVULM768) -------
Enter the URL for the Team Foundation Server (default is ) https://tfspro.-----.-------.net/tfs
Configure this agent against which agent pool? (default pool name is 'default')
Enter the path of the work folder for this agent (default is 'C:\agent_work')
Would you like to install the agent as a Windows Service (Y/N) (default is N) n
ErrorConnectingToTheServer
An error occurred while sending the request.
PS C:\agent>
I just tested on my side to deploy a build agent cross domain. After enter the TFS domain username and password, I got a TF14045 error.
After seeing this error, run .\RunAgent.cmd, you'll see the agent register successfully.
Another way you can try is to create a shadow account like case How to authenticate build.vnext agent to on-premise TFS do.
Related
I have a Windows 10 Enterprise VM running an Azure Devops Agent in Interactive mode. The agent runs using the only user the machine has, and it is an Administrator with UAC disabled. However, when executing tasks that require an elevated command prompt, as registering dlls, the command fails with the following error message:
##[error]Cmd.exe exited with code '5'.
And this message is when I'm trying to COPY files into Windows\SysWow64
##[error]Error: Failed cp: cp: copyFileSync: could not write to dest file (code=EPERM):C:\windows\SysWow64\test.txt
My testes also fail with the following error message:
Test method TestesRegressaoPGB.Autenticacao.AutenticarNoPGBL02 threw exception:
System.AggregateException: One or more errors occurred. (The requested operation requires elevation.) ---> System.ComponentModel.Win32Exception: The requested operation requires elevation.
TestCleanup method TestesRegressaoPGB.Autenticacao.Cleanup threw exception. System.NullReferenceException: System.NullReferenceException: Object reference not set to an instance of an object..
How do I run all commands while elevated?
In the Azure DevOps, If you want to access local file in the azure devops pipeline via self-hosted agent, It accesses the file via service account instead of Personal account.
Workaround
We could open check the file permission and configure the service account permission. service account format User/Administrator/Administrators({Agent.ComputerName}\User/Administrator/Administrators)
Also, we could change the agent service account to your owner account.
Steps: Open service on the agent machine and search the agent service account, check the pic below, just change the account name and password to yours, then It will use this account to perform the operation.
I just added permissions on each and every folder the pipeline agent needed to open. As I said to Vito, the agent was not running using a service account.
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.
Trying to setup a simple AzureVMFileCopy task from the VSTS Release. I have already done the following steps:
Execucted Enable-PSRemoting
Setup the WinRM listener with self signed certificate and opened the Port 5986 over HTTPS for WInRM
Configured the Inbound firewall rule to allow traffic on port 5986 and 5985 as well.
In the VSTS task, tried giving the username using different conventions - Domain/username, .\username, username
In VSTS task, enabled copy prerequisites.
Configured the VSTS Agent on the VM to run in "interactive mode" and used the administrator user account. Have tried to configure using Service Account as well with the same administrator account.
Interesting thing is that the files are copied in the VSTS Agent _work folder but the final copy to target folder gives "Access is Denied".
Have tried verifying the connection using Enter-PSSession but that also gives the same error.
Here is the exception I get:
System.Management.Automation.Remoting.PSRemotingTransportException:
Connecting to remote server devocxdbvm.westeurope.cloudapp.azure.com
failed with the following error message : Access is denied
Any basic element I may be missing ?
Screenshot of the Azure File Copy Task
I experienced this same issue setting up a build machine for VSTS, fix for me was Method 2 here:
https://support.microsoft.com/en-us/help/896861/you-receive-error-401-1-when-you-browse-a-web-site-that-uses-integrate
which is to add the following registry key:
In Registry Editor, locate and then click the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
Right-click Lsa, point to New, and then click DWORD Value.
Type DisableLoopbackCheck, and then press ENTER.
Right-click DisableLoopbackCheck, and then click Modify.
In the Value data box, type 1, and then click OK.
Restart the VM
I believe (can't find where I read this now) that this was introduced by a security update to windows so may change again in future.
We have TFS 2017 in premise setup hosted on our internal network. Lets call that tfs.OurInternalDomain.com
TFS application and its build controllers and agents are all hosted on our internal n/w.
Our production servers are hosted on a separate domain (data center) for security reasons.
I am trying to deploy TFS Build artifacts [files and folders] from within our internal n/w onto our production server using TFS Release management definition.
I am able to copy the files using "Copy files from" task onto a folder on our production server (which is on a separate domain) from our internal n/w using a separate ID with $(AdminLogin) and $(Password). This userID is a local admin on the production server. TFS services are running under a separate ID on our domain.
These are the variables for task: "Copy files from"
Source=$(System.DefaultWorkingDirectory)/$(BuildDefinitionName)/$(BuildArtifactName)
Machines=$(ServerOneOnSeparateDomain)
Admin Login=$(AdminLogin)
Password=$(Password)
Destination Folder=$(BuildDropLocation)
So far so good.
Next task is to run a powershell script on the target machine and that is where the build agent on our internal n/w is not able to execute the powershell script. I used both -http and https protocol. Below is the error log when http was selected.
Executing the powershell script: D:\TFS2017Build\Agent1\tasks\PowerShellOnTargetMachines\1.0.41\PowerShellOnTargetMachines.ps1
Deployment started for machine: '<ServerOneOnSeparateDomain>.com:5985'
##[debug]Deployment logs for Deployment operation on <ServerOneOnSeparateDomain>:5985
##[debug]Permission denied while trying to connect to the target machine <ServerOneOnSeparateDomain> on the port:5985 via power shell remoting. Please check the following link for instructions: https://go.microsoft.com/fwlink/?LinkID=390236System.Management.Automation.Remoting.PSRemotingTransportException: Connecting to remote server <ServerOneOnSeparateDomain> failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x80090311 occurred while using Kerberos authentication: There are currently no logon servers available to service the logon request.
Possible causes are:
-The user name or password specified are invalid.
-Kerberos is used when no authentication method and no user name are specified.
-Kerberos accepts domain user names, but not local user names.
-The Service Principal Name (SPN) for the remote computer name and port does not exist.
-The client and remote computers are in different domains and there is no trust between the two domains.
After checking for the above issues, try the following:
-Check the Event Viewer for events related to authentication.
-Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
Below is output when I execute winrm on production server:
winrm quickconfig
WinRM service is already running on this machine.
WinRM is already set up for remote management on this computer.
Is there a way to fix this such that we do not disturb the existing TFS architecture of having the TFS Application, Build controller and agents hosted on the InternalDomain and be able to execute a powershell script on a separate domain? If not, is there any other way to fix this?
My end objective is to be able to deploy code to production via TFS that is hosted on our internal n/w.
I may provide more details if required.
According to this part error info:
##[debug]Permission denied while trying to connect to the target machine <ServerOneOnSeparateDomain> on the port:5985 via power shell remoting. Please check the following link for instructions: https://go.microsoft.com/fwlink/?LinkID=390236System.Management.Automation.Remoting.PSRemotingTransportException: Connecting to remote server <ServerOneOnSeparateDomain> failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x80090311 occurred while using Kerberos authentication: There are currently no logon servers available to service the logon request.
Permission denied The account used here must have permission to connect via power shell remoting.
To establish a PSSession or run a command on a remote computer, the user must have permission to use the session configurations on the remote computer.
By default, only members of the Administrators group on a computer have permission to use the default session configurations. Therefore, only members of the Administrators group can connect to the computer remotely.
To allow other users to connect to the local computer, give the user Execute permissions to the default session configurations on the local computer.
The following command opens a property sheet that lets you change the security descriptor of the default Microsoft.PowerShell session configuration on the local computer.
Set-PSSessionConfiguration Microsoft.PowerShell -ShowSecurityDescriptorUI
If that fails try adding the source to the TrustedHosts of the remote machine. You can read how here http://technet.microsoft.com/en-us/library/hh847850.aspx.
If you want to use https, you need Configure WinRM to listen on 5986.
More detail info please refer below similar issue and tutorial:
Release Management Error - Permission denied while trying to connect
to the target machine
Configuring WinRM over HTTPS to enable PowerShell remoting
I created a VSTS task PowerShell on Target Machines which executes a power shell on remote machine. This task is created as a part of release definition.
Logically speaking when I trigger a new release then build agent executes this power shell on remote machine. Let's say target machine is M1 & my build agent is running under a user account u1. I made u1 as administrator on M1.
If the account under which service agent is running is an administrator on target machine, then why do I need to explicitly mention the credentials again. If I do not specify the credentials, then it throw error.
Logically speaking when build agent execute any task then it would have the same identify under which build agent service is running. If that application is an administrator on target machine, then why do I need to pass credentials explicitly. Should it internally pass the identity.
Atul Sureka
Atul
Because it isn’t use the current user (build agent running account) for Resource UserName (uses Admin username) and it fails before deploying machine.
In other words, the check Resource Username action will be passed (will be failed if don’t specify the admin username) if you specify any user for Resource Username (Admin login name) even through the user isn’t existing in target machine. (You can set system.debug to true, then queue builds and compare the log)
I submit a user voice here: VSTS build PowerShell on target machine default user, that you can vote.