• Shortcuts : 'n' next unread feed - 'p' previous unread feed • Styles : 1 2

» Publishers, Monetize your RSS feeds with FeedShow:  More infos  (Show/Hide Ads)

Date: Tuesday, 09 Jul 2013 22:40

WebDeploy v3.5 is now available for download, and there are a few features to consider in this minor release.

Load Balancer Support with Session Affinity

This feature allows WebDeploy to be used with load balancers like ARR supporting layer 7 (OSI application layer) session affinity. If the load balancer sends a session cookie to WebDeploy, WebDeploy will return this cookie to the load balancer to have it route subsequent requests to the proper publishing endpoint.

Here is an example for configuring the ARR load balancer to generate and send the session cookie to WebDeploy (no specific configuration is required for WebDeploy). Navigate to the server farm to configure using IIS Manager:

IIS Manager - server farm

Enable client affinity under the server farm’s Server Affinity option:

IIS Manager - server farm Server Affinity

Encrypting web.config Settings Post-Publish

A new EncryptWebConfig rule handler was created to encrypt connection strings within a web.config file before updating it on the destination. This rule handler applies to the following providers: appHostConfig provider, contentPath provider and <>iisApp provider. The EncryptWebConfig rule handler is disabled by default and can be enabled by clients. When this rule handler is enabled, WebDeploy uses the standard .NET framework RsaProtectedConfigurationProvider which relies on the default key container NetFrameworkConfigurationKey (other KeyContainers can also be used because WebDeploy supports provider name override).

Here is example usage with the default RsaProtectedConfigurationProvider:

msdeploy.exe –verb:sync –source:iisapp=”sourceTestSite” –dest:iisapp=”destinationTestSite” –EnableRule:EncryptWebConfig

App Offline Template

WebDeploy v3.5 adds an enhancement to the existing AppOffline rule which allows you to take an ASP.NET application offline before publishing. In this release, WebDeploy supports specifying the relative path to an app offline template file located on the destination system. This rule handler applies to the following providers: appHostConfig provider, contentPath provider and iisApp provider.

The app offline template file can capture any static HTML content to be displayed for users while the app is offline. Here is example usage:

msdeploy.exe -verb:sync -source:iisApp=sourceApp -dest:iisApp=destApp,appOfflineTemplate="offlineTemplate.htm" -enablerule:AppOffline

ETW Instrumentation

WebDeploy v3.5 enables ETW logging for improved diagnosability with minimal impact for system resource consumption. The Error and ConnectionInfo channels are enabled by default, and additional Debug, Verbose, Info, and Warning channels can be enabled by Event Viewer configuration.

Here is an example for accessing and enabling Web Deploy ETW channels via Event Viewer under Applications and Services Logs\Microsoft\Windows\WebDeploy

IIS Manager - server farm Server Affinity

Author: "romanf" Tags: "IIS News, Walkthroughs, Web Deployment, ..."
Comments Send by mail Print  Save  Delicious 
Date: Thursday, 26 Jul 2012 23:58

Web Deploy V3 RTM is now available. Plese follow our release announcement here



Author: "harshmittal"
Comments Send by mail Print  Save  Delicious 
Date: Thursday, 19 Apr 2012 23:15

We are happy to announce that we have just released the Release Candidate for Web Deploy 3.0. You can download the x86 or x64 versions.

If you are new to Web Deploy, Please read our Introduction to Web Deploy tutorial. Currently Web Deploy RC is only available through direct download. We are still working on WebPI feed. Easiest way to install V3 RC is to first install Web Deploy V3 Beta using WebPI 4 beta (x86/x64) as instructed in Installing & Configuring Web Deploy tutorial, and later update it using RC setup.  Web Deploy 3.0 beta will be upgrade to the RC version, and this V3 will continue to live side-by-side with Web Deploy 2.0 & Web Deploy 1.1.

Here's a rundown of new features:

1. Publishing & Migration to IIS8

You must have heard about our latest & greatest server release Windows Server 8 Beta. It comes with IIS8 which has lots of cool new features. To take advantage of these features, you might be thinking about migration strategy from your existing IIS Servers. Web Deploy 3.0 fully supports migrating to IIS8 from IIS 6, IIS7 and IIS7.5.  Please follow our documentation walkthrough on migration

  1. Synchronize IIS
  2. Migrate a Web Site from IIS6.0 to IIS7 and above

Publishing experience for IIS8 is no different than publishing to IIS7, you can learn more about publishing in our tutorial "Testing Web Deploy Publishing From Visual Studio 2010 and WebMatrix." 

Note that WebMatrix 2.0 and Visual Studio 11 are still in beta and they shipped with beta version of Web Deploy 3.0. Web Deploy team has not done extensive testing of compatibility between beta versions of these products with RC version of Web Deploy 3.0, so we would recommend you to wait for WebMatrix and Visual Studio teams to release post beta builds if you are planning to do anything more than just testing out new features of Web Deploy 3.0 in test environments.

2. Automatic Backup       

One of the common feedback we received that customers often make mistakes while publishing changes to websites. This is especially true for amateur developers and small business owners. It is very hard to recover from these mistakes. In Web Deploy V3 RC we are introducing new feature "Automatic Backup" which will allow server administrators to configure servers in such a way that each publish will automatically generate a backup and store it on server. If you need to roll back or go to a previous version, you will be able to do it without involving server administrator.

You can learn more about this feature in our "Automatic Backups" Tutorial.  Please do provide your feedback on this brand new feature!

3. PowerShell Cmdlets

Web Deploy command line is very versatile which also makes it equally complex. Based on your feedback, team has invested into PowerShell Cmdlets for common Web Deploy tasks. We are releasing more than 20 PowerShell Cmdlets in this release for very first time.

Powershell cmdlets includes help description as part of cmdlets themselves. More details are provided in "PowerShell Cmdlets" tutorial.

4. Improved parameterization

Web Deploy supports parameterization of publish settings during deployment time. To learn more read Web Deploy parameterization.

Earlier versions of Web Deploy only supported replacing attribute values which already existed as part of the package. We have added support for

  1. Extend the current xml parameterization beyond attribute value replacements to a more complete xml modification story by allowing addition/deletion/replacement of new elements.
  2. Accept the replacement data for parameters to come from the server, from the package itself or from the source.

Here is one example of a parameters.xml file which will add newNode to all nodes including the root in target xml file.


  <parameter name="Additive" description="Add a node"   defaultValue="&lt;newNode />"  tags="">

    <parameterEntry kind="XmlFile" scope=".*" match="//*" />



Below are some examples which demonstrate how to get the values from other places

Get values from remote server:

