Submit My Question - Recent Questions - Recent Answer
Msdn Tech >> Visual Studio Team System >> Team Foundation Server - Setup

TFS setup - Red X on Documents and Reports, WSS authentication issues

So I'm setting up a single server TFS install. Actually, I have 2 different test installs that are temporary (one is a Virtual machine under Virtual Server, and the other is under Virtual PC), and then 1 "real" install. So everything seemed to go pretty well with the setup on the test installs and the real install. I've got to the point where I've customized a process template, and even done an import from VSS to a team project. I also used the TFS Admin tool to try to setup permissions for the project(s) for TFS, WSS and ReportServer.

However, I now have a big problem that I'm having a tougher time resolving than it seems like I should. On one of the test installs and on the real install, I have a new team project where I get a red X on the Documents folder and Reports folder when I access it in Team Explorer on a computer other than the server. When running Team Explorer on the server (logged in as the same user as I was remotely), then it all works fine. Source control seems to be fine.

At first, I thought it was a firewall issue. So I turned off the firewall, and still no luck. So then I ran ethereal to see what might be failing. I saw that it was getting a 401 on /sites/(Project)/_vti_bin/Lists.asmx. So then I tried to hit that resource with Internet Explorer, and got "HTTP Error 401.2 - Unauthorized: Access is denied due to server configuration.
Internet Information Services (IIS)", without ever being asked for my credentials. So then I tried other URLs.http://(name)/sites/(project),http://(name.domain.com)/sites/(project), etc. all gave me a 401.2. Basically, anything tied to port 80 on the machine gives me this. Both for Windows SharePoint Services things (WSS), and SQL Server Reporting pages. When I hit these pages while on the server, then it all works fine (I get prompted for my credentials for the web pages, and login fine).

One of the test setups seems to work OK (a Virtual PC) whether accessed from the server itself, or a remote computer . I don't get a red X, and I can hit the port 80 WSS and ReportServer pages from another machine. When it "works", I get prompted for my credentials to login.

I tried adding the site to my trusted sites, and have it set to automatically use my username and password, but that still doesn't work.

I double checked the settings in IIS on the problem machines. The TFSWSS AppPool is set to use the TFSSERVICE domain account, and the ReportServer AppPool is set to use Network Service. The Directory security is set to only use Integrated Windows Authentication. Running

cscript adsutil.vbs get w3svc/1/NTAuthenticationProviders

I get

NTAuthenticationProviders : (STRING) "NTLM"

I tried running

setspn -A HTTP/servername domain\account
setspn -A HTTP/servername.fullyqualifieddomainname domain\account

I compared TFSIntegration.tbl_service_interface between all 3 installations, and they all look similar.

One thing that made a small differences is when I went into Directory Security and added "Basic authentication" in addition to Integrated Windows Authentication. When I did that and restarted IIS, I could hit the web pages (and it prompted for my credentials), but the red X on the Documents folder and Reports folder were still there (even after exiting Team Explorer/VS and getting back in).

What else can I try?

Thanks!
-Daniel

[3663 byte] By [Daniel_Bowen] at [2007-12-23]
«« how to add DataSource property to my user control
»» Welcome
# 1

More info.

So, if I try to hit a web page on the share point site from the domain controller itself, things work - I get prompted for my credentials.

If I go to the configuration for the default web site, and change it to some other port (like 8000), then I get prompted for my credentials when hitting it from all the other machines where I'd only get a 401.2 error before! Of course, not everything works quite right when I do that - it looks like there's still a reference on one of the pages to the report server on the default port 80, and then team explorer doesn't know to use port 8000 instead of port 80, so the red Xs are still there.

So looking in the IIS logs, here's what it looks like when I hit http://server/default.aspx and it works (I get prompted for my credentials, and log in) (this is from the domain controller to the TFS machine):

2006-08-29 18:21:48 W3SVC1 192.168.1.34 GET /default.aspx - 8123 - 192.168.1.106 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1;+.NET+CLR+1.1.4322;+.NET+CLR+2.0.50727) 401 2 2148074254
2006-08-29 18:21:52 W3SVC1 192.168.1.34 GET /default.aspx - 8123 MYDOMAIN\myusername 192.168.1.106 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1;+.NET+CLR+1.1.4322;+.NET+CLR+2.0.50727) 200 0 0

When it doesn't work, I see very similar log entries. There's a 401.2 error, with a Win32 code of 2148074254 (0x8009030E / SEC_E_NO_CREDENTIALS). But there's no retry from the client that prompts for credential and tries again.

So then I broke out ethereal on the client and the server. When it doesn't work, the GET from the client happens, then the response from the server is a HTTP/1.0 401 Unauthorized. There's one important difference with the first response from the GET between what the server sent out and what the client received. The server sent out an HTTP header

WWW-Authenticate: NTLM\r\n

The client didn't receive this HTTP header, but did have:

X-Cache: Miss from barracuda.mydomain.com

So there's something acting as a proxy! And after IT swore up and down there was no proxy :_( Getting with them now to see how we can resolve this.

I'm still not sure why my virtual PC configuration worked. One difference is that it was a stand-alone server at first, and then joined to the domain later (for the sake of TFS).

...

It turns out that someone went into the server room and "rearranged" some of the wiring to try to circumvent for some computers a filtering/proxy type server (a barracuda box) that you usually have to go through to go to the open internet, but not between computers on the LAN. What this change ended up doing was segmenting the LAN so that for some LAN connections, it was going through the proxy, but for other LAN computers, it bypassed the barracuda on the way to the internet.

Its all working now.

-Daniel

Daniel_Bowen at 2007-8-31 > top of Msdn Tech,Visual Studio Team System,Team Foundation Server - Setup...
Visual Studio Team System
Team Foundation Server - Setup

Visual Studio Team System Hot Topic

Visual Studio Team System New Topic

Visual Studio Team System

Java / MSDN / Linux Tech / PHP Tech / MSDN DotNet / MSDN TECH / Health Library / Programmers Tech / visual basic Tech / Developer Tech / Ipod faqs / Msdn China Tech

Site Classified