In IIS, you run into an interesting situation when you need to access another resource off of the IIS server and certain fairly common situations occur.  When using Integrated Security, anonymous access is disabled, and impersonation is turned on, a security measure kicks in and doesn't allow your site to access resources on any network servers.  This includes access to a UNC path directly from IIS or SQL Server using Windows authentication.

The reason is because of a 'double hop' that authentication is doing.  When you authenticate to the IIS server using Integrated Authentication, that uses up your first 'hop'.  When IIS tries to access a network device, that would be the double or second hop which is not allowed.  IIS cannot in turn pass on those credentials to the next network device, otherwise the developer or administrator could abuse your credentials and use them in ways that the site visitor didn't anticipate.

This doesn't occur with anonymous access or with impersonation off because in that case IIS takes care of authenticating you and then it uses a different user for local or network access.  This means that the app pool identity or anonymous user can make a network call as the first hop.

Anyway, I didn't mean to even write that much since the following blog post answers this well already, and includes the three most common solutions.  I wanted to blog this as a reference point for anyone running into this authentication issue, and so that I have a reference to it myself.  I'll let Numos complete the story:

http://blogs.msdn.com/nunos/archive/2004/03/12/88468.aspx

I've written a couple times about what configuration changes cause AppDomain recycles.  Most recently how the ASP.NET tab causes a server-wide AppDomain recycle, and previously about changes in ASP.NET 2.0.

Here I'm going to cover things that, when done in IIS 7, will cause a full application pool recycle.  I obtained the following list from the Microsoft.com folk at Microsoft.  They worked with the IIS team during IIS 7 development to get a complete list of all settings which cause full app pool recycles.  What this means is that if you make changes to applicationHost.config that touches anything in the following list, the applicable application pool will be recycled.  If you change other settings to applicationHost.config, the app pools on the server will remain unaffected.

Note: It's important to realize that an application pool in IIS is different than an AppDomain in ASP.NET.  The previous blog posts were about AppDomain recycles, but this one is about application pool recycles. 

Windows Activation Process Service (WAS) recycles an application pool if you change the configuration of any of the following:

• Restart parameters (for example, restart time, number of requests, and scheduled memory)
• Idle timeout
• Ping interval
• Startup and shutdown time limit
• Orphan action
• CLR version
• Pipeline mode
• A 32 to 64 bit worker process
• Job objects (for example, CPU limit)
• CPU affinity
• Worker process identity

Essentially this means that virtually any change to the application pool settings will cause it to immediately recycle, so be careful when making a change to an app pool.  This applies when using IIS Manager, any of the programming APIs or if you edit applicationHost.config directly.  You may need to schedule to setting change off hours if you don't want a recycle to occur at an inopportune time.  Changes to global settings will not cause the application pools on the server to recycle.

This blog post was a long time coming and fortunately doesn't apply to IIS7, but I thought I would finally take a few minutes and cover this shortcoming with the ASPNET tab that ASP.NET 2.0 introduced into IIS 6 and IIS 5.

As I've covered in a previous post, only 1 version of ASP.NET can run at a time in each IIS Application Pool.  When you want to target a newer or older version of the ASP.NET framework for a particular site or application, you must update that website or application.

When ASP.NET 1.1 was released

When ASP.NET 1.1 was released, the common way to do this was to use aspnet_regiis.exe from the command line.  There was a serious shortcoming with that method though, as I detailed back in December of '03.  (That article and attached script is long overdue for a revision which I'll cover later in this blog post.)  The essence of what I said, and gave a sample script for, is that if you use aspnet_regiis.exe, it will cause an AppDomain recycle on ALL AppDomains on the server, even if you target a single site.  This means that on a production server, it is not safe to use aspnet_regiis outside of a scheduled maintenance window unless you don't mind the impact of an AppDomain recycle.  (for more information on what an AppDomain recycle is and what the impact is, check out this blog post)  The alternate is to change all of the script mappings manually, which properly changes the framework version but has zero impact on other sites on the same server.

When ASP.NET 2.0 was released

When ASP.NET 2.0 was released, Microsoft provided a new tab in IIS called "ASP.NET" as seen in the following screenshot:

At first this appears to be a welcome addition, and for development computers, it really is.  The issue is this:

The ASP.NET tab in IIS 5 and IIS 6 uses the aspnet_regiis.exe command in the background and, if used, will cause a full AppDomain recycle on the *entire server*.

It's not what most people would expect, and there is no warning provided, so be very careful about this.  In fact, you may survive an AppDomain recycle without having anyone complain.  Therefore, I'm sure oodles of people use this tab on production servers without realizing that they are blowing away InProc session state, causing slow first loads on the pages, and, for sites that take a long time to start up after an AppDomain recycle, possibly causing downtime.

