Couple IIS7 gotchas running ASP.NET Apps

March 21, 2006 @ 2:15 pm

I've had a little time today playing around with IIS 7 on Vista, and there are a couple of problems that took some time to get around to get an application to run. If you're trying out IIS with your ASP.NET applications this might help you.

The default installation sets up AppPools under NETWORK SERVICE, but NETWORK SERVICE is not added the Temporary ASP.NET directory in the .NET framework path. This causes ASP.NET to fail out right complaining that an invalid directory name is used.

Actually this may not be the whole of it as I tried adding NETWORK SERVICE to the permission set and adding it file full access rights. Still doesn't work. Ultimately I had to change the AppPool to run under Local System and then the app started running.

I'm not sure what else could be the problem with NETWORK SERVICE, but it works with SYSTEM. Obviously this is not a secure solution but it works for now. In any case the default installation apparently doesn't have enough permissions to run ASP.NET apps (much like .NET 1.0 did).

It looks like the ASP.NET State Service is nowhere to be found. I installed IIS using default options, but no state service. I went back to Windows Component to install under IIS but I see nothing that explicitly installs this service.

At this point I had to switch back to InProc, which is fine for testing.

It's taken a few false starts to get even this far. At this point I have several apps running both in ISAPI pipeline (IIS 6 mode) or in the integrated pipeline (IIS 7 mode) and the 3 apps I threw at it were running fine. In addition I also installed a Web Connection ISAPI application on the server and that ran fine as well at least in ISAPI mode. However, in either of these cases the configuration applications did not work as it looks like ADSI configuration is either not there at all or disabled in this build.

Now I can actually play around with the new features of the integrated pipeline. The most interesting thing to me at least is the low level HTTP Module integration that allows .NET components to handle all traffic directed at the server. There are a couple of interesting things I want to try including throwing Web Connection into this area and replacing the truly hideous ISAPI/COM code that drives that particular engine.

One of the more visual changes for IIS 7 is the new management tool which replaces the MMC interface. I was looking forward to this, because as far as I'm concerned the MMC has produced nothing but horrible interfaces. The new management tool looks a lot nicer and more importantly is a lot more snappy.

Unfortunately it's a mess to use at this point. The interface is horribly busy and there are way too many options the various pages with names that are not real clear. The console mixes both IIS and ASP.NET settings which I think is part of the reason for this confusing interface as there are terminology overlaps. While there are grouping options it seems that you end up hunting around a lot for finding the right options. As bad as the IIS 6/5 MMMC interfaces were, the way they grouped the various choices together seemed reasonably logical and well organized and you get to most places with a couple of clicks.

Here the choices seem scattered about in inconsistent ways in many places. One good example, is the basic properties dialog which is not accessible through the main list but sits of on the side and context menu only. But these options are accessible only in the top level view, not when you're furtherdown.

I'm sure it's not easy to build an interface for this many options, but I think what's really needed is much better grouping of options. Some high level overview that has a manageable number of options on it into which you can drill down later.

Feedback for this Weblog Entry

# re: Couple IIS7 gotchas running ASP.NET Apps
by dominick March 21, 2006 @ 7:09 pm

hey rick - here is your security conciousness :)

don't run as local system :))

try this:

create this directory (make sure NETWORK SERVICE has modify ACLs)

\Windows\ServiceProfiles\NetworkService\AppData\Local\temp\

and set the AppPool back to Network Service.

dominick

# re: Couple IIS7 gotchas running ASP.NET Apps
by Bill Staples March 22, 2006 @ 2:29 pm

Hey Rick - thanks for checking IIS7 out!

Looks like you hit the dreaded temp directory bug, which dominick cleverly pointed out. Needless to say, that bug is already fixed in current builds.

As is the State Service dissapearance.

To get ADSI working, you'll need to install the "IIS 6 Management Capability Feature" under Internet Information Services->Web Management Tools setup component. This is where the metabase, ADSI and WMI providers, as well as scripts (like adsutil) can be found if you want to use the legacy configuration interfaces. They should work just fine once installed - let us know.

