Providing seamless external access to Team Build drops

There are a few articles describing how to configure your Team Foundation Server to be accessible externally. These articles focus on exposing the TFS web services, the SharePoint team project portals, Reporting Services, Team System Web Access and, in TFS 2010, even Lab Management, via public HTTP(S) urls.

The primary TFS resource omitted from such articles is how to expose the build outputs externally too, so that clicking the Open Drop Folder and View Log File links in the Visual Studio Build Explorer just work wherever you are.

My solution is based on the feature of modern versions of Windows (ie XP and later) to automatically try WebDAV when the standard file share protocol (SMB/CIFS) fails to connect to a given UNC path. Simply, you configure a WebDAV URI (using the IIS 7.5 WebDAV module in my case) that corresponds directly to the file share UNC used for build drops. That is, if your build drop path is \\myserver\myshare\ then the WebDAV URI must be http://myserver/myshare/.

While build drops can be hosted on any file server, I usually see the Team Foundation server itself, or even the build agents used as the location for the drop share. Having the WebDAV server and the drop file server as the same machine simplifies the setup (for the reasons below) but installing WebDAV on your build agent just complicates a build environment that should be kept as clean as possible, so I’d recommend against using the agent for the drop location. In my case I opted for a dedicated build drop file server, but you can just as easily use the TFS server if your infrastructure resources are limited.

When configuring the WebDAV module for HTTP we use Windows Authentication for granting access and this works great for resources on the WebDAV server. However, from my experience*, if the WebDAV site itself, or a virtual subdirectory, is mapped to a remote file share, impersonation of the credentials provided by Windows Authentication fails. If you switch to Basic Authentication though, access to resources not local to the WebDAV server then works, but Basic Authentication has its own problems.

With Basic Authentication, the user’s password is sent over the wire, so WebDAV refuses to allow it by default unless you also use SSL. Sadly, the Windows WebDAV redirector won’t automatically try HTTPS for UNC paths unless the server name is suffixed with “@ssl” (eg \\myserver@ssl\myshare\) and this unfortunately forces WebDAV to be used even when internal systems do have direct access to the file share.

Another small catch with using WebDAV to expose drop folders is that they often contain “web.config” files and IIS naturally tries to parse these files typically breaking the ability to browser to those folders. The solution I found from Steve Schofield was to set the “enableConfigurationOverride” property to “false” for the Application Pool used by the WebDAV IIS Site. This property isn’t available via the Management Console so you’ll have to use “appcmd” or edit the “applicationHost.config” file directly.

Update: With Windows 7 or Vista, a registry change is also required to add the WebDAV server’s FQDN to a list of servers to forward credentials to. It’s all documented in the Microsoft KB article 943280.

Finally, to complete the seamless experience, the drop file server should be referenced by the same fully-qualified domain name (FQDN) both internally and externally (eg \\\myshare\). The first step for this is to ensure that the drop file server itself will authenticate via the FQDN locally, especially if it’s the TFS server. This is done by adding the FQDN to the server’s BackConnectionHostNames registry key. Secondly, ensure that the FQDN resolves correctly for both internal and external users. In my case I configured Split DNS to resolve the FQDN to an internal IP address for internal users and a public IP for the public, keeping the routes as short as possible.

You can now change your build definitions to use the FQDN UNC as the default drop location and all future build outputs should be reachable via the same path wherever you are.

*It may be possible to get Windows Authentication impersonation to work for resources not hosted on the WebDAV server by granting the correct delegation permissions but I would need to do more research.