<parameter name="Replacement Param" defaultValue="\\myshare\share\web.config:://connectionStrings" >

  <parameterEntry kind="XMLFILE" scope="web\.config$" match="//connectionStrings" />


Get values from a file in the package that is being synced:

<parameter name="Replacement Param" defaultValue="\web.config:://connectionStrings" >

  <parameterEntry kind="XMLFILE" scope="web\.config$" match="//connectionStrings" />


More details about parameters.xml file can be found here

5. ApphostAuthOverride Provider

This is a new Web Deploy provider which will provide support for changing authentication mode for a given website. Many a times in enterprise environments applications want to choose their own authentication method using web.config file, but AppHostConfig file locks this setting.  This means that if a developer tries to set his/her site's authentication settings, IIS will not obey it.  The Application Host Authentication Override provider allows developers to configure how IIS locks an authentication setting on the server by adding a <location> tag for that setting within the server's applicationHost.config file.  Here is an example of what that looks like in config:

   <location path="siteName" overrideMode="Allow">




                    <windowsAuthentication />





 Here is a few command line examples of how this could be done (msdeploy.exe is located under "%programfiles%\IIS\Microsoft Web Deploy V3"):

·         Allow Windows Authentication on Destination at site = SiteName: 
msdeploy.exe -source:ApphostAuthOverride -dest:ApphostauthOverride="<siteName>;windowsAuthentication=Allow"

·         Allow ASP.Net Forms Authentication on Destination at site = SiteName:
msdeploy.exe -source:ApphostAuthOverride -dest:ApphostauthOverride="<siteName>;aspNetAuthentication=Allow"

·         Deny Anonymous Authentication on Destination at site = SiteName:

msdeploy.exe -source:ApphostAuthOverride -dest:ApphostauthOverride="<siteName>;anonymousAuthentication=Deny"

·         Reset Windows Authentication Setting on Destination at site = SiteName:
msdeploy.exe -dest:ApphostAuthOverride="<siteName>;windowsAuthentication"

Please note the sytax carefully, both <sitename" and authentication setting are part of -dest:ApphostAuthOverride value.

6. Others

Apart from these new features there are many bug fixes in the release. Please follow ReadMe file for more details.

Author: "harshmittal" Tags: "IIS News, Migration, Web Deployment, IIS..."
Comments Send by mail Print  Save  Delicious 
Date: Monday, 25 Jul 2011 04:56
How to set up your own WebMatrix server and publish to it using Web Deploy: http://www.bilalaslam.com/setting-up-your-own-webmatrix-server/
Author: "panic_at_the_disco" Tags: "Web Deployment"
Comments Send by mail Print  Save  Delicious 
Date: Wednesday, 29 Jun 2011 05:24

If you have an existing web site, you can open it in Microsoft WebMatrix. There are some caveats (which I have noted below), but overall it works quite well. Let’s suppose you have a Wordpress site:

1) Start WebMatrix

2) Click Site from Web Gallery. Walk through the wizard and install Wordpress locally. This will make sure that all the application dependencies (such as PHP and MySQL) are installed. More importantly, WebMatrix will now have all the configuration it needs to publish this site.

3) Click Publish in the ribbon

4) Enter publishing settings. I recommend Web Deploy because you can publish databases as well as files using this technology. You can learn more about entering settings here.


5) Next, an all-important step: click the dropdown under the Publish button and click “Download published site…”. This feature only works with the Web Deploy protocol (caveat!) but it lets you download a full copy of your live site.


6) Make any changes you want and click Run in the ribbon.

7) If the site looks good, click Publish.

Author: "panic_at_the_disco"
Comments Send by mail Print  Save  Delicious 
Date: Tuesday, 05 Apr 2011 03:54

We are happy to announce that we have just released a refresh of Web Deploy 2.0 for MIX ‘11. Our goal for this release was to make Web Deploy easier to install and manage. You can download the x86 or x64 versions.

Web Deploy 2.0 will upgrade to the latest version, and this latest version will continue to live side-by-side with Web Deploy 1.1.

Here’s a rundown of new features:

1. Easier setup for non-administrator deployments on IIS7

One of the common requests from our users was to make it easier to setup Web Deploy so non-administrators can publish to their sites. Typically, you will need to do this if you are running a shared hosting environment or if you are administering a build machine and you do not want users to have admin access.

If you launch the Web Deploy installer and choose “Custom”, you will notice a new option, “Configure for Non-administrator Deployments”:



If you choose this option, Web Deploy will automatically create Management Service Delegation rules for the following providers, as well as user the accounts needed for providers like createApp and recycleApp that need elevated privileges.

These are the rules you will have in the Management Service Delegation UI  in IIS Manager after you install this component:


Notice that Web Deploy setup created two new local user accounts:

- WDeployConfigWriter, which has Write permissions to the IIS server’s applicationHost.config. This is used by delegation rules for createApp, appPoolNetFx and appPoolPipelineMode.

- WDeployAdmin, which is an administrator. This is used by delegation rules for recycleApp.

If you prefer to create these rules by hand, uncheck the component in the installer. We also provide a PowreShell script for creating delegation rules (more on this later in the post) if you prefer that route.

2. Services are configured out of the box

We made a few common-sense changes to Web Deploy setup so you, as an administrator, can just run our installer and have the right sets of services started and configured so Web Deploy just works out of the box.

- If Remote Agent Service is installed, it is started automatically by the installer.

- If the Management Service is installed and you install the IIS7 Deployment Handler component, Web Deploy setup enables incoming connections to the Management Service from Windows and IIS Manager Users and starts the service.

Additionally, administrators are allowed to bypass Management Service Delegation rules by default. This is useful if you are an administrator on the box and just want to deploy to it without having to worry about delegation rules getting in the way.

3. Improved error messages

Web Deploy now includes error codes and friendlier error messages. This can be helpful in diagnosing why your Web Deploy command is not working.

Read more about error codes here.


Notice that the first line shows a request ID. Guess what? The same request ID now shows up in ..

4. Per-request tracing for Web Management Service (IIS7 only) in the Windows Event Log

By default, Web Deploy now logs errors caused by requests to the Web Management Service. This is a major improvement over previous logging mechanisms which logged to a text file or to Failed Request Tracing (aka FREB) logs.

To view Web Deploy logs, simply start Event Viewer and navigate to Applications and Service Logs > Microsoft Web Deploy. Quick tip: add the User column to the view to sort by User ID – this can be useful when you’re on the phone with a remote user!


