In all the news about Windows 10 and Windows Server 2016, I haven't read anything about new features in IIS except for the support of HTTP/2.
Maybe there is something else?
I'm looking at Server 2016 Technical Preview 2 (Build 10074), and Windows 10 (Build 10240) which seems to be no different in respect of IIS.
In Server 2016 TP2 and current builds of Windows 10, HTTP/2 is enabled by default, no need to set the DuoEnabled value in the registry, no need for a reboot.
To verify that your are now using HTTP/2, open Chrome and connect to your secure site hosted on IIS 10. In a second tab, type the following:
chrome://net-internals/#spdy
You may have to refresh your page, but you should see your request listed with a Protocol Negotiated value of h2
In Firefox 39, using the F12 tools, the Headers on the Network tab show: Version: HTTP/2.0
IE 11 or Edge don't seem to show any difference in their F12 tools.
A feature many people asked about for a long time is the support of wildcard host headers. In older versions of IIS up to 8.5 you could only specify a full host name in the bindings for a web site.
In IIS 10 you can now do:
New-WebBinding -Name "Default Web Site" -IPAddress "*" -Port 80 -HostHeader "*.foo.bar"
and your bindings are:
ls iis:\sites
Name ID State Physical Path Bindings
---- -- ----- ------------- --------
Default Web Site 1 Started %SystemDrive%\inetpub\wwwroot http *:80:
https *:443: sslFlags=0
http *:80:*.foo.bar
This means you can easily point multiple host names to the same site.
I never needed this, but for some people it's a big deal. There is a long thread on forums.iis.net about this.
You can now use site1.foo.bar and site2.foo.bar and as long as you have your DNS server or hosts file set up, they both go to the same site.
What about server1.department.foo.bar? - Doesn't work, the wildcard * stands for a single "word", using a binding of *.*.foo.bar is invalid, same for foo.*.bar. The wildcard has to be the leftmost character. An No: *.bar doesn't work.
To make this work you have to add a binding:
New-WebBinding -Name "Default Web Site" -IPAddress "*" -Port 80 -HostHeader "*.department.foo.bar"
But I think that is fair enough.
While the existing PowerShell module (WebAdministration) has hardly changed, the IIS team added a second module with direct access to the underlaying 'Microsoft.Web.Administration.ServerManager' object.
The big thing here is much better support for the PowerShell pipeline.
Get-command -Module IISAdministration | Select Name
Clear-IISConfigCollection
Get-IISAppPool
Get-IISConfigAttributeValue
Get-IISConfigCollection
Get-IISConfigCollectionElement
Get-IISConfigElement
Get-IISConfigSection
Get-IISServerManager
Get-IISSite
New-IISConfigCollectionElement
New-IISSite
Remove-IISConfigAttribute
Remove-IISConfigCollectionElement
Remove-IISConfigElement
Remove-IISSite
Reset-IISServerManager
Set-IISConfigAttributeValue
Start-IISCommitDelay
Start-IISSite
Stop-IISCommitDelay
Stop-IISSite
You can read more about it in Baris Caglar's Blog, a list of all new cmdlets is on TechNet
We can set specific environment variables per app pool. There is not UI for this yet.
Add-WebConfigurationProperty -value @{name='TestVar';value='42'} -filter "system.applicationHost/applicationPools/add[@name='DefaultAppPool']/environmentVariables" -pspath 'MACHINE/WEBROOT/APPHOST' -name "."
Looking at the Worker Process in Process Explorer:
Used in the HTTP Redirect module, make sure you have that:
Install-WindowsFeature Web-Http-Redirect
then set a new redirect using PermRedirect:
Set-WebConfigurationProperty -pspath 'MACHINE/WEBROOT/APPHOST/Default Web Site' -filter "system.webServer/httpRedirect" -name "enabled" -value "True" Set-WebConfigurationProperty -pspath 'MACHINE/WEBROOT/APPHOST/Default Web Site' -filter "system.webServer/httpRedirect" -name "destination" -value "http://foo.bar" Set-WebConfigurationProperty -pspath 'MACHINE/WEBROOT/APPHOST/Default Web Site' -filter "system.webServer/httpRedirect" -name "httpResponseStatus" -value "PermRedirect"
you now get:
No UI for this yet, use:
Set-WebConfigurationProperty -pspath 'MACHINE/WEBROOT/APPHOST/Default Web Site' -filter "system.webServer/security/requestFiltering" -name "removeServerHeader" -value "True"
or one the server level:
Set-WebConfigurationProperty -pspath 'MACHINE/WEBROOT/APPHOST' -filter "system.webServer/security/requestFiltering" -name "removeServerHeader" -value "True"
now the header
Server: "Microsoft-IIS/10.0"is no longer sent.
A new failure definition: traceAllAfterTimeout, I'm not sure what this does exactly.
Windows 10 supports at least two additional cipher suites:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE-RSA-WITH_AES_256-GCM-SHA384
The first one is an important one, because it is very high on the list of cipher suites that Google's Chrome browser is using.
Cipher suites for TLS 1.2 in Windows 10 (as of July 15th 2015):
Preferred:
ECDHE-RSA-AES256-GCM-SHA384 ECDH-256 bits 256 bits HTTP 200 OK
Accepted:
ECDHE-RSA-AES256-SHA384 ECDH-256 bits 256 bits HTTP 200 OK
ECDHE-RSA-AES256-SHA ECDH-256 bits 256 bits HTTP 200 OK
ECDHE-RSA-AES256-GCM-SHA384 ECDH-256 bits 256 bits HTTP 200 OK
AES256-SHA256 - 256 bits HTTP 200 OK
AES256-SHA - 256 bits HTTP 200 OK
AES256-GCM-SHA384 - 256 bits HTTP 200 OK
ECDHE-RSA-AES128-SHA256 ECDH-256 bits 128 bits HTTP 200 OK
ECDHE-RSA-AES128-SHA ECDH-256 bits 128 bits HTTP 200 OK
ECDHE-RSA-AES128-GCM-SHA256 ECDH-256 bits 128 bits HTTP 200 OK
RC4-SHA - 128 bits HTTP 200 OK
RC4-MD5 - 128 bits HTTP 200 OK
AES128-SHA256 - 128 bits HTTP 200 OK
AES128-SHA - 128 bits HTTP 200 OK
AES128-GCM-SHA256 - 128 bits HTTP 200 OK
DES-CBC3-SHA - 112 bits HTTP 200 OK
To get such a list download sslyze, unblock and extract the zip, then run:
.\sslyze.exe --regular www.mysite.com
as a standard user