MSDeploy vs. xcopy network bandwidth throughput

MSDeploy (aka Microsoft Web Deploy) is great for syncing up all kinds of things between two machines. One issue I've noticed recently is, for whatever reason, it doesn't always do well at maxing out your network bandwidth.

We were recently syncing up large SQL Server backups between two boxes connected through a gigabit ethernet switch. I initially decided to use msdeploy.exe, because I wanted it to not only bring over the latest files, but delete the ones on the destination server that no longer exist on the source server. Using -verb=sync and an xml -source:manifest and -dest:manifest file, I ran the test sync from the destination server, and watched the network usage with task manager.

The average throughput was in the 5-15% range on our gigabit connection.

As a test, I ran xcopy /S /D for the same directory tree, and was getting over 90% throughput most of the time, often at 99% throughput!

Unfortunately, xcopy will not truly sync, it's only copying the files over. So now what we do in our .bat file is run the xcopy command first to copy over all the newest data at a high rate of speed, and then we call the same msdeploy command as before, and it deletes any files on destination not found on source. Since all the copying of new data has been done by xcopy, it finishes very quickly and now we're synced up.

I am aware of robocopy's ability to do a lot of this stuff, but it's clear that msdeploy is where Microsoft is putting it's eggs for a lot of the newer syncing technology, so we default to using that first, and now just augment with xcopy when pure throughput is needed.

If anyone knows why msdeploy is so much slower, please comment and I will update this article with any tips to gain performance. My guess is it's due to using the HTTP agent? It just seems weird, because I'm talking about copying of really huge files, so the slowdown is not with hash checking.

MSDeploy Bug: Archives Directories Referenced in HTTP Redirect Virtual Directories

Alternate title: MSDeploy Recursively Copying Data Files During Sync (Infinite Loop)

We were testing msdeploy recently to migrate an IIS 6 web server to IIS 7, and discovered something that took a while to track down.

When you run the -verb:sync option (aka -verb:migrate), and you are trying to archive one or more of your IIS 6 websites to an archive directory, you may discover that msdeploy goes into an infinite loop recursively copying directories into each other. In our case, it eventually bombed, but only after creating a directory structure so deep that Windows itself could not delete it.

(Sidebar: to fix that issue, we had to write a little script that would dig down dozens of directories at a time, then move the remaining directory tree to the root level, then continue digging another dozen directories deep, move the next tree to the root level, and so on until it finished. Then we were able to delete each of these dozen-directory-deep trees from the root level! This idea was adapted from Microsoft's article.)

Anyway, back to the problem at hand...

It turns out, long-forgotten, were virtual directories in IIS that were created for the purpose of creating HTTP Redirects. IIS 6 forces you to first create a virtual directory, give it a real directory that it points to, and only THEN can you change its properties so that it acts like an HTTP Redirect to another resource entirely.

You may not have realized, but IIS 6 is still storing your original directory location in the metainfo for that virtual directory. If you, like someone here (OK, me), just filled in "D:\" or some other root level directory temporarily, then msdeploy will try to archive that directory when it's doing its sync function. YES, I realized long ago that it wasn't wise to use a root level directory, for security reasons alone, but it only takes one of these slipping past you to cause this problem.....

And if you, like us, decided to tell msdeploy to archive to the same drive that you referenced in that virtual directory, you will discover that msdeploy will happily attempt to recursively archive your folder, archive your folder, archive your folder, archive your folder, archive your folder, archive your folder..........

I feel this is a bug in msdeploy. Why does it need to archive these 'old' directory references in virtual directories that are being used as redirects?

The fix is to go back through all of your HTTP Redirect virtual directories, switch the radio button over to the primary directory setting, change the directory to something harmless (e.g. c:\temp\my-special-directory), and then change the setting back to your HTTP Redirect. I actually did this editing the MetaBase.xml file directly, but that's outside the scope of this article!

Good luck and back up your MetaBase and IIS sites before screwing with this...