Note that the logging level is Errors Only by default. You can change the logging level from 1 to 4 (4 being the most verbose) by setting this registry key (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\IIS Extensions\MSDeploy\2\WMSVCTracing) and restarting the Web Management Service – be forewarned, a logging level of 4 will greatly slow down the Web Management Service and is NOT recommended for production! You can read more about Management Service logging levels here.

5. IIS Manager UI for Configuring Web Deploy for a Site (IIS7 only)

The very first feature in this list set up rules which allow non-administrators to run some Web Deploy providers on your server. However, you still need to enable Web Deploy for specific web sites. This is similar to how you install and configure FTP globally for your server, but you still have to enable FTP for a site before users can access it.

In the past, this involved manually setting file system security permissions. And when you wanted to generate a publish settings file which could be consumed by Microsoft WebMatrix, you were on your own. Now, IIS Manager includes a new UI to make it easy to set up file system and IIS Manager permissions needed to enable Web Deploy publishing for a site. As an added bonus, this UI also generates a publish settings file which can be used to quickly set up publishing in WebMatrix.

To try this UI,

1) Start IIS Manager by clicking Start > Run and type “inetmgr.exe”

2) Right-click the site you want to publish to, click Deploy and then click “Configure Web Deploy Publishing…”


For now, you can just click “Setup” and copy the generated file to your development computer. If you are interested in customizing some of these options, here’s an explanation of what each one of them does:

Select a user to give publishing permissions

If you want to publish as the currently logged-in user, leave this unchanged. Otherwise, you can specify a different account by clicking on “…”

Enter a SQL Server / MySQL connection string to be used during publishing

If you enter connection strings here, they will be saved to the publish settings file this dialog generates.

Specify the URL for the publishing server connection

This is the HTTPS endpoint your development computer will talk to. For the majority of cases, you can leave this unchanged. However, in cases where your computer name does not match its public DNS name (common in many virtual dedicated computers), you should enter the public DNS name or IP here.

6. PowerShell Setup Automation Scripts

Note: Requires PowerShell 2 installed

Web Deploy 2.0 also comes with a set of PowerShell scripts which automate setup-related tasks. Web Deploy 2.0 comes with the following scripts in the \scripts folder of the installation directory:

- Create delegation rules

- Set up a site for Web Deploy publishing

- Create a MySQL database

- Create a SQL Server database

You can read more about the scripts here.


Lastly, a big thank you to all our users for your feedback and for using your product. We hope you find this refresh useful. If you need help, check out our forum or drop us a line at wdtrel@microsoft.com with your thoughts!

Author: "panic_at_the_disco"
Comments Send by mail Print  Save  Delicious 
Date: Monday, 07 Feb 2011 19:35

Yishai Galatzer wrote an informative blog post about what to do if you see errors in the Publish Compatibility feature of WebMatrix. May be relevant to you if you use Web Deploy protocol to publish from WebMatrix: http://blogs.iis.net/yigalatz/archive/2011/02/04/compatibility-checking-in-webmatrix-when-the-checker-reports-failures.aspx

Author: "panic_at_the_disco"
Comments Send by mail Print  Save  Delicious 
Date: Thursday, 03 Feb 2011 05:28

Web Deploy 2.0 has been out for a few weeks now. If you don’t have it, I encourage you to go get it now. I’ve been meaning to do a blog post on what’s new … so here it is:


1) Continuous publishing. If you use WebMatrix, you are already using this feature. Web Deploy 2.0 has the ability to create a store of web app-specific settings in the IIS web server’s configuration directory. These settings can be used when a web app is synced to a destination.

Let’s take a concrete example: suppose you have installed DotNetNuke from the Web Application Gallery in WebMatrix. Application Gallery packages are just Web Deploy packages with manifest.xml and parameters.xml files. During the initial install, WebMatrix uses Web Deploy 2.0’s continuous publishing feature to store the application’s original manifest and parameters (highlighted below) along with user-supplied values for parameters for each computer the application is published to. In the screen below, the application has been installed or ‘published’ to localhost, so you see a folder for that computer.

The net effect is that not only can the application be published to another computer once it has been installed on your computer, it can also be downloaded from a remote computer. Hence the ability to ‘continuously’ publish an app again and again without losing any of its parameters or manifest entries.

Of course, the store is programmatically accessible via public APIs. I am planning on showing some sample code for it in a couple of weeks – if you’re really interested in it, drop me a line at baslam at microsoft dot com, and I might share it sooner. The store is currently enabled only on IIS Express.


2) Side-by-side setup. It is now possible to have different versions of Web Deploy live side-by-side. Web Deploy 2.0 is backwards-compatible with Web Deploy 1.1 at an API level. We hope this lets our customers try out new versions of Web Deploy without breaking existing systems.


3) Ability to sync a GAC assembly to destination without having it installed on the source.

One common customer request has been to be able to install a GAC assembly on the destination without having it installed on the source. This is typically required in build machines, where you don’t want to add extra DLLs to the GAC. Web Deploy 2.0 has a new provider which uses the same APIs as gacutil.exe to install signed assemblies into the GAC:

msdeploy.exe -verb:sync -source:gacInstall="c:\mybuild\myassembly.dll" -dest:auto,computername=”remotecomputer”,username=foouser,password=somepassword, authType=basic –allowUntrusted

This will install myassembly.dll into the remotecomputer’s GAC.

3) Improved database providers

Web Deploy1.1 already contained the ability to sync SQL databases using the dbFullSql provider, and MySQL databases. We have now added the ability to sync Sqlite databases as well via the dbSqlite provider. You do need Sqlite installed in the same path as msdeploy.exe:

msdeploy.exe -verb:dump -source:dbSqlite="Data Source=filename;Version=3;Password=password;"

dbFullSql also supports syncing SQL Compact databases to SQL Compact and to SQL Server.


Questions? Comments? Feel free to drop me a line at baslam at microsoft dot com

Author: "panic_at_the_disco"
Comments Send by mail Print  Save  Delicious 
Date: Tuesday, 11 Jan 2011 19:35

One of our Web Deploy testers was running into a bizarre issue: even though she had set up delegation rules current (and debugged them using failed request tracing logs), she was still seeing an error like this when publishing a site from Microsoft WebMatrix using Web Deploy:

