Scott Forsyth's Blog

Why is the IIS default app pool recycle set to 1740 minutes?

2013-04-06T15:06:23Z

Microsoft IIS Server has what appears to be an odd default for the application pool recycle time. It defaults to 1740 minutes, which is exactly 29 hours. I’ve always been a bit curious where that default came from. If you’re like me, you may have wondered too.

Wonder no longer! While at the MVP Summit this year in Bellevue WA I had the privilege again of talking with the IIS team. Wade Hilmo was there too. Somehow in the conversation a discussion about IIS default settings came up, which included the odd 1740 minutes for the app pool recycle interval. Wade told the story of how the setting came into being, and he granted me permission to share.

As you can imagine, many decisions for the large set of products produced by Microsoft come about after a lot of deliberation and research. Others have a geeky and fun origin. This is one of the latter.

The 1740 story

Back when IIS 6 was being developed—which is the version that introduced application pools—a default needed to be set for the Regular Time Interval when application pools are automatically recycled.

Wade suggested 29 hours for the simple reason that it’s the smallest prime number over 24. He wanted a staggered and non-repeating pattern that doesn’t occur more frequently than once per day. In Wade’s words: “you don’t get a resonate pattern”. The default has been 1740 minutes (29 hours) ever since!

That’s a fun little tidbit on the origin of the 1740. How about in your environment though? What is a good default?

Practical guidelines

First off, I think 29 hours is a good default. For a situation where you don’t know the environment, which is the case for a default setting, having a non-resonate pattern greater than one day is a good idea.

However, since you likely know your environment, it’s best to change this. I recommend setting to a fixed time like 4:00am if you’re on the East coast of the US, 1:00am on the West coast, or whatever seems to make sense for your audience when you have the least amount of traffic. Setting it to a fixed time each day during low traffic times will minimize the impact and also allow you to troubleshoot easier if you run into any issues. If you have multiple application pools it may be wise to stagger them so that you don’t overload the server with a lot of simultaneous recycles.

Note that IIS overlaps the app pool when recycling so there usually isn’t any downtime during a recycle. However, in-memory information (session state, etc) is lost. See this video if you want to learn more about IIS overlapping app pools.

You may ask whether a fixed recycle is even needed. A daily recycle is just a band-aid to freshen IIS in case there is a slight memory leak or anything else that slowly creeps into the worker process. In theory you don’t need a daily recycle unless you have a known problem. I used to recommend that you turn it off completely if you don’t need it. However, I’m leaning more today towards setting it to recycle once per day at an off-peak time as a proactive measure.

My reason is that, first, your site should be able to survive a recycle without too much impact, so recycling daily shouldn’t be a concern. Secondly, I’ve found that even well behaving app pools can eventually have something sneak in over time that impacts the app pool. I’ve seen issues from traffic patterns that cause excessive caching or something odd in the application, and I’ve seen the very rare IIS bug (rare indeed!) that isn’t a problem if recycled daily. Is it a band-aid? Possibly, but if a daily recycle keeps a non-critical issue from bubbling to the top then I believe that it’s a good proactive measure to save a lot of troubleshooting effort on something that probably isn’t important to troubleshoot. However, if you think you have a real issue that is being suppressed by recycling then, by all means, turn off the auto-recycling so that you can track down and resolve your issue. There’s no black and white answer. Only you can make the best decision for your environment.

Idle Time-out

While on the topic of app pool defaults, there is one more that you should change with every new server deployment. The Idle Time-out should be set to 0 unless you are doing bulk hosting where you want to keep the memory footprint per site as low as possible.

If you have a just a few sites on your server and you want them to always load fast then set this to zero. Otherwise, when you have 20 minutes without any traffic then the app pool will terminate so that it can start up again on the next visit. The problem is that the first visit to an app pool needs to create a new w3wp.exe worker process which is slow because the app pool needs to be created, ASP.NET or another framework needs to be loaded, and then your application needs to be loaded. That can take a few seconds. Therefore I set that to 0 every chance I have, unless it’s for a server that hosts a lot of sites that don’t always need to be running.

There are other settings that can be reviewed for each environment but the two aforementioned settings are the two that should be changed almost every time.

Hopefully you enjoyed knowing about the 29 hour default as much as I did, even if just for fun. Happy IISing.

Using WebDAV with ARR

2013-01-29T17:33:32Z

Application Request Routing (ARR) is a great solution for load balancing and other proxying needs. I’m a big fan and have written often about it.

I had someone ask me this week about WebDAV support for ARR. With his ARR setup, he noted that WebDAV creation, uploads, and downloads worked well, but renaming and moving files did not. He aptly noticed in the IIS logs that the source IP address showed as being from the ARR server rather than from the original user.

Here’s what the IIS log recorded:

2013-01-28 10:36:20 10.11.12.13 MOVE /Documents/test https://domain.com/Documents/test 80 User 10.9.8.7 Microsoft-WebDAV-MiniRedir/6.1.7601 400 1 0 31

The 10.9.8.7 IP Address is an IP address on the ARR server. And yes, the real IP address has been replaced with a made-up IP to protect the innocent.

To be honest, I haven’t tested WebDAV with ARR yet, but the issue sounded like the proxy-in-the-middle issue. I suggested installing ARRHelper on the web servers, and sure enough, that took care of it. While I didn’t setup a full repro myself, he confirmed that it worked for him after the ARRHelper install so I feel quite confident in saying that WebDAV will work with ARR as long as ARRHelper is installed.

So for anyone working with WebDAV and ARR and it doesn’t work for you, it’s likely that ARRHelper needs to be installed on the web servers.

You can find ARRHelper here, and if interested, I have a short video explaining what it is and why it’s important.

Handing MVC paths with dots in the path

2013-01-16T14:37:42Z

A friend of mine asked me recently how to handle a situation with a dot (.) in the path for an MVC project. The path looked something like this:

http://domain.com/aspnet/CLR4.0

The MVC routes didn’t work for this path and the standard IIS 404 handler served up the page instead. However, the following URL did work:

http://domain.com/aspnet/CLR4.0/

The only difference is the trailing slash. For anyone that runs into the same situation, here’s the reason and the solution.

What causes this inconsistency

The issue with the first path is that IIS can’t tell if the path is a file or folder. In fact, it looks so much like a file with an extension of .0 then that’s what IIS assumes that it is. However, the second path is fine because the trailing slash makes it obvious that it’s a folder.

We can’t just assign a wildcard handler to MVC in IIS for all file types because that will break files like .css, .js, .png, and other files are processed as static images.

Note that this would not be an issue if the dot is in a different part of the path. It’s only an issue if the dot is in the last section. For example, the following would be fine:

http://domain.com/aspnet/CLR4.0/info

So how do we resolve it?

As I mentioned, we can’t simply set a wildcard handler on it because it will break other necessary static files. So have about three options:

You could always change the paths in your application. If you’re early enough in the development cycle that may be an option for you.
Add file handlers for all extension types that you may have. For example, add a handler for .0, another for .1, etc.
Use a URL rewriter like IIS URL Rewrite to watch for a particular pattern and append the training slash.

Let’s look at these second two options. I’ll mention now up front that the URL Rewrite solution is probably the best bet, although I’ll cover both in case you prefer the handler method.

Http Handler Solution

You can handle specific extensions by adding a handler for each possible extension that you’ll support. This maps to System.Web.UI.PageHandlerFactory so that ASP.NET MVC has a handle on it and you can create an MVC route for it. This would apply to ASP.NET, PHP, or other frameworks too.

C:\Windows\System32\inetsrv\appcmd.exe set config "Sitename" -section:system.webServer/handlers /+"[name='.0-PageHandlerFactory-Integrated-4.0',path='*.0',verb='GET,HEAD,POST,DEBUG',type='System.Web.UI.PageHandlerFactory',preCondition='integratedMode']" /commit:apphost
C:\Windows\System32\inetsrv\appcmd.exe set config "SiteName" -section:system.webServer/handlers /+"[name='.1-PageHandlerFactory-Integrated-4.0',path='*.1',verb='GET,HEAD,POST,DEBUG',type='System.Web.UI.PageHandlerFactory',preCondition='integratedMode']" /commit:apphost

Run this appcmd command from the command prompt to create the handlers.

Make sure to update “Sitename” with your own site name, or leave it off to make it a server-wide change. And you can update ‘*.0’, ‘*.1’ to your extensions.

If you do create the site-level rule, make sure to save your web.config back to your source control so that you don’t overwrite it on your next site update.

IIS URL Rewrite Solution

Probably the best solution, and the one that my friend used in this case, is to use URL Rewrite to add a trailing slash when needed. The advantage of this is that you can use a more general pattern to redirect the URL rather than a bunch of handlers for each specific extension.

This assumes that you have IIS 7.0 or greater and that you have URL Rewrite installed. If you’re not familiar with URL Rewrite, check out the URL Rewrite articles on my blog (start with this one).

Note: If you want, you can skip this section and jump right to the next section for an easier way to do this using URL Rewrite’s rule wizard.

The following rule watches for a pattern of exactly “something.{digits}” (without a trailing slash). If it finds it then it performs a redirect and appends the trailing slash. It also confirms that it’s not a file or directory that exists on disk.

<rule name="Add trailing slash for some URLs" stopProcessing="true">
    <match url="^(.*\.(\d)+)$" />
    <conditions>
        <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
        <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
    </conditions>
    <action type="Redirect" url="{R:1}/" />
</rule>

