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
Related
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 am trying to get some automatic deployments up and running using TFS 15 (on-premise). I have a powershell script on the deployment target to call.
The deployments starts fine by downloading the artifact. But when the agent runs the script it wants to create a folder C:\Windows\DtlDownloads (thats not part of my script but part of preparing things for TFS I guess). That fails:
##[debug]System.AggregateException: Failed to install 'VisualStudioRemoteDeployer20597940-38b2-4ba8-9a4d-fcc894308730' from service executable path VisualStudioRemoteDeployer.exe . Consult the logs below:
Access to the path 'DtlDownloads' is denied.
CategoryInfo :PermissionDenied: (C:\Windows\DtlDownloads:String) [New-Item], UnauthorizedAccessException
FullyQualifiedErrorId :CreateDirectoryUnauthorizedAccessError,Microsoft.PowerShell.Commands.NewItemCommand
The user used to logon is a server-local user named deploy who is also a local administrator on that machine. I also checked the effective access for that user on the windows folder and it should be able to create directories.
Something similar happens with the copy step. Robocopy signals two errors:
2017/03/16 08:57:21 ERROR 5 (0x00000005) Getting File System Type of Destination \\server.domain.com\c$\abc\def\
Access is denied.
and
2017/03/16 08:57:21 ERROR 5 (0x00000005) Creating Destination Directory \\server.domain.com\c$\abc\def\
Access is denied.
The second is a bit unexpected as the folder def already exists but I guess it is a follow up because getting the type failed beforehand.
The user itself must have been recognized because I get different errors when using invalid credentials. I have enabled WinRM using Enable-PSRemoting and ConfigureWinRM.ps1 from WinRM-Http-Https-Without-Makecert.
What could still restrict the permissions?
Update: Using a domain user instead of a local one of that server solves the issue. But I do not understand why. Can someone explain or even provide information how to make it work with a local user?
The username of either a domain or a local administrative account on
the target host(s).
Formats such as username, domain\username, machine-name\username, and .\username are supported.
UPN formats such as username#domain.com and built-in system accounts such as NT Authority\System are not supported.
Source Link
Both the domain account and local admin should be work. Please double check your format and give a try with another format.
One problem could be if that you have the agent as a service, that service has not the proper privileges, like being on Network Account. Try to change that to the user account which has administrative privileges.
Running "winrm quickconfig" fixed this problem for me
winrm quickconfig
https://learn.microsoft.com/en-us/windows/win32/winrm/installation-and-configuration-for-windows-remote-management
I'm trying to deploy a web application from Visual Studio Team Services Build. I'm using Visual Studio Build task to build the project. Then, use command line task to execute generated release.deploy.cmd to deploy in IIS server. On executing, I faced the below issue:
E"C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" -source:package='C:\CIDeploy\webapp.zip' -dest:auto,includeAcls="False" -verb:sync -disableLink:AppPoolExtension -disableLink:ContentExtension -disableLink:CertificateExtension -setParamFile:"C:\CIDeploy\webapp.SetParameters.xml"
2016-12-02T10:29:18.2576272Z Warning: BACKUP_FAILED - Skipping backup because it failed due to an unknown reason. For more information, contact your server administrator.
2016-12-02T10:29:18.2586324Z Skipping backup because it failed due to the following error 'System.UnauthorizedAccessException: Filename: redirection.config
Error: An error occurred when reading the IIS Configuration File 'MACHINE/REDIRECTION'. The identity performing the operation was 'TASKAGENT5-0017\buildguest'.
2016-12-02T10:29:18.4396280Z Error: Filename: \?\C:\Windows\system32\inetsrv\config\redirection.config
2016-12-02T10:29:18.4396280Z Error: Cannot read configuration file due to insufficient permissions
Thanks in advance.
Using WinRM-IIS Web App Deployment task/step to deploy your web project.
Install IIS Web App Deployment Using WinRM extension
Add WinRM-IIS Web App Management step/task to your build/release definition
Specify necessary arguments (e.g. Admin Login, Password)
On the other hand, there are others extension in marketplace that can deploy web project.
Update:
Detail steps:
Download or create ConfigureWinRM.ps1 file (source code)
Go to target server (IIS)
Start Windows PowerShell as Administrator
Go to (CD command) the path that contains ConfigureWinRM.ps1 file
Run .\ConfigureWinRM.ps1 [machine name with domain] https
Open Microsoft Management Console (MMC) (Type mmc in Run command (win+R))
File=>Add/Remove Snap-in=>Select Certificates=>Add=>Ok
Expand Certificate (Local Computer)=>Personal=>Certificates
Select the certificate file according to the Issued to (step 5)
Right click it=>All task=>Export to export certificate file
Copy exported file to your build server
Double click that file=>Install Certificate=>Local Machine=>Place all certificates in following store=>Trusted Root Certification Authorities
Add Visual Studio Build step/task (MSBuild argument: /p:SkipInvalidConfigurations=true /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageLocation="$(build.artifactstagingdirectory)\WebGeneralDemo.zip")
Add Windows Machine File Copy step/task
Add WinRM- IIS Web App Management step/task
Add WinRM-IIS Web App Deployment step/task
BTW: you can put deploy task in release (refer to that article)
You cannot deploy locally on a Hosted Agent: you must deploy to another machine. The easiest way is to use VSTS Resource Management and and Agent running on the target machine with administrative privileges (I would suggest to run it non-admin and grant in IIS permission to the user to deploy).
We currently have upgraded our Team Foundation Server 2015 to Team foundation server 15, RC1.
But i cannot get our existing or new build agents running. The error we got is always the same.
No agent pool found with identifier 1 (or 2, ....).
I have checked the database and there is an agent pool with that ID.
Any idea anyone?
thanks.
If the build agent pool definitely exists, but the error is can't find the agent pool. Then the issue is very likely related to permissions.
When configuring the build agent(new created or existed), you need to make sure the account which running the configure command or script have enough permission.
The user account needs to be part of the Agent Pool Administrator Accounts.
Update
Try below ways to narrow down the issue:
First check in that if the build server is available and enabled in
TFS at https://YOURCOMPANYNAME:8080/tfs/_admin/_AgentQueue, and
your build agent should be “Green”.
Make sure the agent is in interactive mode.
Try to change a domain account which is a member of the Build
Agent Service Accounts group and belongs to "Agent Pool Service
Account" role, to see whether the agent would work or not.
Double check whether there are some Firewall interface block the
build, try to disable all related settings.
Update 2
Browse the Control Panel - Team Project Collection - Team Project- Agent queues- click agent pool - Roles- click Add... - Add your user ID and select Administrator in Role
After this try again.
Thanks for your time, however the issue is solved with Microsoft support.
It turned out that my default access level was stakeholder, while build permissions are in the basic. So i had to change the default access level to Basic.
That's obvious a bug in the new RC1, but like you said, it was some kind of a permission issue.
thanks again.
I had the exact same thing: an existing build server, which was working until somebody upgraded it. Error message in the .\BuildAgent_Diag\ folder kept saying
Failed to create session. Sleeping for 10 seconds before next retry
----------------------------------------
Microsoft.TeamFoundation.DistributedTask.WebApi.TaskAgentPoolNotFoundException: No agent pool found with identifier 7.
I already had the service running as a domain account with "build admin" permissions.
The solution was to run 'ConfigureAgent' again: Open a command prompt as administrator. Change directory to your 'BuildAgent' folder (or where ever your 'ConfigureAgent.cmd' file is located) and run 'ConfigureAgent.cmd'. It will ask a few questions. I stayed with the current settings. I had to enter the password for the service account. Eventually the wizard completed and everything worked again.
I'm trying to install Team Build (2008) on a different Build Server (BS) to the Application Tier (AT). BS is a 32-bit Windows 2008 server (as is the AT). They are on a corporate domain.
The EXE in question is
C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies>
TFSBuildService.exe
The service on BS cannot start - the error is "Windows could not start the Visual Studio Team Foundation Build service on Local Computer\r\nError 5: Access is denied.". There is NO additional information in the Event Log. It is set to run as DOMAIN\TFSSERVICE account, which is also added to the Local Administrators group. It fails very quickly.
When I try to run it 'interactively' - the error on the command line is "Program too big to fit in memory".
It seems to me like this should be a fairly simple thing to set-up and use. What am I missing?
Notes:
I got my .config from Buck. I'm pretty sure I've correct set the ports, Windows Firewall rules
I can access the web services on AT from BS via Internet Explorer (using the DOMAIN\TFSERVICE login)
I've added DOMAIN\TFSSERVICE user to a TFS project's Build Services group
I have checked DOMAIN\TFSSERVICE has full permissions on pretty much everything on the Build server.
Try this:
Associate the default port to the new build service account using the wcfhttpconfig.exe command-line tool located in the following folder:
C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies
Execute (from the folder above):
wcfhttpconfig.exe reserve DOMAIN\UserAccount 9191
Full credit from the following post:
http://wesmacdonald.spaces.live.com/Blog/cns!25108A9ADA96C9D7!1553.entry
I suggest you should set up a dedicated TFSBUILD account and not use the TFS Service account for this task as a best practice.
OK, the fact that you can access web services using the TFSSERVICE account from BS through to AT is a good thing, I am making the assumption you have created a LOCAL account on the BS machine for the TFSSERVICE account?
If not, please:
add a LOCAL account with the same name as DOMAIN\TFSSERVICE.
ensure that the password matches that of the DOMAIN\TFSSERVICE account.
ensure that account has "log on as a service" right under Local Security Policy.
Please read article: http://social.msdn.microsoft.com/Forums/en-US/tfsbuild/thread/d519b8e3-451a-4f07-97b1-e2943c2756c2
My issue was that my passwords for the AT and BS machine had to MATCH on the same domain. Please double-check that the TFSSERVICE account password matches on both the AT and BS machine, as the service will use impersonation when on the same domain.