(non-DCR) Preview issues (671SP1+patch - Windows)

One thing to do with Firefox

In your browser type

about:config

scroll down to:

network.negotiate-auth.trusted-uris

edit that and set it to all the possible names for your server (comma separated) , server,server.mydomain.co.com,1.2.3.45

restart FF

Plus I have TSIMP as the anonymous user for both default web site and iwmount.

Both have only integrated windows login checked and anonymous

just a shot in the dark..

but what does iwproxy in debug mode report.. since the request does pass thru the iwproxy (I remember when trying to debug my cannot preview issue, and would see the requests going thru).. that should report some header/request info.. so maybe you can see what its actually trying to request..

another thought is a cross-domain issue.. like (http://ts-server.do.main vs. http://ts-server) not sure if your post showed it using both of them.. which maybe TS is getting confused for some reason, like its not fully qualified in some config, but is in others..

Another thought is what happens if you remove the preview (tmp) file after the first preview.. where it usually would work the 2nd time.. maybe it can't get to the file (for permissions or some other reason) and the prompt is more like from an odd 404/403 redirect or something wierd like that.. ..

One thing to do with Firefox

In your browser type

about:config

scroll down to:

network.negotiate-auth.trusted-uris

edit that and set it to all the possible names for your server (comma separated) , server,server.mydomain.co.com,1.2.3.45

restart FF

Didn't seem to have any effect one way or the other.

just a shot in the dark..

Another thought is what happens if you remove the preview (tmp) file after the first preview.. where it usually would work the 2nd time.. maybe it can't get to the file (for permissions or some other reason) and the prompt is more like from an odd 404/403 redirect or something wierd like that.. ..

Adam said non-DCR so that *should* not be an issue.

How does IIS itself behave ? If you browse through port 81 and click on a file ? Are you using any special proxy settings ? I think you said no. Change your links to relative links (if they are not already) that should bypass iwproxy

Plus I have TSIMP as the anonymous user for both default web site and iwmount.

Both have only integrated windows login checked and anonymous

That's what I seem to have here - which I thought was right.

That's what I seem to have here - which I thought was right.

Can you check the status of the TSIMP account ? I have seen it get locked because of screwed up security policies

just a shot in the dark..

but what does iwproxy in debug mode report.. since the request does pass thru the iwproxy (I remember when trying to debug my cannot preview issue, and would see the requests going thru).. that should report some header/request info.. so maybe you can see what its actually trying to request..

This might hold some promise in that a quick run showed different results in the log output for a single success and single failue attempt - but there's so much text to parse through and - ultimately - they should be identical because it's the same page ... however, I'm not sure that this isn't a red-herring as I'm not sure that the preview request for two successful previews is going to be identical... I'll have to try doing this a number of times and see if I can get two (or more) successful dumps and two (or more) unsuccessful dumps to really compare them.

The one thing I noticed off the bat between the 1 & 1 dump was that the IWPROXY_PATHTRACK was different from the get go (a different JPG file being used) - but again, this might just be "normal random behavior".

another thought is a cross-domain issue.. like (http://ts-server.do.main vs. http://ts-server) not sure if your post showed it using both of them.. which maybe TS is getting confused for some reason, like its not fully qualified in some config, but is in others..

I don't think this applies. If I was working on two TS servers and one worked and the other didn't, this would probably be more applicable - but I'm working on one TS server and so the same iw.cfg settings are being used both when it works and when it doesn't. (feel free to try to convince me otherwise if you really think this could be the source of the problems)

Another thought is what happens if you remove the preview (tmp) file after the first preview.. where it usually would work the 2nd time.. maybe it can't get to the file (for permissions or some other reason) and the prompt is more like from an odd 404/403 redirect or something wierd like that.. ..

I don't believe this applies - I'm not talking about previewing a DCR which causes a generation of HTML into a temporary file (zz_tst_*) - I'm talking about clicking on the HTML file within the TS GUI to preview the HTML content itself - for which I do not believe there are any temporary files involved.

How does IIS itself behave ? If you browse through port 81 and click on a file ? Are you using any special proxy settings ? I think you said no. Change your links to relative links (if they are not already) that should bypass iwproxy

Hmm - interesting - I went through the IIS admin interface, navigate to the page I used for iwproxy testing (see other response in thread) and did a right-click > Browse on the HTML file. IE came up without any security issues (though none of the images displayed).

I then clicked the refresh button in that IE Window several times - the first few had no prompts, then I got a prompt, filled it in, and it seemed to accept it. I did a few more refreshes, then I got another prompt, filled it in, and it wouldn't accept it - after several failed attempts I get the standard 401.3 error page...

This [still] has me leaning towards being an IIS / permissions / access issue - but ...

And no - there are no iwproxy settings in the iw.cfg file.

I'd like to avoid changning the link specifications in the HTML file except as a last resort (because if that is the issue - I'm going to have a **** of a time fixing every one of their existing HTML files ... and it just doesn't seem to me that it should be the source of this random-behavior problem)

Can you check the status of the TSIMP account ? I have seen it get locked because of screwed up security policies

No - the TSIMP account is fine (not locked out, password set to never expire)

Another thought is what happens if you remove the preview (tmp) file after the first preview.. where it usually would work the 2nd time.. maybe it can't get to the file (for permissions or some other reason) and the prompt is more like from an odd 404/403 redirect or something wierd like that..

yeah.. I realized after that we were not talking about the DCR preview.. for this one.. :-)

as for http://ts-server.do.main vs. http://ts-server.. the only reason I mentioned it is sometimes DNS can treat it differently, a hosts file entry, a wierd route in the tables.. and not sure if IIS could see it as a totally different site (i.e. the "default" site, vs a named site for example) ..

I wonder if you just use http://ts-server (instead of http://ts-server.do.main) as a try, if you get any different results.. since based on your post your using http://ts-server.do.main..

technically you should be able to see the request (and rejection of login attempt{s}) is the IIS logs too I would think.. to at least know that under either circustance.. IIS is seeing it at the correct path.. Maybe turning on logging in IIS.. and checking the requests/errors might show something.. if there are multiple "websites" there, turning on default as well.. to see if its somehow getting requests.. if IIS is bound to IP's.. what happens if you try going via the IP.. any differences?

I'd like to avoid changning the link specifications in the HTML file except as a last resort (because if that is the issue - I'm going to have a **** of a time fixing every one of their existing HTML files ... and it just doesn't seem to me that it should be the source of this random-behavior problem)

No I am not suggesting you change them permanently, it was more of a test. If the proxy (or if you are using other virtual directories) that would bypass them.

However your test results imply something different. Remove the check for integrated Windows login and see if that changes (for good preferably) the behavior.

How far away is the domain controller ? Is there a way to see if there have been errors when it is not responding in time ?

yeah.. I realized after that we were not talking about the DCR preview.. for this one.. :-)

