I just set up a new site in IIS on an existing server that's running the main production site for that app. I've done the wsconfig thing, and I can get to the login page, but there's a crash after that, whose details I can't see. There's only the generic IIS error message. Normally in a case like this, I'd temporarily set IIS to show detailed errors for local requests only, and use a browser directly on the server to debug this. However, this site is a subdomain of the main one, and I'm not clear how to make a "local" request in that case. In other words, this site is https://foo.mysite.com. If I'm on the actual web server machine, what constitutes a local request to that site?

rings a bell - can you map the hosts file to point that domain locally on the machine instead of the public ip?

Is the error logged in C:\Windows\System32\LogFiles\HTTPERR ?

@cfsimplicity nope, doesn't show in there. the subdomain name is found, or 500.

127.0.0.1 <http://sub.site.com|sub.site.com>

i would have thought

I'll give it a shot, but my quite possibly ignorant gut reaction is that that doesn't make sense, the subdomain has to come before the domain. I tried a similar thing I thought might work, but it didn't, foo.127.0.0.1.

The IP address and the domain are different things. And there is nothing saying that the domain and the subdomain need to have different IP addresses. The hosts file starts each line with an IP address, and then lists all the hostnames that map to that IP address. So

127.0.0.1 localhost <http://sub.domain.com|sub.domain.com>

<http://domain.com|domain.com>

<http://otherSub.domain.com|otherSub.domain.com>

would be a perfectly valid entry.

@Tim Do you think that with that hosts entry, a request to

<http://sub.domain.com|sub.domain.com>

would appear to IIS as local?

I don't know for sure, but I think it wouldn't actually care either way. The IIS logs include the requester's ip address, and I think it'll recognize anything from any of the server's ip addresses as "local."

Didn't work, still getting the generic IIS error pg.

😟

mmm

I'm outside my knowledge now, but maybe a route tracer would help figure out why it's not recognizing it as local?

Weirdly, error handling in the app (not IIS) suddenly started sending the emails we expect from errors, so I see what's wrong (nothing to do w cf hookup, caused by an out of date db). That seems to mean IIS started treating those requests like it should have in the first place, I'm not sure why. Which I hate, but I've got stuff to do, so working now is better than not.