A new version of IIS is included in Windows 10, which was recently released. I was expecting it to be called "IIS 9.0" to follow the model used until now, but we've jumped all the way to "IIS 10.0". However, not much information seems to be available about what has changed, and the documentation at IIS.NET has yet to be updated.
I'll outline some changes I've noticed on this post. Most of them where found simply by going over the configuration schemas in %WINDIR%\System32\inetsrv\config\schema on my own.
Wildcard Host Header Support
This is a very useful feature that allows you to create a Web Site with a host header value of "*.<domain>", meaning that you don't have to create separate bindings for each subdomain you need to bind to the same Web Site! You can read more about this feature here.
IISAdministration PowerShell Module
The WebAdministration module for managing IIS from PowerShell was introduced in IIS 7.5. However, it suffers from several issues, including the fact that it often doesn't feel very "PowerShelly". With IIS 10.0, a new alternative PowerShell module has been added, called IISAdministration. You can read more about this here.
In IIS 10.0, you can now easily specify a custom set of environment variables for an Application Pool, which will be defined for any worker process created from it. This is not supported in the UI, but you can easily add them using the Configuration Editor, or using AppCmd. For example, the following command will add a new environment variable to the ".NET v4.5" application pool named "MYVARIABLE":
appcmd set apppool ".NET v4.5" /+environmentVariables.add[@start,name='MYVARIABLE',value='C:\temp']
I think this is a very nice, useful feature, particularly for complex hosting environments with many application pools and where you might not want to define the variables at the machine level.
Log Event On Recycle Defaults
Up to IIS 8.5, the logEventOnRecycle property of application pools had a default value of "Time, Memory, PrivateMemory". This means that when an application pool was recycled for any other reason, WAS (Windows Process Activation Services) would not leave an audit event on the System Event Log telling you about it.
With IIS 10.0, the default value of logEventOnRecycle property has been changed to "Time, Requests, Schedule, Memory, IsapiUnhealthy, OnDemand, ConfigChange, PrivateMemory", which is much more useful and aligned with our recommended practices.
Support for Permanent Redirects
When using the "HTTP Redirection" feature, you can now tell IIS to respond with an status code of 308 Permanent Redirect.
Remove the Server Header
One feature that the old UrlScan tool had that was missing from the Request Filtering module introduced in IIS 7.0 was the option to remove the IIS Server version header ("Server: Microsoft-IIS/10.0"). The option to do so has now been added back in IIS 10.0 with the
removeServerHeaderoption. I don't think this has been exposed in the Management Console yet, but you can use the AppCmd.exe to enable it, like this:
appcmd.exe set config "Default Web Site" /section:system.webServer/security/requestFiltering /removeServerHeader:True
Tracing after Timeout in FREB
IIS 7.0 introduced a fantastic feature known as Failed Request Tracing (aka FREB). However, one issue with FREB was that if you had rules configured for collecting traces based on request execution time, the trace file would get written as soon as the time limit expired. That meant you usually ended up with a "partial trace" that didn't include all events until the request completed.
There is a new attribute you can configure on your rules called traceAllAfterTimeout in IIS 10.0. When it is enabled, IIS will wait until the request is actually completed before writing the trace file. This option, however, is not exposed in the User Interface, but you can still use command line tools to enable it. The following command will add a rule and then enable the option, for example:
appcmd configure trace "Default Web Site/" /enable /path:*.aspx /timeTaken:00:10:00
appcmd.exe set config "Default Web Site" -section:system.webServer/tracing/traceFailedRequests /[path='*.aspx'].failureDefinitions.traceAllAfterTimeout:"True"
Overall, I think these are all excellent, and welcome additions to IIS. Once the next version of Windows Server ships, we'll see if there are any other improvements implemented.