4:23:33 PM: Updating createApp (mysite.webstack01.cytanium.com/rb19).
4:23:34 PM: Updating setAcl (mysite.webstack01.cytanium.com/rb19/web.config).
4:23:38 PM: Updating createApp (mysite.webstack01.cytanium.com/rb19).
4:23:38 PM: Updating setAcl (mysite.webstack01.cytanium.com/rb19/web.config).
4:23:44 PM: Make sure you have appropriate permissions on the server to publish IIS settings. Alternatively, exclude settings that require administrative permission on the server.
4:23:44 PM: Unable to publish. Make sure you have appropriate permissions on the server to publish IIS settings. Alternatively, exclude settings that require administrative permission on the server.
4:23:44 PM: Error detail:
4:23:44 PM: (11/19/2010 4:23:44 PM) An error occurred when the request was processed on the remote computer.
4:23:44 PM:    at Microsoft.Web.Deployment.StatusThreadHandler.CheckForException()
4:23:44 PM:    at Microsoft.Web.Deployment.AgentClientProvider.RemoteDestSync(DeploymentObject sourceObject, DeploymentSyncContext syncContext)
4:23:44 PM:    at Microsoft.Web.Deployment.DeploymentObject.SyncToInternal(DeploymentObject destObject, DeploymentSyncOptions syncOptions, PayloadTable payloadTable, ContentRootTable contentRootTable)
4:23:44 PM:    at Microsoft.Web.Deployment.DeploymentObject.SyncTo(DeploymentProviderOptions providerOptions, DeploymentBaseOptions baseOptions, DeploymentSyncOptions syncOptions)
4:23:44 PM:    at Microsoft.Web.Deployment.DeploymentObject.SyncTo(String provider, String path, DeploymentBaseOptions baseOptions, DeploymentSyncOptions syncOptions)
4:23:44 PM:    at Microsoft.Web.Deployment.DeploymentObject.SyncTo(DeploymentWellKnownProvider provider, String path, DeploymentBaseOptions baseOptions, DeploymentSyncOptions syncOptions)
4:23:44 PM:    at Microsoft.WebMatrix.Deployment.MsDeployWorker.Execute(Boolean pullback)
4:23:44 PM: The server experienced an issue processing the request. Contact the server administrator for more information. http://go.microsoft.com/fwlink/?LinkId=178035

It turns out that this can happen rarely if there is write contention on applicationHost.config (as can happen in shared hosting environments). The suggested steps in the error aren’t actually helpful. The solution? Just try again!

Still stuck? Please visit the forum, we'll be happy to help!

Author: "panic_at_the_disco"
Comments Send by mail Print  Save  Delicious 
Date: Thursday, 11 Nov 2010 16:20

The Web Deploy team is excited to announce a new Beta of Web Deploy v2.

Download the English x86 and x64 installers (more languages are coming in the final release)

Got feedback?

We would love to hear from you. E-mail us: wdeploy at microsoft dot com with your thoughts.

Summary of changes:

- Lots of bug fixes: We spent a ton of time taking care of quirks and bugs. This release is more stable and complete than v1.1.

- Integration with developer tools: In this release, we focused on making Web Deploy work better with new developer tools like IIS Express and WebMatrix. Many of the cool new deployment features in WebMatrix (such as Download Published Site) are actually powered by Web Deploy v2. Also, Web Deploy now maintains a programmatically-accessible application definition store in IIS Express, which caches manifest.xml, parameters.xml and last values provided for parameters.xml. This allows an application to be published to another server even after it has been installed on your computer.

- Side-by-side setup: Web Deploy can now exist side-by-side with older versions. If you install v2, you will notice that it lives in a different folder. You can try out new features without having to uninstall older versions. v2 is also backwards compatible at the API level.

- New and updated providers:

- (new) sqlite: supports transferring SQLite databases

- (updated) dbFullSql: now supports transferring SQL Server Compact databases

- (updated) gacAssembly: now supports syncing an assembly from source to destination even if it’s not installed in the GAC of the source machine

Author: "panic_at_the_disco"
Comments Send by mail Print  Save  Delicious 
Date: Tuesday, 09 Nov 2010 21:25

NOTE: This is posted in the Web Deploy blog because this new feature in WebMatrix Beta 3 makes great use of new features in Web Deploy v2.


The new Beta 3 release of WebMatrix includes an exciting new feature: Download Published Site. This feature allows you to download files and databases from your live, previously-published site to your computer so that you can, for example, make and test edits on an up-to-date version before publishing them up to the live site.

To use this feature, you simply need to publish a site once to a web hosting provider using the Web Deploy protocol. Then, click “Download Published Site…” on the Publish ribbon dropdown menu.

Detailed Steps

1. Install an application or make your own from a template

Site from Gallery walkthrough: http://learn.iis.net/page.aspx/878/create-a-website-from-a-gallery-application/

FAQs for specific applications: http://learn.iis.net/page.aspx/873/installing-publishing-apps-with-webmatrix/

2. Choose a hosting provider and get an account

We recommend the hosting providers noted on this site (http://www.asp.net/webmatrix/hosts) because they have installed and configured Web Deploy. You may not be able to use Web Deploy publishing with a hosting provider that is not featured here. You can also get to this page of recommended hosting providers at any time by choosing “Find Web Hosting…” from the Publish ribbon dropdown menu.


3. Publish your site using the Web Deploy protocol

This page has instructions for doing this: http://learn.iis.net/page.aspx/871/publish-your-website/

(note that some of the feature names/placements have changes slightly since this was published, such as “Configure…” now being called “Settings…”).

4. Download your previously-published site

Start by choosing the Download Published Site… option from the Publish drop down


Next you’ll see the preview dialog which will show any files that are different between your local site and the remote site. Note that the database is checked for download by default – you must uncheck it if you don’t want to overwrite your local database. You can choose to exclude downloading specific files (or all files) by un-checking them. Click Continue when you’re ready to start the download.


The notification bar will start with “Download: Starting…” then will scroll through download actions as they occur and switch to “Download: Complete” when the download is finished. You can click on the link in the notification bar or click the “Run” button to browse your now-up-to-date site.



Workaround for Common Issues:

1. Proxy settings error

Download Published Site Failed Bad gateway: Check proxy settings

The remote server returned an error: (502) Bad Gateway.

Workaround: Same as when publishing. Copied from here (http://blogs.iis.net/bilalaslam/archive/2010/07/29/webmatrix-publishing-common-errors-and-workarounds.aspx) for quick reference: “Error: Bad gateway: check proxy settings

Solution: This one is literally what it says – check proxy settings because Web Deploy traffic is being blocked. Try installing your corporation’s required firewall client, and disabling all settings in Internet Explorer > Tools > Options > Connections > LAN settings.”

2. Download fails with a SQL Server administrator error

Details looks like this:

9:14:15 AM: Download Published Site Failed
9:14:15 AM: Download Published Site Failed Download Published Site Failed
9:14:15 AM: Error Detail:
9:14:15 AM: Logged-in user must have SQL Server administrator privileges to download SQL databases
9:14:15 AM: at Microsoft.WebMatrix.Deployment.MsDeployWorker.Execute(Boolean pullback)

Issue: Due to the way database scripting options are applied during a download, it is required that the application either uses database administrator (sysadmin) credentials in the connection string already or that your logged-in user has SQL database administrator (sysadmin login) permission.

Workaround: Give your logged-in user account sysadmin permissions to the SQL database by adding a login for them. There are directions here for adding a login using SQL Server Management Studio (available from WebPI if not already installed): http://msdn.microsoft.com/en-us/library/aa337562.aspx. Make sure when you add the login that you go to the Server Roles page and check the “sysadmin” box.


3. My site isn’t working after download

Issue: All applications are different, and there’s a chance the one you’re using requires a manual edit somewhere to make the application work again.

Workaround: There may be more information on your application on its FAQ page if it requires a specific action from you: http://learn.iis.net/page.aspx/873/installing-publishing-apps-with-webmatrix/

4. My problems don’t look anything like these or the workarounds aren’t working!

Workaround: Please let us know you are having trouble by posting here: http://forums.iis.net/1166.aspx or logging issues here: https://connect.microsoft.com/site1112/Feedback! Posting to the forum with details of the problem is a good way to get help from the feature team or other users, and your feedback helps us make decisions on how to improve WebMatrix.

Author: "panic_at_the_disco"
Comments Send by mail Print  Save  Delicious 
Date: Monday, 04 Oct 2010 22:30

A couple of customers have asked me how to skip setting an ACL in a VS 2010 deployment package. There are project-level properties for everything we do in VS to publish or create a deployment package. To disable setting ACLs, you can do either of these:

1) Edit the .csproj file and set  <IncludeSetAclProviderOnDestination>False</IncludeSetAclProviderOnDestination>

2) msbuild.exe myproject.csproj /p:IncludeSetAclProviderOnDestination=False