To apply this rule, using IIS Manager you can create a dummy rule as a placeholder and then edit web.config and replace your placeholder rule with this rule. If this still doesn’t make sense then be sure to review the articles I mentioned above. The configuration location is in <configuration><system.webServer><rules><rule>…

An added benefit of this rule is that you’ll make the search engines happy by having just one path for each page, rather than possibly two with and without the slash. This will help with your SEO rankings.

I didn’t think of it at the time but just now I realized that you could use a general match url pattern of “.(*[^/])” and it will work for you too. The reason is that the check for IsFile and IsDirectory will ensure that your static images will continue to be served directly from disk so you won’t break them. So feel free to use <match url="(.*[^/])" /> instead if you want to add the trailing slash for all paths that don’t have them.

The Real Easy Solution (URL Rewrite wizard)

In fact, to make this easier yet, you can use URL Rewrite’s existing rule wizard to add the trailing slash. You must apply this at the site or folder level since the trailing slash wizard doesn’t exist at the server level.

From IIS Manager, open URL Rewrite at the site or folder level.
Click “Add Rule(s)…” from the Actions pane.
Select “Append or remove the trailing slash symbol” rule.
Use the default option of “Appended if it does not exist”
Press OK.

That’s it! You’ll have a rule added which will append the trailing slash for all non-physical file or folder paths that don’t already have the trailing slash. Not only will it handle dots in the path but the search engines will be happy too.

As with the http extension solution, if you create this as a site or folder-level rule, it will be applied to your web.config file. Make sure to update web.config in your source control so that you don’t lose your changes on your next site deployment.

Windows 8 / IIS 8 Concurrent Requests Limit

2012-11-13T22:14:00Z

IIS 8 on Windows Server 2012 doesn’t have any fixed concurrent request limit, apart from whatever limit would be reached when resources are maxed.

However, the client version of IIS 8, which is on Windows 8, does have a concurrent connection request limitation to limit high traffic production uses on a client edition of Windows.

Starting with IIS 7 (Windows Vista), the behavior changed from previous versions. In previous client versions of IIS, excess requests would throw a 403.9 error message (Access Forbidden: Too many users are connected.). Instead, Windows Vista, 7 and 8 queue excessive requests so that they will be handled gracefully, although there is a maximum number of requests that will be processed simultaneously.

Thomas Deml provided a concurrent request chart for Windows Vista many years ago, but I have been unable to find an equivalent chart for Windows 8 so I asked Wade Hilmo from the IIS team what the limits are. Since this is controlled not by the IIS team itself but rather from the Windows licensing team, he asked around and found the authoritative answer, which I’ll provide below.

Windows 8 – IIS 8 Concurrent Requests Limit

Windows 8 (Basic edition)	3
Windows 8 Professional, Enterprise	10
Windows RT	N/A since IIS does not run on Windows RT

Windows 7 – IIS 7.5 Concurrent Requests Limit

Windows 7 Home Starter	1
Windows 7 Basic	1
Windows 7 Premium	3
Windows 7 Ultimate, Professional, Enterprise	10

Windows Vista – IIS 7 Concurrent Requests Limit

Windows Vista Home Basic (IIS process activation and HTTP processing only)	3
Windows Vista Home Premium	3
Windows Vista Ultimate, Professional, Enterprise	10

Windows Server 2003, Windows Server 2008, Windows Server 2008 R2 and Windows Server 2012 allow an unlimited amount of simultaneously requests.

URL Rewrite – Protocol (http/https) in the Action

2012-11-07T14:04:02Z

IIS URL Rewrite supports server variables for pretty much every part of the URL and http header. However, there is one commonly used server variable that isn’t readily available. That’s the protocol—HTTP or HTTPS.

You can easily check if a page request uses HTTP or HTTPS, but that only works in the conditions part of the rule. There isn’t a variable available to dynamically set the protocol in the action part of the rule. What I wish is that there would be a variable like {HTTP_PROTOCOL} which would have a value of ‘HTTP’ or ‘HTTPS’. There is a server variable called {HTTPS}, but the values of ‘on’ and ‘off’ aren’t practical in the action. You can also use {SERVER_PORT} or {SERVER_PORT_SECURE}, but again, they aren’t useful in the action.

Let me illustrate. The following rule will redirect traffic for http(s)://localtest.me/ to http://www.localtest.me/.

<rule name="Redirect to www">

  <match url="(.*)" />

  <conditions>

    <add input="{HTTP_HOST}" pattern="^localtest\.me$" />

  </conditions>

  <action type="Redirect" url="http://www.localtest.me/{R:1}" />

</rule>

The problem is that it forces the request to HTTP even if the original request was for HTTPS.

Interestingly enough, I planned to blog about this topic this week when I noticed in my twitter feed yesterday that Jeff Graves, a former colleague of mine, just wrote an excellent blog post about this very topic. He beat me to the punch by just a couple days. However, I figured I would still write my blog post on this topic. While his solution is a excellent one, I personally handle this another way most of the time. Plus, it’s a commonly asked question that isn’t documented well enough on the web yet, so having another article on the web won’t hurt.

