That has been a question we have come across frequently. Before IIS 8, you could host multiple sites needing SSL on a single IP address if the sites utilized the same SSL certificate or used a wildcard SSL certificate.  A wildcard certificate was only beneficial if you needed SSL on the subdomain level of a current site/domain. But what if you had sites with different names? Well, you could get a Subject Alternative Names (SAN) SSL certificate.  This SSL certificate would allow you to protect multiple sites with a single SSL certificate. The last available option prior to IIS 8 required setting each additional SSL site on the same IP address but with a different SSL port number. This would allow you to utilize each site’s/domain’s SSL on the same IP address as another site.  By default, SSL certificates utilize port 443 for secure communication. This port doesn’t need to be specified in the URL since this is the standard port. When you use a different port number for SSL you will be required to add the non-standard SSL port number in the URL in order for it to work.  As you can imagine, this is not the way you want to run a public site. How would a user know to enter the port number and it’s not a common step that users are familiar with doing when browsing a site.

Adding an additional IP address to host another site needing SSL is the common method used but sometimes this isn’t an option for some people. With the inception of IIS 8 on Windows Server 2012, a new feature called Server Name Identification (SNI) was added. This feature offers an easier solution to hosting multiple sites that have a different or individual SSL on a single IP address. This feature is included in IIS 8 by default and doesn’t require the installation of any additional features to begin using it. Below, we will walk through the steps involved with configuring SNI. One thing to note with implementing SNI for your SSL solution, it will not work for those users running Internet Explorer on Windows XP. If your server has multiple IP addresses, you can implement SNI for some sites in addition to assigning individual sites to a single IP address for SSL. Both methods will work along side each other on different IP addresses without issue.

Steps:

1)  One of the first things you will need to do is import the SSL certificates for each site on the server if this hasn’t been done already
2)  Next, open IIS 8 Manager and add your first site that will need SSL
  a.  If the first site is already in place, proceed to step the next step
3)  After the site is added select the site and click Bindings… under the Actions menu pane on the right

4)  Click Add
  a.  Select https for the Type
  b.  You can leave the IP address to “All Unassigned” or choose the IP address you want to use
(If you have multiple IP’s on the server you will want to specify the one you want to use for SNI)
  c.  Enter your site/domain name for Host name
  d.  Check the box for “Require Server Name Indication”
  e.  Select the SSL certificate for the site from the drop down box
  f.  Click OK

5)  Create the second site and add the SSL binding following the steps below
6)  Select Bindings and click Add
  a.  Select https for the Type
  b.  You can leave the IP address to “All Unassigned” or choose the IP address you want to use
   (If you have multiple IP’s on the server you will want to specify the one you want to use for SNI)
  c.  Enter your site/domain name for Host name
  d.  Check the box for “Require Server Name Indication”
  e.  Select the SSL certificate for the site from the drop down box

7)  Click OK to complete the setup

That’s all that needs to be done.  Test SSL for the site to make sure each site is working properly.  If you have additional sites that need SSL added, you can continue following the steps above for adding the SSL binding for each new site.

This article discuss brief information about the improvements in IIS 8. Internet Information Services (IIS) 8 includes many new and improved features that make moving to Windows Server 2012 compelling for organizations that rely on Windows Servers as their web server.

Improvement 1: Centralized SSL Certificate Management

With IIS on Windows 8 or Windows Server 2012, you can take advantage of the SSL certificate management console. This is a central management console that is able to install certificates and work with certificates across all IIS 8 web servers.

This includes the ability to more rapidly bring new servers online by being able to import all certificates that are needed. If a certificate needs to be renewed on multiple systems, it can be done through the IIS 8 certificate management console. You no longer have to log onto each system to update the certificate.

Note: Centralized SSL Certificate management is installed as a separate feature. You can install IIS without Centralized SSL Certificate Support. Centralized SSL Certificate Support is in the security section of “Windows Features.”

Improvement 2: Application Initialization

One frustrating problem that many web server admins face is the problem of slow-responding sites as web applications are initializing. A common workaround is to use tools and scripts to “cold start” the applications early in the morning so that the sites are ready to perform: The in-memory cache is loaded, and in some cases the content must be generated, before the IIS server is ready to respond to HTTP requests.

With IIS 8, Application Initialization lets you establish rules for “warming up” sites. For example, you can have larger applications begin the initialization process earlier than smaller applications. You can also configure through application initialization a new splash screen to be displayed in case people find themselves waiting while the application is initializing.

I can see a much better user experience by logging onto a SharePoint site early in the morning and having the first page displayed being a simple “Please wait while this application is being prepared for use” splash screen instead of just a blank page and a spinning circle.

Improvement 3: Dynamic IP Address Restrictions

Restricting access to a website by its IP address is nothing new -- admins have long been able to do that. You can even restrict by a block of IPs in an address range.

The problem that persists is tracking down all of the IP addresses to block. This would usually take a long time of parsing through logs, and even if going through the logs and filtering out the IP addressed were scripted, it is done in a reactive manner.

Instead, using the Dynamic IP Address Restrictions feature in IIS 8 for Windows 8 and Windows Server 2012, you can specify on a per web application level the maximum number of connections that an IP address can create within a certain time frame. And you can also specify the maximum number of attempts that can be made into the IIS 8 server from an IP address within a specific time. Any attempts beyond what is allowed are automatically filtered out, making your web applications and your web server much more resistant to malicious activity.

