BillS IIS Blog : Troubleshooting

Error connecting to SQL Server from Windows 7 / Windows 2008 R2 with ASP.NET

bills — Wed, 07 Oct 2009 20:41:00 GMT

Just ran into this and thought I’d share. If you are trying to connect to a "user instance" of SQL Server from your Web application running on Windows 7 or Windows 2008 R2 and you’re getting a message that looks like this:

Failed to generate a user instance of SQL Server due to failure in retrieving the user's local application data path. Please make sure the user has a local user profile on the computer. The connection will be closed.

I can probably help you out.

Note: this error only happens if you have User Instance=true in your connection string. The IIS team made a change to the default identity of the worker process. Starting with IIS 7.5, Application Pools run with a unique identity based on the Application Pool name, rather than NetworkService – the default identity for IIS6 and IIS7. The primary reason for this change is to increase the security of IIS and Application Pools by default, providing a much better sandbox between Applications and other Windows services by default.

Unfortunately, the new identity does not have a user profile, and as you can see from the error, this causes the SqlClient data stack to fail. There are a few things you can do to "fix" this error: 1) switch back to NetworkService 2) switch to a user account that has a local profile (like a real user / domain user account). To do that, fire open IIS Manager and browse to Application Pools node for your computer. Click on the AppPool for the application you are trying to run and select the “Advanced Settings” task (in yellow on right). Select identity and choose NetworkService as a built-in account, or select “Custom account” and type in the user/password.

If you’re a command-line person, you can do it this way (all on one line):

%windir%\system32\inetsrv\appcmd.exe set config  
-section:system.applicationHost/applicationPools /[name='YOUR_APPPPOOL_NAME_HERE'].processModel.identityType:"NetworkService"  
/commit:apphost

More Tips and Troubleshooting Help for Classic ASP Developers

bills — Fri, 20 Feb 2009 23:10:18 GMT

Back in May of 2007 I posted a tips for Classic ASP developers post which has since received more than 50 comments and 85,000 views. Robert McMurray just posted a set of fabulous tutorials for Classic ASP developers. If you’re out there and having issues with Classic ASP and IIS7 and need some help, you’re not alone! Read these articles to get help:

Classic ASP is not installed by default on IIS 7.0 and IIS 7.5

In IIS 7.0 and 7.5, the classic version of ASP is not installed by default. Because of this, you might see HTTP 404 errors when you try to browse to an ASP page on your server, or you might see the source code for your ASP page displayed in your browser window ...

Using Classic ASP with Microsoft Access Databases on IIS 7.0 and IIS 7.5

Note: Microsoft Access databases have been popular for many years with developers who use Active Server Pages (ASP) for small-scale applications, but Microsoft Access databases are not designed for scalability, therefore Access databases should only be used ...

Classic ASP script error messages are no longer shown in a Web browser by default

In earlier versions of IIS, error messages from classic ASP scripts were sent to a Web browser, by default. Because these error messages might reveal sensitive information to malicious users, IIS 7.0 disables this feature by default. When your classic ASP ...

Using Failed Request Tracing to troubleshoot Classic ASP errors

One of the great troubleshooting features that is built in to IIS 7.0 is Failed Request Tracing, which lets you configure tracing rules on your server that will create detailed troubleshooting log files for custom failure conditions that you define. For example ...

Classic ASP parent paths are disabled by default

Classic ASP Parent Paths let developers use relative addresses that contain ".." in the paths to files or folders. For example, the following code excerpt illustrates an ASP page that maps a parent path: % Response.Write Server.MapPath("../example.asp")%> ...

APPL_PHYSICAL_PATH Server Variable on Windows Vista RTM

The original release of IIS 7.0 that shipped with Windows Vista returned a different value for the APPL_PHYSICAL_PATH server variable than that which was returned by previous

Why IIS7? Top 12 cool features…

bills — Fri, 21 Nov 2008 04:13:45 GMT

Every time I talk with customers in meetings or at conferences I’m struck by how many cool amazing new capabilities IIS7 has. I can go on for literally hours talking about the new features and benefits, and showing demos. And with each new IIS7 Extension, the list of new features just gets bigger and bigger. A few months ago I realized we didn’t have the top list of features written up anywhere, and so we started the process of distilling down the list to the top 10. We almost made it! We ended up with the top 12 reasons you should get IIS7 today. Check them out here:

http://www.iis.net/getstarted

Over the next few weeks we’ll be adding a cool demo for each of the reasons to show the features in action. Be sure to check back soon!

How to backup/restore IIS7 configuration

bills — Tue, 25 Mar 2008 03:55:07 GMT

Won's recent post on possible configuration corruption caused by OneCare/Forefront reminded me of something that every IIS7 customer should know about: how to backup and restore IIS7 configuration!

No matter whether your configuration file gets corrupted, you make changes you decide to roll-back, you accidentally foo-bar your .config file or some act of terror occurs, some day you'll want to go back to a prior configuration file. Thankfully, IIS7 makes this super easy.

Backup/Restore via the command line

Backing up IIS7 configuration is as simple as copying the \windows\system32\inetsrv\config directory (and subdirectories) into a backup directory, so you don't need anything special to do it. Just include this directory in whatever your OS/content back-up plan is, or write a custom script to do it.

To help make managing backups easy, we've added a simple cmd-line option to AppCmd.exe that makes management of backup/restore sets easy. For example, to backup configuration, run the follow command:

> %windir%\system32\inetsrv\appcmd.exe add backup "My Backup Name"

to restore that backup, run this command:

> %windir%\system32\inetsrv\appcmd.exe restore backup "My Backup Name"

to delete a backup, run this command:

> %windir%\system32\inetsrv\appcmd.exe delete backup "My Backup Name"

Pretty easy, eh? Except for the dirty little secret everyone knows...remembering to do a backup! Thankfully, IIS7 comes to the rescue here. Thanks to a feature called IIS7 configuration history, IIS will automatically make history snapshots of ApplicationHost.config each time a change is detected, enabling you to easily restore to a prior version. By default, IIS checks for a new version every 2 mins, and will keep 10 prior versions of the file. IIS7 stores these snapshots in the %systemdrive%\inetpub\history folder by default. You can change any of these settings by editing the <system.applicationHost/configHistory> section in ApplicationHost.config. This article explains the feature in great detail.

IMPORTANT NOTE: This feature only appears in Windows Server 2008 and Vista SP1. It is not in original release version of Vista , as it was not yet finished when Vista first shipped. This is one of the thousands of changes that was made to IIS7 after Vista RTM, and is one of many reasons you should install SP1 as soon as possible!

How do you restore a prior snapshot? Well, you could just go to the \inetpub\history\cfgHistory_NNNNNNNNNN directory and copy the applicationHost.config file into it's proper place: \windows\sytem32\inetsrv\config. Or you can use the same command as above for restoring a backup to restore a configuration history file.

To enumerate a list of backups and configuration history files, use the following command:

> %windir%\system32\inetsrv\appcmd.exe list backup

See how the config history files show up just like backups? Use WinDiff or some other tool to figure out which configuration history you want to restore, then use AppCmd.exe restore backup command to restore it!

IIS7 Videos on Channel 9

bills — Wed, 14 Nov 2007 03:30:00 GMT

Remote Administration and Delegation in IIS7
In this screencast, we configure our IIS7 server for remote administration and delegation. The remote administration service in IIS7 is a new and powerful feature that allows us to connect securely to our remote IIS server using a firewall-friendly SSL connection. Additionally, we can choose to use traditional Windows accounts for authentication or choose the new IIS Manager user accounts instead.

We will walk through the steps you must perform as the IIS administrator as well as the experience for a remote administrator using delegated features.

Failed Request Tracing on IIS7
In this screencast, we see how to configure our IIS7 server for Failed Request Tracing (sometimes called FREB). Failed Request Tracing is a powerful new capability in IIS7 that allows us to easily set rules on our web applications, that once triggered will log that request to disk and pull in all the relevant trace information. This feature is immensely useful for troubleshooting running applications where attaching a debugger is impractical.

Installing PHP Applications on IIS7
In this screencast, discover how easy it is to get PHP up and configured on your IIS7 webserver using FastCGI. The popular PHP-based blogging application, Wordpress, is used to demonstrate.