I can think of four different ways to handle this, and depending on your situation you may lean towards any of the four. Don’t let the choices overwhelm you though. Let’s keep it simple, Option 1 is what I use most of the time, Option 2 is what Jeff proposed and is the safest option, and Option 3 and Option 4 need only be considered if you have a more unique situation. All four options will work for most situations.

Option 1 – CACHE_URL, single rule

There is a server variable that has the protocol in it; {CACHE_URL}. This server variable contains the entire URL string (e.g. http://www.localtest.me:80/info.aspx?id=5) All we need to do is extract the HTTP or HTTPS and we’ll be set. This tends to be my preferred way to handle this situation.

Indeed, Jeff did briefly mention this in his blog post:

… you could use a condition on the CACHE_URL variable and a back reference in the rewritten URL. The problem there is that you then need to match all of the conditions which could be a problem if your rule depends on a logical “or” match for conditions.

Thus the problem. If you have multiple conditions set to “Match Any” rather than “Match All” then this option won’t work. However, I find that 95% of all rules that I write use “Match All” and therefore, being the lazy administrator that I am I like this simple solution that only requires adding a single condition to a rule. The caveat is that if you use “Match Any” then you must consider one of the next two options.

Enough with the preamble. Here’s how it works. Add a condition that checks for {CACHE_URL} with a pattern of “^(.+)://” like so:

How you have a back-reference to the part before the ://, which is our treasured HTTP or HTTPS. In URL Rewrite 2.0 or greater you can check the “Track capture groups across conditions”, make that condition the first condition, and you have yourself a back-reference of {C:1}.

The “Redirect to www” example with support for maintaining the protocol, will become:

<rule name="Redirect to www" stopProcessing="true">

  <match url="(.*)" />

  <conditions trackAllCaptures="true">

    <add input="{CACHE_URL}" pattern="^(.+)://" />

    <add input="{HTTP_HOST}" pattern="^localtest\.me$" />

  </conditions>

  <action type="Redirect" url="{C:1}://www.localtest.me/{R:1}" />

</rule>

It’s not as easy as it would be if Microsoft gave us a built-in {HTTP_PROTOCOL} variable, but it’s pretty close.

I also like this option since I often create rule examples for other people and this type of rule is portable since it’s self-contained within a single rule.

Option 2 – Using a Rewrite Map

For a safer rule that works for both “Match Any” and “Match All” situations, you can use the Rewrite Map solution that Jeff proposed. It’s a perfectly good solution with the only drawback being the ever so slight extra effort to set it up since you need to create a rewrite map before you create the rule. In other words, if you choose to use this as your sole method of handling the protocol, you’ll be safe.

After you create a Rewrite Map called MapProtocol, you can use “{MapProtocol:{HTTPS}}” for the protocol within any rule action. Following is an example using a Rewrite Map.

<rewrite>

  <rules>

    <rule name="Redirect to www" stopProcessing="true">

      <match url="(.*)" />

      <conditions trackAllCaptures="false">

        <add input="{HTTP_HOST}" pattern="^localtest\.me$" />

      </conditions>

      <action type="Redirect"

        url="{MapProtocol:{HTTPS}}://www.localtest.me/{R:1}" />

    </rule>

  </rules>

  <rewriteMaps>

    <rewriteMap name="MapProtocol">

      <add key="on" value="https" />

      <add key="off" value="http" />

    </rewriteMap>

  </rewriteMaps>

</rewrite>

Option 3 – CACHE_URL, Multi-rule

If you have many rules that will use the protocol, you can create your own server variable which can be used in subsequent rules. This option is no easier to set up than Option 2 above, but you can use it if you prefer the easier to remember syntax of {HTTP_PROTOCOL} vs. {MapProtocol:{HTTPS}}.

The potential issue with this rule is that if you don’t have access to the server level (e.g. in a shared environment) then you cannot set server variables without permission.

First, create a rule and place it at the top of the set of rules. You can create this at the server, site or subfolder level. However, if you create it at the site or subfolder level then the HTTP_PROTOCOL server variable needs to be approved at the server level. This can be achieved in IIS Manager by navigating to URL Rewrite at the server level, clicking on “View Server Variables” from the Actions pane, and added HTTP_PROTOCOL. If you create the rule at the server level then this step is not necessary.

Following is an example of the first rule to create the HTTP_PROTOCOL and then a rule that uses it. The Create HTTP_PROTOCOL rule only needs to be created once on the server.

<rule name="Create HTTP_PROTOCOL">

  <match url=".*" />

  <conditions logicalGrouping="MatchAll" trackAllCaptures="false">

    <add input="{CACHE_URL}" pattern="^(.+)://" />

  </conditions>

  <serverVariables>

    <set name="HTTP_PROTOCOL" value="{C:1}" />

  </serverVariables>

  <action type="None" />

</rule>

<rule name="Redirect to www" stopProcessing="true">

  <match url="(.*)" />

  <conditions logicalGrouping="MatchAll" trackAllCaptures="false">

    <add input="{HTTP_HOST}" pattern="^localtest\.me$" />

  </conditions>

  <action type="Redirect" url="{HTTP_PROTOCOL}://www.localtest.me/{R:1}" />

</rule>

Option 4 – Multi-rule

Just to be complete I’ll include an example of how to achieve the same thing with multiple rules. I don’t see any reason to use it over the previous examples, but I’ll include an example anyway. Note that it will only work with the “Match All” setting for the conditions.

<rule name="Redirect to www - http" stopProcessing="true">

  <match url="(.*)" />

  <conditions logicalGrouping="MatchAll" trackAllCaptures="false">

    <add input="{HTTP_HOST}" pattern="^localtest\.me$" />

    <add input="{HTTPS}" pattern="off" />

  </conditions>

  <action type="Redirect" url="http://www.localtest.me/{R:1}" />

</rule>

<rule name="Redirect to www - https" stopProcessing="true">

  <match url="(.*)" />

  <conditions logicalGrouping="MatchAll" trackAllCaptures="false">

    <add input="{HTTP_HOST}" pattern="^localtest\.me$" />

    <add input="{HTTPS}" pattern="on" />

  </conditions>

  <action type="Redirect" url="https://www.localtest.me/{R:1}" />

</rule>

Conclusion

Above are four working examples of methods to call the protocol (HTTP or HTTPS) from the action of a URL Rewrite rule. You can use whichever method you most prefer. I’ve listed them in the order that I favor them, although I could see some people preferring Option 2 as their first choice. In any of the cases, hopefully you can use this as a reference for when you need to use the protocol in the rule’s action when writing your URL Rewrite rules.

Further information:

Viewing all Server Variable for a site.
URL Parts available to URL Rewrite Rules
Further URL Rewrite articles

Reading a memory.dmp or other .dmp file

2012-07-18T13:40:56Z

While the dreaded Blue Screen of Death (BSOD) occurs less frequently with newer versions of Windows than it did in years past, there are still times when the BSOD reveals itself.

I just ran into four BSOD’s on two Windows Server 2012 machines and I had the ‘opportunity’ to analyze a memory.dmp file today, so I thought I would post quick instructions on how to get a handy summary of the memory dump.

I’ve had this ”I Found a Fix” debugging page bookmarked for years and I’ve used it many times, so I need to give full credit to ifoundafix for their helpful steps. The only change I have below is to include updated paths.

It’s possible to debug remotely, and you may have requirements to do that. My quick instructions here are for local debugging. The debugging tools are very stable and if you install just what you need then they are small and a quick install, so running this on a production machine is generally safe, but you must make that decision for your particular environment.

This can be accomplished with 7 easy steps:

Step 1. Obtain and install the debugging tools. The links do change over time, but the following link is currently an exhaustive page which includes Windows Server 2012 and Windows 8 Consumer debugger tools, Windows 7, Vista, XP and Windows Server 2003.

Debugging Tools Windows

All you need to install is the “Debugging Tools for Windows”. Everything else is used for more advanced troubleshooting or development, and isn’t needed here. Today I followed the link to “Install Debugging Tools for Windows as a Standalone Component (from Windows SDK)” although for a different OS you may need to follow a different link.

Step 2. From the command prompt navigate to the debugging folder. For me with the latest tools on Windows Server 2012 it was at C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\. You can specify the path during the install.

Step 3. Type the following:

kd –z C:\Windows\memory.dmp (or the path to your .dmp file)

Step 4. Type the following:

.logopen c:\debuglog.txt

Step 5. Type the following:

.sympath srv*c:\symbols*http://msdl.microsoft.com/download/symbols

Step 6. Type the following:

.reload;!analyze -v;r;kv;lmnt;.logclose;q

Step 7. Review the results by opening c:\debuglog.txt in your favorite text editor. Searching for PROCESS_NAME: will show which process had the fault. You can use the process name and other information from the dump to find clues and find answers in a web search. Usually the fault is with a hardware drivers of some sort, but there are many things that can cause crashes so the actual analyzing of the dump may take some research.

Often time a driver update will fix the issue. If the summary information doesn’t offer enough information then you’ll need to dig further into the debugging tools or open a CSS case with Microsoft. The steps above will provide you with a summary mostly-human-readable report from the dump. There is much more information available in the memory dump although it gets exponentially more difficult to track down the details the further you get into windows debugging.

Hopefully these quick steps are helpful for you as you troubleshoot the unwelcome BSOD.

Last Day With OrcsWeb

2012-05-19T03:29:20Z

It’s hard to believe that it’s been 10 years since my first day at OrcsWeb. Today is my last official day, but I’ll still be close by. I have a number of ties here, including being a customer through Vaasnet.

So much has changed in this time. Ten years ago I began working for OrcsWeb from Canada. Nine years ago I moved my family down here to North Carolina and assumed the role of Director of Technology. I was able to be a part of the company as it grew in staff, servers, customers, and reputation. I feel honored to be a part of OrcsWeb during these exciting years.

During my time at OrcsWeb I have been given opportunities to attend conferences, meet and become friends with top technical experts in the field, write articles, co-author two books, and speak at conferences and code camps. It was through OrcsWeb that I was given opportunities to be active in the community, to become a Microsoft MVP and an ASPInsider.

I’m grateful to Brad and Karla Kingsley who have always treated me like more than an employee. They have always encouraged me to grow and to pursue my dreams.

I’m thankful to Jeff Graves who has been accommodating to my evolving schedule and less than full time availability. And in terms of technical smarts, Jeff tops the list! And I’m also thankful of the rest of the team at OrcsWeb who are experts in the field, and with whom it’s always been a privilege to work.

Moving forward, I have two main focuses. I’ll be able to spend more time on Vaasnet (a company I co-founded with Jeff Widmer) to see the company position itself further in the market and to strengthen both the product and the brand. Additionally, I’m working in a part time basis with Dynamicweb an established CMS and eCommerce company in Europe who is just moving into the US market. Dynamicweb has a strong product already and I’m excited to work with the leadership team in the US. Expect to see more of Dynamicweb in the coming months and years.

I just want to reiterate a big thanks to OrcsWeb for helping write such an important chapter in my life. And it’s with excitement that I look forward to the next chapter of my life.

Introducing Testing Domain - localtest.me

2012-05-14T15:59:54Z

Save this URL, memorize it, write it on a sticky note, tweet it, tell your colleagues about it!

localtest.me (http://localtest.me)

and

*.localtest.me (http://something.localtest.me)

If you do any testing on your local system you’ve probably created hosts file entries (c:\windows\system32\drivers\etc\hosts) for different testing domains and had them point back to 127.0.0.1. This works great but it requires just a bit of extra effort.

This localtest.me trick is so obvious, so simple, and yet so powerful. I wouldn’t be surprised if there are other domain names like this out there, but I haven’t run across them yet so I just ordered the domain name localtest.me which I’ll keep available for the internet community to use.

Here’s how it works. The entire domain name localtest.me—and all wildcard entries—point to 127.0.0.1. So without any changes to your host file you can immediate start testing with a local URL.

Examples:

http://localtest.me
http://newyork.localtest.me
http://mysite.localtest.me
http://redirecttest.localtest.me
http://sub1.sub2.sub3.localtest.me

You name it, just use any *.localtest.me URL that you dream up and it will work for testing on your local system.

This was inspired by a trick that Imar Spaanjaars introduced me to. He created a loopback wildcard URL with his company domain name. I took this one step further and ordered a domain name just for this purpose.

I would have liked to order localhost.com or localhost.me but those domain names were taken. So to help you remember, just remember that it’s ‘localtest’ and not ‘localhost’, and it’s ‘.me’ rather than ‘.com’.

I can’t track usage since the domain name resolves to 127.0.0.1 and never passes through my servers, so this is just a public tool which I’ll give to the community. I hope it gets used. And, since I can’t really use the domain name to explain itself, please spread the word and tell others about it.

Some examples on how to use it would include:

Creating websites on your dev machine. site1.localtest.me, site2.localtest.me, site3.localtest.me.
Great for URL Rewrite (IIS) or mod_rewrite (Apache) testing: redirect.localtest.me, failuretest.localtest.me, subdomain.localtest.me, city1.localtest.me.
Any testing on your local system where a friendly URL would be useful.

I hope you enjoy!

Google and Geo-location, CNDs, DNS Load Balancing-Week 50

2012-04-20T01:24:18Z

You can find this week’s video here.

This week answers two Q&A questions from viewers. DNS Load Balancing and then some discussion and a walkthrough using Application Request Routing (ARR) for a Content Delivery Network (CDN).

There’s a growing movement towards Content Delivery Networks (CDN); fronting web farms and geographically dispersing websites. This week I continue with Q&A’s from viewers, taking questions on DNS Load Balancing and CDNs.

Question 1:

I would love to see some clever DNS load balancing (not sure what capability windows is offering). Flesik

Question 2a:

I would love to see an end-2-end CDN redundant network setup (dns balancing, ARR nodes, parent notes etc). Flesik

Question 2b:

I would be interested in seeing a series on building an ecdn or ecn using ARR and what the best practices would be to scale it out geographically.

It seems ARR is sold that way... really not sold but talked about. I have tried to put my theory out and try it but i just don't know the best way to route my clients to their designated locations. Can you help out with an awesome weblog maybe? Adam

The following URL is the one I mentioned in the video: http://learn.iis.net/page.aspx/649/deploying-application-request-routing-in-cdn

In this week’s video we look at DNS load balancing and geo-location issues that Google faces by using DNS to determine a user’s location. We also take a look at using Microsoft Application Request Routing (ARR) to create a CDN.

This is week 50 of a 52 week series for the web pro. You can view past and future weeks here: http://dotnetslackers.com/projects/LearnIIS7/

You can find this week’s video here.

What’s new in IIS8, Perf, Indexing Service-Week 49

2012-03-27T13:37:08Z

You can find this week’s video here.

This week I'm taking Q&A from viewers, starting with what's new in IIS8, a question on enable32BitAppOnWin64, performance settings for asp.net, the ARR Helper, and Indexing Services.

This week we look at five topics.

Pre-topic:

We take a look at the new features in IIS8. Last week Internet Information Services (IIS) 8 Beta was released to the public. This week's video touches on the upcoming features in the next version of IIS. Here’s a link to the blog post which was mentioned in the video

Question 1:

In a number of places (http://learn.iis.net/page.aspx/201/32-bit-mode-worker-processes/, http://channel9.msdn.com/Events/MIX/MIX08/T06), I've saw that enable32BitAppOnWin64 is recommended for performance reasons. I'm guessing it has to do with memory usage... but I never could find detailed explanation on why this is recommended (even Microsoft books are vague on this topic - they just say - do it, but provide no reason why it should be done). Do you have any insight into this? (Predrag Tomasevic)

Question 2:

Do you have any recommendations on modifying aspnet.config and machine.config to deliver better performance when it comes to "high number of concurrent connections"? I've implemented recommendations for modifying machine.config from this article (http://www.codeproject.com/KB/aspnet/10ASPNetPerformance.aspx - ASP.NET Process Configuration Optimization section)... but I would gladly listen to more recommendations if you have them. (Predrag Tomasevic)

Question 3:

Could you share more of your experience with ARR Helper? I'm specifically interested in configuring ARR Helper (for example - how to only accept only X-Forwards-For from certain IPs (proxies you trust)). (Predrag Tomasevic)

Question 4:

What is the replacement for indexing service to use in coding web search pages on a Windows 2008R2 server? (Susan Williams)

Here’s the link that was mentioned: http://technet.microsoft.com/en-us/library/ee692804.aspx

This is now week 49 of a 52 week series for the web pro. You can view past and future weeks here: http://dotnetslackers.com/projects/LearnIIS7/

You can find this week’s video here.

What’s New in IIS 8

2012-03-01T20:07:00Z

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.

IIS FTP Troubleshooting-Week 48

2012-02-21T15:58:57Z

You can find this week’s video here.

This lesson covers ways to troubleshoot IIS FTP. When it works, it works well, but if you run into issues getting an FTP account working it can sometimes be difficult to resolve. This video will help you understand some helpful tricks and it will walk you through ways to isolate and resolve the issue.

Over the last five weeks we’ve been looking at IIS FTP. See the list below to jump to a specific FTP topic. This week we explore some troubleshooting techniques and review the following FTP connectivity stack.

DNS Resolution/Network Connectivity
Firewall Access (Passive/Active / Secure?)
IIS Bindings
Authentication
Authorization
Isolation Mode / File paths
NTFS Permissions

There were two external resources which I referenced. They are:

Flushing the IIS FTP logs to disk http://weblogs.asp.net/owscott/archive/2012/02/03/flush-http-and-ftp-logs-in-iis.aspx
One of the more advanced steps is to use Event Tracing. Here is the link I referred to.http://blogs.msdn.com/b/robert_mcmurray/archive/2008/08/29/ftp-and-etw-tracing.aspx

This is now week 48 of a 52 week series for the web pro and it is the final of a 5-week mini-series on IIS FTP. The five weeks include:

Week 1: IIS FTP Basics
Week 2: IIS FTP and IIS Manager Users
Week 3: IIS FTP and User Isolation
Week 4: IIS FTP Firewall settings, Active vs. Passive
Week 5: IIS FTP Troubleshooting

You can find this week’s video here.

FTP Firewall Settings, Active vs. Passive, and FTPS Explicit vs. Implicit-Week 47

2012-02-13T14:28:48Z

You can find this week’s video here.

Have you ever wondered what FTP Active mode or Passive mode means? Do you have a good understanding of the FTP data channel or control channel? It can be difficult to fully understand FTP, which firewall ports to enable, and how to navigate the two communication channels. This lesson will hopefully clear up these questions and more.

This week’s video lesson takes a deep dive into FTP Active vs. Passive modes. As part of this you’ll get a chance to see the various modes in action, see what the traffic looks like in Wireshark, see exact firewall rules, learn about stateful FTP, find out about Explicit FTPS and Implicit FTPS, and learn about the FTP data channel and control channels.

This week's video lesson is the 4th of a 5-week mini-series on IIS FTP. The five weeks include:

Week 1: IIS FTP Basics
Week 2: IIS FTP and IIS Manager Users
Week 3: IIS FTP and User Isolation
Week 4: IIS FTP Firewall settings, Active vs. Passive
Week 5: IIS FTP Troubleshooting plus FTP Host Headers

This is now week 47 of a 52 week series for the web pro, and the 4th of a 5 week mini-series on IIS FTP. You can view past and future weeks here: http://dotnetslackers.com/projects/LearnIIS7/

You can find this week’s video here.

Flush IIS HTTP and FTP Logs to Disk

2012-02-04T04:11:13Z

Today I wanted to find a way to flush the IIS FTP logs on-demand. The logs for IIS FTP flush to disk every 6 minutes, and the HTTP logs every 1 minute (or 64kb). This can make troubleshooting difficult when you don’t receive immediate access to the latest log data.

After looking everywhere I could think of, from search engine searches to perusing through the IIS schema files, I figured I had better go to the source and ask Robert McMurray.

Sure enough, Robert had the answer and even wrote a blog post in response to my question with code examples for four scripting/programming languages (C#, VB.NET, JavaScript, VbScript).

There is not a netsh or appcmd solution though, so the scripting or programming options are the way to do it. Actually, you can also flush the logs by restarting the Microsoft FTP Service (ftpsvc) but, as you would assume, it will impact currently active FTP sessions.

This blog post serves three purposes.

It’s a reference pointing to Robert’s examples
I’ll include how to do the same for the HTTP logs
I’ll provide a PowerShell example which I based on Robert’s examples

1. The reference is mentioned above already, but to give me something useful to write in this paragraph, I’ll include it again. Programmatically Flushing FTP Logs.

2. For HTTP there is a method to flush the logs using netsh.

netsh http flush logbuffer

This will immediately flush the HTTP logs for all sites.

3. The FTP logs can be done from PowerShell too. Here’s a script which is the PowerShell equivalent of Robert’s examples. Just update $siteName, or pass it as a parameter to the script.

    Param($siteName = "Default Web Site") 

    #Get MWA ServerManager

    [System.Reflection.Assembly]::LoadFrom( "C:\windows\system32\inetsrv\Microsoft.Web.Administration.dll" ) | Out-Null

    $serverManager = new-object Microsoft.Web.Administration.ServerManager 

    $config = $serverManager.GetApplicationHostConfiguration()

    #Get Sites Collection

    $sitesSection = $config.GetSection("system.applicationHost/sites")

    $sitesCollection = $sitesSection.GetCollection() 

    #Find Site

    foreach ($item in $sitesCollection){ 

        if ($item.Attributes.Item("Name").Value -eq $siteName){

            $site = $item

        }

    }

    #Validation

    if ($site -eq $null) { 

        Write-Host "Site '$siteName' not found"

        return

    }

    #Flush the Logs

    $ftpServer = $site.ChildElements.Item("ftpServer")

    if (!($ftpServer.ChildElements.Count)){

        Write-Host "Site '$siteName' does not have FTP bindings set"

        return

    }

    $ftpServer.Methods.Item("FlushLog").CreateInstance().Execute()

I hope one of these programming/scripting options come in handy for times when you want immediate access to the latest FTP log data.

IIS FTP User Isolation-Week 46

2012-01-23T16:34:37Z

You can find this week’s video here.

I’ve been looking forward to releasing this week’s video. IIS FTP User isolation is an interesting topic because it offers a lot of power and flexibility but it’s not very intuitive because of how it’s managed.

This week we walk through the five isolation modes to gain a full understanding of the IIS FTP method of configuration for user isolation.

IIS FTP is a powerful application, but some of the flexibility is hidden through a unique convention based method of management. It’s easy to miss the fact that IIS FTP allows the ability to have multiple users who can be directed to different folders and be fully isolated from each other. For example, you can have a designer1 who has access to the whole site while designer2 has access to just project1 only, while—if you set it up correctly—you can feel confident that designer2 can’t gain more access than they are allowed.

IIS FTP requires understanding a few core principles to manage it effectively and to ensure that you don’t overlook key security settings that would allow users to gain more access than they should. IIS FTP 7.5 offers five different isolation modes, each of which targets a different situation.

This is now week 46 of a 52 week series for the web pro, and the 3rd of a 5 week mini-series on IIS FTP. You can view past and future weeks here: http://dotnetslackers.com/projects/LearnIIS7/

Also, if you’re reading this early enough, I’m taking questions for the last couple weeks of the series. Read more about it here.

You can find this week’s video here.