NOTE: This is a cross-post from bilalaslam.com. Interested in learning more about Web Deploy? Follow us on Twitter @wdeploy. Need help? Contact bilal dot aslam at microsoft dot com

Author: "panic_at_the_disco"
Comments Send by mail Print  Save  Delicious 
Date: Thursday, 30 Sep 2010 18:51

NOTE: This is a cross-post from bilalaslam.com. Interested in learning more about Web Deploy? Follow us on Twitter @wdeploy

I had a customer contact me with an issue: FTP Authorization Rules for a site were being deleted after sync.

He has two IIS 7 servers (call them source-server and destination-server), and there’s an FTP website called “MyFtpSite” on both servers. Destination-server has some extra settings for MyFtpSite, specifically FTP Authorization Rules, which are not present on source-server. The customer ran this command on source-server:

msdeploy.exe -verb:sync -source:webServer -dest:auto,computername=destination-server -skip:website="MyFtpSite"

msdeploy.exe command line provides nice syntatic sugar, –skip:website=<websiteName> for skipping a whole website. Once this command ran, he noticed that MyFtpSite’s content was untouched but its FTP Authorization Rules were deleted. What was going on?


Under the covers, –skip:website=<yourWebsite> is the same as doing –skip:objectName=<yourWebsite>. This will skip all objects named yourWebsite. However, I looked at destination-server’s applicationHost.config, and voila, FTP Authorization Rules were being declared in a <location> tag. It turns out there’s a bug in Web Deploy v1.1. where the –skip:website syntactic sugar does not skip <location> tags and, as a result, it’s an object the source does not see, so it’s deleted:

<location path="MyFtpSite"> <system.ftpServer> <security> <authorization> <add accessType="Allow" users="*" permissions="Read, Write" /> </authorization> </security> </system.ftpServer> </location>

What’s the workaround? You have to have a separate skip for the <location> tag:


msdeploy.exe -verb:sycn -source:webServer -dest:auto,computername=destination-server -skip:website="MyFtpSite" -skip:xPath="//section[@name='system.ftpServer/security/authorization']"

Note: I should really make this skip a little tighter, because it will skip syncing system.ftpServer/security/authorization sections for ANY website. But you get the idea … Smile

Author: "panic_at_the_disco"
Comments Send by mail Print  Save  Delicious 
Date: Tuesday, 28 Sep 2010 04:18

Note: this is a cross-post from bilalaslam.com

Chances are if you are deploying an application using Web Deploy, you are using the setAcl provider. What is setAcl? It’s a provider that lets you set permissions on file system objects. Typically, this involves setting permissions on a sub-folder of your application, such as App_Data.

I recently had a customer contact me and I had to explain this particular behavior for setAcl. Let’s say you run this command:


msdeploy.exe -verb:sync -source:setacl -dest:setacl="Default Web Site",setacluser=ApplicationPoolIdentity,setaclaccess=Read

This command will give the ApplicationPoolIdentity Read access to the App_Data folder. Before it does that, however, it will clear existing permissions on the folder for the identity. This makes sense, since setAcl has to set the correct permissions and the only way to do that is to clear existing permissions for the identity. For example, if the ApplicationPoolIdentity had Read,Execute permissions before, now it will just have Read permissions.

Author: "panic_at_the_disco"
Comments Send by mail Print  Save  Delicious 
Date: Friday, 24 Sep 2010 18:45

Note: this is a cross-post from bilalaslam.com

I recently had a shared hosting provider customer contact me about a problem with non-administrators deploying using Web Deploy. The specific issue he was running into was that the deployment would work if the user deployed to a sub-application (e.g. mywebsite/myapp) but not if he deployed to the root of the site (e.g. mywebsite). I want to walk through how to debug issues with Web Deploy delegation rules.

First things first – let’s take some steps to make debugging easier. Read here about how to enable Web Management Service (wmsvc) tracing – you can read about IIS tracing in general here. Don’t forget to restart wmsvc once you enable tracing! This will start recording all sorts of useful information every time a request comes to wmsvc.

Once the customer did that, I looked at his tracing logs files. I generally search for the names of common Web Deploy providers, such as createApp, setAcl and recycleApp, that require non-standard permissions. Sure enough, I found the culprit:


