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

In part 1 of this small blog post series I discussed the alternatives for remote execution of web deploy commands and how to set it up.

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.


This time I’m going to use my setup (picture below), which now has web deploy configured on both servers in VIRJOLE network, to run a couple of samples and discuss some pros and cons etc.

image

1. Dissecting the syntax

Let’s first begin with a simple command and discuss the parts of it.

That simple command will just return that content of the default website on remote server virjole-wfe1 but let’s go through the provider settings which are the interesting parts of it.

1.1 line 4 – computerName

,computerName=<host>

where <host> specifies the name of a remote web server or proxy url. The computer name will be translated to the default web deploy url. For example, computerName=Server1 will become http://Server1/MsDeployAgentService

So, to get a connection to the wmsvc service (port 8172) we need to supply the full url to the wmsvc instead….or

1.1.1 – The wmsvc provider setting

The same command but with the wmsvc provider setting instead (a little simpler perhaps).

,wmsvc=<name>

where <name> specifies the name of a remote computer or proxy url whose IIS Web Management Service (wmsvc) will be used over HTTPS. It is assumed that the service is listening on port 8172.
You can also skip the the authType when using the wmsvc provider setting.

1.2 line 7 – authType

,authType=<authenticationType>

where <authenticationType> specifies the type of authentication to be used. The possible values are NTLM and Basic. If the wmsvc provider setting is specified, the default authentication type is Basic; otherwise, the default authentication type is NTLM.

1.3 line 8 – allowUntrusted

-allowUntrusted=<BOOL>

where <BOOL> must be true or false. True if untrusted SSL connections are allowed; otherwise, false. The default is false.

We need to use this switch otherwise the following error appears:

Error Code: ERROR_CERTIFICATE_VALIDATION_FAILED
More Information: Connected to the remote computer (“virjole-wfe1”) using the specified process (“Web Management Service”), but could not verify the server’s certificate. If you trust the server, connect again and allow untrusted certificates.  Learn more at:
http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_CERTIFICATE_VALIDATION_FAILED.
Error: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
Error: The remote certificate is invalid according to the validation procedure.
Error count: 1.

Lastly username and password speak for themselves so I’ll skip those and instead talk about storing credentials.

 

2. Working with credentials

Perhaps it’s not the best solution to always have to specify and include the username and password for every command you issue. Fortunately, web deploy supports reading/writing credentials out of the windows credential manager.

2.1 line 7 – storeCredentials

,storeCredentials=<target>,userName=<username>,password=<password>

where <target> is a user-specified variable that identifies, in the Windows Credential Manager, a set of credentials (username and password) that will later be used when you connect to a remote computer. storeCredentials must be used with the username and password provider settings. After you have stored the credentials, you can retrieve them by using the getCredentials provider setting. This lets you avoid placing a username and password directly in a command line.

After running a command like the one above just look in your windows credentials manager and you’ll see:

image

Now, how to use that then—?

2.2 line 5 – getCredentials

,getCredentials=<target>

where <target> is a variable that identifies, in the Windows Credential Manager, a set of credentials (username and password) that will be used when you connect to a remote computer. By using the getCredentials provider setting, you can avoid placing a username and password directly in a command line. To create a <target> variable, use the storeCredentials provider setting to associate a set of credentials with the variable name that you specify.

note: getCredentials has one issue though and that is that you can’t use it together with wmsvc. If you do you’ll get the following error:

Error: The specified credentials cannot be used with the authentication scheme ‘basic’.
Error: Default credentials cannot be supplied for the basic authentication scheme.
Parameter name: authType
Error count: 1.

So, if you want to use getCredentials you have to use the computerName provider setting instead and specify the full url to the wmsvc service.

So to sum up, first use any command (dump and iisApp is a simple one) to store the credentials. Then you can skip username and password but you have to use the full url and computername instead of wmsvc.
Easy…no, well it works anyways!

,

  1. Web Deploy: using web deploy on remote servers – Part 1 « Johan Leino
  2. Web Deploy: filePath Provider « Johan Leino
  3. Practical Web Deploy Provider Examples « Johan Leino

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: