Our environment is interesting.
For a variety of reasons, the Development, QA, Integration and UAT environments have been partitioned from the Corporate AD forest for a long time. This year we’re attempting to move Development, QA, UAT and Integration into one new AD forest to simplify management of the server and network resources.
We’re also deploying Team Foundation Server 2010. The prerequisite was to use the existing Microsoft Office SharePoint Server (2010) which has been deployed in the Corporate forest. Lastly, the new domain has a one way trust to the Corporate AD forest (which is administered by a professional hosting and support company), which means that anyone in the Technology team can authenticate to the Development domain.
Initially, I tried to run TFS 2010 from within the Development domain, integrated with SharePoint 2010 in the Corporate forest. This ended up working with about 95% of functionality; I had TFS working with Corporate domain based service accounts, and the only thing broken were the TFS dashboard templates (Excel Workbook reports mainly) which needed to authenticate to the Report Server in the Development AD forest.
It dawned on me that this was simply not feasible arrangement, despite my best efforts. It also presented an awkward administration perspective, since tools such as TFS Administrator couldn’t reconcile Security Groups I’d created in the Development forest for grouping Corporate users into “TFS User” groupings (e.g. Contributors, Project Managers, Administrators at a broad level).
We discussed the drawbacks of migrating SharePoint 2010 into the Development forest (I was, and remain, adamant that we needed a simplified administration model for TFS and related resources) until it was pointed out that there was another option. Running TFS 2010 in the Corporate forest. This hinged on us being delegated an OU (Organizational Unit) in the Corporate forest, so that we could create and administer service accounts and management (security) groups of our own.
This is the option we went with, and it is working like a charm.
Users belong to the Corporate domain, which allows them integration with all the company assets (like payroll, timesheets, mail), but also to reuse the same credentials when accessing work items, source control, build environments and development server resources. The Team Build server sits in the Development forest and can communicate with the TFS server, it is running with Corporate forest service credentials – and can deploy deeper into the Development forest resources.
Anyhow, this is a work in progress. In the next week or so we will be migrating new and current applications and services and also performing upgrades to convert the solutions into Visual Studio 2010 compatible solutions. This is more pain and learning, but should start to build the basis for a more unified and consistent development environment.
