Microsoft Web Deployment Team Blog : IIS

Web Deployment Tool 1.0 has shipped!

faith_a — Thu, 24 Sep 2009 18:30:00 GMT

After 2 years of development and lots of customer feedback, we are proud to announce that the Web Deployment Tool has shipped the RTW of our version 1.0!

In version 1.0, we have the following components:

Powerful APIs that allow you to deploy, sync and migrate web applications on IIS, and perform granular operations like changing IP bindings, site names and changing file structures on the fly. You can also create a new provider to sync a new type of resource.
Command-line tool (msdeploy.exe) that allows you to perform all the same operations available in the APIs.
User interface built into IIS Manager 7.0 on Vista, Windows 2008 and Windows 7 that allows you to create packages (zip files containing IIS config, content, databases and more) and install them.
Delegation framework and service built into IIS 7.0 that allows you to delegate tasks like installing applications and databases without requiring them to be administrators on the box.
Remote administrative service that works on IIS 6.0 and 7.0 to allow server-level synchronization by administrators.

So, what can you do with these components?

Migrate Web applications from IIS 6.0. Simplify the planning of your IIS 6.0 to IIS 7.0 migrations by determining incompatibilities and previewing the proposed changes before starting the process. Learning about any potential issues in advance gives you the chance to take corrective measures and simplifies migration.
Synchronize your server farm. Synchronize between IIS 6.0 > IIS 6.0 or IIS 7.0, and only sync the differences. The tool simplifies the synchronization process by automatically determining the configuration, content and certificates to be synchronized for a Web site. Optionally, specify additional resources for sync, including databases, COM objects, GAC assemblies and registry settings.
Package, archive and deploy Web applications. Package configuration and content of Web applications, including databases, and then use the packages for storage or redeployment. These packages can be deployed using IIS Manager without requiring administrative privileges. The tool integrates with Visual Studio 2010 to help developers streamline the deployment of Web applications to the Web server. The tool also integrates with the Web Platform Installer to allow you to simply and easily install community web applications.

What are some of the new features in RTW?

Brand new UI to create those server-side delegation rules, instead of directly editing config.
Delete and recycle application support inside IIS Manager, even as a remote non-admin user.
A new temporary agent that doesn't require you to have any services installed on your remote machines, but instead temporarily adds the agent and then removes it after sync.
A rule to avoid overwriting newer files on the destination with a new rule.
A rule to avoid syncing based on time stamp differences and instead perform a checksum comparison.
A new provider (runCommand) allows you to run a batch file, script or exe as part of synchronization. This is convenient if you need to net start a service, for example.
Lots of enhancements to our parameterization, including the ability to validate what the user enters, and provide a parameters.xml file with answers to parameters instead of passing them one at a time in the command-line.

Some of our favorite scenarios include:

Create application packages that contain all of the IIS config, content, databases and more, including parameters so that when the server admin installs the package, they are prompted to fill in parameters like SQL Server connection string.
Insert a few XML files into your existing application zip file (such as DotNetNuke or WordPress) and make your application work seamlessly in control panels or through the Web Platform installer.
Build an automated deployment system using our APIs, cmd-line or the Visual Studio integration, so that you can deploy daily from test to staging to production.
Allow your developers to directly deploy to the staging server without admin intervention, and lock down exactly what they can change (mark a folder as an app but not change the site's binding).
Replace Application Center with a set of scripts or programs that call our APIs or cmd-line to sync multiple servers in a web farm.
Build a roll-back solution by taking a package of your live app, deploying the app_v2 package created in your dev environment, and checking for failures. In case of failures, automatically apply the v1 package or backup that you took.

But there are a lot more tasks and scenarios you can accomplish, we'd love to hear about what you're doing...

Go get our 1.0 release at http://www.iis.net/webdeploymenttool and let us know what you think!

Happy deployments,
Faith Allington and the entire Web Deployment team

UI sample for web farm synchronization

faith_a — Fri, 01 May 2009 21:47:00 GMT

One of our team members has built a pretty cool sample UI that allows syncing of multiple web servers and also using file change notifications to trigger syncs. Take a look at the sample at http://blogs.iis.net/moshaikh/archive/2009/04/26/web-server-change-notification-or-web-server-compare-or-multi-server-sync-in-a-web-farm.aspx

BTW we do plan to add this functionality at some point into the Web Deployment Tool itself but it will likely be after version 1 releases.

New release of MS Deploy RC1

faith_a — Fri, 17 Apr 2009 17:08:00 GMT

We have a new release of the RC1 build to fix a couple issues that people found. We recommend that folks download the new version as it fixes some important issues.

How can I get the new build?

Just go to our download links for x86 and x64.

How does it upgrade if I already have the earlier RC1 build?

If you install the new build, it will automatically uninstall the older build and install the new one.

How does it work if my server is running the old RC1 (437) and my client is running the new RC1 (438)?

You will get an error that there is a version mismatch. The reason for this is that if your builds are out of sync, something might be different in the syncing process and cause an error. So we require the client and server to be running the same build.

What issues were fixed?

Installing an application package in certain time zones would result in an error.
Skip and replace rules didn't work properly.
A couple of other smaller infrastructure changes.

Let us know if you see any issues!

Thanks,

-faith

Beta 2 skip and replace rules

faith_a — Mon, 16 Feb 2009 18:13:00 GMT

We posted about skip and replace rules awhile back, but this is probably one of the more complex areas of MS Deploy. You have to understand our provider structure to figure out what type of object needs to be replaced, what attribute, and then write a RegEx match. There are a lot of parameters you can set to scope the rules, and then the added complexity of regular expressions. So I wanted to post some of my favorite rules (not in priority order ;-)) for the command-line and also show the same rule for the PowerShell cmdlets.

If there are more rules that we should post as examples, please let me know!

1. Replace the home directory of a site or application

msdeploy -verb:sync -source:archiveDir=c:\App1 -dest:appHostconfig=MySite/App1 -replace:objectName=virtualDirectory,scopeAttributeName=physicalPath,match=c:\\inetpub\\wwwroot\\app1,replace=c:\dest\app1

I have an archive with an application that points to c:\inetpub\wwwroot\app1. I already have content in that location so when I sync, I want to create a new destination directory.

2. Replace multiple home directories for a site and child applications that have different paths

msdeploy -verb:sync -source:archiveDir=c:\NewSite1 -dest:appHostconfig=NewSite2 -replace:objectName=virtualDirectory,scopeAttributeName=physicalPath,match=c:\\inetpub\\wwwroot,replace=c:\dest2 -replace:objectName=virtualDirectory,scopeAttributeName=physicalPath,match=c:\\dest,replace=c:\dest3 -replace:objectName=virtualDirectory,scopeAttributeName=physicalPath,match=c:\\images,replace=c:\images2

I have an archive of a web site that contains a lot of directories. Most exist under c:\inetpub\wwwroot, and I likely already have content in this location, so I've decided to create a brand new site (just by specifying a new site name in the destination) and also change all the directories.

I use 3 replace rules for each different physical path I need to replace. My archive has a site with 5 applications, 3 underneath c:\inetpub\wwwroot and 2 under separate directories. In order to figure out all the paths I need to replace, I might know this in advance or I can open archive.xml in Notepad and search for every entry of ".dirPath". This will show me every place that we have a directory path.

3. Change the binding for a web site

msdeploy -verb:sync -source:package=site1.zip -dest:appHostconfig=MySite -replace:objectName=binding,targetAttributeName=bindingInformation,match=:80:,replace=:81:10.0.0.1

$dest = Get-DeploymentObject apphostconfig MySite
$source = Get-DeploymentObject archiveDir c:\FullSite
Update-DeploymentObject $dest $source -replace 'objectName=binding,targetAttributeName=bindingInformation,match=:80:,replace=:81:10.0.0.1'

In this case, I'm syncing from an archive that contains a site called Faith. With this sync, I am syncing it with a new name, MySite, to create a brand new site. I am also changing the port and adding an IP address. Note that it will change every binding that has matches :80: globally.

