Archive for the ‘IIS7’ Tag

IIS7 and UNC-based virtual directories.   2 comments

Today threw up another one of those wonder “if you say so” type errors. This time, it was with IIS7 on Windows Server 2008 SP2 (not R2, in this case). If you want to skip the story, head to the end for some tips on troubleshooting the issue (keep in mind though that this is for a specific issue, mainly revolving around apparent access denied and server HTTP 500.19 errors).
 
We house our intranet photos on the server that also houses related data, and one of our team is in the process of drumming up a new web application that he wanted to use the photos in. This led to the fairly common scenario of wanting to create a virtual folder on his web server that pointed to the JPEGs on the external server.
 
Now, in the days of IIS6, this was both simple and intuitive, but woe unto me for trying to get this going in a hurry on IIS7! Strictly speaking, the resolution is very few steps, but as per usual, I was trying to jump into something feet first without having kept myself up to date with yet another component’s changes. As a refresher, under IIS6, all one had to do was create the new virtual directory and utilise the “connect as” and voila, you were done. The “tricksy” (just watched Lord of the Rings yesterday, and I had to find a reason to use that word!) nature of this task in IIS7 is the UI looks pretty much the same. However, I ran into half a days worth of dramas while I tried to work through what the issue was.
 
As part of the diagnostic process, I quickly established via the Security event log that for whatever reason, IIS7 was trying to verify this “connect as” account existed locally before using it to connect with the foreign system. This was borne out by the fact that there were no entries in that servers event log – not even anonymous ones. That problem was taken care of inside of the first five minutes of looking at this issue by simply creating a local account with the same username and credentials. Okay, but we still didn’t have liftoff, Captain. Why not?!
 
At this point, I was still getting a lot of errors, and they all seemed to get back to the good old “Access Denied” root cause, which of course I didn’t buy because I had verified with a net use command that access wasn’t in fact the issue. At least, it wasn’t an issue with the “connect as” account, and a quick scan of the foreign Security event log confirmed that the computer account – for whatever reason, was trying to authenticate with this foreign machine. That was never going to happen, since the foreign machine is a workgroup machine, unlike the IIS7 server which is domain joined. The error indicated was HTTP error 500.19.
 
Naturally, I decided that was an oversight on my part and headed straight to the Authentication applet to enable Windows authentication, except I couldn’t get into the applet. After double clicking it, the status column remained stuck on something to the effect of “refreshing”, much to my annoyance, and trying to open any option was bringing up a new error that the web.config file couldn’t be found. Suffice to say I was a little bewildered. A web.config for a virtual directory? I don’t think so, Tim.
 
So, jumping to the end of this chain of events, I ended up deleting the virtual directory, going back to the site root and enabling Windows Authentication at that level, then recreating the virtual directory, and lo and behold, it worked exactly as it should of from the outset!
 
 
So, in point form, here’s what I found to be different from IIS6:
  • Connect As account needs to exist locally on the IIS7 server if both the IIS7 server and the foreign host do not live in the same domain (or forest, if you want to expand into larger topologies).
  • You may need to enable one of the additional authentication mechanisms before you create the virtual directory to avoid the 500.19 errors the server will throw if it’s trying to track down the web.config file. Personally, I used the Windows Authentication option, but I suspect the others would have their uses depending on what you’re hosting your content on.
  • When filling out the Connect As window, do NOT use the local hostname in front of the account name, as that creates a disassociation between the local version of the Connect As account and the foreign system’s version. This is one point you should pay extra attention to, as I read a number of articles suggesting you should in fact use the hostname. As I said already, do NOT do this under IIS7. So, to use an example, you want to use “JohnDoe” as the username, and not “hostname\JohnDoe”.

Anyway, as I say, the change itself is just as quick to make as it ever was, there’s just a few things to watch out for in terms of new configuration traps.

Cheers,
Lain

Posted February 9, 2010 by Lain Robertson in Windows Server 2008

Tagged with , , , ,