Migrating IIS7 configurations

In the process of setting up my development environment on a new laptop, I was looking for a way to migrate my IIS7 configurations from the old laptop, so I didn’t have to manually configure the many web applications and virtual directories required in my day to day development duties. As there was no obvious ‘Export’ or ‘Import’ options available, I asked my good friend Mr Google, who suggested this article.

The steps outlined seemed pretty straightforward, and just what I was looking for. A few of the commenters remarked that they couldn’t get the process to work, with HTTP 503 errors being reported when attempting to run imported web sites. After the import I had the same problem with my web sites and static content being served, but unlike the commenters, with a little diagnostics and a smattering of common sense, I was able to solve the problem.

The first step was to take a peek in the event viewer to see if that would give any insight into what was going on.

As the above screenshot shows, the IIS worker process was unable to find a DLL with the name compdyn.dll. This DLL is used by the dynamic HTTP compression feature of IIS7, which is not installed by default, and a quick squiz into the C:\Windows\System32\inetsrv directory confirms that the DLL is not present on my system. I fired up Programs and Features so I could install this feature, but after waiting a few minutes I was informed that the installation had failed. This time the event log wasn’t too helpful as to why.

Working on a hunch that this may have been due to the install process failing because of locked files, I rebooted my machine, tried to apply the configuration change again, and this time it succeeded. I then confirmed that the config change had the desired effect, and that compdyn.dll now existed in the C:\Windows\System32\inetsrv directory. This dance was went another round, due to another required dll that was missing, but once all required IIS features had been installed, I was successfully able to run my imported web applications. As it turns out, I suspect a full reboot was probably not necessary, as the files in use were probably being locked by the IIS worker process attempting to service the failed request. So it would probably have been sufficient to either recycle the applicable application pool, or restart the IIS service.

Share This | Email this page to a friend

Posted by David Clegg on April 16th, 2009 under .NET, ASP.NET, IIS |