Additionally, we see how quickly and easily we can integrate a PHP app with IIS7's integrated pipeline as we convert Wordpress to use IIS7's built-in Forms Authentication.

Free IIS7 Online Training

bills — Mon, 10 Sep 2007 16:36:00 GMT

A few months ago the IIS team did a quick tour of Europe, speaking in various cities and countries in an all-day IIS conference specifically geared toward training people on IIS7. Luckily, the good people of Poland decided to record and publish the training for everyone to use. Check out the sessions below to watch Brett Hill and Isaac Roybal present IIS7. Here is a list of all the sessions: http://www.microsoft.com/emea/itsshowtime/result_search.aspx?event=69&x=13&y=2

IIS 7 Web Server Platform- Windows Server “Longhorn”

Microsoft’s Next Generation Web Server: What’s New in IIS 7 for IT Pros

Isaac Roybal, Product Manager, Windows Server, Microsoft Corporation

This overview session will highlight the key points of interests for IT Pros in Internet Information Services version 7. IIS7 modularity increases security by allowing a reduced installation footprint and creation of specialized, streamlined servers. Application Pools are now “sandboxed” by default. You’ll see how IIS7 eases administration with a new IIS Manage UI, delegated administration, and new tools for automating administrative tasks. Applications run more reliably as they are easier to troubleshoot with built in tracing and diagnostics. Finally, multiple servers can use a single configuration file with the shared configuration feature for web farms.

IIS7 Administration: The New IIS Manager

Brett Hill, IIS Sr. Technical Evangelist, Microsoft Corporation

IIS7 Administration centers around the new task-oriented IIS Manager. This redesigned administration tool has many major new capabilities including the ability to delegate features, edit .NET configuration and has significantly improved performance when managing many sites. The IIS Manager itself is an extensible, modular application that administrators can customize and developers can extend. In this presentation we’ll explore how use and control the IIS Manager with a special focus on Delegated Administration. In addition, we’ll explore how to use Granular Locking to fine tune your delegated settings beyond those available in the UI.

IIS7 Administration: Shared Configuration, Remote Control, and Automated Tools

Isaac Roybal, Product Manager, Windows Server, Microsoft Corporation

For web farms, IIS7 has a powerful new feature – Shared Configuration. This allows you to configure multiple servers to share a single configuration file. The benefits are clear - all web servers have identical configuration so there’s no need to do configuration replication.

In addition, IIS Manager has built in remote administration capabilities. Using https between the IIS Manager and the remote server, this feature includes the ability to define trusted users in IIS Manager and have identities securely stored in the IIS configuration, Windows SAM or AD, or a .NET provider.

Of course, many organizations need to automate administration tasks. APPCMD is the new powerful, general purpose command line utility for controlling configuration, state for site and pools, and querying status. WMI has been improved specifically for IIS management, and there’s a new managed code API Microsoft.Web.Adminsitrationis that makes it easy for developers use .NET to write IIS management tools. PowerShell can use the managed API or WMI, giving you a superior command line and scripting environment for managing your servers.

IIS 7 Security: Less Exposure, Greater Control

Brett Hill, IIS Sr. Technical Evangelist, Microsoft Corporation

IIS7 security improvements can be found in many areas. In addition to the ability to control the server footprint, security is improved with the new URLFiltering and URLAuthorization capabilities. Also, you can now use Forms authentication with any content while leveraging .NET role and membership providers. In addition, there are key changes in the user principles and groups used by IIS7 that will make the server both easier to manage and more secure. Finally, application pool sandboxing helps to improve the security boundary between application pools.

IIS 7 Troubleshooting: Failed Request Tracing

Isaac Roybal, Product Manager, Windows Server, Microsoft Corporation

One of the most exciting features in IIS 7 for administrators is the new built-in failed request tracing capabilities. You can configure IIS 7 to automatically create a detailed trace log of events that occurred in the request processing pipeline when specific error codes are seen and/or if a request takes more than N seconds to complete. This is configurable at the server, site, application, or file level, and can be configured in the UI or with a command line tool. The resulting trace log is ideal for identifying bottlenecks. Like everything in IIS 7, it is extensible and can be customized with new events.

Problems installing SQL Server 2005 on Vista and IIS7

