I tried to create a TFS agent in a new server. I had enabled anonymous authentication also. but not working.
Enter server URL > http://xxx.xxx.x.xxx:8080/
tfs Enter authentication type (press enter for Integrated) >
Connecting to server ...
VS30063:You are not authorized to access http://xxx.xxx.x.xxx:8080. Failed to
connect. Try again or ctrl-c to quit
Please do these steps for the manual agent installation.
Prerequisites:
1- make sure ports 80, 8080, and 443 are opened between the agent server and the TFS server.
2- Ensure your user is an administrator in TFS Security [Team Foundation Administrators].
3- download the agent files from the TFS server portal.
In agent server:
1- put agent files after extracting them in any path, we will use "C:\azagent"
2- run PowerShell as administrator.
3- run these commands:
cd C:\azagent
.\config.cmd --deploymentgroup --deploymentgroupname "AnyNameInTFS" --agent $env:COMPUTERNAME --runasservice --work '_work' --url 'http://00.00.00.00/tfs/' --collectionname 'DefaultCollection' --projectname 'TestDeploymentProcess' --auth Negotiate;
3- enter your username don't forget the domain.
4- enter the password.
and it's done successfully.
Related
We have a 3 tier TFS environment: 1 application server, 1 build server and 1 DB Server. TFS 2017 is installed and configured. We are attempting to connect the Build server with the Application server using config.cmd but receive the following error:
PS D:\agent01> .\config.cmd
Connect:
Enter server URL > https://tfs.domain.com
Enter authentication type (press enter for Integrated) >
Connecting to server ...
An error occurred while sending the request.
Failed to connect. Try again or ctrl-c to quit
Firewall Settings:
Source: TFS Build Server
Destination: TFS Application Server
Ports: 443 and 8080
What other ports need to be allowed between servers?
Since you are using https as your public TFS url.
Please make sure you have created the Self Signed Certificate over TFS server and installed the same over build agent machine.
More details take a look at this similar issue here: TFS Build Agent Fails to Configure & Run with TFS2018 Self-Signed SSL Certificate
If you still have the same error after above actions, then please give a try with below steps which may help to narrow down the issue:
Make sure you add the user running the installation of agent, to the
pool and queue administrators
Try to use PAT if you are using username/passwoard
Temporarily turn off the firewall and try again
I reimported the wildcard certificate and I imported DigiCert High Assurance CA in Trusted Root on both TFS Build and Application server.
My question is - to copy files to remote machines from the Drop folder, do I need that remote machine registered as an agent?
My remote machine is in the same network but still, I'm getting an ERROR to copy files.
No, it is not required to have a TFS Agent on the target server in order to copy files over to it, but you do need to have permission to write to it. See the screenshot of what I did. Notice that I am storing the credentials as variables in the build definition. The password is "locked" so no one can see the clear text password. I have the Build Agent running under the same service account that has Admin privileges on the target server, but leaving them off did not help. To test this out, try to log into the build server via RDP and then try to open file explorer and connect to the Target Server using the network path (\SomeServer\C$\SomePath\dir) and using the credentails (domain\login or just login) and see if it works, along with the password.
I've verified that Web Deploy works (using NTLM authorization) when I fire it from Visual Studio on my local machine. Now I want my build server to auto-deploy (if appropriate) every night. I'm using Jenkins on the build server, and I've granted the account access in IIS on the remote machine. My parameters to MSBuild are as follows:
/p:DeployOnBuild=true
/p:Configuration=Debug
/p:Platform=x86
/p:PublishProfile=DEV
/p:AuthType=NTLM
/p:AllowUntrustedCertificate=True
/p:Username=
The DEV publish profile specifies my DEV server which uses a self-signed certificate thus necessitating an untrusted certificate. The NTLM and blank username should use the current user/account to connect.
However, the Jenkins' job's MSBuild step fails with this error
msdeploy error ERROR_USER_UNAUTHORIZED: Web deployment task failed. (Connected to the remote computer ("DEV-SERVER") using the Web Management Service, but could not authorize. Make sure that you are using the correct user name and password, that the site you are connecting to exists, and that the credentials represent a user who has permissions to access the site. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_USER_UNAUTHORIZED.)
When I look at the IIS logs on DEV-SERVER, I see the following:
2016-01-06 23:55:10 159.212.19.186 HEAD /msdeploy.axd site=MySite 8172 - 159.212.19.123 - 401 2 5 0
2016-01-06 23:55:10 159.212.19.186 HEAD /msdeploy.axd site=MySite 8172 CO\BUILD-SERVER$ 159.212.19.123 - 401 2 64 78
I was expecting to see CO\jenkins, the account Jenkins is running under, instead of CO\BUILD-SERVER$. (And what's with the $ on the end?) Am I correct in thinking the wrong account is being used? What do I need to do to get this working?
CO\BUILD-SERVER$ is the machine account of your build server.
If you have a slave running on that machine, is it running as a windows service? If so it's probably running as "System"
Also re Selenium tests, if the tests are running on the build server then the service may need to set to run interactively so that the tests can run against a UI.
When I am running the build from TFS server I got the following error:
Cannot import the following key file: C:\TfsData\Build_work\fa450055\EXChecker 2015\signingKey.pfx. The key file may be password protected. To correct this, try to import the certificate again or manually install the certificate to the Strong Name CSP with the following key container name: VS_KEY_EFCA4C5B6DFD4B4F
Could anyone help out with that?
It seems that your TFS Build Service account has no required permission to access the signingKey.pfx on build agent machine.
Make sure you have this file on build agent machine first.
Then follow below steps:
Log on the build agent as your local build service account (Better have Administrator permission)
Open a visual studio command prompt and navigate to the directory
the key is stored in
Type command sn –i signingKey.pfx VS_KEY_EFCA4C5B6DFD4B4F(Ensure that you use the key name appearing in the error message)
When prompted for a password type the password for the pfx file
Then rebuild it
Note: If you are not running Visual Studio as an Administrator try doing that as well.
More details you can reference the answer from Brandon Manchester Cannot import the keyfile 'blah.pfx' - error 'The keyfile may be password protected'
In my case, I did these steps and it worked successfully.
Open the Team Foundation Server Administration console
Click the XAML build configuration
Click the build service properties
Stop the service
Change 'Run the service as a' — enter the user account and give the
credentials of your own PC
Start the service again
I am using VSSConverter.exe to migrate from VSS to TFS (About time too). I am having an issue because the account I am running it under is not on the same domain as the TFS server. Is there any way to tell the VSSConverter.exe tool which server account to use?
For example when I use the tf command line I add the /login:myname,mypassword switch like this:
C:> tf dir $\ /login:myname,mypassword etc...
Is there some way I can do the same with the VSSConverter.exe?
The error I am getting by is this:
TF60071: Your user account does not have permission to connect to the Team
Found ation Server 'https://www.example.com/tfs/DefaultCollection'.
Please contact your Team Foundation Server administrator and request that
the appropriate permission be added to your account.
VSSConverter.exe will try and connect to TFS with the account that it is currently running as. Sometimes that account cannot be added to TFS, or used with TFS - e.g. There is no domain trust between the two domains.
To specify alternate credentials, you can use the windows credential manager to store them. VSSConverter will then try and use these to connect to the server.
In Windows 7, you can do this:
Control Panel > User Accounts > Manage Windows Credentials > Add a Windows credential
Network address: www.example.com
User name: DOMAIN\user
Password: Password
You can also get to it by going to:
Start > Run
Type: **rundll32.exe keymgr.dll,KRShowKeyMgr**