Microsoft Web Deployment Team Blog

Announcing Web Deploy 3.0 RTW

harshmittal — Thu, 26 Jul 2012 23:58:00 GMT

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

Announcing Web Deploy 3.0 Release Candidate!

harshmittal — Thu, 19 Apr 2012 23:15:00 GMT

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

Synchronize IIS

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

Extend the current xml parameterization beyond attribute value replacements to a more complete xml modification story by allowing addition/deletion/replacement of new elements.

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.

<parameters>

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

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

</parameter>

</parameters>

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" />

</parameter>

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" />

</parameter>

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">

        <system.webServer>

            <security>

                <authentication>

                    <windowsAuthentication />

                </authentication>

            </security>

        </system.webServer>

    </location>

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.

Interesting blog post: Setting up your own WebMatrix server

panic_at_the_disco — Mon, 25 Jul 2011 04:56:00 GMT

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/

Opening an existing live site in WebMatrix

panic_at_the_disco — Wed, 29 Jun 2011 05:24:51 GMT

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.

Announcing Web Deploy 2.0 Refresh!

panic_at_the_disco — Tue, 05 Apr 2011 03:54:21 GMT

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.

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!

Understanding Publish Compatibility Check failures

panic_at_the_disco — Mon, 07 Feb 2011 19:35:35 GMT

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

A run-down of new features in Web Deploy 2.0

panic_at_the_disco — Thu, 03 Feb 2011 05:28:23 GMT

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

What to do if you see a createApp failure

panic_at_the_disco — Tue, 11 Jan 2011 19:35:00 GMT

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!

Introducing a new Beta of Web Deploy v2!

panic_at_the_disco — Thu, 11 Nov 2010 16:20:55 GMT

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

WebMatrix Beta 3: Download Published Site

panic_at_the_disco — Tue, 09 Nov 2010 21:25:24 GMT

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.

Summary

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.

Skipping setting an ACL in a Visual Studio 2010 deployment package

panic_at_the_disco — Mon, 04 Oct 2010 22:30:24 GMT

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

Workaround for FTP Authorization Rules being deleted on sync

panic_at_the_disco — Thu, 30 Sep 2010 18:51:45 GMT

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 …

A note on setAcl provider behavior

panic_at_the_disco — Tue, 28 Sep 2010 04:18:30 GMT

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.

Debugging delegation rules for Web Deploy

panic_at_the_disco — Fri, 24 Sep 2010 18:45:10 GMT

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)
                                            BUILTIN\Administrators:(OI)
                                            machine\someuser:(OI)(CI)(R)
                                            machine\someuser:(OI)(CI)(M)
                                            machine\someuser:(OI)(CI)(RX)
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

Common Web Deploy connection errors (and recipes for fixing them)

panic_at_the_disco — Wed, 22 Sep 2010 22:25:00 GMT

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 'https://demo-host:8172/msdeploy.axd?Site='.
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