Moving your TFS installation from a workgroup to an Active Directory domain? Good for you! Honestly, you shoulda started with the domain anyway but we’ll not go there right now. Maybe you didn’t have the domain in place in the beginning. I’ve been playing with the process. Well, I wouldn’t say playing as I’m not into inflicting pain on myself.
First step, of course, is to RTFM. There’s a decent article on MSDNon how to do that. When you read the article, it seems pretty straightforward. Not necessarily simple – it’ll make you wish you’d started out in a domain – but straightforward. Follow the steps and all should be good, right? Well, it’s all good on the TFS side. When you get to the end and you’re thinking to yourself “Phew … almost done with this” you come across this little tidbit at the end of the article:
No tools are available to automatically change SharePoint Products and Technologies and Reporting Services users and groups and their role memberships from local accounts (used in workgroups) to domain accounts. Although the local accounts will still work as local accounts, you might want to take advantage of the flexibility and management of Active Directory groups. Both SharePoint Products and Technologies and SQL Server Reporting Services will show the users and groups and their role memberships for each site or report folder. You can populate SharePoint Products and Technologies and Reporting Services to use new or existing Active Directory groups depending on your new deployment.
It’s so small that, in the context of the article, you just might miss it. And remember – you can’t edit permissions for SharePoint or Reporting Services from TFS Explorer; that’s why they have the TFS Admin tool. And that’s exactly what you have to do … go project by project and set the permissions for SharePoint and Reporting Services. If you have a lot of projects, this gets to be mind-numbing. This is a VERY good reason to use groups for your management!!! Even if they are local groups, you can put the domain members in there and be done with with … no TFS Admin tool required (except for setting up the initial permissions).
But wait, there’s more. The local machine administrators group doesn’t have access to any of the SharePoint sites for Team System!! So you have to log in to TFS with a local account that has admin rights on the SharePoint sites. And is a server admin on TFS as well. Then you can go about fixing up the permissions. One more thing – I was adding the local machine Administrators group to every SharePoint (Full Control) and Reporting Services (Content Manager) site. You cannot add BUILTIN\Administrators as the group into the TFS Admin Tool (it gives you an error) … you have to add the group as “.\Administrators”. But SharePoint doesn’t like that syntax for the local administrator’s group and fails when you try to apply permissions. Once you refresh the view. you’ll see the Administrators groups listed as “BUILTIN\Administrators” (then why couldn’t I just add it like that??). You can then set Full Control permissions for the SharePoint site and apply your changes.
I really hope that they improve the permission/security management story in TFS 2010. I’ve not seen anything about that, but it sure would be nice.
Edit: Forgot to mention this … you’ll also need to change the account for the SharePoint Timer Service to the domain account for the TFS Service. If you don’t, OWSTIMER.EXE will very happily eat your CPU cycles. Once I changed the account to the domain TFS Service account, all was good.