Any side-effects from deleting Reader and Contributor groups in TFS?

Question

I want to set up TFS permissions to better reflect the responsibilities and levels of clearance of different roles within my organization; I'm finding that the default Reader and Contributor groups are too coarse-grained for my needs (and too loosely named).

To keep maintenance overheads to a minimum, I'm therefore thinking of replacing the Contributor and Reader groups with my own groups, but... is there any negative side effect of deleting those two groups? Does any part of TFS rely on them being there?

Thanks.

Answer 1

You should be fine. The built-in groups at the project level are for convenience only.

(This is NOT true of some of the server-level groups like TF Valid Users and TF Licensed Users. Maybe TF Service Accounts as well, I forget. These "well known groups" play a specific role in internal TFS operations. Delete them and the system won't work, even if you recreate them exactly as they were, because the GUIDs won't match.)

Just make sure that if you remove the Project Administrators group, you still have admin privileges inheriting from another group (eg TF Admins), otherwise you'll find yourself in a catch-22 situation. If you do get stuck by accident, know that local admins on the application tier machine are "TFS super-admins" who can bypass all security checks and put things back in order.

-EDIT-

One thing you will have to do is manually grant permissions to the new groups in Sharepoint and Reporting Services. I'd recommend downloading the TFS Admin Tool -- makes these tasks much simpler.