as for http://ts-server.do.main vs. http://ts-server.. the only reason I mentioned it is sometimes DNS can treat it differently, a hosts file entry, a wierd route in the tables.. and not sure if IIS could see it as a totally different site (i.e. the "default" site, vs a named site for example) ..

I wonder if you just use http://ts-server (instead of http://ts-server.do.main) as a try, if you get any different results.. since based on your post your using http://ts-server.do.main..

technically you should be able to see the request (and rejection of login attempt{s}) is the IIS logs too I would think.. to at least know that under either circustance.. IIS is seeing it at the correct path.. Maybe turning on logging in IIS.. and checking the requests/errors might show something.. if there are multiple "websites" there, turning on default as well.. to see if its somehow getting requests.. if IIS is bound to IP's.. what happens if you try going via the IP.. any differences?

From limited testing - using IE directly on the TS-server, going through port 81 and avoiding iwproxy ...

The default when browsing through IIS is to use localhost:81 and while it works sometimes, when it fails the dialog box indicates it is looking for authentication to the fully-qualified domain name.

If I use the short domain name (foo:81 as opposed to foo.bar.baz:81), it again seems to work sometimes, but when it fails the dialog box indicates it is looking for authentication to the fully-qualified domain name.

If I use the fully-qualified domain name (foo.bar.baz:81) it seems to follow the same behavior, though I'm less sure - the first time it failed right out (but that might have been because I did it too closely on the heels of another failed attempt), the second time IE told me I had to add the host to trusted sites (which I did), it worked, and then when I refreshed again, I got the authentication prompt again.

The failure mode, despite it's seemingly random behavior, actually seems to be semi-consistent - at least the last two runs I had (with localhost:81), it works without any issues the first two times, then fails on the third - if I let it sit for a minute (give or take), it again works for the first two times and then fails...

Okay - I decided to take this test a bit further. I waited about a minute, then browsed to the web page through localhost:81 - no issue, I counted approximately 30 seconds, refreshed - no problem.

I repeated that about 5 or so times, no problem.

