What’s New in IIS 8

With the beta release of Windows Server 8 today, Internet Information server (IIS) 8 is available to the public for testing and even production workload testing.  Many system administrators have been anxious to kick the tires and to find out which features are coming.

I’ll include a high level overview of what we will see in the upcoming version of IIS.  The focus with this release of IIS 8 is on the large scale hoster.  There are substantial performance improvements to handle thousands of sites on a single server farm—with ease.  Everything that I mention below is available for download and usage today.

Forgive me if there are typos.  I’m writing this while at the MVP Summit in Seattle while trying to listen to another session at the same time.  Thanks to the IIS team who gave detailed demos on this yesterday and gave me permission to talk about this.

Real CPU Throttling

Previous versions of IIS have CPU throttling but it doesn’t do what most of us want.  When a site reaches the CPU threshold the site is turned off for a period of time before it is allowed to run again.  This protects the other sites on the server but it isn’t a welcome action for the site in question since the site breaks rather than just slowing down. 

Finally in version IIS 8 there are kernel level changes to support real CPU Throttling.  Now there are two new actions for sites that reach the CPU threshold.  They are Throttle and Throttle under load.  If you used WSRM to achieve this in the past, you no longer need to do so, and the functionality is improved over what is available with WSRM.

The throttle feature will keep the CPU for a particular worker process at the level specified.  Throttling isn’t applied to just the primary worker process, but it also includes all child processes, if they happen to exist.

The Throttle under load feature will allow a site to use all possible CPU if it’s available while throttling the worker process if the server is under load.

The throttling is based on the user and not specifically on the application pool. This means that if you use dedicated users on more than one app pool then it throttles for all of app pools sharing the same user identity. Note that the application pool identity user is unique so if you use the app pool identity user—which is common—then each app pool will be throttled individually.

This is a welcome new feature and is nicely implemented.

SSL Scalability

Unless you deal with large scale site hosting with many SSL certificates you may not have realized that there is room for improvement in this area. 

Previous versions of IIS have limited secure site density.  Each SSL site requires its own IP address and after adding a few SSL sites, startup performance becomes slow and the memory demand is high.  Every certificate is loaded into memory on the first visit to an SSL site which creates a large memory footprint and a long delay on the first load. 

In IIS 8 the SSL certificate count is easily scalable to thousands of secure sites per machine with almost instantaneous first-loads.  Only the certificate that is needed is loaded and it will unload after a configurable idle period.  Additionally, enumerating or loading huge numbers of certificates is substantially improved.

SNI / SSL Host Header Support

Using host headers and a shared IP address with SSL certificate has always been problematic.  IIS 8 now offers Server Name Indication (SNI) support which allows many SSL sites to share the same IP.  SNI is a fairly new feature (within the last few years) which allows host headers to work with SSL. It does this by carrying the target host name in the TLS handshake rather than the encrypted part of the packet.

IIS 8 makes SNI support a first class citizen in the site bindings.

Note that SNI doesn't work on all browsers. For example, Internet Explorer in Windows XP does not support SNI.  Read more about that from Eric Law's blog post. Over 85% of browsers is use today support SNI, but since it's not 100%, it will not work universally. However, like the adoption issue with host headers in the '90s, it will a fully supported before we know it. More details with a list of browsers can be found here: http://en.wikipedia.org/wiki/Server_Name_Indication

This sets the stage for sharing IP addresses which is extra important as ipv4 IPs become more valuable and consolidation of IPs becomes the trend. 

SSL Manageability - Central Certificate Store (CCS)

In IIS 7 managing SSL is labor intensive, particularly for server farms.  All certificate must be imported on every machine in the farm.  When setting up new servers you must account for time needed to import certificates when scaling out, and even on small server farms.  In previous versions keeping certificates in sync between servers is difficult to manage and often requires manual steps.

In IIS8 there is a new Central Certificate Store (CCS).  Central Certificate Store allows storing certificates on a central file share instead of each machine.  You can point the servers to a single network share, or use replication like DFS-R to sync the folders between machines.

Renewal and syncing is as simple as xcopying pfx files to the location that you specify when enabling CCS on the web server.  Enabling CCS is straight forward too.  It works very similar to enabling Shared Configuration.

CCS compliments the SNI functionality to support sites with multiple certs and a single IP.

The mapping of bindings to certificates uses a bit of magic … by convention rather than configuration. This is important for extremely large lists of certificates. Now you don't need to select them from a huge list. The value of the host header needs to match the name of the cert. Your CCS folder will have many .pfx files with names that match the domain name.  Basically the name of the .pfx files in the certificate store is the primary key.

If you use a wildcard cert then it needs to be named _.domain.com.pfx.

As you would assume, there is support for Multiple Domain Certificates (Unified Communications Certificate [UCC]). If you use multiple domain certificates using the subjectAltName feature of the certificate then you just create multiple copies of the pfx, one for each subjectAltName.

Note that you can use the old method which binds to by certificate identifier and it works the same as it did in the past.

Furthermore there is a neat feature for the central repository that allows grouping by expiration date, which groups by "Today / This Week / Next Week / Next Month / Later" which is handy for seeing which certificates are ready to expire.

With these changes to the certificates, it makes for a powerful solution for large scale webfarm hosting with multiple tenants.

Dynamic IP Restrictions

Information about this is already available on the web, but it's moving along and getting closer for the final release.

FTP Logon Restriction

Yay. A new FTP IP Restrictions module is coming! This is similar in concept to Dynamic IP Restrictions for HTTP. One of the key differences is that it does gray listing rather than black listing. When someone is blocked, they are only blocked for the sample period (e.g. 30 seconds). This is nice because it's enough to thwart or slow brute force and common name password attacks, but legit invalid attempts can continue to attempt to log in without waiting for long periods of time.

What's extra nice about having this feature is that you can set it slightly more sensitive than your domain username lockout policy so that brute force attacks don't cause your username to be locked out from too many invalid attempts. The FTP IP Restrictions can throttle the hack attempts without locking out your domain users.

Application Initialization Module

Previously known as the application warm-up module which was pulled for a time, now it's ready in full force as Application Initialization Module.

This allows spinning up sites and pages before traffic arrives and handling of requests in a friendly way while the application first loads. It's not uncommon for a site to take a minute or longer on the first load (yes SharePoint admins, we feel your pain).  This allows you to protect the end user from being the person that triggers this.

It's possible to set a warm-up page at the server level as a single setting, or you can use powerful URL Rewrite rules for more flexibility.

You can also ensure that your load balancer’s health test page doesn’t serve up a valid response until the site is fully initialized according to your preferences.  Then the load balancer will bring a node into rotation only after the entire warm-up has completed.

Configuration Scale

The IIS configuration files (e.g. applicationHost.config) can handle very large files with ease now.  There are substantial performance improvements in the upcoming version. Only administrators with large numbers of sites on the same server or server farm (think thousands) would have noticed before, but for large scale performance the new changes are paving the way for huge scale.

Web Sockets

It’s important to include Web Sockets in this list too.  Apart from some brief information I really haven’t looked into Web Sockets in detail yet so I’ll just include a great link from Paul Batum on it.  Web Sockets does require Windows 8 or later on the server side. 

All in all these are welcome changes.  While previous versions of IIS already did a great job of handling massive amounts of traffic, IIS 8 now can handle thousands (or tens of thousands) of sites and their extensive configurations on a single server farm.  With HTTP and FTP logon restrictions, CPU throttling, the Application Initialization Module, and large scale SSL and configuration improvements, IIS 8 brings a number of welcome improvements.