Getting Web Deploy Working For Non-Admin Logins

There’s a lot of good information around online about how to get Web Deploy (a.k.a. msdeploy) working.  What most of the information tends not to cover is how to get it functioning for non-admin users.

In this post I’m going to cover the steps to go through to get a non-Admin windows user working for deployments.

The Foundation

First of all, let’s get the basics out of the way.  This is the environment these instructions are applicable to:

  1. Windows Server 2008 R2 (with SP1).
  2. Web Role (IIS) Installed – make sure you have installed the Management Service (see below).
  3. Windows Firewall on but with an Inbound allow rule for TCP traffic on port 8172.
  4. You have downloaded Web Deploy.

Management Service Installed.

Now we have the main bits ready to go we need to setup Web Deploy.

Install and Configure Web Deploy

When you install Web Deploy you need to make sure all components are available.  Either select ‘Complete’ or ‘Custom’ when prompted for what to install.  You should find that the components to install looks like the following.

What items from Web Deploy you need to select.

Once you have finished the installation you can verify the state of your configuration by reviewing your server and you should find:

1. A new local user called WdeployAdmin.

2. Two new services – Web Deployment Agent Service and the Web Management Service.

New Services Installed.

Add Windows Login

We’re going to be using a non-Admin user for our deployments so lets go ahead and add a new Standard Windows login (i.e. one that is not an Administrator).

Note: Username and password should be chosen with care – in some deployment scenarios your password (particularly) may cause issues if it has characters that cannot be included in XML without being escaped. A simple rule of thumb is to avoid &, < and >.

Tip: If you have authentication issues test using a simple password that has no special characters.

Configure Management Service

We need configure the management service to allow remote connections and (in this instance) to only allow Windows credentials (the default).

Open up the IIS Manager on your server and ensure you have Features View on in the right pane.

Look for the Management Group (usually at the bottom) and then within that group select Management Service (see below).

Management Service Highlighted in Blue.

When this view opens you will most likely find the form is disabled – this is because the service is running – you can’t change the configuration.  If you look at the right pane you will see an option to Stop the service.

Make sure to check the ‘Enable remote connections’ option and to leave the ‘Windows credentials only’ selected (as below).  Now restart the service.

Management Service Configuratoin

Grant Windows Login IIS Manager Permissions

You can now grant the non-Admin user you created earlier the rights to manage sites on your IIS machine.

In the left pane of the IIS Manager select the site you wish to add your Windows login as a manager for (you will need to repeat for each site).

In the right pane you should see a Management group with two options (Configuration Editor and IIS Manager Permissions).  Open the IIS Manager Permissions view.

In the new view that opens on the right hand pane near the top you should see ‘Allow User…’ – click on it and a popup will appear.

From the popup you can select the Windows user you wish to add – click on the Select button and then search for the user you create previously.  Finally click OK on the two dialogs so you return to the initial screen where you will see a new entry for your user (sample below).

User View once granted access to deploy.

The Missing Link

I can almost guarantee you at this point that if you run the deployment it will fail.  This is something I spent a fair amount of time trying to troubleshoot and so I have this advice for you:

The non-Admin Windows login you granted IIS Manager Permissions to must be able to read / write to the root folder location that the IIS site is deployed to.

Using this approach I’ve been able to get non-Admin users publishing successfully so the approach should work for you too.

May 2012 – Updated!

One important addition to add to all of the above.

When you setup Web Deploy it will create a two local users on the host that have priveleges to setup IIS sites and modify configuration files.  The logins are WDeployAdmin and WDeployConfigWriter.

If you find that after a period of time Web Deploy starts giving errors and not deploying it is most likely due to the passwords for these users expiring and Windows setting the “user must change password on next logon” flag (assuming you left the default password policy in place on your Windows server).  Either set the password not to expire or update it and clear the next logon flag.

Safely Testing .Net Code That Does Email Delivery

As a .Net developer you will most likely have come across the need to create and send an SMTP (email) message as part of a solution you’ve built.  When under development you will have either stubbed out the mail delivery code or will have substituted a test email address for those of the final recipients in a live environment (did your mailbox get full?!).

This approach is simple and works pretty well under development, but you know one day someone will come to you with a production problem relating to mail delivery to multiple recipients with each receiving their own copy of the message.  How do you test this without needing multiple test mailboxes and without spamming the real recipients?

A few years back I learnt of a way to test mail delivery with real email addresses that can be performed locally of a development machine with minimal risk (note I didn’t say “no risk”) that email will actually be delivered to the intended recipients.  The great thing is you don’t need to understand a lot about networking or being a sysadmin god to get this working.

IIS To The Rescue

Yes, IIS.

In this case you don’t even need any third party software – just the web application server that most ASP.Net developers know (“and love” is probably pushing the relationship a little though I think).

First off, you will need to install the SMTP feature support for IIS on your local machine.  You can get instructions for IIS 7 from TechNet as well as for IIS 6.  If you’re on IIS Express, you’re out of luck – it only supports HTTP and HTTPS.

Once you have the SMTP Feature installed you will need to make one important change – set the SMTP server to use a drop folder.  The IIS SMTP process will simply drop files into a location you’ve selected and there they will sit – each file containing an emaill message.

To make this change open the IIS Manager and select the main server node.  You should see (screenshot below) an option for SMTP E-mail.

IIS Manager with SMTP Email option highlighted

IIS Manager with SMTP Email Option Highlighted.

Double-click the SMTP E-mail option to open the settings dialog. Notice at the bottom the option labelled Store e-mail in pickup directory – you should select this and then select an appropriate location on disk.

SMTP Email Settings Page with Drop Folder Highlighted

SMTP Email Settings Page with Drop Folder Highlighted.

Right, that’s the hard bit done.

Run Teh Codez

Now you have a safe place for your test mail to sit you need to ensure that your code is configured to attempt delivery via the SMTP instance you just configured.  You can most likely achieve this by changing your application’s settings (they’re in an XML config file, right?) so that you use either of “localhost” or “127.0.0.1″ as the SMTP host name – you won’t need to change the port from the standard port 25.

Now when you run your code you should find that the mail delivery folder you set will be populated with a range of files consisting of a GUID with a .EML extension – each of these is an individual email awaiting your eager eyes.

Lovely EML Files Ready To View.

Lovely EML Files Ready To View.

The files are plain text so can be opened using Notepad or your favourite equivalent – you can view all the SMTP headers as well as the message body.  For extra goodness you can also open these files in Outlook Express (does anyone even use that any more?!) or Outlook as shown below.

Outlook Goodness - See HTML Email Body Content Easily.

Outlook Goodness – See HTML Email Body Content Easily.

I used this approach just recently to help debug some problems for a customer and I could do it using their real email addresses safe in the knowledge that I would not end up spamming them with junk test emails.

Hope you find this approach useful.

Update

I had a reader pass on a service link to Mailtrap which might be more useful if you’re looking to test with a large diverse team.