We've also done quite a few last Beta 2 usability tweaks to the UI, to improve usability, but I think you're right that the new admin tool takes some getting used to, since it is quite different than what we had in IIS 4 and 5 and 6. One trick I use to find a feature in that list is to type the feature name. By clicking in the feature list, then typing the feature name, you'll find the selection quickly follows your typing to land on the particular feature you're after. You can also use the filter UI above the feature list to drill into a particular area of features. We've tried literally dozens of categorization schemes to re-organize these properties, and we may not still have it right (but we are getting better!). Any feedback or ideas you have on what would help, are appreciated! thanks!

Bill Staples

# re: Couple IIS7 gotchas running ASP.NET Apps
by Rick Strahl March 23, 2006 @ 11:16 am

Bill,

Re: ADSI - ah that's a bit of a bummer - if this stuff isn't on by default it's kind of a problem for customers to configure legacy applications that need to install into IIS. Is the plan to leave this off by default? I hope not.

Also, during one of the IIS7 previews I remember hearing that ADSI support won't be upgraded to support new server features, so it's basically for legacy functionality. Is this still the case? Everything new should move the new WMI provider and or generating/modifying .Config files in some other way I assume?

This won't be a big problem for new installations, but I am concerned for backwards compatibility.

As for the UI, I hear 'ya. As I said there are a lot of options and at some point there's going to have be some decision on how to lay it out.

My personal feeling is that the 5308 layout is way too busy on the top level view. I really think that the first thing you see should be a view that shows may 10 or so (whatever fits into a typical layout) icons that provide the high level groups to look at.

I guess it's like everything - eventually you'll get used to whatever <s>...

# re: Couple IIS7 gotchas running ASP.NET Apps
by bill March 26, 2006 @ 8:17 pm

Yep, we plan to leave ADSI (along with the metabase and other legacy configuration interfaces) off by default with IIS7. Our goal is to continue our philosophy of minimal surface area by default. The thinking is you can install just the components you want / need for your server, and not worry about the rest. The big benefit is: if you don't install it, you don't have to worry about patching it if a patch is released. And you don't have to worry about hackers attacking it, if you never install it. On the other hand, if you do want a particular component like ADSI, it's just a click away. We feel pretty strongly that this small, one-time inconvenience to get the right components installed is far outweighed by the benefits down the road in terms of servicing / patching. Another reason metabase / ADSI don't make sense to install by default is that while many apps may use them today, we don't expect that to be the case in 2-3 years as apps move to our new APIs written for our new configuration store. IIS7 is going to be around for 10 years, so we're planning for the long haul. Hope this makes sense.

One note: the two lists at the top of the feature list can be used to filter the list down to the areas you care about. You might try using the filters to see if that gets you an easier to parse list of stuff to work on.

thanks!

# re: Couple IIS7 gotchas running ASP.NET Apps
by Rick Strahl March 27, 2006 @ 10:32 am

Yeah I understand. It's just that at the get go there'll be a fair amount of legacy applications out there that all install relying on ADSI, which will now fail by default. But as you say - it can be turned on and just a manual step that will have to be introduced.

The filters are Ok, but I couldn't find a comfortable view using the filters. Part of it is just the fact that the IIS and ASP.NET featuers are mixed together and that there ends up being a lot more functionality exposed then there was before a lot of it overlapping.

I suppose I'll need to get over the mindset of ASP.NET and IIS settings as separate <g>, but it still does matter in terms of Developer vs. Administrator settings.

# DotNetSlackers: Couple IIS7 gotchas running ASP.NET Apps
by DotNetSlackers Latest ASP.NET News May 24, 2007 @ 10:23 pm

# re: Couple IIS7 gotchas running ASP.NET Apps
by Jim Hollender April 10, 2008 @ 9:39 am

In my job I am responsible for creating Install Kits, some of which are web applications, so I need to be able to use the default tools to create the virtual diretories, applications & other related items that make up a web application.

From what I can tell, appcmd.exe is what should be used ... but there is no good documentation on command. It would be really nice if there were a source of appcmd examples for each and every one of those things you can perform with the GUI IIS Manager.

Also, there needs to be a definitive source of information on what changes between IIS6 and IIS7 to make the conversion a heck of a lot easier than it currently is. If you do one thing for IIS, how do you do it in IIS7 ... and then how to do it with appcmd.

I am also finding inconsistencies with appcmd where spaces are handled different depending on which feature you are making changes to.

Please point me to some WORTHWHILE documentation. Right now it is too scattered & definitely incomplete.