<EventData> <Data Name="ContextId">{00000000-0000-0000-517F-0080020000F6}</Data> <Data Name="Uri">/msdeploy.axd</Data> <Data Name="eventData">Tracing deployment agent exception. Request ID &apos;&apos;. Request Timestamp: &apos;09/23/2010 18:47:04&apos;. Error Details: System.UnauthorizedAccessException: Attempted to perform an unauthorized operation. at System.Security.AccessControl.Win32.SetSecurityInfo(ResourceType type, String name, SafeHandle handle, SecurityInfos securityInformation, SecurityIdentifier owner, SecurityIdentifier group, GenericAcl sacl, GenericAcl dacl) at System.Security.AccessControl.NativeObjectSecurity.Persist(String name, SafeHandle handle, AccessControlSections includeSections, Object exceptionContext) at System.Security.AccessControl.NativeObjectSecurity.Persist(String name, AccessControlSections includeSections, Object exceptionContext) at Microsoft.Web.Deployment.FileSystemSecurityEx.Persist(String path) at Microsoft.Web.Deployment.SetAclProvider.Add(DeploymentObject source, Boolean whatIf) at Microsoft.Web.Deployment.DeploymentObject.Update(DeploymentObject source, DeploymentSyncContext syncContext) at Microsoft.Web.Deployment.DeploymentSyncContext.HandleUpdate(DeploymentObject destObject, DeploymentObject sourceObject) at Microsoft.Web.Deployment.DeploymentSyncContext.SyncChildrenOrder(DeploymentObject dest, DeploymentObject source) at Microsoft.Web.Deployment.DeploymentSyncContext.ProcessSync(DeploymentObject destinationObject, DeploymentObject sourceObject) at Microsoft.Web.Deployment.DeploymentObject.SyncToInternal(DeploymentObject destObject, DeploymentSyncOptions syncOptions, PayloadTable payloadTable, ContentRootTable contentRootTable) at Microsoft.Web.Deployment.DeploymentAgent.HandleSync(DeploymentAgentWorkerRequest workerRequest)</Data> </EventData>

Notice that one of the lines mentions the SetAclProvider. This told me that Web Deploy was failing to set file system permissions. I then asked him for the output of icacls.exe on the folder where the website’s files are stored. I saw something like this:

C:\Users\Administrator>icacls C:\hostingspaces\foobar\foobar.com\wwwroot
C:\hostingspaces\foobar\foobar.com\wwwroot NT AUTHORITY\SYSTEM:(OI)(CI) 
Successfully processed 1 files; Failed processing 0 files

From this, I can tell that the customer hasn’t given the local user account (someuser) Full Control over the wwwroot directory. SetAcl is failing because Modify permissions are not enough to change the permissions on a directory, they’re just enough to set permissions on child objects (such as sub-folders and files underneath the directory). Giving this user Full Control fixed the problem!

I hope this blog post helps you debug Web Deploy delegated deployments. If you have any questions, feel free to reach out to me at: baslam at microsoft dot com. Follow us on Twitter: @wdeploy

Author: "panic_at_the_disco"
Comments Send by mail Print  Save  Delicious 
Date: Wednesday, 22 Sep 2010 22:25

Note: this is a cross-post from bilalaslam.com

Because Web Deploy is a client-server product, unless it is set up correctly, chances are you will hit a wall pretty quickly at the point where a connection is made. In this blog post, I will show you common solutions for common errors.

Read on for general tips and recipes for fixing common connectivity errors.

General Tips

  • Web Deploy sometimes returns different information in errors messages if you provide administrator credentials vs. non-administrator credentials. If you hit an error, try to run the command as administrator.
  • Web Deploy sometimes returns different information if source and destination machine are the same vs. destination machine is remote. If you hit an error, try to run it on the remote machine.
  • Run the command with –verbose and –debug switches. These will make Web Deploy spit out more information which can be useful in debugging.

Error: 503 Server Unavailable

Error Trace:

msdeploy.exe -verb:dump -source:apphostconfig,computerName=demo-host

