I'm trying to deploy an existing build with the "LabDefaultTemplate.11.xaml".
My problem is, that the build times out, as soon as I use an existing build. Here are the last steps including details and the timeout exception:
See http://i.stack.imgur.com/po1i6.png
I have two different servers. The first has TFS 2013 with Build Service, Controller and Agent installed on it. The second is thought to be used for Testing and has a Test-Controller and Agent on it (configured as a Standard-Environment in MS Test-Manager).
Build Service Account is a Domain-Admin
Build Connection to TFS goes with a TFS-Admin
Test Controller Service Login Account is a Local-Admin (mirrored on the Build-Server) and earlier tried with the Domain-Admin
Test Controller TFS-Connection also with a TFS-Admin
Test Controller Lab Service Account is not used, earlier also tried with the Domain-Admin
When I set the build to use the latest TFS-Build it runs into the timeout.
And when i set the path to use a Build from a specific location to the Build Directory on the Build-Server it all just works fine.
The difference between a working build and the timeout described above can be seen in this picture: http://i.stack.imgur.com/gPM07.png
Has anyone an idea where I'm struggling?
The problem was, that my previous builds only "partially succeeded" because they had some failing unit tests. The setting to use the only uses fully successful builds. So the latest build which was used had no drop folder configured.
I received no info about that, until I saw it in the logs. My fault was to never check, which build really is used as the latest.
My team uses Web Deploy in order to deploy updates to our website on to our production server. The last few days I've been doing some housekeeping and have changed my password (which I made sure to update in my Web Deploy configuration) and moved the solution for our website to a different location in TFS. I'm not sure which (if either) of these has caused the issue, but I am now no longer able to publish our website using Web Deploy.
I can preview the publish fine, but I can't actually publish it.
The Output in Visual Studio shows this:
Start Web Deploy Publish the Application/package to https://[REDACTED]:8172/msdeploy.axd?site=[REDACTED] ...
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web\Microsoft.Web.Publishing.targets(4270,5): Error ERROR_COULD_NOT_CONNECT_TO_REMOTESVC: Web deployment task failed. (Could not connect to the remote computer ("[REDACTED]") using the specified process ("Web Management Service") because the server did not respond. Make sure that the process ("Web Management Service") is started on the remote computer. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_COULD_NOT_CONNECT_TO_REMOTESVC.)
Publish failed to deploy.
(Note that I've removed some identifying information from this log, which has been replaced with '[REDACTED]')
I found a page describing this issue here: http://www.iis.net/learn/publish/troubleshooting-web-deploy/troubleshooting-web-deploy-problems-with-visual-studio
It says to check in the WMSvc log to find the status and substatus codes for further troubleshooting.
Here I've colour coded lines relating to the preview in green and lines relating to the actual publish in red. As you can see, the requests returned with a 200 (OK) status, meaning the server is not aware of any error occuring. However Visual Studio reports a failure and my production website has not been updated.
The fact that log entries are generated tells me that Web Deploy is properly installed and the handler is setup correctly.
It seems the deploy always fails after ~30 seconds. This could be coincidence, but I'm wondering if there's a timeout at play.
Could anyone suggest further troubleshooting steps?
EDIT: This issue occurs when I try to publish to ANY server, so it's definitely a client issue and not a server issue.
EDIT2: I have two branches of my project, Main and Dev. I just discovered that I can still publish from Dev, just not from Main. They both have identical settings. Very weird.
This can be caused by few reasons. I've written this blogpost earlier about the issues.
When we install the Web Deploy tool, it creates local users "WDeployConfigWriter" and "WDeployAdmin". In your case, you've explicitly changed the password to reset these local users passwords I think, or, the passwords of those in charge. To reset these local users passwords, you can do following:
"Control Panel -> User Accounts -> Give other users access to this
computer -> Advanced -> Advanced -> Users"
Reset WDeployConfigWriter's password
Reset WDeployAdmin's password
"IIS -> Server Node -> Management Service Delegation"
Right click on each
rule with users "WDeployAdmin" and "WDeployConfigWriter"
Click Edit
Click on "Set..." button in "Run As" group
Enter the name of the account you are going to update the password of
Enter password on two areas
If the operation is still erroneous see Event Logs on Windows, they are the real deals here. Check this link.
I added the TestController user which belongs to appropriate security groups. After that I click test and see that it's ok.
Now I click Apply Settings and it finishes saying that:
Failed to configure TFS Team Project Collection.
Failed to remove this test controller from TFS Team Project Collection.
Failed to clear load test database configuration.
So the final result is that settings (user and password) are not applied.
The point is that in my scenario I don't need to stick Controller to TFS. That's why I didn't set any settings in the Team Project Collection section (as well as in the Load testing section). So why does the program warn me about all that stuff?
This could be a bug in the cleanup. Cleanup of previous configurations is done before attempting to start a fresh configuration. Did you configure this machine earlier against a tfs or with other settings?
You can try to unconfigure the controller via the commandline before configuring it again.
testcontrollerconfig.exe delete
You will find this exe in the install path. Run the command from an admin command prompt and then try your configuration again.
I have the problem with failing TFS build if my drop location is in domain different from TFS server. The error I get is
Results file: C:\TestResults\CPU_Release.trx
Test Settings: Default Test Settings
Waiting to publish...
Publishing results of test run buildAgent#computername 2011-01-03 15:31:38_Any CPU_Release to http://tfsserver:8080/...
.....................The drop share directory "\\computername\Builds\projectName\CI_1.0.193.0" could not be accessed.
The drop share directory "\\computername\Builds\projectName\CI_1.0.193.0" could not be accessed.
1:6>C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets(1403,5): error MSB6006: "MSTest.exe" exited with code 1. [C:\Users\BuildType\TFSBuild.proj]
How can at least I skip publishing test results? I tried to set up property
<PublishTestResults>false</PublishTestResults>
but it does not help. I use TFS server 2008.
This workaround finally helped me.
Wish I could speak to the PublishTestResults setting, but what appears to be happening is the tool is trying to authenticate across domains or doesn't have the appropriate permissions on the network drop location.
Two things you can do:
Add the username and password needed to access the droplocation to the Credential Manager of the build agent machine.
Verify that this credential has the correct permissions to this network resource.
The Credential Manager was introduced in XP and beyond.
There is an excellent PDC talk available here from Vishal Joshi which describes the new MSDEPLOY features in Visual Studio 2010 - as well as how to deploy an application within TFS. (There's also a great talk from Scott Hanselman but he doesn't go into TFS).
You can use MSBUILD within TFS2010 to call through to MSDEPLOY to deploy your package to IIS. This is done by means of parameters to MSBUILD.
The talk explains some of the command line parameters such as :
/p:DeployOnBuild
/p:DeployTarget=MsDeployPublish
/p:CreatePackageOnPublish=True
/p:MSDeployPublishMethod=InProc
/p:MSDeployServiceURL=localhost
/p:DeployIISAppPath="Default Web Site"
But where is the documentation for this - I can't find any?
I've been spending all day trying to get this to work and can't quite get it right and keep ending up with various errors. If I run the package's cmd file it deploys perfectly. If I run WebDeploy through Visual Studio it also works perfectly.
But I want to get the whole deployment running through msbuild using these arguments and not a separate call to msdeploy or running the package .cmd file. How can I do this?
PS. Yes I do have the Web Deployment Agent Service running. I also have the management service running under IIS. I've tried using both.
Args I'm using :
/p:DeployOnBuild=True
/p:DeployTarget=MsDeployPublish
/p:Configuration=Release
/p:CreatePackageOnPublish=True
/p:DeployIisAppPath=staging.example.com
/p:MsDeployServiceUrl=https://staging.example.com:8172/msdeploy.axd
/p:AllowUntrustedCertificate=True
giving me :
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets (2660): VsMsdeploy failed.(Remote agent (URL https://staging.example.com:8172/msdeploy.axd?site=staging.example.com) could not be contacted. Make sure the remote agent service is installed and started on the target computer.) Error detail: Remote agent (URL https://staging.example.com:8172/msdeploy.axd?site=staging.example.com) could not be contacted. Make sure the remote agent service is installed and started on the target computer. An unsupported response was received. The response header 'MSDeploy.Response' was '' but 'v1' was expected. The remote server returned an error: (401) Unauthorized.
IIS7 + related answer ....
Ok - here's what I ended up doing. More or less, following the post by Simon Weaver in this thread/question.
But when it comes to the MSBuild settings .. most people here are using following setting: /p:MSDeployPublishMethod=RemoteAgent which is NOT RIGHT for IIS7. Using this setting means TFS tries to connect to the url: https://your-server-name/MSDEPLOYAGENTSERVICE But to access that url, the user to authenticate needs to be an Admin. Which is fraked. (And you need to have the Admin-override rule thingy ticked). This url is for IIS6 I think.
Here's the standard error message when you try to connect using RemoteAgent :-
Standard 401 Frak Off u suck RemoteAgent, error
C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets
(3588): Web deployment task
failed.(Remote agent (URL
http://your-web-server/MSDEPLOYAGENTSERVICE)
could not be contacted. Make sure the
remote agent service is installed and
started on the target computer.) Make
sure the site name, user name, and
password are correct. If the issue is
not resolved, please contact your
local or server administrator. Error
details: Remote agent (URL
http://your-web-server/MSDEPLOYAGENTSERVICE)
could not be contacted. Make sure the
remote agent service is installed and
started on the target computer. An
unsupported response was received. The
response header 'MSDeploy.Response'
was 'V1' but 'v1' was expected. The
remote server returned an error: (401)
Unauthorized.
So .. you need to change your MSDeployPublishMethod to this:
/p:MSDeployPublishMethod=WMSVC
The WMSVC stands for Windows Manager Service. It's basically a newer wrapper over the Remote Agent but now allows us to correct provide a user name and password .. where the user does NOT have to be an admin! (joy!) So now you can correct set which users u want to have access to .. per WebSite ..
It also now tries to hit the the url: https://your-web-server:8172/MsDeploy.axd <-- which is EXACTLY what the Visual Studio 2010 Publish window does! (OMG -> PENNY DROPS!! BOOM!)
And here's my final MSBuild settings:
/p:DeployOnBuild=True
/p:DeployTarget=MSDeployPublish
/p:MSDeployPublishMethod=WMSVC
/p:MsDeployServiceUrl=your-server-name
/p:DeployIISAppPath=name-of-the-website-in-iis7
/p:username=AppianMedia\some-domain-user
/p:password=JonSkeet<3<3<3
/p:AllowUntrustedCertificate=True
Notice the username has the domain name in it? Ya need that, there. Also, in my picture, I've allowed our DOMAIN USERS access to the website for managament. As such, my new user account i added (TFSBuildService) has Membership to the Domain Users group ... so that's how it all works.
Now - if u've read all this, have a lolcat (cause they are SOOOOOOOO 2007)....
Here's the steps that finally worked for me.
I wanted to get the working with RemoteAgent, but couldn't get that working no matter what I tried.
You don't have to do exactly like this, but this is how I got it working
Configure WMSVC
Make sure the service is started
Configure an IIS user (click on the TOP MOST SERVERNAME in IIS) and go to 'IIS Manager Users'. I suggest making it different to your windows name.
Make sure the user account for WMSVC (LOCAL SERVICE for me) has write permissions to the IIS directory you're using
In my case I'm using an SSL certificate (even though it is hitting localhost).
Remember these are all arguments to MSBUILD added within the TFS Build definition
/p:DeployOnBuild=True
/p:DeployTarget=MSDeployPublish
/p:MSDeployPublishMethod=WMSVC
/p:MsDeployServiceUrl=https://staging.example.com:8172/msdeploy.axd
/p:username=sweaveriis
/p:password=abcd1234
/p:DeployIisAppPath=staging.example.com/virtual_directory_name
/p:AllowUntrustedCertificate=True
Note: staging.example.com is actually the local box with a hosts file entry pointing to 127.0.0.1. Localhost would probably work here too.
Useful articles:
Troubleshooting MSDeploy issues
More troubleshooting
Unfortunately there is not a lot of info on this at this time. I'll give you some hints at the end of this message though.
About your problem, I've seen this before when I was trying to deploy using MSDeploy and the account that I was running on didn't have the permissions to execute the deployment on the target machine. So you need to take a look at the account that your builds are running under, and see if this account has the rights to deploy to the target machine. If not then you have a few options; grant the build user the rights, or pass the username/password in.
If you want to pass the values in then you will have to define an item named MsDeployDestinationProviderSetting and its metadata will have to contain the necessary values.
So in your project file (or via properties passed in) define something like the following.
<PropertyGroup>
<UserName>USERNAME-HERE</UserName>
<Password>PASSWORD-HERE
</PropertyGroup>
About where can you find documentation, like I said before there is not much out there yet. But since the entire Web Publishing Pipeline is captured in MSBuild targets and tasks you can learn alot on your own if you are familiar with MSBuild. If you take a look at the .csproj(or .vbproj) files for web projects created with Visual Studio 2010 you'll notice a statement like the following:
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />
This imports the file located at
%ProgramFiles(x86)%\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets, and this file in turn imports
%ProgramFiles(x86)%\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets
So in order to learn this topic in detail right now you have to inspect those files and learn for yourself.
I'm going to be working on something that will be covering these technologies in detail, but it won't be out for quite a while, and I still have a lot to figure out myself about this stuff.
Can you try out the username/password deal and let me know if it worked for you?
I had a similar problem and the solution was to have the following parameter:
/p:MSDeployPublishMethod=RemoteAgent
Here are all of the parameters I used.
/p:DeployOnBuild=True /p:DeployTarget=MSDeployPublish /p:MSDeployPublishMethod=RemoteAgent /p:MsDeployServiceUrl=http://my-server-name /p:username=myusername /p:password=mypassword
NOTE: I'm not using DeployIisAppPath because I'm building a solution and trying to build three web applications at once. Also I think your MsDeployServiceUrl should be just http://staging.example.com
It appears that when using InProc (which may be the default) for the MSDeployPublishMethod MSBuild ignores MsDeployServiceUrl and always tries to deploy to the local server. I changed it to RemoteAgent and all three of my web applications deployed successfully. I did notice that the Package file is nolonger contained in the MyWebApplication_Package folder, but that isn't a big deal to me.
Note that you can also set DeployTarget=Package -- this will prepare the package but not deploy it right away. For more info see this blog post.
For me the problem was that Web Deployment Agent Service was not started.
A simple net start msdepsvc fixed it. You could also set startup mode to Automatic on this service.
The arguments I'm using are:
/p:DeployOnBuild=True
/p:DeployTarget=MsDeployPublish
/p:MSDeployPublishMethod=RemoteAgent
/p:MSDeployServiceUrl=stagingserver
/p:DeployIisAppPath=test.local
/p:UserName=
You only need to specify the server name, and not the full path (no http needed).
Note that UserName is left empty to work around a bug with NTLM authentication (this way it uses the credentials of the TFS build agent for the deployment). see the accepted answer here
Here's how I got it to work. This was with Webdeploy 2.0. I am deploying on the same domain from our build machine to a dev webserver machine windows server 2008 r2. The account I am using to deploy is a service account on the domain that has administrator permissions on both machines. My solution includes a couple of unit test projects, an mvc3 project, and a couple of libraries under the solution. If you don't install MVC3 on the server you are deploying to look at http://www.iwantmymvc.com/2011-03-23-bin-deploy-aspnet-mvc-3-visual-studio for guidance.
/p:DeployOnBuild=True /p:DeployTarget=MSDeployPublish /p:DeployIisAppPath="Default Web Site/YourpplicationNameHere" /p:MsDeployServiceUrl=https://devserver02:8172/msdeploy.axd /p:AllowUntrustedCertificate=True /p:UserName=yourDomain\buildaccount /p:Password=password
The item I struggled with at first were the quotes around "Default Web Site/YourpplicationNameHere" That gives the partial error:
MSBUILD : error MSB1008: Only one project can be specified.
This happens when there are no quotes around Default Web Site/YourApplicationNameHere
The next error I got was because of the wrong username and password in my credentials for deployment. It gave this error:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets (3588): Web deployment task failed.(Remote agent (URL https://devserver02:8172/msdeploy.axd?site=Default Web Site) could not be contacted. Make sure the remote agent service is installed and started on the target computer.) Make sure the site name, user name, and password are correct. If the issue is not resolved, please contact your local or server administrator. Error details: Remote agent (URL https://devserver02:8172/msdeploy.axd?site=Default Web Site) could not be contacted. Make sure the remote agent service is installed and started on the target computer. An unsupported response was received. The response header 'MSDeploy.Response' was '' but 'v1' was expected. The remote server returned an error: (401) Unauthorized.
This was because the username and password I had in /p:UserName=/p:Password=did not include the domain for the user. Even though it the build was running under that user it would not deploy. So I hit the url directly https://devserver02:8172/msdeploy.axd in a browser to make sure it was operation and make sure the username and password worked. This is where I noticed I had to put in the domain/user to get it to work.
I hope this is OK to reply I figured some other poor soul with find these errors and this could help...
If you can deploy your applications with fileCopy, it is easy to customize the TFS workflow to do so.
I've used the CopyDirectory activity, with the help of these articles:
http://www.ewaldhofman.nl/post/2010/11/09/Part-14-Execute-a-PowerShell-script.aspx
and
http://geekswithblogs.net/jakob/archive/2010/09/01/tfs-team-build-2010-how-to-place-the-build-output.aspx
Very simple and straightforward.
I Configured the build service with a user account that has write privileges on the desired share.
Next, I created the CopyDirectory workflow step, configuring the source as BuildDetail.DropLocation + "_PublishedWebsites" and for the destination I created an argument, which I called "DeployPath", that can be filled in the build configuration.
Now I still have to implement a test to check if the build was successful before invoking the CopyDirectory activity. The articles I mentioned show how to do that. They also teach how to invoke a powershell script instead of CopyDirectory.