bills — Tue, 04 Sep 2007 23:22:26 GMT

I've seen this issue pop up a few times so I thought I'd share a few quick tips / tricks to getting SQL Server 2005 to work on Vista.

If you see an error saying "Microsoft Internet Information Services (IIS) is either not installed or is disabled.", but you're sure you did in fact install IIS7, you are not alone. There are several required IIS components for SQL Server to install properly on Vista and if you don't have the complete set you will see this error. The following components are all required in order for SQL Server 2005 to install properly:

Component	Folder
Static Content	Common HTTP Features
Default Document	Common HTTP Features
HTTP Redirection	Common HTTP Features
Directory Browsing	Common HTTP Features
ASP.Net	Application Development
ISAPI Extension	Application Development
ISAPI Filters	Application Development
Windows Authentication	Security
IIS Metabase	Management Tools
IIS 6 WMI	Management Tools

fyi, there is an official KB on this issue now posted here: http://support.microsoft.com/kb/920201

The system cannot find the path specified

bills — Wed, 29 Aug 2007 00:33:48 GMT

I ran across this and thought I'd share in case anyone out there hits the same issue. If you see this error pop up in the IIS7 Administration tool (IIS Manager - inetmgr.exe) that looks like this:

The system cannot find the path specified. (Exception from HRESULT: 0x80070003)"

It may be caused by an invalid path, including using the "/" instead of the "\". When you enter physical paths in the IIS Administration tool, please remember to enter C:\path instead of C:/path or you will see this error.

One other tip when it comes to using physical file/dir paths on IIS7: don't forget you can now use environment variables!

%systemdrive%\path\foo is much better than C:\path\foo, because it is transportable across machines even where the system-drive is not the same. You may want to consider creating your own %webroot% variable on every machine, so you can easily tweak the physical location of your config/content without touching configuration.

IIS sets all physical paths using environment variables by default. Don't muck it up by using hard coded paths, you'll regret it later! ;)

Tip / Trick: how to turn off "verify file exists" in IIS7

bills — Fri, 25 May 2007 15:37:57 GMT

I've seen several posts asking the question: how do I turn off the "verify file exists" setting on handlers / script maps in IIS7. I must admit, this seems to not be as straightforward as it should be. Hopefully this post helps you out.

The configuration setting for this feature is stored in the <handlers> section for each handler mapping, and is known as the resourceType attribute. For example:

For the ASP script map, we set resourceType="File" by default, so that the ASP engine won't get invoked for requests that are not mapped to real files. If you want your handler to be invoked for requests, even if there is no file or directory behind the request, set the resourceType="Unspecified". The allowable values for resourceType are "File", "Directory", "Either", or "Unspecified".

You can set this value in the administration tool by doing the following:

Step 1 - double click on handler mapping in the <handlers> feature:

Step 2: uncheck checkbox to set the handler to 'unspecified':

hope this makes life a little easier. ;)

Tips for Classic ASP developers on IIS7

bills — Tue, 22 May 2007 00:11:00 GMT

I was reminded the other day just how many classic ASP applications and developers there are out there! The original ASP rocks, I remember experiencing it for the first time back in 1996/97 when it first came out with IIS3, and being amazed at how programmable it was compared to ColdFusion. I built many an application using Classic ASP, and there will always be a soft spot in my heart for it. :)

There are a few changes in IIS7 which Classic ASP developers should be aware of.

ASP not installed by default

First things first! If you're moving from XP to Windows Vista / Longhorn Server, you may be getting this error:

--------------------------------------------------------------------------------------------------------------------

HTTP Error 404.3 - Not Found

Description: The page you are requesting cannot be served because of the Multipurpose Internet Mail Extensions (MIME) map policy that is configured on the Web server. The page you requested has a file name extension that is not recognized, and is not allowed.

--------------------------------------------------------------------------------------------------------------------

this is usually the case when you haven't installed the ASP component. Go to where you installed IIS and look under IIS/WWW Services/Application Development/ASP and install it. :)

Access and Classic ASP

