TFS Proxy Server Unexpected Shutdowns

TFS Proxy Servers are essential for my current client’s TFSenvironment because they allow the disparate SharePoint development environment to experience improved network performance by caching copies of VC files. Since this particular environment is geo-distributed, this is a necessary architectural requirement in order to maintain appropriate developer efficiency.

Recently, a strange issue was occurring with my clients geo-environment where the proxy servers would start shutting down repetitively. The exact error you may run into is:

The VSTF Proxy Server stopped at [server]. The application is being shutdown for the following reason: HostingEnvironment. For more information …..”

Now this can happen for a variety of reasons, but first thing is you should enable proxy server tracing to get some more relevant error information by opening the web.config in the VersionControlProxy folder by setting the traceDirectoryName to a familiar storage location and changing traceWriter to true. For this particular error, one of the error returns can be:

Detailed Message: TF53002: Unable to obtain registration data for application VersionControl.
TF30055: Visual Studio could not find or read the Team Foundation Server server name in the configuration file. Contact your Team Foundation Server administrator. (type VstfNotConfiguredException)

If you get this error, the TfsNameUrl appsetting is not configured in the web.config file for the proxy server. Locate the:


element and change it. After, check your IIS app pool setting and check that the recycle interval or memory limit. After, you should be good to go!


SharePoint Claims Based Authentication Architectures Explained Part 2 Claims Architecture Priming

You can use one of many different types of approaches in order to create a claims based application. Both Web applications and SOAP Web Services can accomplish the same thing but they take different approaches for making it happen. Yet the overall structure that is there is the same as it’s the overall goal. The purpose is to create claims that can communicate with each other and that are secure.

We are going to take a close look at how you can evaluate the different types of architecture that can be used. Taking variables into consideration including different perspectives, the experience of the user, opportunities for optimizing, the performance of the different applications, and even how the claims get passed from the application to the issuer all need to be closely looked at. Only then will you see the entire picture of what is offered. I will also give you some advice about how to create your claims and how to know your users.

The overall purpose of the different architectures is to allow for either an active for passive type of federation to be implemented. With an active federation you will have the WS-Trust and WS-Federation Active Requestor Profile in place. They help to describe the way in which the communication between the clients and the services go about requesting a token from the issuer. It also covers how that token is sent for authorization.

With passive federation, the WS-Federation Passive Requestor Profile describes the same type of communication flow between the web application and the browser. In order for tokens to be requested and authorized the web browser has to redirect those requests.