The MSDeploy SQL Database Provider (dbFullSql)

yaminij — Mon, 10 Nov 2008 20:34:00 GMT

Overview

The MSDeploy SQL Database provider, also called dbFullSql is desgined for first-time installation or deployment of SQL databases to a specified destination database. This blog will serve more as a first step towards using the dbFullSql provider that recently shipped with the Beta 2 version of MSDeploy. The provider can be used in the following ways

1) Syncing a single source database to an empty or nonexistent destination database

2) Syncing a source database to an editable .sql file

3) Sync from a .sql file to an existing destination database.

Implementation

The dbFullSql provider uses SMO internally to generate the source database scripts and apply them to the target database. The following SMO Scripting Options are set to true by default inside the dbFullSql provider

a) ScriptSchema

b) ScriptData

c) DriAll

d) Triggers

e) Indexes

f) NoFileGroup

We support passing all SMO options, that take boolean values, as parameters to the dbFullSql provider. For more examples on how to use the SMO options with the dbFullSql provider, please check the command-line usage below. Since the script is only generated from the database specified as the source, it is not required to specify the SMO option as a parameter on the destination as well.

The dbFullSql provider will also create the target database if it does not exist. If you would like to drop the destination database and create a new one on sync, you can use the dropDestinationDatabase=true parameter on the destination

The dbFullSql provider also has transactional support during the execution of the SQL scripts on the destination database. This means, if there is an error in the middle of the sync, all the changes made to the destination database until then will be rolled back.

Command-line Usage

1) To sync a single source database (eg. SourceDatabase), to an empty or nonexistent destination database, you should run the following command

Syntax:

msdeploy.exe -verb:sync -source:dbFullSql="<source db connection string>" -dest:dbFullSql="<dest db connection string>"

Example:

msdeploy.exe -verb:sync -source:dbFullSql="Data Source=.\SQLEXPRESS;Initial Catalog=SourceDatabase;Integrated Security=true"

-dest:dbFullSql="Data Source=.\SQLEXPRESS;Initial Catalog=DestDatabase;Integrated Security=true"

2) To sync a source database (eg. SourceDatabase), to an editable .sql file

Syntax:

msdeploy.exe -verb:sync -source:dbFullSql="<source db connection string>" -dest:dbFullSql="<absolutePath to a .sql file>"

Example:

msdeploy.exe -verb:sync -source:dbFullSql="Data Source=.;Initial Catalog=SourceDatabase;Integrated Security=true"

-dest:dbFullSql="d:\SourceDb.sql"

3) To sync a .sql file to an existing destination database

Syntax:

msdeploy.exe -verb:sync -source:dbFullSql="<absolutePath to a .sql file>" -dest:dbFullSql="<dest db connection string>"

Example:

msdeploy.exe -verb:sync -source:dbFullSql="d:\SourceDb.sql"

-dest:dbFullSql="Data Source=SqlMachine\SQLEXPRESS;Initial Catalog=DestDatabase;User Id=user1;password=blah"

4) To specify SMO options as parameters to the dbFullSql provider

Syntax:

msdeploy.exe -verb:sync -source:dbFullSql="<absolutePath to a .sql file>",smoOptionName=value -dest:dbFullSql="<dest db connection string>"

Example:

In order to skip scripting data on the source database and to sync only schema, you can run the following command

msdeploy.exe -verb:sync -source:dbFullSql="Data Source=.\SQLEXPRESS;Initial Catalog=SourceDatabase;Integrated Security=true", ScriptData=false

-dest:dbFullSql="Data Source=.\SQLEXPRESS;Initial Catalog=DestDatabase;Integrated Security=true"

Example:

In order to include schema-qualified table references for foreign key constraints into the generated script, you can pass SchemaQualifyForeignKeysReferences=true to the dbFullSql provider

msdeploy.exe -verb:sync -source:dbFullSql="Data Source=.\SQLEXPRESS;Initial Catalog=SourceDatabase;Integrated Security=true", SchemaQualifyForeignKeysReferences=false

-dest:dbFullSql="Data Source=.\SQLEXPRESS;Initial Catalog=DestDatabase;Integrated Security=true"

