Using MS Deploy to compare two web sites

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