Dynamic IP Address Restrictions is added as an additional feature of IIS that is not installed by default. To install the feature, open Windows Features, then place a check in the box to select Web Server (IIS) -> Web Server -> Security -> IP and Domain Restrictions. After all that, click Finish.

This article contains brief information about CPU Throttling in the IIS 8. What the differences approach between CPU Throttling in IIS 7 and IIS 8.

CPU Throttling in IIS 7 (and 7.5)

IIS 7 introduced support for CPU Throttling at an Application Pool level.  You could specify a limit of CPU usage and a corresponding action to take when that limit was exceeded.  The two available options were NoAction or KillW3wp.  The names accurately reflect what each option does: Doing nothing in the case of NoAction, or killing the worker process for KillW3wp. 

Let’s take a look at what the KillW3wp option looks like in practice. 

First, I will configure the DefaultAppPool with a limit of 10% CPU.  I have also set the Limit Interval to 1 minute to make it easier to demonstrate how the process is killed and then allowed to restart.

Next, I will apply load to the server using a load generation tool (WCAT, available for download here). 

Here is how things look in the Performance Monitor:

As you can see, the CPU usage is high when the process starts, then the line goes away.  What is happening is that the process is using a high amount of CPU, and after some time IIS realizes that they would use more than their 10% limit within 1 minute (the Limit Interval we configured earlier), so it kills the process for the remainder of the Limit Interval.  The process is prevented from restarting until the Limit Interval expires.  During this time, any user requests will fail with a HTTP 500 error.  After the Limit Interval is reached, the process is allowed to restart, it uses a high amount of CPU again, and it gets killed again.  This cycle will continue to repeat for this application that uses high CPU.

CPU Throttling in IIS 8.0

In IIS 8.0, we’ve worked closely with the Windows Kernel team to deliver a much better CPU throttling experience.  Unlike IIS 7 where the only solution was killing W3WP, in Windows 8 we have two additional throttling options: Throttle and ThrottleUnderLoad.  The Throttle option will always restrict the application to the specified amount of CPU utilization, while the ThrottleUnderLoad option will allow the process to use more than the specified amount of CPU, provided that there is no contention for CPU resources.

The CPU throttling settings are made on the Application Pool.  So if you use the recommended configuration of having each application use its own App Pool, each application will have its own setting for maximum CPU utilization. 

For this example we will use the Throttle option:

As with the IIS 7 scenario, I am using WCAT to apply load to the server.  Here is the CPU graph during the test:

As you can see from the graph, the CPU utilization stays around 10% all the time, instead of climbing higher and having the process be killed like IIS 7. 

Let’s try another example, using PHP this time.  As you know, PHP will use multiple processes for serving requests.  We will see that the CPU utilization stays near 10% even when multiple processes are running.  The sum of CPU usage for all of these processes will be limited to 10%.  Here is a view of Task Manager showing the FastCGI processes running when I put load on the system.  Note how the sum of all 5 processes is 10.4%.

Conclusion

In this post you’ve seen a comparison between the CPU throttling approaches in IIS 7 and IIS 8.  The investments in CPU throttling in IIS 8 provide a much better sandbox that you can use to limit CPU use by an application.

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.

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

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.

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

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

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.

Hope you’ll like the newest IIS 8. If you want to give a test drive on IIS 8, please check our site at http://www.hostforlife.eu

IIS 8 gets released along with Windows Server 2012. This comes with several interesting features such as NUMA-support, WebSockets, security improvements and better web deployment tools.

An interesting improvement in IIS 8 is NUMA-aware multi-core scalability -

To take advantage of this multi-core processors, IIS can be setup to work in two different modes depending on your expected workload – run multiple worker processes in one application pool (ideally one worker for each NUMA node) or run multiple application pools in a single workload/site. There are other configurations as well which deal with responsibility for node optimization and soft or hard thread affinity. You can read more about NUMA-aware scalability in IIS and how Windows Server 2012 works with NUMA hardware in an eBook called “Introducing Windows Server 2012” (as well as some of the below features in detail).

IIS 8 also features

- Web Sockets support for ASP.NET – .NET developers can leverage System.Web.WebSockets introduced in .NET 4.5
- Throttling improvements for multi-tenant environments
- Improvements in the way SSL is handled.

There are also some other security enhancements such as

- Dynamic IP restrictions, which can not only deny connection to IPs that break certain rules, but can also be set to return a 401, 403, 404 or just terminate connection altogether without a response
- Ability to enable FTP logon restrictions (by number of tries)

 The IIS team also announced Web Deploy 3.0 RTW which supports deployment to IIS 8 and comes with several features to make deployments easier for system administrators. Some of these are -

- dbDacFx Provider for Incremental Database publishing – with support for SQL Server and SQL Azure
- Ability to take an Application Offline before Deploy
- Parameterization improvements – such as ability to add/delete/replace xml elements,
- Automatic Backups
- Ability to change Authentication mode for the site
- Several PowerShell cmdlets

You can read an introduction to Web Deploy for more information about the tool.