A lot of people use Access as a database - because it is small, can be copied around, and is easy to manage. One of the changes we made in IIS7 in Vista broke using ASP and Access by default. I described this change in more detail in this post, but essentially it has to do with the fact that Application Pools now use the Application Pool identity's profile and temporary directory, rather than \windows\temp by default. And since the only one that can write to Network Service's temp directory is the Network Service, anonymous or authenticated ASP applications break, since ASP uses the impersonated identity to access the database. If you use ASP and Access on IIS7, you've probably seen this error, or a variation of it:

--------------------------------------------------------------------------------------------------------------------

Microsoft JET Database Engine error '80004005'
Unspecified error

--------------------------------------------------------------------------------------------------------------------

The answer is pretty straight forward: turn off loadUserProfile, or ACL the temp directory to allow writes. As a result of this and other compatibility issues, we're considering reverting this change in Longhorn Server / Vista SP1. In the mean time, you can work around it by doing either of the following:

This appcmd command will turn off loadUserProfile for the Default Application Pool. if your application runs in a different AppPool, make the corresponding change:

%windir%\system32\inetsrv\appcmd set config /section:applicationPools /[name='DefaultAppPool'].processModel.loadUserProfile:false

This command will ACL the Network Service temp directory to allow creator write / read privledges. If you run your Application Pool under a different identity, you'll need to ACL that owner's temp directory:

icacls %windir%\serviceprofiles\networkservice\AppData\Local\Temp /grant Users:(CI)(S,WD,AD,X)

icacls %windir%\serviceprofiles\networkservice\AppData\Local\Temp /grant "CREATOR OWNER":(OI)(CI)(IO)(F)

**Update 2/19/2009** if you are having issues with Access and ASP you might want to read this terrific guide recently posted on IIS.NET: http://learn.iis.net/page.aspx/563/using-classic-asp-with-microsoft-access-databases-on-iis-70-and-iis-75/

Script errors no longer shown in browser by default

As a result of our security paranoia, we turned off ASP's default behavior of sending script errors (including line number and code snippet to the browser. So instead of seeing the typical error you would see ASP throw, you will now see this:

--------------------------------------------------------------------------------------------------------------------

An error occurred on the server when processing the URL. Please contact the system administrator

--------------------------------------------------------------------------------------------------------------------

To revert back to IIS6- behavior, simply run the following command:

%windir%\system32\inetsrv\appcmd set config -section:asp -scriptErrorSentToBrowser:true

Or you can find it in the UI here:

then you'll be back to seeing this style of error instead:

--------------------------------------------------------------------------------------------------------------------

Microsoft VBScript compilation error '800a03ea'

Syntax error

/test.asp, line 4

Response.Write("I love classic ASP" && foo)
-------------------------------------^

--------------------------------------------------------------------------------------------------------------------

Parents paths disabled by default (redux)

We disabled parent paths by default with IIS6, but I've seen this hit people on Vista coming from XP, where it is still enabled by default in IIS5.1 The enableParentPaths setting determines where ASP "includes" should be allowed to escape the parent directory (eg. ../../../includeFile.inc). You'll see this error by default if you try to escape the current directory:

--------------------------------------------------------------------------------------------------------------------

Active Server Pages error 'ASP 0131'

Disallowed Parent Path

/test.asp, line 1

The Include file '../bad.inc' cannot contain '..' to indicate the parent directory.

--------------------------------------------------------------------------------------------------------------------

or you may see this error if you are using a path with ../ in it and your ADODB code

--------------------------------------------------------------------------------------------------------------------

Server.MapPath() error 'ASP 0175 : 80004005'

Disallowed Path Characters

/testdir/test.asp, line 9

The '..' characters are not allowed in the Path parameter for the MapPath method.

--------------------------------------------------------------------------------------------------------------------

To revert back to IIS 5.x behavior, simply run the following command:

%windir%\system32\inetsrv\appcmd set config -section:asp -enableParentPaths:true

or you can find the UI setting here:

APPL_PHYSICAL_PATH no longer returns "\" with path

If you use Request.ServerVariables("APPL_PHYSICAL_PATH") to get at the physical path for your application, you may notice that the physical path no longer returns with a trailing slash. In previous releases of IIS, we returned this value as stored in the metabase. In IIS7, we calculate this value based on the configuration store, and we never return a trailing slash. You'll need to account for this especially if you are the return value with some other part of the path in your application.