5) You could also sync a database to a package or an archive

Example:

a) msdeploy.exe -verb:sync -source:dbFullSql="Data Source=.\SQLEXPRESS;Initial Catalog=SourceDatabase;Integrated Security=true"

-dest:archivedir="c:\archive"

b) msdeploy.exe -verb:sync -source:dbFullSql="Data Source=.\SQLEXPRESS;Initial Catalog=SourceDatabase;Integrated Security=true"

-dest:package="c:\package.zip"

6) To sync multiple databases and database scripts to multiple databases, you can use a manifest file with the MSDeploy manifest provider.

Limitations

The dbFullSql provider cannot be used for incremental publishing to a target database. You can incrementally publish to a target database, only if there is no collision between existing objects on the source database and the target database.

The dbFullSql provider operates at the database level only and not at the SQL Server level. Hence any objects at the server level, like logins, on which objects at the database level depend on (like users) will not be scripted.

We currently do not support passing any non-boolean SMO option to the dbFullSql provider.

References

For more information about SMO scripting options, you can refer this link

For information on how to download and install SMO and MSDeploy in general, you can refer the MSDeploy Help File

The Web Deployment Tool Beta 2 is now available!

faith_a — Wed, 29 Oct 2008 21:31:00 GMT

The IIS team is proud to announce the latest release of the Web Deployment Tool Beta 2, which includes significant new features for both IT professionals and developers. In addition to our existing functionality of server synchronization and migration, but we’ve added web application packaging and deployment with integration with IIS Manager and the upcoming Visual Studio 2010!

Because the Beta 2 release has brand-new functionality around application packaging not previously available, this release is not a production-ready or Go Live release. We will be changing and adding more functionality in the next milestone after Beta 2.

Easily deploy, store and redeploy Web applications.
The Web Deployment Tool enables you to package configuration and content of your installed Web applications, including SQL databases, and use the packages for storage or redeployment. These packages, which may include certificates, can be deployed using the IIS Manager interface without requiring administrative privileges. This tool also integrates in Visual Studio 2010, which helps developers streamline the development and deployment of Web applications.

Efficiently synchronize your server farm.
The Web Deployment Tool allows you to efficiently synchronize sites, applications or servers across your IIS 7.0 server farm by transferring only those changes which need synchronization. The tool simplifies the process by automatically determining the configuration, content, databases and certificates to be synchronized for a specific site. In addition to the default behavior, you still have the option to specify additional “providers” for the synchronization to modify COM, GAC and registry settings.

Migrate Web applications between IIS 6.0 and IIS 7.0 with ease.
Simplify the planning of your IIS 6.0 to IIS 7.0 migrations by determining incompatibilities and previewing the proposed changes before starting the process. Learning about any potential issues in advance gives you the chance to take corrective measures considerably improving your chances of having a smooth execution of your migration.

We have some new walkthroughs to help you understand and try out the application deployment process in the IIS Manager. Please try out the tool and give us feedback in the forums. We look forward to hearing about your experiences and what else you’d like to see us add.

Downloads

x86 version: http://go.microsoft.com/fwlink/?LinkId=109365
x64 version: http://go.microsoft.com/fwlink/?LinkId=109366

Learn the Basics (Quick Guides)
1. Web Deployment Tool Overview (overview of the features)
2. Installing the Web Deployment Tool (installation and remote service options)

Learn How to Package and Deploy (Quick Guides)
1. Create a Package (creating a package including content, databases and more)
2. Install a Package (deploying the package to a local or remote machine)
3. Configure the Web Deployment Handler (enable deployment to an IIS 7.0 server)

More quick guides can be found at the Web Deployment Tool main page.

Get Help or Interact with the Community
Web Deployment Tool forum: http://forums.iis.net/1144.aspx
Web Deployment Team blog: http://blogs.iis.net/msdeploy/

Happy deployments!

The Web Deployment Tool is @ PDC!

faith_a — Mon, 27 Oct 2008 20:49:00 GMT