I then reduced my wait time to about 20 seconds, again it seemed to work for 5 or so times, no problem.

I then tried reducing it to about 15 seconds - seemed okay
I then tried reducing it to about 10 second - the problem showed up.

So - this would seem to imply that there's some sort of timeout somewhere that if you try to hit the same (or some? or any?) content within IIS within 10(+/-) seconds - you get prompted for this authentication stuff - which in and of itself doesn't seem to work.

this was "sort-of" mentioned in the other thread... not 100% the same but probably worth looking at..

http://support.microsoft.com/kb/327753

http://support.microsoft.com/kb/297080

http://kbalertz.com/312176/Heavy-Authentication-Traffic-Occurs-Between-Internet-Explorer-Proxy-Server.aspx

http://www.experts-exchange.com/Software/Server_Software/Web_Servers/Microsoft_IIS/Q_21139941.html

I see one of those suggestions was same as mine, remove the integrated authentication check.

Did you try it ?

I see one of those suggestions was same as mine, remove the integrated authentication check.

ah.. I just noticed that :-)

also.. here is another thing that I saw on the support site.. only reason I mention it is because of this

Also - and I just noticed this right now - it appears the hostname was changed on this machine sometime after IIS was originally configured - because the IUSER account is "IUSER_WEBCONDEV" whereas the TSIMP account (which corresponds with ipconfig /all) is TSIMP_WEBCONPRD - sigh)

https://support.interwoven.com/kb/kb_show_article2.asp?ArticleID=57728

its description sounds like your issue too.. since it uses the word sometimes:

When you try to preview a file in TeamSite, sometimes you may be prompted for Windows basic authentication.

seems to say that "The TSIMP_ user needs to be manually deleted and then recreated and the password (blank or otherwise) must be updated since you will now need to add TSIMP_ user to the account allowed for anonymous access in IIS."

I see one of those suggestions was same as mine, remove the integrated authentication check.

Did you try it ?

to have integrated authentication

this was "sort-of" mentioned in the other thread... not 100% the same but probably worth looking at..

http://support.microsoft.com/kb/327753

http://support.microsoft.com/kb/297080

http://kbalertz.com/312176/Heavy-Authentication-Traffic-Occurs-Between-Internet-Explorer-Proxy-Server.aspx

http://www.experts-exchange.com/Software/Server_Software/Web_Servers/Microsoft_IIS/Q_21139941.html

