Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

we're currently using the MS Web Deployment Tool to sync a live website and some WebServices from a staging box to two live servers.

The staging box hosts the site on any IP on port 17000, whereas the two live servers are load-balanced and have a different IP for each of them.

At present, I generate two separate packages for deployment - one for each machine - using the sync operation and specifying a DestinationBinding parameter as follows:

msdeploy -verb:sync 
  -source:WebServer,computerName=localhost
  -dest:package="machinename.zip"
  -setParam:type="DestinationBinding",scope="SiteName",value="ip_address:port:".

(Split across multiple lines to make it easier to read!)

I run this twice, with a different target filename and ip address for each of the two machines. When it comes to deployment, I simply do a sync from each package to its respective live site.

I know, I know - I should be able to do it by generating one parameterised package and then perhaps using the SetParamFile switch for each of the two Servers - believe me I'd like to, but the documentation on doing this is frankly non-existent.

Now I need to configure and deploy both HTTP and HTTPS binding for this site; including also the ssl cert that is to be used.

I've added an SSL binding for the site on the staging box - which uses a development cert (which will need to be replaced - or should the staging box be using the live cert?), and now the above command line has the effect of replacing the target IP on both http and https entries.

It appears that I cannot specify multiple bindings plus the cert information in the DestinationBinding value in the -setParam above, so anyone know how would I go about doing this?

Any help greatly appreciated.

share|improve this question
1  
maybe you should add msdeply as a tag. might also jump over to stackoverflow.com as there are a number of msdeploy –  MikeJ Feb 8 '10 at 14:52
    
now there's a good point :) –  Andras Zoltan Feb 8 '10 at 14:54
    
Yeah - I did think of StackOverflow first; figured that lower-level ops of msdeploy are more likely to be of use to tech support/admins than developers. If I don't get anywhere here then perhaps I'll retire this question and post over there instead as you suggest. Could always argue that I'm a developer, and not an analyst, and if I need to know it then other devs probably do too! –  Andras Zoltan Feb 8 '10 at 15:07

1 Answer 1

up vote 6 down vote accepted

Ok so I got this far - I'm not posting this as an edit to the question, on the off-chance that although this appears to be on the right track, there might be a better way than what I've been working on. Figure I'd let democracy decide!

Using this link I was able to figure out the format of the XML file that should be used with the setParamFile switch for msdeploy. I'd also, in the past, figured out the format for the declareParamFile XML by using the embedded GUI within IIS after installing the Web Deployment Tool.

So, given a site called 'SiteA', with two binding entries in the applicationHost.config file as follows:

<bindings>
  <binding protocol="http" bindingInformation="*:80:" />
  <binding protocol="https" bindingInformation="*:443:" />
</bindings>

(Which means, specifically - any IP address on port 80 and any IP address on port 443)

The actual cert being used is not stored in applicationHost.Config, but instead in the configuration for Http.sys (according to this article). When msdeploy prepares a package for the site, it will embed that information - which might not be a blessing as I mention at the end.

The first step is to declare a parameters xml file that we will use to parameterise a single package for the target live servers:

<parameters>
  <!-- declare parameter for Http Binding -->
  <parameter name="SiteA-http" description="SiteA Http Binding">
    <parameterEntry kind="DestinationBinding" scope="SiteA" match=":80:" />
  </parameter>
  <!-- declare parameter for Https Binding -->
  <parameter name="SiteA-https" description="SiteA Https Binding">
    <parameterEntry kind="DestinationBinding" scope="SiteA" match=":443:" />
  </parameter>
</parameters>

Note the 'match=' attribute values on the two inner parameter entries. This ensures that the correct binding is replaced. This is a Regex (as described in this technet article) that selects the existing binding values that are to be changed with the parameter value that will be passed in a moment.

We save this as declareparameters.xml.

With this in place, we can now generate a parameterised package, from our staging box, from which we can then deploy, using this command line (this is to 'image' a whole IIS within which our SiteA is present):

msdeploy -verb:sync 
  -source:WebServer,computerName=localhost
  -dest:package="parameterised.zip"
  -declareParamFile:declareparameters.xml

If the web site is on a different web server, replace 'localhost' with that web server's name. The Web Deploy Agent service has to be running on the target machine for this to work.

Now, we declare a parameters xml file that will actually provide parameter values for a deployment to a live server:

<parameters>
  <setParameter name="SiteA-http" value="[fixedIPAddress]:80:"/>
  <setParameter name="SiteA-https" value="[fixedIPAddress]:443:"/>
</parameters>

And we save that as

[targetServerName]parameters.xml

(in my case I have two target servers, so each gets its own parameters xml with a different file name, and slightly different IPs in each).

Finally, we can perform the parameterised deployment to the target server(s) with this command line:

msdeploy -verb:sync 
  -source:package="parameterised.zip"
  -dest:WebServer,computerName="[targetServerName]"
  -setParamFile=[targetServerName]parameters.xml

So now we can change the IPs of either the Http or Https Binding and, if the originals are sufficiently different, we can parameterise any number of individual bindings that might be required for that site.

This has one drawback so far - so any alternative answers appreciated please - the SSL configuration is copied from the source machine into the package - meaning that in order for the SSL config on the live site to be correct on deployment, both the staging machine and the live server(s) must use exactly the same SSL certs.

What would be great is if the staging box could use a self-signed or internal cert for sanity checking, and then have the real SSL cert be applied on the actual deployment - again, parameterised from the XML files.

share|improve this answer
    
This would appear to be a limitation of the msdeploy tool - and the only solution is to write an additional iis script that msdeploy can execute. This script would wrap up the additional bindings, with SSL cert stuff. This is an incredible shame. –  Andras Zoltan Apr 1 '10 at 12:26

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.