IISReset and TFSServiceControl quiesce

“Isn’t it the same if I just run IISReset /stop to take the Team Foundation Server down?”

No, it isn’t.

If you just run IISReset /stop, you are just locking the IIS access – but the Team Foundation Server is still up and running, it is just not reachable.

This is why TFSServiceControl quiesce is needed: by running it, you are effectively taking down the server, stopping the Application Pools, all the jobs and the agents running on it. Moreover, MSDN states “You cannot manually perform all of the tasks carried out by the TFSServiceControl command.”, so little choice here

Other than being sure of the TFS’ status and consistency, by running it together with IISReset you are ensuring that the IIS won’t be overstressed and it won’t forward any query to the TFS itself.

Basically, you are locking the safe (TFS) and the room’s door (IIS).

Suggestions for preparing a TFS deployment with SQL AlwaysOn

SQL Server AlwaysOn is a utterly cool technology, but it is not a technology itself which solves all the problems you may have.

In particular, it is not just about tweaking a couple of settings and adding servers as needed. A careful planning and thorough tests are mandatory in order to succeed without affecting the existing service or going overtime. So I wanted to sum up some tips I found during a project I am following with a huge deployment of Team Foundation Server 2013 which uses SQL Server AlwaysOn as an underlying High Availability solution.

1. Size your storage
   I am dealing with TBs of data, so I am experiencing that TBs of storage flies away in a snap. Do not underestimate your storage size and do not rely just on SANs. Importing your data takes time and space, especially if you restore your databases to the secondary replica using the Full mechanism of backup-and-restore provided by SQL Server AlwaysOn.
   
2. You can’t mix and match all the HA technologies
   Not all the SQL HA technologies are supported by TFS in the first place. MSDN is pretty clear on this, no replication and no log shipping. Log shipping could technically work, but you won’t be supported by the Microsoft CSS, so it is a no no. You can mix a clustered SQL Server with another one in another location within the same AlwaysOn Availability Group though, and it is pretty robust. Keep in mind anyway that TFS is pretty agnostic about the underlying SQL deployment though, in fact the only feature which requires a specific configuration is AlwaysOn Availability Groups.
3. The MultiSubnetFailover setting
   When configuring Team Foundation Server for using AlwaysOn Availability Groups, remember to tick the specific checkbox about this setting. Beware of the setting: if you are not directly using an AG but you select it at TFS configuration time, you are going to be in trouble. If you are restoring it to a new server, launch TFSConfig RegisterDB to enable it:
       
   TFSConfig RegisterDB /SQLInstance:MyDB\namedinstanceifneeded /databaseName:Tfs_Configuration /usesqlalwayson
   
    
4. All the Team Foundation Server databases must be in the AlwaysOn Availability Group
   No exceptions to this – if you use it, all the DBs must be contained in the AG.

How to perform a TFS Security Audit

It is common to be asked for performing a security audit on Team Foundation Server, and it is not a nightmare as it would seem…

The easiest way is to download the Audit Log. You can find it in the Access Levels administration page:

What you are going to get is a .csv file, containing all the groups and accounts allowed into Team Foundation Server, each with its unique internal URI (vstfs://…), the last access date and its access level.

But this is just the beginning – you get a list of flat users and groups, without their relationships. In order to get these, you can use the TFSSecurity command with the /i, /im and /imx switches.

These will give you all the informations about each user/group and its relationships and privileges, so wrapping their outputs and creating a very simple report is just a matter of time