The following snippets will fix the case where there is something wrong with the SSL certificate on the server you are calling. For example, it may be self-signed or the host name between the certificate and the server may not match.
This is dangerous if you are calling a server outside of your direct control, since you can no longer be as sure that you are talking to the server you think you're connected to. However, if you are dealing with internal servers and getting a "correct" certificate is not practical, use the following to tell the web service to ignore the certificate problems and bravely soldier on.
The first two use lambda expressions, the third uses regular code. The first accepts any certificate. The last two at least check that the host name in the certificate is the one you expect.
... hope you find it helpful
//Trust all certificates
System.Net.ServicePointManager.ServerCertificateValidationCallback =
((sender, certificate, chain, sslPolicyErrors) => true);
// trust sender
System.Net.ServicePointManager.ServerCertificateValidationCallback
= ((sender, cert, chain, errors) => cert.Subject.Contains("YourServerName"));
// validate cert by calling a function
ServicePointManager.ServerCertificateValidationCallback += new RemoteCertificateValidationCallback(ValidateRemoteCertificate);
// callback used to validate the certificate in an SSL conversation
private static bool ValidateRemoteCertificate(object sender, X509Certificate cert, X509Chain chain, SslPolicyErrors policyErrors)
{
bool result = cert.Subject.Contains("YourServerName");
return result;
}
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)....
Best Answer
If you go into IIS,
Click on the server node in the "Connections" list,
Double click "Management Service" then you are taken to a screen which has an "Enable remote connections" check box.
This checkbox (and the rest of the sreen) maybe greyed out because the service is running. Just click the "Stop" link in the Actions pane, then check the "Enable remote connections" box and any other settings you want to change here, then click 'Apply' and 'Start' on the Actions pane again.
That should hopefully let you connect, with proper credentials, to the service from a remote machine. (If the correct ports and stuff are opened and all that jazz.)
I think this helps your situation. At least you won't get 403's but you may have some other MsDeploy error.