• Is this error when you're connecting through the proxy?
• Do you get the same error if you're connecting (still with https) directly (not through the proxy)?
• Is 192.168.1.1 also an IP address of the TFS server? (I'd assume not, but wanted to check)

The connection that's failing is an internal TFS-to-TFS connection - you hit a Version Control API, but to dig up the connection string for that database, it contacts the GetRegistrationEntries web method from the Registration.asmx web service (under Services). The errors causing that internal call to fail don't appear, off-hand, to be related to the initial connection being a Basic-auth'd ISAPI-filter'd connection, so checking it on internal connections would be a good data point. If it's still failing, taking the ISAPI filter out of the picture would be useful, too.

As James points out, it looks like a problem with the TFS-to-TFS web service calls. You should probably also check to see that you have correctly configured your system to use SSL/HTTPS (independent of the ISAPI filter).

The instructions are in http://msdn2.microsoft.com/en-us/library/ms242875.aspx.

Thanks,

This error occurs when I connect using any method with the ISAPI filter installed. I didn't even try going through a proxy with the ISAPI filter because it wasn't working at all.

My router has the ip address of 192.168.1.1, so all traffic coming in from the web should come through that address. The server is at 192.168.1.100.

Since I was unable to get the ISAPI filter working, I have now switched back to SSL+NTLM without the filter - which works fine.

The way I setup TFS was to put the 'Team Foundation Server' website on port 443 and force it to use SSL. The Default and Sharepoint websites are NOT using SSL in our setup. The reason for only setting up one site with SSL is that we spend a lot of time working behind a couple of different firewalls and one of them limits SSL connections to port 443 only.

Also, I initially installed the ISAPI filter to try and work around the proxy authentication problems I was having, but now that is working with the 'Start Page' work-around.

Did you just put the TFS website on port 443 and force it to use SSL? What about the additional instructions as indicated in the MSDN help topic? Did you follow these as well?

Also can you send us the filter configuration file, plus are there any errors in the event log to do with the filter?

Thanks,

Just to help out a little:

• The ini file contents are in the first post in the thread
• TFS is indeed on 443 and forced to use SSL. He can't force the other sites into SSL due to firewall problems they have, only allowing SSL traffic through 443

Matheny - any chance you forgot to leave "Integrated Windows Authentication" enabled when you had the ISAPI filter in place? We still need NTLM enabled for these TFS-to-TFS calls to work - if IWA was turned off, you'd get this kind of failure on the internal call. It's unfortunate that we still need NTLM enabled even when you don't want external users to use it, but it's a limitation of the current implementation. Hopefully that'll do the trick.

I did follow the instructions on the MSDN help topic and this does work with SSL enabled. I don't think it would work at all if I hadn't followed those steps, right?

I also did leave the integrated windows authentication enabled as well as turning on the basic authentication option.

One thing I did do different from the steps on MSDN was to change the URLs in the database and registry to be externally visible. For example, I changed all the references to http://tfs:### to http://tfs.domain.net:###. I did the same with the SSL URLs, so they are now https://tfs.domain.net:443. (I wasn't sure what parts of TFS ended up using those URLs, the client or the server.) Would this cause the problem I'm seeing with the filter?

It could be a problem if those url's don't also work internally. Heck, if nothing else it's worth trying to back those out to internal URL's and see if that works. I wish I had a better answer, but doing the usual debug "change one thing at a time, see what fixes it" is the route to go here. :)

Thanks!

Sounds good, I'll try that out and let you know how it works. It sounds like my assumption of those URLs being used by clients was probably wrong:).

I played around with changing all of those internal URLs back and was finally able to find a working combination.

Here are the changes I had to make:

1. I set RequireSecurePort=false because I could never get it working the other way
2. I disabled the 'Require SSL' option on the Team Foundation Server web site
3. I changed all the URLs from https://tfs.domain.net to http://tfs:8080 except for the TFSUrlPublic value in 'Web Services\web.config'. Without the filter, these needed to be set to the fully qualified name.

Anyway, it looks like everything is working perfectly now. Thanks again for the help on these issues. I have to say that this product is really turning out to be pretty impressive.