Session_OnEnd not firing

If you find that Session_onEnd event in your global.asa is not firing, check out this blog post from Lou on the issue and the fix.

Summary

I browsed through the IIS7 Classic ASP Forums, and these tips seemed to cover nearly all of the issues people were having. if you are having a problem with ASP on IIS7, check out the forums or leave a comment for me here. If I find the answer, I'll add it to this post! Thanks!

Where do I go for IIS Support?

bills — Tue, 07 Nov 2006 05:03:00 GMT

This is a question that I'm surprised doesn't come up more often. I guess, like many of you, I take pride in figuring things out on my own. I hate asking for help and admitting I don't know the answer. And we've all had the unfortunate experience of calling a support line for help and getting someone who we just *know* is even more clueless than we are. :)

The IIS Forums are a great place to start - many members of the product team hang out there, and our top-notch MVPs. But when you just can't find an answer on your own, remember that your time is valuable, and probably worth a lot more than the few hundred bucks you'd spend letting Microsoft research the issue and figure it out. So the next time you get stuck on a problem, don't hesitate to pick up the phone and give the Microsoft IIS support team a call. Here are a few tips that may be helpful:

Who is the IIS support team?

The IIS support team rocks! We are lucky enough to have a support engineer sit directly in our offices as a liaison to help escalate issues - from both sides - and communicate our ongoing development to our support team. In addition, I have the opportunity to sit down with the support leadership team once every quarter to review support trends, hot issues, and customer satisfaction. Every time we meet I'm impressed with how smart and serious they are and how much they care that you are happy with the product. They definitely watch the stats carefully, and they are constantly championing for you to get things fixed in the product so that someday, if we do our jobs perfectly, you'll never have to call support. Too bad we're not perfect. :)

The IIS support team is filled with engineers who are dedicated to help you research the problem and do whatever it takes to find the resolution. Not convinced? Read this blog entry by Doug Hughes about his support experience. PSS engineer Rohan stuck with it until the case was solved. From the comments on the blog, it appears he isn't alone in enjoying great results from the IIS support team.

Where do I call for IIS support and how much does it cost?

If you work for a large business, chances are that you already have a support contract in place with Microsoft. If you aren't sure, ask your IT manager. If a support contract exists, there is an existing way for your company to work with our support team under the agreements of the contract.

If you don't have a support contract, you can just as easily reach our support team directly. Check out this Web page for more information on support options, including information on email support as well as phone support. Email support starts out at $99.00 per request (with 1 business day response time). You may also call support during business hours for $245 per request or $490 per request for business-critical after-hours support. It doesn't take much of your time lost trying to find a solution on your own for this to pay for itself!

How long will it take to solve my problem?

How long it takes to solve your problem depends on a lot of different factors including the nature of the problem itself. Hangs and intermittent performance problems can sometimes be the hardest to reproduce and solve. The type of applications and third party products installed also make a difference. It is more difficult to troubleshoot applications where third party products are involved, but our support team will work with you - and the vendor if their component is installed - to pinpoint the issue. Since the IIS support team makes it their business to provide support, they have a huge database of issues they can comb through to find resolutions rapidly - in some cases on the first call you make. Other times, especially with problems that are more complicated or hard to reproduce, it may be necessary for you to gather more diagnostics data (which they will help walk you through how to do) and iterate on the problem with them over several days. No matter the length of time it takes, one thing is for sure: you will get an answer.

What do I do if I'm not satisfied with the support I'm receiving?

Tell us! If you're not happy with the support you are receiving, or with the resolution once your support case is over, please let us know so that we can continue to improve. On your first contact with an IIS support engineer, you'll receive an email with their contact information, and the contact information for their manager. If at any time during the support process, or after, you aren't satisfied, be sure to use that contact information to give us feedback. The sooner you give us feedback, the better we will be able to respond to your needs and make sure you get a satisfactory answer.

hope this helps -

bill

Improving Custom Errors for IIS7 Server

bills — Fri, 20 Oct 2006 05:41:00 GMT

Another one of my favorite features is the IIS7 Detailed Errors feature. Thomas wrote a great article titled Understanding Custom and Detailed Errors which provides a good overview of this simple, yet powerful feature. (though it needs to be updated for RC1+)

