Urlscan to RequestFiltering migration using MSDeploy

In addition to FastCGI migration provider, MSDeploy 1.0 RTW shipped with a URLScan to request filtering migration provider to ease migration of UrlScan.ini settings to system.webServer/security/requestFiltering section. Even though URLScan 3.1 is supported on Win2K8 and you are not required to move to request filtering module, there are few advantages in using request filtering module. One advantage is that all your configuration can stay together in applicationHost.config and web.config and you are not required to maintain a separate configuration file. Another advantage is that you can take advantages of new configuration system features like distributed configuration, shared configuration, locking, ability to use appcmd, UI, configuration editor etc which cannot be used if you use UrlScan and your configuration is in UrlScan.ini. In Win2K8 R2, you get additional advantages like configuration system auditing. Moreover, request filtering is one of the core IIS modules and will continue to get much attention compared to URLScan. If you are running Win2K8 SP2 or Win2K8 R2 in which request filtering module has all the features available in URLScan 3.1, you should definitely evaluate migrating from URLScan to request filtering. If you decide to migrate, migration is as simple as running a MSDeploy sync command.

URLScan migration is handled by a new provider in msdeploy named UrlScanConfig which accepts “INI” or “APPHOST” as path. When path is “INI”, URLScan configuration from “%windir%\system32\inetsrv\urlscan\urlscan.ini” is read. When path is “APPHOST”, configuration is picked from system.webServer/security/requestFiltering section. This migration provider works similar to FastCGI migration provider. UrlScanConfig migration provider reads UrlScan.ini configuration and produces xml which looks like requestFiltering section configuration. MSDeploy engine then takes care of comparing xml and doing add/update/delete operations on destination to make destination configuration same as source. Because msdeploy sync is a single master sync engine, we take care of not removing configuration from requestFiltering section which doesn’t have a counterpart in UrlScan. For example, hiddenSegments configuration in apphost is not deleted (skipped using urlScanSkipIncompatRuleHandler) and also applyToWebDav properties are not touched. Below are few examples showing the usage of UrlScanConfig migration provider.

Command to dump urlscan.ini settings.
        msdeploy –verb:dump –source:urlScanConfig=ini –xml
        msdeploy –verb:dump –source:UrlScanConfig=apphost -xml

Command to migrate urlscan.ini to requestFiltering section.
        msdeploy –verb:sync –source:urlScanConfig=ini –dest:urlScanConfig=apphost -whatif

UrlScanConfig provider can be used to migrate global urlscan.ini configuration to server level requestFiltering section. Migrating site level UrlScan.ini is not supported. Here is how various URLScan properties map to requestFiltering section.



If set to 1 AllowVerbs section is used. Else DenyVerbs section in urlscan.ini is used


If set to 1 AllowExtensions section is used. Else DenyExtensions section in urlscan.ini is used









MaxAllowedContentLength, MaxUrl and MaxQueryString settings are moved to requestLimits.

AllowVerbs, DenyVerbs

If UseAllowVerbs is 1, verbs@allowUnlisted is set to false and entries are added with enabled=”true”. If UseAllowVerbs is 0, entries has enabled=”false” and verbs@allowUnlisted is set to true.

AllowExtensions, DenyExtensions

When UseAllowExtensions is set 1, extensions are added with enabled=”true” and fileExtensions@allowUnlisted is set to false. When UseAllowExtensions is 0, fileExtensions@allowUnlisted is set to true and entries are added with enabled=”false”.


Moved to requestLimits/headerLimits after removing colon.


alwaysAllowedUrls collection


denyUrlSequences collection


alwaysAllowedQueryStrings collection


denyQueryStringSequences collection


For each rule in RulesList, a filteringRule is created and Rule properties are mapped as following.














All other properties (NormalizeUrlBeforeScan, AllowDotInPat, RemoveServerHeader, AlternateServerName, AllowLateScanning, UseFastPathReject, RejectResponseUrl, EnableLogging, PerProcessLogging, PerDayLogging, LogLongUrls, LoggingDirectory) are ignored because either they don’t make sense or the feature is always enforced by IIS core. We do block migration when incompatible versions of source and destination are present. Some request filtering features like applyToWebDav and hiddenSegments were not present in webDav. urlscanConfig migration provider doesn’t touch these properties if they are present on target. Not that if version of UrlScan is not compatible with IIS version present, migration will not be performed.