At ORCS Web, when v2.0 came out, I cleaned up the script to handle more than 2 versions of the framework and to I made some other enhancements, but I never got around to blogging about it because there were some features that I wanted to add.  The two features that it's lacking the most are 1) you have to manually enter the site ID rather than getting to pick from a list, and 2) it doesn't support changing the framework version for subfolders.  I kept telling myself I would spend 1/2 a day and finish this, but never got around to it.  So, I'll include it here, and if it interests anyone, feel free to use it.  We've been running it in production for years and it works just great, but it could stand for some further improvements.  You can download it here: Change_Framework_version.zip.  (Note: at ORCS Web we use our own control panel to change the framework version now instead of this script, but it was based on this script)

When ASP.NET 3.0 and 3.5 was released

ASP.NET 3.0 and 3.5 followed a new trend.  They aren't full side-by-side versions of the framework like v1.1 and v2.0 were.  Instead they are add-on extensions to ASP.NET 2.0.  So, when you set your site to use v2.0 of the framework but have ASP.NET 3.5 installed on the server, you are actually able to use all of the v2.0 - v3.5 features. 

IIS 7

IIS 7 allows you to set the framework version at the application pool rather than the website.  This change does not cause the server-wide impact and it is safe to do on a production server as long as you realize that the one app pool will have an AppDomain recycle.

In summary, the ASP.NET tab should not be run on a production server except during a maintenance window.  The impact is pretty minor or non-existent for some sites, but it can be pretty bad for other sites.  Just be aware that changing the framework version from the ASP.NET causes an AppDomain recycle on the entire server.  The alternative is to manually change the script mappings which can be done using the script provided above, or manually item by item at the site or application level in IIS.

This quick post is for my own sake so I can find it again later. :-)  I refer to the following link often. 

Mike Volodarsky has put together a detailed list of breaking changes in IIS 7.0 and ASP.NET.  For the most part IIS 7 has great compatibility with IIS 6 apps.  The httpModules and httpHandlers section are two important web.config sections that need to be migrated from system.web to system.webServer in Integrated mode, but most other things will work without changes.

There are exceptions though, which his blog post details well: http://mvolo.com/blogs/serverside/archive/2007/12/08/IIS-7.0-Breaking-Changes-ASP.NET-2.0-applications-Integrated-mode.aspx

I thought I would spend a few minutes today testing out Graffiti from Telligent.  Graffiti is a fairly new blogging and content management system (CMS) which is meant to be very easy to install and setup.  True to its word, it is impressively easy to get up and going.  There are a few things that I found that are worth noting.

I wanted to install this in a VDir on a shared server here at ORCS Web and use ISAPI Rewrite to make it appear to run in the root folder with its own domain name.

In brief terms the install involved the following:

• Download Graffiti (it's less than 3MB for the limited non-commercial version that I downloaded.)
• Extract and save to disk
• FTP the web folder to the vdir on the server
• Mark the vdir as an application (assuming IIS is installed and setup)
• Ensure that ASP.NET 2.0 is installed
• Ensure that the App_Data folder is gave write permissions for the application pool identity (assuming you use VistaDB which is what is used by default)
• Test.  It should work
• Update the default passwords per the Graffiti installation instructions.

This confirmed that it works in a vdir without any issue.  Just make sure to mark it as an application. 

I also tried using ISAPI Rewrite so that one IIS site can be used for multiple websites.  ISAPI Rewrite is an ISAPI Filter for IIS that allows for URL rewriting.  Using ISAPI Rewrite 2.0, the rule looks like this:

RewriteCond  Host:  (www\.)?testGraffitiSite\.com
RewriteRule  (?!/graffiti)(.*)   /graffiti$2 [I] 
# testGraffitiSite\.com is the domain name
# graffiti is the name of the vdir in IIS

Note that ISAPI Rewrite works at a different level than ASP.NET, so any time that ASP.NET does a redirect for any reason, it will append the full IIS path.  That means that you may start out with www.testgraffitisite.com and end up on www.testgraffitisite.com/graffiti.  It will still work, but it adds the extra part of the path to the URL.  There isn't any way around that with ISAPI Rewrite, so just make sure that the vdir is a name that you don't mind people seeing.  Obviouslly you can install Graffiti in the root of the site so that this isn't an issue, but I wanted to prove that it works well with ISAPI Rewrite.

I ran into one issue when helping someone else that installed Graffiti on a shared server.  When trying to view the page, it took forever and finally timed out without displaying any real errors.  That made it difficult to troubleshoot but I eventually determined that it was because of that shared server running in partial trust.  I was able to set the site to run in full trust and everything worked perfectly.  At some point I'll dig further to see what trust settings needs to be changed so that this will work in partial trust, but for now I know that the modified medium trust permission on that shared server wasn't enough to run Graffiti and the error message wasn't clear at all, it simply timed out.

All said and done, it really wasn't difficult at all to get up and going, even running in a vdir with ISAPI Rewrite.

Once installed, the usability of Graffiti is great.  It's easy to figure out, clean and nice and flexible.

There are some exciting events coming up around the Charlotte area which I'll be speaking at.  Next weekend is the Charlotte Code Camp Spring 2008.  I'll be speaking on what is currently fresh on my mind, and what I believe is very applicable to developers today.  The session is titled "What every developer needs to know about IIS 7". 

Here's the Code Camp agenda: http://www.developersguild.org/Default.aspx?tabid=248  For anyone in the area, I encourage you to register before it fills.

IIS 7 has many new changes that affect the developer this time around.  With IIS 6, mostly just the server administrator benefited.  But, with IIS 7, there are many changes that apply to the developer.  There are deployment changes, web.config configuration changes, the new system.webServer which applies to all types of files, distributed configuration, better debugging and troubleshooting tools, new remote management tools and those are just the most obvious.  The list goes on when you talk about the modular framework, extensibility, shared configuration for webfarms, security and FTP changes just to name a few.  I'll be speaking this very topic.

The other event in this area is July 8th in Ashville.  There is a new user group starting up next week, May 13th.  (http://wncdotnet.com/)  Brian Hitney will be presenting on "Building Next Generation Web Applications with VS2008" for the opening night.  Dave Kolb asked if I would speak at one of the following events.  I can't in June because I'll be at TechEd 2008, but I will for July 8th.  Ashville is a beautiful area about 2 hours North of where I live so I'll take my wife and kids and stay the night.  We're all looking forward to the trip.  I'll be covering a similar session as I will at Code Camp.

Searching for file content on your computer or server is a common task and one where you would expect accurate results.  You, like so many of us, may have assumed that but found different results.

Within Windows 2000 Server, if you entered something in the windows search dialog and clicked "Find", it would find it.  But, with Windows Server 2003 or Windows XP, there are a lot of searches that would come up empty, even if you were sure that you had files with the words in them that you were searching for.

The reason that the results are different in Windows Server 2003 and Windows XP is because Microsoft decided to only include certain types of files in the search to speed up the search.  Even if you set the file type as "All Files and Folders", it ignores a large amount of files when doing a search.  The reasoning is that it takes a long time to search every file on the server and binary type files like a jpg or gif or exe don't need to be searched for a plain text search term.  Why include them if they aren’t going to turn up any results anyway.

While I agree with it in part, if I want to find a file based on a keyword, I want it to search every file so that I can be sure that my search is accurate.

The fix is fairly easy as long as you don't mind making a registry change. My preferred method is to set Windows to index every file, even if it's an unknown exception.  This is done by adding or changing a DWORD called FilterFilesWithUnknownExtensions in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ContentIndex.  Set it to 1. (1 for on, 0 for off)

In fact I added it as part of the build process here at ORCS Web when Windows Server 2003 first came out a few years ago.  The search on every server on our network will search every file type.

Here is how I prefer to do it.  Create a file called AddIndexingToAllFiles.reg (Or, I just call it abc.reg since I delete the file immediately after using it).  Then put the following in it:

Windows Registry Editor Version 5.00

  [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ContentIndex]

"FilterFilesWithUnknownExtensions"=dword:00000001

Save the file on your desktop and double click on it.  After accepting the prompt and warning, the entry will be added to your registry.  You can delete the registry file since you're done applying it.

Here's a good Microsoft KB article on this with further details: http://support.microsoft.com/default.aspx?scid=KB;EN-US;309173.  It also explains how you can add specific extensions rather than just indexing all files if you prefer to do that.

Note: This is for Windows XP and Windows Server 2003.  The rules change again in Vista with a whole new search engine and method.  Here is a long discussion between Microsoft and some not-so-happy people discussing how Vista works: http://windowsvistablog.com/blogs/windowsvista/pages/advanced-search-techniques.aspx.

I use Remote Desktop all the time to manage servers remotely, and often I join other people's sessions to troubleshoot something with them, or walk through something or other.

In Windows Server 2003 (and Windows 2000 Server), the easy way to start up Terminal Services Manager is Start -> Run -> 'tsadmin' -> [Enter].  This calls us Terminal Services Manager where I can right-click on a user and click 'Remote Control', and if they approve, I can join their session.

This doesn't work in Windows Server 2008 anymore.  The change is ever so slight.  In Windows Server 2003 the tool was tsadmin.exe, so typing 'tsadmin' was all that was required to start the tool.  Now, in Windows Server 2008, this has been moved to a MMC snap-in and is called tsadmin.msc (plus tsadmin.dll is used silently).

So, to spin up Terminal Services Manager in Windows Server 2003, you can click on Start and your cursor focus will already be in the search box.  Type 'tsadmin.msc' and press [Enter] and you'll be in Terminal Services Manager.

If you really don't want to type the '.msc' each time, you could create a batch file to do it for you.  Create a file in c:\windows\system32 (which is in the system path already), call it tsadmin.bat and type 'tsadmin.msc' (without the quotes) in the body of the file.  Save it and you'll be set.  The disadvantage of doing this though is that you won't be practiced up on typing tsadmin.msc on fresh servers, so personally I prefer to just remember the extra .msc now on Windows Server 2008.

Note: If you don't type this often enough to remember 'tsadmin.msc', this has always been available from the Administrative Tools folder.  In Windows Server 2003/2000 it's directly under Administrative Tools.  In Windows Server 2008 it's one folder deeper under 'Terminal Services'.

I was just asked to help someone troubleshoot a site that worked fine on Windows Server 2003 / IIS6 but didn't work on Windows Server 2008 / IIS7.  A file was in a folder under the bin folder on the site and displayed an error when trying to view the page.  The path looked something like this:

http://www.sitename.com/subfolder/bin/debug/file.xml

The subfolder wasn't marked as an application, although that doesn't really matter.  The point is that since /bin/ was in the path somewhere, IIS7 wouldn't allow the file.xml to be displayed.  It served up a 404.2 error saying file or directory not found.

404 - File or directory not found.

The resource you are looking for might have been removed, had its name changed, or is temporarily unavailable.

Since I knew that it worked in IIS6, I knew that it wasn't asp.net that was blocking it, so I looked in applicationHost.config and found the following under the <requestFiltering> section:

                <hiddenSegments applyToWebDAV="true">
                    <add segment="web.config" />
                    <add segment="bin" />
                    <add segment="App_code" />
                    <add segment="App_GlobalResources" />
                    <add segment="App_LocalResources" />
                    <add segment="App_WebReferences" />
                    <add segment="App_Data" />
                    <add segment="App_Browsers" />
                </hiddenSegments>

So, IIS7 now blocks those key folders and doesn't allow them to be seen.  To the outside world, any page in any of these folders appears to not exist.

There may be times when you really do want to display the page, as in this particular case.  Not to worry, it can be changed easily enough.  This setting in on purpose though, so you usually shouldn't remove it for the whole site.

You can use AppCmd or do it manually from applicationHost.config or web.config.  Since requestFiltering is allowed to be set at the site or folder level by default, it's probably best to set a web.config file in the folder that you want to allow.

To do this, create a web.config file in your folder and type or paste the following into it.  I should look something like this:

<?xml version="1.0"?>
<configuration>
   <system.webServer>
       <security>
          <requestFiltering>
               <hiddenSegments>
                   <remove segment="bin" />
               </hiddenSegments>
           </requestFiltering>
       </security>
   </system.webServer>
</configuration>

If you want to make the change to your applicationHost.config file instead, you can do it by adding a location tag to the bottom of the file (well, almost the bottom - along with the other location tags) like this:

    <location path="sitename.com/subfolder/bin/debug">
        <system.webServer>
            <security>
               <requestFiltering>
                    <hiddenSegments>
                        <remove segment="bin" />
                    </hiddenSegments>
                </requestFiltering>
            </security>
        </system.webServer>
    </location>

You can do this using AppCmd instead.  Just drop to the command prompt and type the following: (Be sure to change the paths to the correct page before running this.)

C:\Windows\System32\inetsrv\appcmd.exe set config "sitename.com/subfolder/bin/debug" -section:system.webServer/security/requestFiltering /-hiddenSegments.[segment='bin']

After making this change, you will be able to view pages normally, even if they have /bin in the site path. 

The title is a bit biased since I co-authored the book, but Professional IIS 7 will be out in print within a couple weeks and I highly recommend picking up a copy!

I've had my head buried in this book for months—spending more time that I realized possible, but learning IIS 7 inside out and ultimately enjoying it.  (Although I have to admit that sometimes at 4:00 in the morning, trying to hit deadlines, I'm not sure that I realized that I was enjoying it. :))

The book will be in bookstores and shipping online during the 2nd week of March 2008.  You can order it directly from Wrox: http://www.wrox.com/WileyCDA/WroxTitle/productCd-0470097825.html or from Amazon.com.

We had a great team of authors on this book, each writing in areas that they knew best, and all delivering excellent content that is both knowledgeable, but also practical, based on their experience.  The author list is: Ken Schaefer, Jeff Cochran, Scott Forsyth, Rob Baugh, Mike Everest, Dennis Glendenning.

I wrote on application pool administration, remote delegation, webfarm management and configuration, programmatic configuration and administration and diagnostics and troubleshooting.

Be sure to pick up a copy and tell all of your IIS friends about it too!