I took a look at these, and the one about adding a DWORD through the registry seemed the most promising (in that I tried it despite the fact that the article doesn't mention IE7, and it seemed to work - but after about 10 or so refreshes, I started getting the same authentication issues again)

The experts-exchange link doesn't help me because I don't have an account there and don't feel like creating one there either.

The first Microsoft link is the one that Andy indicated reflected what he suggested - about removing the Integrated Windows Authentication - but as I've already replied to his post - that fails miserably.

The second Microsoft link talks about dealing with proxies - but when I'm browsing to port 81 on the TS-server itself instead of from my client workstation) and I run into these problems - what proxy could be involved. Since it doesn't seem to fit the description of the problem and the proposed fix is clearly marked as only to be used if the problem described matches the issue --- I think that's a pass too.

Thanks anyway

how about the one from the IWOV support KB item, about deleting and just recreating the TSIMP_ User.. seems far fetched.. but then again..

also.. here is another thing that I saw on the support site.. only reason I mention it is because of thishttps://support.interwoven.com/kb/kb_show_article2.asp?ArticleID=5772

its description sounds like your issue too.. since it uses the word sometimes:

When you try to preview a file in TeamSite, sometimes you may be prompted for Windows basic authentication.

seems to say that "The TSIMP_ user needs to be manually deleted and then recreated and the password (blank or otherwise) must be updated since you will now need to add TSIMP_ user to the account allowed for anonymous access in IIS."

Are you sure about that article reference?
I just tried to search for "5772" on the Support site and wasn't able to find anything - perhaps you meant 57728 ?

I looked at that - and I deleted the TSIMP account, recreated it (had to give it a password, won't let me create it without one) - ended up using tspostreboot.pl, re-added the account to the TSWebPreview account, restarted IIS, restarted iwproxy (even though my current tests aren't going through there) - I notice that in the IIS settings, the IWA setting is now not checked (last time I was in there, I'm pretty sure I had it checked) - so tspostreboot.pl must have removed that check.

It doesn't work at all - so I check the IWA setting and it's back to where I started.

I'm wondering if the fact that I decided to use "TSWebPreview" instead of "TeamSite Web Preview" for my webserver_group is causing the issue - I noticed that when I did the installation of TS it created the latter even though I had specified the former in the iw.cfg before ever rebooting - sigh, I may have to go through and fix permissions on every branch, workarea, directory, and file if that's the case.

Are you sure about that article reference?
I just tried to search for "5772" on the Support site and wasn't able to find anything - perhaps you meant 57728 ?

I looked at that - and I deleted the TSIMP account, recreated it (had to give it a password, won't let me create it without one) - ended up using tspostreboot.pl, re-added the account to the TSWebPreview account, restarted IIS, restarted iwproxy (even though my current tests aren't going through there) - I notice that in the IIS settings, the IWA setting is now not checked (last time I was in there, I'm pretty sure I had it checked) - so tspostreboot.pl must have removed that check.

It doesn't work at all - so I check the IWA setting and it's back to where I started.

I'm wondering if the fact that I decided to use "TSWebPreview" instead of "TeamSite Web Preview" for my webserver_group is causing the issue - I noticed that when I did the installation of TS it created the latter even though I had specified the former in the iw.cfg before ever rebooting - sigh, I may have to go through and fix permissions on every branch, workarea, directory, and file if that's the case.

yeah.. sorry ArticleID=57728

can you create a group within a group (I'm more or a UNIX guy, so not as sure with windows).. to cover "both" the webserver_group you wanted.. and theirs.. or just add your group the their group and vice-versa (assuming its even the issue).. instead of touching every branch/WA/Dir ??

also.. and on the expert exchange (which I did not seem to need to login to see, just scrolled down to the bottom since I did not reg either).. here was the comment.. which is why i mentioned it..

Authentication popus up randomly when using Windows Integrated Auth.Zone: Microsoft IIS Web Server
Tags: authentication, popus, integrated, windows

Here's the situation:

We had to re-build a crashed Exchange / IIS server (Windows 2000 Server SP4) recently and restored all the documents and data, but none of the IIS or Windows settings. We set up IIS with its default settings, installed our security certificate, and changed authentication to ONLY use Windows Integrated Authentication. For the most part, this works fine like it did before the crash - the user's domain login is passed to IIS and scripts like ASP can read it and the login also gets written to the IIS logs.

Users are now reporting that they are occasionally getting an authentication pop-up (and we're able to see a matching 401 entry in the IIS logs and the domain login spot is empty). If they close out of everything and go back in, usually everything works again, but it's annoying. Plus, this MAY be related to a similar problem with Exchange - a couple of users are reporting that Outlook randomly pops up with a login box and freezes Outlook - the login box can't be cancelled.

So I'm wondering if these are two separate issues or if there's some bigger central issue (maybe with security policies or Kerberos or something?). Any pointers would be helpful. Thank you!

- Jonathan

here was the reply back from him.. seeing like he spoke with MSFT.

gr8gonzo:
Okay, here was the solution to the problem after calling Microsoft - they had me disable the Kerberos/Negotiate authentication protocol, which forced the server to use NTLM security:

1. Go to the server and go to the command line.

2. cd into the Inetpub\Adminscripts directory, like this:
cd c:\inetpub\adminscripts

3. Then run this command:
cscript adsutil.vbs set w3svc/NTAuthenticationProviders "NTLM"

4. Restart the server.

- Jonathan

in the Release Notes for 6.7.1sp1.. they also talk about the same adsutils.vbs script.. not related to your issue.. but related to IIS and no longer serving ASP's after running tspostreboot.ipl (issue 72869)

and again.. I know this is a shot in the dark.. but figured any out of the box thinking might help (well with me anyway)

also.. and on the expert exchange (which I did not seem to need to login to see, just scrolled down to the bottom since I did not reg either).. here was the comment.. which is why i mentioned it..
...
here was the reply back from him.. seeing like he spoke with MSFT.
...
in the Release Notes for 6.7.1sp1.. they also talk about the same adsutils.vbs script.. not related to your issue.. but related to IIS and no longer serving ASP's after running tspostreboot.ipl (issue 72869)

and again.. I know this is a shot in the dark.. but figured any out of the box thinking might help (well with me anyway)

I don't believe this is applicable since it's not an issue of IIS serving ASP pages and its not not a crashed IIS server.

The other references you posted were probably more on-target, though I'm still not sure that any of them actually address the problem I'm having (probably because there are always so many problems on Windows and IIS that they all start to sound the same ;-))