Just wanted to let everyone know that a bunch of us from the IIS and MS Deploy team are here at PDC 2008 in sunny Los Angeles! If you're here for PDC, please stop by the Windows Server 2008 Web Platform booth or check out our great talks on web deployment. We have some great news being announced and we'd love to meet folks that are currently using or interested in using the Web Deployment Tool.

Happy deployments!

Faith Allington, and the entire Web Deployment Tool team

Web Deployment Tool Beta 1 (Go Live) just released

faith_a — Tue, 13 May 2008 21:58:00 GMT

Today the Web Deployment Team released the Beta 1 version of the deployment tool! If you're not familiar with the tool already, it is here to help you keep sites or servers in sync with IIS6 or IIS7, as well as migrate from IIS6 to IIS7. One of the key things we've worked on is the flexibility of the underlying framework, which you can see in the number of rules, the ability to configure dependencies and especially, the different providers that we support.

You can sync or migrate not only the configuration of a web site, but also it's physical content and any SSL certificates. We also allow you to create your own manifest and define an application the way that you choose. Does your application depend on an assembly in the GAC? Or a registry key? These can be added to the manifest.

Okay, enough about the tool, for everyone who has been waiting patiently for this latest release and given us excellent feedback in the forums, THANK YOU! Please give the tool a try and let us know what you think.

Listed below are the links for the download pages for each of the individual installation packages:

32-bit Installation Package:
- Microsoft Web Deployment Tool (x86)
64-bit Installation Package:
- Microsoft Web Deployment Tool (x64)

We've loaded this version with many great new features such as:

PowerShell Support - We have PowerShell cmdlets so that you can integrate MS Deploy commands with PowerShell directly.
Enhanced Dependency Checking - We have IIS7 dependency information listed, plus the ability to see where a dependency is being triggered from. For example, if you have a dependency on Windows Authentication, you can now determine where this is set in the configuration.
Detailed Help File - We have a Help chm file included in the tool so that you can browse through all the functionality and flexibility offered by the tool, instead of looking through online walkthroughs.

And much more. :)

Please don't forget to check out the latest release notes available online at http://www.iis.net/Downloads/files/MSDeploy/beta1/msdeploy_readme.html for important known issues!

Thanks again, and many happy deployments,
-Faith Allington, Program Manager, and the entire Web Deployment team

Microsoft.com uses the Web Deployment Tool

faith_a — Mon, 14 Apr 2008 23:20:00 GMT

The folks at Microsoft.com used the Web Deployment Tool to perform a migration of an IIS 6.0 server to IIS 7.0. They published a whitepaper describing their experiences with Tech Preview 1, available at their new operations site.

http://technet.microsoft.com/en-us/mscomops/cc424869.aspx

BTW, the new operations site also happens to have some interesting articles about other IIS 7.0 functionality, such as how they are using delegated configuration and streamlining their installations. I think we can expect to see more whitepapers in the future.

Enjoy!

Thanks,
-faith

What is the long-term support for the MS Deploy tool?

faith_a — Wed, 27 Feb 2008 04:26:00 GMT

In the past week or so, we've gotten quite a few questions about our long-term support of the tool. Yes, the tool will be fully supported by Microsoft Product Support at RTW (release to web). Currently it is in Tech Preview so the only support comes from the forums, but the team is pretty active on the forums as we're getting questions.

Also, we've gotten some great feedback from folks testing the tool and really appreciate it. Some of the requests have included the ability to ignore files whose only changes are attributes (like write time, etc.). Some of the good bugs found have been with script maps and dependency checks. We're spending a lot of time to improve these areas, this has come directly from customers trying it out.

Keep that feedback coming. This is the best time to request changes and influence our first version. We really want to know if the providers that we have are a good set, that we haven't missed any critical ones and we'd love to get some customers trying it on more complex applications.

Thanks again to everyone who is posting questions and helping us test!

Core components of Microsoft Web Deployment tool

ksingla — Thu, 07 Feb 2008 06:27:00 GMT

There are four concepts that are important for you to understand to be able to effectively use the new Microsoft Web Deployment Tool.

1. Providers