Error: Object of type 'appHostConfig' and path '' cannot be created.
Error: Remote agent (URL http://demo-host/MSDEPLOYAGENTSERVICE) could not be contacted.  Make sure the remote agent service is installed and started on the target computer.
Error: An unsupported response was received. The response header 'MSDeploy.Response' was '' but 'v1' was expected.
Error: The remote server returned an error: (503) Server Unavailable.
Error count: 1.

Why it happens:

  • Incorrect destination name or host unreachable.
  • Remote Agent Service not installed on destination.

How to fix it:

  • Make sure you can ping the remote computer.
  • Run this command on the destination in an elevated command prompt: “net start msdepsvc”. This will start the Remote Agent Service on the destination, which allows administrator deployments.

Error: Default credentials cannot be supplied for the basic authentication scheme

Error Trace:

msdeploy.exe -verb:dump -source:apphostconfig,wmsvc=demo-host
Error: Object of type 'appHostConfig' and path '' cannot be created.
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.

Why it happens:

  • You are telling Web Deploy to connect to the Web Management Service on the destination. By default, Web Deploy will connect using HTTP Basic Authentication.
  • When using HTTP Basic Authentication, specific credentials must be supplied, which is not true in the command shown above.

How to fix it:

Change the command to:

msdeploy.exe -verb:dump -source:apphostconfig,wmsvc=demo-host,authType:basic,username=someuser,password=somepassword

Error: The remote certificate is invalid according to the validation procedure.

Error Trace:

msdeploy.exe -verb:dump -source:apphostconfig,wmsvc=demo-host,authType=basic,username=someuser,password=somepassword
Error: Object of type 'appHostConfig' and path '' cannot be created.
Error: Could not complete the request to remote agent URL '
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.

Why it happens:

  • You are connecting to the destination using the Web Management Service (wmsvc), which creates an HTTPS connection.
  • The certificate on the destination is invalid, so you see this error.

How to fix it:

  • Install a valid wmsvc certificate on the destination
  • OR add the –allowUntrusted flag on the command

msdeploy.exe -verb:dump -source:apphostconfig,wmsvc=demo-host,authType=basic,username=someuser,password=somepassword –allowUntrusted

Author: "panic_at_the_disco"
Comments Send by mail Print  Save  Delicious 
Date: Wednesday, 22 Sep 2010 17:59

NOTE: This is a cross-post from bilalaslam.com

Sometimes, as part of a deployment, you want to stop, start or recycle the remote application pool. For example, some lightweight database engines hold the database in memory, so if you publish a new database, changes won’t show until you recycle the app pool. Another reason to recycle the application pool is if your application has flaky memory management, and you want to start from a clean slate.

Web Deploy has a provider, recycleApp, which allows you to perform certain operations on application pools. This provider only works on IIS7 and higher. Read on to find out more.

recycleApp provider as administrator:

First, let’s see how we can recycle a remote application pool:

msdeploy.exe -verb:sync -source:recycleApp -dest:recycleApp="Default Web Site",recycleMode="RecycleAppPool",computerName=remote-computer

Let’s break this down:

  • -verb: sync. A sync verb is a little odd since you are really trying to do an operation on a remote object, but not so odd if you remember that Web Deploy has a source-to-destination sync model.
  • -source:recycleApp. We want to use the recycleApp provider.
  • -dest:recycleApp=”Default Web Site”. We are telling Web Deploy to recycle the application pool for the Default Web Site.
  • recycleMode=”StopAppPool”. Pretty self-explanatory, we’re telling the recycleApp provider to stop the app pool.
  • computerName=remote-computer. You may trip up here. We are telling Web Deploy to connect to the Remote Agent Service on the remote computer. If that service isn’t started, you’ll see an error like this:

Error: Remote agent (URL http://remote-computer/MSDEPLOYAGENTSERVICE) could not be contacted.  Make sure the remote agent service is installed and started on the target computer.
Error: An unsupported response was received. The response header 'MSDeploy.Response' was '' but 'v1' was expected.
Error: The remote server returned an error: (503) Server Unavailable.
Error count: 1.

To fix this, make sure Web Deploy (with all of its optional components, including the Remote Agent Service) is installed on the remote computer. Also, on the computer, run “net start msdepvc” from an elevated command prompt.

recycleApp provider as non-administrator:

Some of you may want non-administrators to be able to run the recycleApp provider. For example, shared hosting providers like to do this because recycling application pools makes some applications behave better after deployment. We will enable users to do this by created a delegation rule for the recycleApp provider.

First, read up on how to set up delegation rules in general. Kristina’s Blog has a good post on this. However, she doesn’t cover recycleApp.

Add a new delegation rule like this:


Notice that you have to set the Run As identity to a specific user, namely an administrator. This is a limitation of IIS, that only administrators can recycle application pools. One thing to be careful about: if you allow multiple sites or applications to share an application pool, do NOT set up this rule. If you do, while recycling their own application pools, users will be able to disrupt other people’s sites. You should only set up this rule if you have a one-application-per pool model.

To test this rule, run this command from the source computer:

msdeploy.exe -verb:sync -source:recycleApp -dest:recycleApp="Default Web Site",wmsvc=remote-computer,userName=IISManagerUserName,Password=IISManagerUserPassword,recycleMode="RecyleAppPool" –allowUntrusted

Notice that in this command, we are telling Web Deploy to connect using the Web Management Service (wmsvc), which is required for delegated deployments. Also, unless you have a valid certificate on the remote machine, you should use the –allowUntrusted flag which bypasses certificate errors.

Author: "panic_at_the_disco"
Comments Send by mail Print  Save  Delicious 
Date: Friday, 17 Sep 2010 16:40

NOTE: This is a cross-post from bilalaslam.com 

When should you use Replace Rules vs. Parameters with Web Deploy? Read on, brave reader!

Web Deploy supports several ways to transform objects during deployment. Why would you want to do this? Because, as I have noted in earlier blog posts, connection strings and even site bindings differ from environment to environment.

The first way is to parameterize. I have covered parameterization in a previous blog post, but I’ll give a quick recap here. A parameter defines a part of an object that should be changed every time the deployment happens. For example, you may want to build a deployment package and parameterize a database connection string. The person who does the deployment is responsible for providing a value for this parameter each time the deployment happens. Here’s how you declare the parameter:

msdeploy.exe -verb:sync -source:apphostconfig -dest:package=c:\temp\package.zip -declareParam:name ="Handler Mappings Access Type",scope="apphostconfig",match="//handlers[@accessType]",kind="ProviderPath"

If you look at the ZIP of the package, it now contains a file called parameters.xml with the following contents:

<parameters> <parameter name="Handler Mappings Feature Permissions"> <parameterEntry kind="DeploymentObjectAttribute" scope="appHostConfig" match="//handlers/@accessPolicy" /> </parameter> </parameters>

When installing the package, you can specify a value for the parameter like this:

msdeploy.exe -verb:sync -source:package=c:\temp\package.zip -dest:auto -setParam:name="Handler Map pings Feature Permissions",value="Read,Script"

The second way is to use a replace rule. A replace rule literally replaces an object or a piece of an object at the time of deployment. You should use replace rules when you know the new value. This blog post covers replace rules. Here’s a sample replace rule which changes an attribute in a node in applicationHost.config from “Read” to “Read,Script” (this sets a Handler Mappings feature setting):

msdeploy.exe -verb:sync -source:apphostconfig -dest:package=c:\temp\package.zip -replace:objectName=handlers,scopeAttributeName=accessPolicy,match="Read",replace="Read,Script "
Author: "panic_at_the_disco"
Comments Send by mail Print  Save  Delicious 
Date: Tuesday, 24 Aug 2010 17:53

Note: this is a guest post from Crispin Wright, who works in the media sector in the Netherlands, and has been working with Microsoft technologies since 1990. Interested in sharing your own Web Deploy story? E-mail me: baslam at microsoft.com

clip_image009I was recently asked to develop installers for some of our web applications, so they could be installed in a production environment.

I needed to give our engineers a “package” that could be run on a fresh install of Windows Server 2008 R2, and would deploy the entire solution.

I want to write about how the technologies I used to achieve this, focusing on Web Deploy, and how I arrived at an end to end solution, with help from MSBuild, Powershell, and some simple command scripts.

So let’s dive in….

Our Deployment World

Everyone’s architecture is different, but here’s ours – so you can see what we’re working with:


MSBuild & CI

Our first task is to build our Web Deploy packages as part of our nightly CI build. Vishal Joshi has written a great article about this here.

Here’s the part of our MSBuild project that publishes our site:

The approach we’re taking here is to compile the web application project and then publish it to a physical filepath.


It’s good to remember that when you can specify a configuration for compilation, you can have your specific Web.config that provides the correct parameters for that configuration.

We’re using CruiseControl.NET to deploy to a test server to verify our builds, here’s a snippet from our ccnet.config:


I’ll talk more about the Web Deploy syntax later, but the deployment above will sync only the content in the source path with the content on our destination server using the contentPath provider, no permissions or IIS Setup work is done here, and this is because our site is already up and running, our environment is configured (permissions,web.config e.t.c) and all we’re doing here is syncing our “old” build files with our new ones.

We execute this compilation, and it does several things:

It takes the site that we publish to our C:\build\WebAppServer\client folder, and performs a sync with the site at c:\WAS on

It uses some skip rules to exclude the following files (because they are already configured how we want them):

· All .config files

· All .config.xml files

Once we have verified and signed off the build we can use the /T:Package command with MSBuild to package our build. This gives us the zip file we need to pass to the engineers.


To install our web applications onto a new install of Windows Server 2008 R2, we’re going to need to configure the box and install some prerequisites, including Web Deploy itself. I’m going to demonstrate some of the parts of the Powershell script we use to do this.

Script Parameters

We can pass arguments to our Powershell script to specify the install location when we “dot source” (or execute) our script:


This Powershell code takes our script arguments, and steps through them adding them to a structure we can reference later on – in this case to specify the install location.

$ArgList = @{}

For($i=0; $i -lt $args.count; $i +=2)


      $ArgList[$args[$i]] = $args[$i+1]


Server Roles

The first thing the script does is configure the server, and the Powershell ServerManager cmdlet can configure the server roles and features we need for us:

#Import the server manager module to configure roles and features

Import-Module servermanager


#Configure the server roles

#Install the .NET Framework parts

Add-WindowsFeature Net-Framework -IncludeAllSubFeatureLogPath c:\NetFramework_Add_Role.log

#Install the Application server role

Add-WindowsFeature Application-Server -IncludeAllSubFeature -LogPath c:\AppServer_Add_Role.log

#Install the Web Server role

Add-WindowsFeature Web-Server -IncludeAllSubFeature -LogPath c:\WebServer_Add_Role.log

You can read more about the Server Manager cmdlets here:


The script installs the .NET Framework, Application Server, and Web Server roles for us, and we’ve also included logging information for the engineer using the –LogPath switch.


A key part of deploying the solution is installing prerequisites on the server, these include the .NET Framework 4, and Web Deploy itself. We’re going to use Powershell to start them as external processes, and wait for them to finish using this function:

function StartProcess([string] $command = $(throw "Missing: command parameter"), [string[]] $parameters, [switch] $wait, [switch] $cmd)


    if ($cmd.IsPresent)


        cmd /C $command $parameters




        $process = [Diagnostics.Process]::Start($command, $parameters);

        if ($wait.IsPresent)






So we can install Web Deploy like this:

StartProcess -command:$PATH_WebDeployInstall -wait:$true -parameters:"/q"

Where $PATH_WebDeployInstall contains the full path and filename of our Web Deploy msi file.

The /q parameter is a “quiet” switch which means the installations run silently as background processes with default settings.

NOTE – Web Deploy installed with default settings will NOT include the remote management service if you need to deploy sites remotely to that server – although hedge my bets that there is a switch to pass to the msi which will install in a “Complete” fashion.

Registry Operations

We can also use Powershell registry commands to store the install path of the application so that when we come to “upgrade” our application, we know the physical sync path to pass to Web Deploy.

-path "HKLM:\Software\CompanyName\ApplicationName" -name "InstallLocation" -value $location

So we’ve now configured the server, installed all the prerequisites, and stored our install location.

Clean Install or Upgrade?

We’re at a stage now where we can deploy our web application, we’re going to use two different command scripts to do this.

We first want to decide if we need to install or upgrade our application, so we turn to Powershell again, and ask it to find out if our web application already exists – if it does, then we run the upgrade script, if not, then we run a clean install. This is the Powershell function we use to do it:

#Detect if the Site is already installed - if it is do an upgrade - else brand new install

function Get-IISSiteExists([string]$AppSiteName)


      $root = New-Object System.DirectoryServices.DirectoryEntry("IIS://localhost/W3SVC")


      $site = $null


      $site = $root.get_Children() |Where-Object { $_.ServerComment -eq $AppSiteName }


      if ($site -eq $null)


            return $false




            return $true



There are other functions we use in our Powershell script to do things like event logging, checking if the installer is in the administrators group, and display a gui for application parameter configuration. There is a ton of information out there on Powershell, here are a couple of sites I found useful on my travels:



Over to Web Deploy

Now our server is configured we can install our web application using Web Deploy.

You can use the deploy cmd scripts that the package build generates, and you can pass any number of Web Deploy arguments to those standard scripts. I’ve written a slightly different script here.

This is our script:

"%ProgramFiles%\IIS\Microsoft Web Deploy\msdeploy.exe" -verb:sync -presync:runCommand="md %1 & %SYSTEMROOT%\System32\inetsrv\appcmd add site /name:WebAppServer /bindings:http/*:85: /physicalPath:%1" -source:package=WebAppServer.zip -dest:Auto -setParamFile="was_params.xml" -verbose > webappserversync.log

So broken down – this is what the script does:

The first thing we do prior to running our Web Deploy sync is execute some run commands, these create our site in IIS, it’s physical directory, and it’s bindings:

-presync:runCommand="md %1 & %SYSTEMROOT%\System32\inetsrv\appcmd add site /name:WebAppServer /bindings:http/*:85: /physicalPath:%1"

Next the Web Deploy sync command will run, so without the presync commands it looks like this:

"%ProgramFiles%\IIS\Microsoft Web Deploy\msdeploy.exe" -verb:sync -source:package=WebAppServer.zip -dest:Auto -setParamFile="was_params.xml" -verbose > webappserversync.log

The command will install our web application into the location we specified, installing dependencies, configuring ACLs, certificates, and gladly doing all the heavy lifting for us.

Note that we include logging here again using the verbose switch, this benefits the installation engineers a lot, they check this post install for any problems:

-verbose >webappserversync.log

Upgrade or Downgrade?

Because of the Web Deploy “sync” behaviour, the approach above can be used to roll back a site to a specific version just as easily as installing a new version, and in a live environment, if something goes wrong, it can be extremely useful to have that ability.


There are many ways to skin a cat with Web Deploy. You can use the API with VB.NET or C#, you can use it inside IIS to export or import applications, and you can use it as I’ve done here, in a scripted manner with Powershell and command files.

Hopefully this gives an example of the latter approach, and how you can use Web Deploy in your CI integration and testing, through to delivering maintainable installers for production environments.

I’d like to say a huge thanks to Bilal Aslam, Vishal Joshi and the whole Web Deploy team for all their assistance. I came to Web Deploy knowing nothing about it, and they were extremely helpful – thanks guys.

Author: "panic_at_the_disco"
Comments Send by mail Print  Save  Delicious 
Date: Thursday, 04 Feb 2010 16:46

We happy to announce that we just shipped an update to our RTW 1.0 bits with a set of bug fixes that have been reported on the forums and through our feedback channels.

What's new:

You can get the new bits at our extension page, http://www.iis.net/webdeploymenttool and in the Web Platform Installer.

Happy deployments,
Faith and the rest of the Web Deploy team

Author: "faith_a" Tags: "Deployment, Web Deployment, IIS News Ite..."
Comments Send by mail Print  Save  Delicious 
Next page
» You can also retrieve older items : Read
» © All content and copyrights belong to their respective authors.«
» © FeedShow - Online RSS Feeds Reader