In using IIS7 the past two years, while it has been under development, I can honestly say that Detailed Errors are the single biggest help in making IIS easier to use. If you haven't read Thomas' article yet, let me summarize how Detailed Errors works:

By default IIS now returns two kinds of errors when a problem occurs. The first kind you are used to if you've used IIS before. They are our standard custom errors, which a terse error description and error code. If you don't like how our custom errors look, you can always configure IIS to return your own custom error message and away you go. The second kind of error we now call "Detailed Error" which, by default, we only return to requests from localhost. You can also configure IIS to return detailed errors all the time (if you want the application in debug mode) or to never return detailed errors - always return custom errors (if you get annoyed by our debug information).

Here is a screenshot of the administration UI for this feature, which is pretty straightforward:

Error Pages UI (click for full size image)

Note: the schema for this feature changed slightly between Beta 2 and RC1. The config section for this feature is <httpErrors> and the errorMode attribute descripes which behavior to use on the server. Here is the relevant schema:

The detailed error information we return is pretty darn helpful. It includes a bunch of details about the request, like which pipeline notification the error occured during, which module and / or handler threw the error, the physical path which was processed for the request, the logon user and method (if available), and more goodies. Even better than that, we do our best to provide possible causes that lead to the error, based on the error code, sub-error code, and win32 hresult returned from the offending party. And even better, we also try to give you some help in terms of next steps you should take to resolve the problem. And last, if those don't work, we also provide a "more information" link which hooks up to our error database (not yet online) which will return the latest troubleshooting instructions we have for the particular error you've encountered! Now that is cool. Here is a sample of one particular error that I end up running into from time to time, when I type too fast and end up with invalid XML in my web.config file. Notice how it even tells me where the XML problem occured:

Server 500 Error - Vista Edition (click for full size image)

And so this is how detailed errors works, and what you can expect in Vista. One of the bits of polish we're working on for IIS7 in Longhorn Server (and will also most likely get updated in SP1 of vista) is a cleaner look for the error pages to make them easier to read. I wanted to provide a preview of the current mock-ups and ask for your feedback. What do you think, are they an improvement? What would you do different?

The same Server 500 Error - Draft for Longhorn Server Edition (click for full size image)

Here is another example of a Server 401 error. Note the "most likely cause" and "things to try" sections:

Server 401.1 Error - Draft for Longhorn Server Edition (click for full size image)

So what do you think? Are these an improvement? Leave your comments below.

Making Failed Request Tracing More Approachable

bills — Thu, 19 Oct 2006 07:06:00 GMT

One of my favorite IIS7 features is something we call "FREB", which originally stood for "Failed Request Event Buffering". We've given it a more friedly name now: 'failed request tracing', but everyone around here still calls it freb. It is a really awesome feature that essentially allows you to configure IIS to "watch for" certain error coditions and provide you detailed trace information about the request. This makes it much easier to diagnose failures than in past versions of IIS, especially those hard to repro issues that seem to only happen at 3am when you should be sleeping. IIS will not only log all of the IIS trace events we've sprinkled through our code, but ASP.NET trace events, and even your own page trace events! It is one powerful feature.

Do you see requests "slow down" over time, or "hang"? Simply configure IIS to watch out for requests that exceed a given timeout threshold and you'll get detailed information on everything that happened during the request up to the time limit. Using that info, you should be able to better pinpoint where the hang-up is happening.

Are you seeing random 401, 404 or Server 500 errors? IIS is infamous for returning these standard error messages for lots of different reasons. With IIS7, detailed errors provide much more information to you if you're on localhost, but if you want to know which component returned the error, or what happened in sequence before the error, FREB is the way to do it.

For more information on how to use FREB, see this article titled Using Failed Request Tracing on IIS.net.

In Vista, all of the FREB logs are stored, by default, to \inetpub\logs\FailedReqLogFiles\w3svcn where n is the site ID for each site. In this directory, you'll find an XML log file for each freb log that was generated when a failure rule was met. You'll also see a freb.xsl file which Jaro, one of our stud developers built early on which makes the trace data much easier to read than in notepad:

Yuck! who wants to read the trace data in raw XML (full size image)

The default XSL view of the freb file which ships in Vista (full size image)

Today Eric - the PM owner for this feature - announced a new XSL that takes consuming this information to the next level. We brought back our iis.net designer, Kevin Goldman, to help us design an even friendlier XSL. Here is a screen shot of the new XSL:

The new XSL home page view of FREB log(full size image)

One of the things you'll notice right away with the new XSL is that it segments the information a little more and provides navigation tabs at the top to help you filter the data. By default, you see the Request Summary tab, which shows basic information about the request, and all error and warning events that were found in the trace log. This is a great way to zero in on which event may have caught your error. By clicking on "view trace" you can actually "zoom" in to the entire heirarchy of events that occured - in order - during the request, and see the event you clicked on in context. Of course, you can also click the +|- links to expand and contract additional details.

If you click on the "Request Details" tab, you'll get see this view:

The new Request Details page(full size image)

The request details page - Complete Request Trace (default view) - provides a view of all the events in the log file, in heirarchical order with elapsed time for each event.

The other "tabs" under Request Details provide additional filters for the FREB file. For example, if you want to see just events that are associated with ISAPI filter notifications, click on the "Filter Notifications" tab. If you want to see all events related to modules that were executed in the request, click on "Module Notifications", and you'll see this view:

The new Module Notifications page(full size image)

Eric describes all of the tabs in more detail in his forum post.

You can download the XSL here and start using it with Vista today! Please be sure to leave any feedback in the forum thread Eric started, we'd definitely love to hear if you like it, and what is still missing.

enjoy -

Bill

loadUserProfile and IIS7 - understanding temporary directory failures

bills — Wed, 18 Oct 2006 15:47:00 GMT

I've noticed quite a few people running into temporary directory permission issues. The PHP blog post I made last month is one example of this issue, there are also several forum posts related to ASP & Access database failures, where the reported failure is:

Microsoft JET Database Engine error '80004005'
Unspecified error

Not a very helpful error, to be sure. It turns out all of these cases have a similar underlying cause: the effective user of the web application (including the anonymous user for unauthenticated requests) can not effectively write to the temporary directory. What changed in IIS7 and why did this always work before?

With IIS6, all worker processes, regardless of which the process identity was configured, used to C:\windows\temp as the temporary directory. More specifically, none of the worker processes loaded their 'user profile' by default, causing all of them to use c:\windows\temp as a temporary directory. Windows allows all users read/write/creator privledges on this directory, which allowed things to 'just work'. The negative side effect of this is that all AppPools are effectively sharing the same temporary directory by default, which could lead to cross-appPool information disclosure.

With IIS7, we've chosen a more secure default and now load user profile by default for all application pools. Unfortunately, the temporary directory underneath the user directory (for example - %windir%\serviceprofiles\networkservice\AppData\Local\Temp for the default NetworkService identity we use for DefaultAppPool) is not writable by anyone other than NetworkService by default.

There are two ways to workaround this. First, I recommend that ACL the NetworkService temporary directory to allow whichever users read/write/creator privs that you want to allow access so that you still have the benefits of loading a user profile and separating temp directories per appPool. This can easily be done on the command line like this:

icacls %windir%\serviceprofiles\networkservice\AppData\Local\Temp /grant Users:(CI)(S,WD,AD,X)

icacls %windir%\serviceprofiles\networkservice\AppData\Local\Temp /grant "CREATOR OWNER":(OI)(CI)(IO)(F)

This allows every user to create files and directories (WD = Write to Directory, AD = Add Directory, X = Execute, S = Synchronize). The user who creates them will be the “CREATOR OWNER” of the file/directory.

The “CREATOR OWNER” ACE allows this user to do whatever he wants with the file. Other users can’t access these files/directories because they are not “CREATOR OWNER” of them.

The other less favorable workaround is to disable the loadUserProfile setting on a per-appPool basis. loadUserProfile is a boolean property on an AppPool section, and can easily be set on the command line (for defaultAppPool) like this:

%windir%\system32\inetsrv\appcmd set config -section:applicationPools /[name='DefaultAppPool'].processModel.loadUserProfile:false

hope this helps -

bill