Some consideration on TFS SETUP (or TFS ADMIN) account

  • Article

 

In earlier versions of the product the TFSSETUP (TFSSADMIN) account was explicitly referenced. It used to be a placeholder name for an account that a customer could use to do the installation of TFS.

If you were installing TFS in a domain environment this had to be a domain account, and if TFS was getting deployed in a standalone/workgroup kind of environment it could be a workgroup account. Later versions of installation guide don’t explicitly call out a TFSSETUP/TFSADMIN account, other than saying the account that is used to install TFS must have administrative privileges on those servers where the TFS components are being laid.

From a practical standpoint it is better to have an account (again let’s call it TFSSETUP/TFSADMIN – a mere placeholder name) to do all of the installation of various components of TFS, and then use this same account to do any subsequent patching.

Now this discussion pertains to TFS in a domain environment, as that is the predominant deployment scenario for TFS in a business environment. You can get away with using one of the user accounts (say the individual account of someone whose role is that of a TFSAdministrator)  also in lieu of an explicit TFSSETUP Account. However there are some drawbacks to doing this, and it is good to use a specific domain account for setup/admin in your domain environment other than an individual user’s domain account to do the TFS setup and servicing operations. Some of these are listed below.

 

  • Consider the scenario when the TFS Admin (or the user owning the individual account) decides to leave the organization much later after he/she had set up TFS. It is most likely this user is purged from the AD in the corporate directory.  So if you have to do some update later on, you will now have to give a new individual organizational account (create this if required first) and then add admin privileges on the servers in question. How long is this going to take in your domain environment – minutes or days?

 

  • You wanted to do a patching (security or cumulative updates CUs)  to the TFS components at a later point in time. See #1.

 

  • You wanted to run TFSConfig commands with various options and parameters as part of a subsequent hardware upgrade or part of attaching new collections – You can again get by with using a user account in the domain, but it would be easier if you ran all such operations with a specific TFSSETUP/TFSADMIN domain account created for this purpose.

 

  • Audit - If there were multiple individual user accounts that altered TFS components. Instead it would be easier if just the TFSSetup or TFSAdmin account was the only one used to do setup, service and patch TFS and its password was just given to the TFSAdmins. So you will always know that it is only the TFS Admins that ever touch the TFS installation.

 

  • Preventing inadvertent use of the TFSSetup/TFSAdmin account. Once the initial TFS setups and configuration are done, simply disable the account. And whenever you need to service/patch TFS - re-enable the setup/admin account, do the servicing operation and then disable it again. In this way you can make sure this account is used only at predetermined points in time (presumably from tickets created in your ticketing system) and not have the temptation to go and make changes to a running TFS environment willy-nilly if it were a regular organizational/individual user account.

 

  • As opposed to individual organizational accounts, the  TFSSetup/TFSAdmin are less likely to have variances in their priviliges/permissions in the domain. Say when TFS was first setup by “John Doe” his individual user accounts’ set of privileges and permissions could be totally different from the second TFSAdmin say “Sue Ann”, who came on board a year down the line. Sometimes these can have side effects, which would not be the case if you were just uniformly using something like a TFSsetup/TFSAdmin account throughout the life-cycle of the TFS installation.