Web Deploy: using web deploy on remote servers – Part 1

The picture above is meant to illustrate a pretty common scenario in most deployment situations.
You’re working for company X and there you have local build server. Your hosting environment/s (Test|QA|xxx) are located on another network that has no (or limited) knowledge of your company network.
If you would like to use web deploy to push/deploy from your build server to the offsite environment you need a way to setup web deploy to support remote execution correctly. This post is meant to show you how to accomplish just that.

Microsoft describes two basic ideas for using web deploy remotely; Web Deployment Agent Service and Web Management Service Handler (WMsvc).

Web Deployment Agent Service

The Web Deployment Agent service can be used only by administrators.

The main idea about this approach is that a user that is administrator on those two machines (wfe1 and wfe2) can from his/her own computer (in the same domain) execute web deploy commands.

Like this:

You would think that you could the use the same approach to call web deploy from an offsite network (as long as you provide the appropriate credentials).

Like this:

However, this only results in “ERROR_USER_NOT_ADMIN” error message.

That’s because “you cannot use basic authentication together with the remote agent service” and windows authentication won’t work over these networks.
There are workarounds but I haven’t had any luck with them.

Web Management Service Handler (WMsvc)

The Web Deploy handler uses the Web Management Service (WMsvc) to allow non-administrative users to access the sites and applications to which they have been delegated access. The handler is useful for Web hosting because it gives users control over the publishing of their own content while preventing them from having administrative rights on the Web server that hosts their content.

As the quote states, it’s mostly used for web hosting providers that want to give users control over their site which gives them the opportunity to call into the remote server/s like this:

That will give user x the right to deploy to http://www.example.com on the remote server. However, it still doesn’t give him/her the ability to perform fully administrative tasks on the whole server which is usually required in an automated deployment situation.

Another option

Ok, now let’s get into setting up our remote server to support commands coming from an offsite (build server) location.
I’m actually going to use the WMsvc/handler approach but use it (and setup) in a way that I can perform administrative tasks.

So, I’m assuming the remote server (virjole-wfe1) has the IIS web role installed and is joined to the domain ‘hyper-v’.

1. Install web deploy

I’m using web platform installer (webPI) to install web deploy for hosting servers(there are other alternatives but this gives me what I need so…)

Now, when you open up the IIS manager UI you will see the management service.

You can see that it runs on port 8172 by default.

Note: if you’re connecting through a firewall (and don’t want to add any new rules) just change the port to 443 and it will work (as long as you don’t have anything else running on 443). Please note that if you run on any other port than the default one (8172) you can’t use the wmsvc provider setting (I’ll show you later) but instead have to use the full computername (like computername=https://virjole-wfe1:443/msdeploy.axd).

2. Make sure you have admin access

So, the simplest approach might be to ask for an account that can be used for web deploy and make that admin on the servers.

So, now all-in-all it should work to execute remote commands.

Try it

To test it I will try to stop an IIS site on the remote server (that will need me to be admin)

Disclaimer:All the gists have been formatted for readability.
That means that if you plan to use them in a command-prompt you need to re-format them accordingly.

You can see on line 6-9 that I have specified the computer name as a web address to the webdeploy.axd service (wmsvc) and provided user name and password to the remote server as well as enabled basic authentication.

Note: since the service runs on port 8172 (default) I could have used the wmsvc=virjole-wfe1 setting instead of the full computer name setting. Optional of course.

On line 10 I also have to allow the call to be untrusted (without cerificates) to make it work.

And…

In part 2 of this mini series I will show you some other neat tricks on remote web deploy commands and discuss the syntax in more depth