Providers are pieces of code that provide data to the tool for various operations like sync. The tool always starts with one provider, with an optional path for the provider. The provider builds the view of the part of the system it can handle, and uses other providers to represent system parts that they handle. These views are internally represented in xml. For example, if you begin with the dirPath provider, it will build an xml view of the folder (specified by the path), which will include files and subfolders present in it. It will delegate the task of handling files to the filePath provider and handling subdirectories to another dirPath provider object.

Parameters you pass in the –source and –dest switches at the command line specify the providers which builds xml views of source and destination systems. Then, the tool only needs to compare these xml views and call for Add, Update, or Delete operations on the destination to make its xml view same as source. Each provider is responsible for handling each of these operations.

Some examples of providers that are provided out of the box are dirPath, appHostConfig, and metaKey. You can see the full list of supported providers in Microsoft.Web.Deployment.config or by running the tool with no parameters to see the Help output. The tool also supports custom providers, which are built by combining one or more existing providers. Two examples of built-in custom providers are the webServer and webServer60 providers, whose definitions can be found in Microsoft.Web.Deployment.config. You can also create these custom manifests in a separate xml file and then use –source:manifest=<xmlfile> to use it as a source. When doing a sync or migrate, the same provider must be used for the source and destination. So if you are using a manifest as the source of your operation, you must also use the manifest provider as the destination. The only exception is the archiveDir provider, which can be used with other providers.

2. Links

Link extensions (or links) are executed for each entry generated by the providers. Links basically connect otherwise unrelated data based on logic coded in the extensions. An example of a link extension is the ContentExtension, which pulls in content whenever it sees a virtualDirectory configuration element added by appHostConfig provider or sees a path metaProperty. It does this by adding a dirPath entry under the virtual directory configuration, and the dirPath provider then pulls in all the content. Another example is the CertificateExtension, which is responsible for pulling in certificate whenever SSLCertHash is seen in the configuration.

Link extensions are executed for all verbs, so a dump will also cause link extensions pull in additional data. If you want to disable a link extension while executing a command, you can use –disableLink switch provided. For example, –disableLink:ContentExtension will cause content to not be included in a view of virtual directory configuration, which would allow for syncing of two servers without moving any content. Link extensions rely on providers to actually pull in the data and are limited by what providers are supported and can do. Together providers and link extensions provide the view of the system that can be dumped, archived, synced, or migrated.

3. Rules

Rules are small pieces of code that have logic to do something special and are evaluated only when a sync operation is performed (not during a dump). A few examples of things that rules do are normalizing paths using environment variables, skipping UNC paths, skipping configProtectedData configuration, etc. By default, rules only run if they are marked with the isDefault attribute set to true. The -enableRule and -disableRule switches will enable or disable a rule explicitly at the command line. For example, –disableRule:SkipUNC will cause UNC content to be included when doing a sync or migrate, because it is disabling the default rule to skip all UNC content. The list of rules can be seen in Microsoft.Web.Deployment.config.

It is also possible to create custom rules that are variations of existing rules. For example, a rule to skip all content located on drive G: would be of the same type as the SkipUNC rule in the configuration (Microsoft.Web.Deployment.SkipRuleHandler). But the absolutePath attribute would be set to “G:\\.*” instead of “\\\\.*” in the configuration file. –skip and –replace switches provided by msdeploy.exe enables creation of new rules as a command-line parameter at runtime, that are included while doing a sync or migrate operation.

4. Methods and Verbs

Methods and verbs are the operations allowed by the tool, which are called using the –verb switch at the command line. If the verb specified is not dump or sync, it is expected to be a method that is specified in the configuration. Currently, the supported methods are GetSystemInfo and GetDependencies.

Hope this helps.

Kanwal, Nina, Faith

Using MS Deploy to compare two web sites

faith_a — Sat, 02 Feb 2008 18:07:00 GMT

Given that we have a metric ton of options :), I wanted to go through a couple common questions that our product support folks get. This is the first in a series of server administrator tasks I'll cover using MS Deploy. When our support folks learned that the tool will help you compare two web sites, they were thrilled.