Migrating FastCGI configuration from IIS 5.1/6.0 to IIS 7.0/7.5


As you know FastCGI functionality on IIS 5.1 and IIS 6.0 is provided by FastCGI ISAPI extension which is available as an independent download. On IIS 7.0 and beyond, FastCGI functionality is provided by IIS FastCGI module which comes with the operating system. These components use different configuration stores to store the settings that affect their behavior. FastCGI ISAPI uses an INI file named fcgiext.ini as its configuration store whereas FastCGI module keeps configuration in applicationHost.config in xml format with rest of IIS configuration. Before, migrating from IIS6 to IIS7 involved migrating fcgiext.ini configuration to FastCGI module manually as there was no automated way to do that. MSDeploy only had functionality to migrate metabase configuration but because FastCGI ISAPI configuration is kept separately in an INI file, that wasn’t possible.


MSDeploy v1 RTW which is released today include a new provider named fcgiextConfig to automate task of migrating FastCGI ISAPI INI configuration to FastCGI module section. FcgiextConfig provider accepts a path which can be “APPHOST” or ”INI”. When path “APPHOST” is specified, configuration from system.webServer/fastCgi section in applicationHost.config is read. Path “APPHOST” should only be used on systems running FastCGI module (i.e. IIS7 and beyond). When path “INI” is specified, this provider reads the configuration from file “%windir%\system32\inetsrv\fcgiext.ini” and produce xml which looks like FastCGI module configuration. Once INI settings are mapped to produce the xml, msdeploy engine can compare configuration of FastCGI ISAPI with FastCGI module and make changes to FastCGI module configuration as required. Again, path “INI” can only be used on a machine which is running FastCGI ISAPI.


Dump command to dump INI settings looks like following.
        msdeploy –verb:dump –source:fcgiExtConfig=ini –xml
        msdeploy –verb:dump –source:fcgiExtConfig=apphost –xml

Sync command to move INI settings to FastCGI module section is following.
        msdeploy –verb:sync –source:fcgiExtConfig=ini –dest:fcgiExtConfig=apphost -whatif


  Here is how INI settings are mapped to system.webServer/fastCgi settings. For each entry   “<extension>:<optionalsiteid>=<sectionname>” under [Types] section of fcgiext.ini, we read the settings under section [<sectionname>]. If optional site id is present, we look for an entry for the same extension but without site id. If an entry is found, we use configuration under this entry as base set of settings for the site specific entry. So if “php=basephp” and “php:1=site1” entries are present in INI, settings under section [basephp] provide base values and then settings under section [site1] override base settings to generate configuration for “php:1” process pool. If a property is not present in the INI file, we assume the default value as assumed by FastCGI ISAPI extension. A FastCGI process pool entry is created for each INI entry with a valid ExePath. Various INI file settings are mapped to a FastCGI process pool as below.

fcgiext.ini configuration setting system.webServer/fastCgi/application property
ExePath fullPath
Arguments arguments
QueueLength queueLength
MaxInstances maxInstances
IdleTimeout idleTimeout
ActivityTimeout activityTimeout
RequestTimeout requestTimeout
InstanceMaxRequests instanceMaxRequests
FlushNamedPipe flushNamedPipe
Protocol protocol
RapidFailsPerMinute rapidFailsPerMinute
EnvironmentVars environmentVariables
ResponseBufferLimit Ignored
IgnoreExistingFiles Ignored
IgnoreDirectories Ignored
UnhealthyOnQueueFull Ignored

If the source version is FastCGI ISAPI 1.5, some additional properties get picked and mapped as below.

StderrMode stderrMode
MonitorChangesTo MonitorChangesTo
SignalBeforeTerminateSeconds signalBeforeTerminateSeconds

If FastCGI ISAPI version on source and FastCGI module version on destination are not compatible, fcgiextConfig provider will block the migration. Note that fcgiextConfig provider doesn’t take care of migrating the relevant IIS ScriptMaps. You can migrate ScriptMaps using a separate msdeploy migrate operation.

Hope this helps.