nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

[Simple] ASP virtualization question

Adam Stoller

(I confess, I'm ASP-challenged ;-)
I know about TechArticle 49749 ("Requirements for Configuring ASPX File Virtualization for the .NET (dot net) Framework") - what I don't know is if simple ASP pages like the below require the same amount of configuration or something less (and what?) in order to be properly virtualized/visualized within TeamSite.

Sample code:[html]
Testing ASP

<% response.write("my first ASP script") %>

[/html]On my customer's server (TS672SP1 on W2K3 SP2) - if I put this page in the IIS docroot - it is viewable, however if I try to access (preview) it within TeamSite I get a 500 error.

IIS is configured to:

.Interestingly enough, on my own W2K3 instance with the above configuration (+ allow "ASP.NET v2.0.50727") - I get a 404 error trying to view the page in the docroot - but at this time I'm far less concerned about my own dev environment.

Find more posts tagged with

Comments

vpatel

Just to rule out some of the possibilities: you are able to "preview" other (i.e. .html) files from TeamSite properly correct? If no, then your site setup in IIS maybe messed up. Please confirm this.

Adam Stoller

Sorry - I should have mentioned that - yes, on my customer's servers, viewing standard HTML, image files, etc. works just fine - just foo.asp pages (like the one shown in my initial post) generate 500 errors.

(I actually haven't tried viewing HTML files on my dev machine yet, it's been in the midst of a major overhaul trying to get SP/LS properly configured - but that's a completely different matter, not for this thread)

dazzlad

[/html]On my customer's server (TS672SP1 on W2K3 SP2) - if I put this page in the IIS docroot - it is viewable, however if I try to access (preview) it within TeamSite I get a 500 error.
.

What is the full detail of the 500 error?
- IE shows a "friendly http message" by default, but this can be disabled.

Adam Stoller

What is the full detail of the 500 error?
- IE shows a "friendly http message" by default, but this can be disabled.

Hmm - well now I'm on site - it looks like I can't even get to the ASP page on the local server docroot.

On the docroot test.asp page, it's giving me:[indent]The page cannot be displayed
There is a problem with the page you are trying to reach and cannot be displayed.

Please try the following:

) with any file that ends with .asp - even if there is no ASP code within the file (e.g.: straight HTML).Now I'm pretty sure there's something really simple and stupid that I'm missing, but I can't seem to find it.

vpatel

Is this a new install or upgrade or something? Or one day it stopped working (without an upgrade or anything)?

In any case it seems like you may have to re-create the "default web site" in IIS. Usually that solves the problem.

Also make sure the account used for binding has valid user account / password (with "password never expire" set).

Adam Stoller

Is this a new install or upgrade or something? Or one day it stopped working (without an upgrade or anything)?

In any case it seems like you may have to re-create the "default web site" in IIS. Usually that solves the problem.

Also make sure the account used for binding has valid user account / password (with "password never expire" set).

Sorry - I'm forgetting myself as obviously I know the context in which I'm operating.

I am in the process of upgrading my customer from TS 552 on W2K to TS 672SP1 on W2K3 SP2 - the "upgrade" is via a fresh install on new server hardware.

So - no, this never worked on this particular server before (but ASP does virtualize within TeamSite on the old 552 server).

I suppose I could re-create the Default Web Site from scratch, but I'm not sure that will do anything - and the TSIMP_* account was created as part of the installation process and correctly has "Password never expires" on it, and is a member of the "TeamSite Web Preview" group. Whatever password it has was generated during the TeamSite post-install process programmatically - I haven't tried resetting it.

Would the TSIMP_* account have anything to do with being able to "browse" ASP pages in the IIS docroot (c:\inetpub\wwwroot)?

At this point I'd almost be happy to get ASP working from the docroot again - since I have no idea what changed since last week to break it (I don't think anyone was touching the server over the weekend, and I'm pretty sure I wasn't hallucinating it working last week - though... ;-)

ISCBorisB

Do you have any w3svc Error Messages in the System or Application event logs?

Jamik

well, typically TSIMP_* is the account that is set up to be used for anonymous access in IIS and I know on several occasions I've had to reset the password for that account and then update the password in IIS just to get preview working again. Have you tried this already?

Adam Stoller

Do you have any w3svc Error Messages in the System or Application event logs?

No errors from w3svc in any of the Event Viewer logs

Adam Stoller

well, typically TSIMP_* is the account that is set up to be used for anonymous access in IIS and I know on several occasions I've had to reset the password for that account and then update the password in IIS just to get preview working again. Have you tried this already?

I just did this - because I knew if I didn't it would be an "unknown variable" in the problem - it had no effect.

Via the IIS Admin console I can "browse":

which was already done, and doesn't seem to be sufficient.

Adam Stoller

Geeze this is frustrating. I made no progress with this while on site.
So now I'm working on my personal Dev box - which is essentially the same environment (W2K3 SP2 / IIS 6 / TS672SP1)

However, while on the customer server I get a 500 error, on my personal DEV server I'm getting a 404 error.

I re-read the KB 49749 and followed the steps - especially the part regarding the work-around fix for W2K3 dealing with a bug 57146 (somehow I missed this when I first read it).

This appears to have fixed the problem on my local DEV box - tomorrow morning I'll try this same approach on the customer's box - with any luck it will work too (there just might be a light at the end of the tunnel...)

Adam Stoller

Geeze this is frustrating. I made no progress with this while on site.
So now I'm working on my personal Dev box - which is essentially the same environment (W2K3 SP2 / IIS 6 / TS672SP1)

However, while on the customer server I get a 500 error, on my personal DEV server I'm getting a 404 error.

I re-read the KB 49749 and followed the steps - especially the part regarding the work-around fix for W2K3 dealing with a bug 57146 (somehow I missed this when I first read it).

This appears to have fixed the problem on my local DEV box - tomorrow morning I'll try this same approach on the customer's box - with any luck it will work too (there just might be a light at the end of the tunnel...)

On my customer's server I followed the W2K3-fix part of the KB article (and re-configured the IISAPI filter) and everything seems to be working now - Yay!