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.

 

UseAllowVerbs

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

UseAllowExtensions

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

VerifyNormalization

allowDoubleEscaping

AllowHighBitCharacters

allowHighBitCharacters

UnescapeQueryString

unescapeQueryString

 

RequestLimits

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”.

DenyHeaders

Moved to requestLimits/headerLimits after removing colon.

AlwaysAllowedUrls

alwaysAllowedUrls collection

DenyUrlSequences

denyUrlSequences collection

AlwaysAllowedQueryStrings

alwaysAllowedQueryStrings collection

DenyQueryStringSequences

denyQueryStringSequences collection

 

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

AppliesTo

filteringRule/appliesTo

DenyDataSection

filteringRule/denyStrings.

ScanURL

filteringRule@scanUrl

ScanAllRaw

filteringRule@scanAllRaw

ScanQueryString

filteringRule@scanQueryString

ScanHeaders

filteringRule/scanHeaders

 

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.

Thanks,
Kanwal

Feature additions and bug fixes coming up in WinCache

We are seeing huge momentum behind adoption of WinCache. In the month of September, WinCache v1 Beta was downloaded more than 13,000 times making it one of the most downloaded IIS extensions in the first month following its release. Many happy customers chose to run it on their production servers despite its beta tag. We got very encouraging feedback from the beta release and we are pushing hard for our next release. Our next release date is approaching fast and I wanted to give an update on new features and bug fixes. If your favorite feature was missing in the beta and is also not in the list below, please email me or post on the forums so that we can consider it for future releases of WinCache.

Bug Fixes

1. We fixed a bug due to which same file was getting included twice even when include_once/require_once was used. Some PHP applications didn’t work due to this bug.
2. Few customers reported crashes when running WinCache on their test servers. This was because file cache component didn’t cache zero-size files properly.
3. One customer didn’t see enough performance improvement when using cakephp. This was because of a bug in opcode cache which caused us to recompile the code every time.
4. One bug caused opcode cache’s total hit count to be negative after first request. Also hit count of different file entries in file cache was one more than expected. Both of these bugs are fixed.
5. WinCache caches compile time errors and warnings generated by PHP engine. We fixed a bug due to which warning/errors caching sometimes caused next request to return 500.

New features

1. We are adding an API “bool wincache_refresh_if_changed()” to force a file change check on a file next time it is used from cache. This is useful if you change a file in PHP code and you want next request to load the file from disk again. You can pass blank or null which tells API to refresh all the files in the cache. An array of absolute/relative paths as argument will make WinCache only refresh these file entries. Please note that file will be reloaded from disk only if a file change is detected. This API enforces a file change check and not necessarily removal of cached entry.
2.
In the next release, users will be able to disable file change checks completely by setting value of wincache.chkinterval to 0. When file change checks are disabled, changed file will be reloaded only when wincache_refresh_if_changed is called or IIS application pool is recycled. Cached files will still get removed by scavenger when the file is not used for a long time causing wincache to load the file again.
3.
Another feature getting added is to enable administrators choose a list of websites for which wincache.ocenabled property is opposite of global setting affecting all the websites. This was requested by a hoster who wanted a safe and quick mechanism to turn-off WinCache for websites which run into some problems.
4.
By default, caching in WinCache will be disabled when PHP is running in CLI (command line) mode. Setting wincache.enablecli to 1 will turn on caching in CLI mode.
5. We will be exposing total_cache_uptime property from wincache_fcache_fileinfo() and wincache_ocache_fileinfo() which will give total cache uptime in seconds.
6.
On popular demand, we are including a PHP script (wincache.php) in WinCache setup which users can use to see cache statistics.

If you haven’t had a chance to test your PHP application with WinCache yet, download and try it out today. We are looking forward to your feature requests, bugs and general feedback to guide us for future releases of WinCache.



Update: WinCache RC release is available now.

Thanks,
Kanwal