We've all seen it happen. Two servers are configured the same way, but suddenly, one of them stops working. The content is same, everything looks right, but one server is exhibiting unusual behavior. You could try to take the config from the working server and overwrite the broken one. But that won't tell you what happened, nor if it might happen again.

There's also the case where you only have one server, which suddenly breaks. Restoring from backup if you have one or manually sifting through config might be your only option. But often the problem isn't easy to spot and backups take time and effort to restore.

Enter MS Deploy. You can compare two live sites, a site with an archive, or compare two archives. In this case, I'll show you comparison of a live web site and an archive. An archive is like a snapshot of a site or server at a given point in time. When you take the archive, you may be doing it for a manual backup, to do an offline sync or to make a copy of a specific version of your app. It's a great way to quickly take a snapshot of your working app (and config) before you make changes.

Anyway, let's take a backup of MyWebSite (creative name, I know :)), using the sync to archive functionality.

msdeploy -verb:sync -source:metakey=lm/w3svc/2 -dest:archivedir=c:\MyWebSiteArchive

This will take all the configuration, content and any certificates, putting them into an archive folder that contains an archive.xml (contains everything except for the content). It will create the folder if it doesn't already exist, and ACL for administrators only. For more info, there's an archive walkthrough available in our documentation.

Now let's say "someone" makes a change. We'll pretend that the poor server admin (that's me) doesn't know. All I know is that Monday morning the server broke. Luckily I took an archive the week before. What's next? Let's do a comparison by performing a sync with the archive as the source and the live site as the destination, using my favorite parameter, the -whatif flag. This tells the framework to show you would happen but not actually do it. Hint: It's really important to use the -whatif or you will overwrite your site from the archive.

msdeploy -verb:sync -source:archivedir=c:\MyWebSiteArchive -dest:lm/w3svc/2 -whatif

On my server, here's the output:

Action: Updating metaProperty (/lm/w3svc/2/root/AuthFlags)
Change count: 1

Now we have narrowed the problem down to AuthFlags. For authentication, it's probably a simple enough matter to check the settings. But let's say it was more complex or you wanted to know the exact change. Now we need to use that very useful flag, verboseLevel. This flag lets you control how much info is shown about an operation.

msdeploy -verb:sync -source:archivedir=c:\MyWebSiteArchive -dest:metakey=lm/w3svc/2 -whatif -verboseLevel:Informational

Here's the output (much longer):

Informational: Dependency Check: 'IisVersion' Level: 'Fatal' Passed: 'True' Fail Operation: 'False'
Informational: Dependency Check: 'Iis5IsolationMode' Level: 'Fatal' Passed: 'True' Fail Operation: 'False'
Informational: Dependency Check: 'ConfigRedirection' Level: 'Fatal' Passed: 'True' Fail Operation: 'False'
Informational: Dependency Check: 'InUseDependency' Level: 'Warning' Passed: 'True' Fail Operation: 'False'
Informational: Dependency Check: 'InstalledComponent' Level: 'Warning' Passed: 'True' Fail Operation: 'False'
Informational: Dependency Check: 'DriveSpace' Level: 'Fatal' Passed: 'True' Fail Operation: 'False'
Informational: Dependency Check: 'IsapiCgiExistence' Level: 'Warning' Passed: 'True' Fail Operation: 'False'
Informational: Dependency Check: 'UsingW3SVCMimemap' Level: 'Warning' Passed: 'True' Fail Operation: 'False'
Informational: Dependency Check: 'AppPoolNotFound' Level: 'Warning' Passed: 'True' Fail Operation: 'False'
Informational: Dependency Check: 'DisabledDependency' Level: 'Fatal' Passed: 'True' Fail Operation: 'False'
Informational: Destination metaProperty (/lm/w3svc/2/root/AuthFlags) does not match source (/lm/w3svc/2/root/AuthFlags) differing in attributes (value['5','3']). Update pending
Informational: Source metaProperty (/lm/w3svc/2/root/AuthFlags) replaced with changed attributes () due to rule EnvironmentVariableNormalize
Action: Updating metaProperty (/lm/w3svc/2/root/AuthFlags)
Change count: 1

We have narrowed down the problem now. But you'll notice a lot of information on dependency checking, this is an automatic process to ensure that your destination has the right components, drive space and even down to the application pool needed by the site. If you want to supress these during operations like a comparison, you can do that using rules.

msdeploy -verb:sync -source:archivedir=c:\MyWebSiteArchive -dest:metakey=lm/w3svc/2 -whatif -verboseLevel:Informational -disableRule:Dependency*

The -disableRule flag allows me to avoid running a rule during an operation. You shouldn't disable the dependency rules unless you're pretty comfortable with the tool and you're using it in a case when you don't need to know if there are dependencies that aren't present on the destination.

After we run without the dependency checking:

Informational: Destination metaProperty (/lm/w3svc/2/root/AuthFlags) does not match source (/lm/w3svc/2/root/AuthFlags) differing in attributes (value['5','3']). Update pending
Informational: Source metaProperty (/lm/w3svc/2/root/AuthFlags) replaced with changed attributes () due to rule EnvironmentVariableNormalize
Action: Updating metaProperty (/lm/w3svc/2/root/AuthFlags)
Change count: 1

This is what we care about: Destination metaProperty (/lm/w3svc/2/root/AuthFlags) does not match source (/lm/w3svc/2/root/AuthFlags) differing in attributes (value['5','3']).

You can see the auth flags changed from 5 on the source, which is the archive of the working site, to 3, which is the live site. If you lookup the auth flags, you'll see 5 is Windows auth and 3 is Basic. In this way you can use the tool to pinpoint any differences between two objects, including sites, directories and other providers that we support. As the support folks pointed out to me, it's a great way to locate any changed configuration between two sites.

Hope this helps!

Thanks,
Faith Allington, Program Manager

Web Deployment walkthroughs are now in RTF format

faith_a — Sat, 26 Jan 2008 17:05:00 GMT

Just a quick note to let everyone know that we updated the walkthroughs slightly based on comments we've gotten, and also turned them into .rtf files. The link to download is http://go.microsoft.com/?linkid=8100895 and they've been updated on the download pages.

Thanks!

Welcome to the Web Deployment Team blog

faith_a — Tue, 22 Jan 2008 19:40:00 GMT

Welcome to the Microsoft Web Deployment Team blog - we hope you will find this a helpful place to get the inside scoop plus plenty of tips and tricks from the team who is building the Web Deployment Tool for IIS.

So what is this new deployment tool? You may have read Scott Guthrie’s post about the future of ASP.NET and IIS. In the post he mentioned the roadmap for a web deployment framework, that’s us. :) In our first version, we’re releasing a command-line tool called msdeploy.exe that provides support for deploying, synchronizing and migrating IIS 6.0 and 7.0.

It supports moving configuration, content, SSL certificates and other types of data associated with a web server. You can choose to sync a single site or the entire web server. Because we know that one tool can never ‘automagically’ guess what your application relies on, we’ve tried to be pretty flexible and powerful – you can customize exactly what you want to sync using a manifest file. You can also skip sites or other objects, or you can perform regular expression replacements during a sync (like changing the home directory on the destination machine).

The goal of the tool is to help you keep servers in sync, to make deployment easier and also to help with migrating to new versions of IIS. You could use a sync on two machines in a web farm, for example. Or maybe you need to move to a new server of the same version, you can use this tool. Of course, we also enable you to do a migration from IIS 6.0 to 7.0.

You can learn more about the tool by reading our walkthroughs. Starting with the Learning Roadmap, you’ll see there is an installation walkthrough and also an introduction to the tool, which goes through operations in detail and shows you not only how the tool works, but why.

We hope you download Technical Preview 1 and provide us with feedback. We’re interested in how well the tool captures your web site/server, if there are any really important data types missing and how we can improve the overall experience.

Learn more about the tool from our walkthroughs.

Download the x86 version or the x64 version of our Technical Preview 1.

Thanks, and happy deployments!
Faith Allington, Program Manager, and the entire Web Deployment team