Update TFS Build Controller via Powershell

October 21, 2014

During a trial-migration of TFS, I typically prepare a lot of command-line tools to run some background update processes. Instead of writing little C# command-line applications in Visual Studio, I’m moving more and more away from Visual Studio and do stuff via PowerShell.

For a migration upgrade from TFS 2010 to TFS 2013, I have to deal with an update of the Build Controller to a new build machine/server. For a Team Project Collection of 100+ Team Projects and lots of build definitions, this is not something you want to do manually or delegate to all involved dev teams.

Instead of having to start from zero, I found this interesting post from Daniel Mann which does exactly what I want: updating the Build Controller from PowerShell via the TFS API. Except, it does it specifically for one dedicated Team Project.

So, the PowerShell script only needed a bit of tweaking to fetch all available Team Projects via the ListAllProjects method of the ICommonStructureService interface.

param(
[Parameter(Mandatory)]
[ValidateNotNullOrEmpty()]
[string]
$TfsUrl,
[Parameter(Mandatory)]
[ValidateNotNullOrEmpty()]
[string]
$NewBuildController,
[Switch]
$WhatIf
)

Function SetBuildControllerForTeamProject($TeamProject, $BuildController, $WhatIf)
{
$buildDefinitions = $buildClient.QueryBuildDefinitions($TeamProject)
$buildDefinitions | % {
Write-Host " >> Checking Build Definition" $_.Name
Write-Host " >>" $_.Name "is using" $_.BuildController.Name

if ($_.BuildController.Uri -ne $controller.Uri) {
Write-Host " >>> Setting" $_.Name "to use $BuildController"
if (!$WhatIf) {
$_.BuildController = $controller
$_.Save()
}
}
else {
Write-Host " >> Build controller is already set. Taking no action."
}
}
}

add-type -Path 'C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\ReferenceAssemblies\v2.0\Microsoft.TeamFoundation.Common.dll'
add-type -Path 'C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\ReferenceAssemblies\v2.0\Microsoft.TeamFoundation.Client.dll'
add-type -Path 'C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\ReferenceAssemblies\v2.0\Microsoft.TeamFoundation.Build.Client.dll'

$tfsUri = new-object System.Uri $TfsUrl
$tpc = new-object Microsoft.TeamFoundation.Client.TfsTeamProjectCollection $tfsUri

$buildClient = $tpc.GetService('Microsoft.TeamFoundation.Build.Client.IBuildServer')
$commonStructure = $tpc.GetService('Microsoft.TeamFoundation.Server.ICommonStructureService')
$controller = $buildClient.GetBuildController($NewBuildController)

$allTeamProjectInfo = $commonStructure.ListAllProjects()
$sortedTeamProjectInfo = $allTeamProjectInfo | sort-object { $_.Name }

foreach($teamProjectInfo in $sortedTeamProjectInfo)
{
Write-Host '************** Scanning Build Definitions in Team Project' $teamProjectInfo.Name
SetBuildControllerForTeamProject $teamProjectInfo.Name $NewBuildController $WhatIf
Write-Host ''
}

You may also use the Community TFS Build Manager (Visual Studio 2013 extension) to modify a number of Build Definitions in bulk, but for my migration scenario, I preferred to have a PowerShell script. Having this script also allows me to modify other settings in the Build Definitions … for example the Build Drop Location.

Community TFS Build Manager


TFS 2010: Virus Scan file/folder exclusions

December 20, 2011

At several customers I have seen that some Virus Scan Systems (no names) have a serious negative impact on the performance of Team Foundation Server. Especially the Build Server may be an easy target for the Virus Scanning actions.

Here’s my latest recommendation I have sent to the Ops Team. Note that all involved servers run Windows Server 2008 R2 (64 bit) and the software is installed on the C drive. The TFS Application Tier also has WSS 3.0 (SP2) installed. Use at your own risk and good luck to get this approved by your Ops Team. Traditionally they handle the presumption of innocence principle: the virus scan is innocent until proven guilty!

  • TFS Application Tier
    • C:\Program Files\Microsoft Team Foundation Server 2010\Application Tier\Web Services\_tfs_data [TFS Version Control Cache folder]
    • C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions [SharePoint Portal]
    • C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files [SharePoint Portal + Web Access]
    • C:\Users\TFSWSSAccount\AppData\Local\Temp [SharePoint Portal]
  • TFS Build Server(s)
    • Build Agent(s) working directory: D:\Builds
    • TFS local cache folder for TFSBUILD account: C:\Users\TFSBUILDAccount\AppData\Local\Microsoft\Team Foundation
  • TFS Data Tier
    • SQL Server data files: .mdf + .ldf
  • Client DevSeat
    • TFS workspaces folder: D:\TFS

I did find some official references:


Work Item Only View (WIOV) Users in TFS 2010

June 29, 2011

Team Web Access (TWA) is a customizable Web interface that can access Team Foundation Server project data. It acts as a client of Team Foundation Server and provides most of the functionality available through Visual Studio Team Explorer. Users that connect to TFS via TWA should also have a valid Client Access License (CAL).

WIOV

But … without having a CAL you may also create and view/modify work items that are created by you in Visual Studio Team Foundation Server. To perform these tasks, you need only Team Web Access in Work Item Only View (WIOV) and the required permissions.

Taken from the Visual Studio 2010 Licensing Whitepaper (area Client Access License Exception for Certain Work Items):

A user does not need a CAL or External Connector License to create new work items or to update work items that that same user has created. This exception applies only to work items related to defect filing or enhancement requests. However, a CAL is required when a user views or modifies a work item created by another user or interacts with Team Foundation Server in any other way.

Great, but how to make this work inside Team Foundation Server 2010?

Open up Team Foundation Administration Console and click on the Group Membership link that belongs to the Application Tier tab.

image

There you will find a TFS Security Group Work Item Only View Users. User accounts of users should be added to this group when these users should only have access to the Work Item Only View feature.

The actual downgrade of the permissions for these users is set through the Security Administration.

image

This TFS Security group is denied access to the full Web Access features.

Being part of this group will show you a limited version of Team Web Access where you will only be able to view and manage your own work items.

image


Going beyond nice and easy installation scenarios of TFS 2010

January 29, 2011

The TFS product team has done a great job in facilitating the installation/configuration of Team Foundation Server 2010, but don’t get too excited about all this. Some scenarios are still a real challenge to complete successfully and require a lot of planning and testing. This all depends on the fact if you are migrating from a previous Team Foundation Server (2005/2008) and what type of TFS topology you are looking for.

Easy

The easiest scenario is of course the TFS 2010 basic installation. A clean install of TFS 2010 on a client operating system (Vista / Windows 7). No hassle with SharePoint and SQL Reporting Services. This scenario can be done by every software developer and is perfect for having a local development playground for version control, work item management and build automation. You may be up-and-running in less than 1 hour! This is the only installation type where you don’t really need the famous TFS 2010 Installation Guide.

The other easy scenario is when you want to setup a clean Team Foundation Server 2010 (no upgrade) on a single server (Application Tier and Data Tier are installed on the single server). This is especially true if you are using all new installations of prerequisite software to host the configuration database, the report server, and the portal server (Windows SharePoint Services 3.0). This scenario involves already some familiarity with the other (optional) TFS Components: SharePoint and SQL Server Reporting Services. Read more about the Single-Server installation procedure.

Difficult

Selecting a (complex) multiple-server installation for Team Foundation Server should always be based on actual requirements instead of the fact that it’s just cool in trying to set this up. Don’t even think about this scenario when your potential users are lower than 250. At this time the complexity will automatically increase because you will probably also need to pass the security department for getting clearance in required service accounts for TFS and you will also need to work closely together with the SQL Server operations team / SharePoint operations team to work out a matching infrastructure for the SQL Server database instance, the SQL Server Report Server, the SQL Server Analysis Server and the Microsoft Office SharePoint Server (MOSS or WSS). Most of the time they won’t give you immediately the infrastructure you really need. You will need to earn their respect and you will need to understand their overall policies. This is definitely the part where you won’t have full control of the situation. The bigger the company, the more time it will take to get agreement from all parties. Start as early as possible with these negotiations!

Let’s shift to upgrading from a previous Team Foundation Server (2005/2008) towards Team Foundation Server 2010. In this case you have two possible options: an in-place upgrade or a migration upgrade. The in-place upgrade to TFS 2010 will use the exact same set of hardware that the previous version was using. The migration upgrade allows you to move at the same time to new and better hardware for all TFS Components. You might also want to consider moving from 32 bit to 64 bit servers. An extra difficulty might come up when the previous TFS installation is still using a SQL Server 2005 data store because TFS 2010 doesn’t offer support anymore for SQL Server 2005. Before going down the path of an upgrade, be sure to carefully read the TFS 2010 Supplemental Upgrade Guide at Codeplex.

In my opinion it’s always better to go for the migration upgrade. On top of the benefits of new hardware for Team Foundation Server 2010 (always very welcome!), you will always have an easy fall back scenario when the migration upgrade didn’t succeed.

Advanced

A not so well known feature in TFS 2010 is the ability to import data and projects from one or more previous Team Foundation Servers (2005/2008) into new Team Project Collections in a single instance of TFS 2010. Importing has some different characteristics than upgrading, but in some situations a combination of upgrading and importing might be the best fit. Consider the following situation:

  • A running multi-server TFS 2008 instance with 150+ Team Projects.
  • Team Projects should be split in different Team Project Collections that will match a specific division in the company.
  • Not all divisions can and want to upgrade at the same time due to different important release cycles. Risk and possible impact are a lot bigger when everything is upgraded at the same time.

Possible solution:

  • Perform a migration upgrade to TFS 2010.
  • Split upgraded Team Project Collection in new Team Project Collections for dedicated company divisions that were ready for the upgrade.
  • Divisions that were not ready for the upgrade can temporarily continue to work on the old TFS 2008 infrastructure.
  • To investigate a future import of remaining 2008 Team Projects for one or more dedicated divisions into TFS 2010, a trial import can be executed. During the trial period all actions to become TFS 2010 ready can be studied (builds, reports, portal, …).
  • Once the trials were successful, one or more (depending on the number of divisions left to move to TFS 2010) final imports can be performed to a new TFS 2010 Team Project Collection in combination with the rework necessary for bringing it fully operational on the new infrastructure.
  • After all remaining Team Projects are imported in TFS 2010, the TFS 2008 environment won’t be needed anymore.

Over time you will end up with a TFS 2010 environment with all desired Team Project Collections and you will have mitigated the risk of doing the one and only big-bang upgrade, forcing everyone to be ready at that particular time. One downside of the import command is that it does not upgrade reports or team project portals that are associated with the projects and databases to TFS 2010. That’s why it’s certainly a good practice to first perform an upgrade and to bring as many Team Projects back online in TFS 2010 after the initial upgrade. The original purpose of the import action is to consolidate different TFS environments into a single TFS instance.


Required permission for TFS 2010 Backup Plan

January 24, 2011

While setting up a TFS Backup Plan (part of the TFS 2010 Power Tools) on a new Team Foundation Server, I ran into a security issue.

TFSBackupError

[ Grant Backup Plan Permissions ] Account tfssetup failed to create backups using path TfsBackups.

I didn’t get rid of this error after making sure that the tfssetup account had the appropriate rights on the shared network folder where the backups will be dropped.

Giving Everyone modifications rights resolved the issue immediately, but of course that’s not the solution I was looking for.

So, ProcessMonitor from SysInternals came once again to the rescue. There I found out that SQL Server (sqlsrvr.exe) was trying to access the shared network folder.

Solution: also grant modifications rights on the shared network folder to the SQLService account that’s running SQL Server.


Timeout with TFS2010 Backup/Restore Power Tool

December 3, 2010

I peviously alread blogged about the TFS2010 Backup/Restore Power Tool, but there are still some gotchas you should be aware of.

At a customer where I made use of the TFS2010 Backup/Restore Power Tool we ran into the (known) timeout issue during a TFS Backup execution.

Active backup plan configuration: full backup each week, differential backup each day, transactional backup each 30 minutes.

The timeout (600 seconds) was caused by very big transactional log files (> 15 GB) that couldn’t be stored in time to the backup location. No matter what backup plan configuration you choose, the transactional log files of all TFS databases are continuously growing because the recovery mode of the TFS databases is set to "Full". To keep it short here, the Full recovery mode is used because it provides greater protection for data than the Simple recovery model. It relies on backing up the transaction log to provide full recoverability and to prevent work loss in the broadest range of failure scenarios. More details on SQL Server recovery modes can be found here.

As a quick fix, I changed the recovery mode of the involved databases from Full to Simple and shrunk the log files. After that I switched the recovery mode back to Full. But the issue with the growing transactional log files (+ timeout) will continue to pop up in the (near) future …

So, I was thinking about setting the recovery mode of the TFS databases to Simple permanently and switching to a nightly full backup each day. I assumed that we will always be able to do a restore to one of those full backups (maximum loss of data = 1 day) … No! Just don’t do this! The Backup/Restore Power Tool relies on SQL marked transactions to keep consistency across the TFS (and dependency products) databases. The SQL marked transaction implementation in the Backup/Restore Power Tool requires the SQL recovery mode to be set to Full. Thanks to the TFS product team for making this clear to me! Switching permanently to a Simple recovery mode could possibly result in a rollback to inconsistent TFS databases. More details on marked transactions can be found here.

A temporary solution is to manually switch to Simple recovery mode, shrink the log files and then switch back to Full recovery mode. The problem is that you would need to do this sometimes when the log files are getting "too big". A better solution might be to automate and schedule these actions for all involved TFS databases.

Here’s a sample SQL script that you might use:

ALTER DATABASE [<DatabaseName>] SET RECOVERY SIMPLE WITH NO_WAIT

USE [<DatabaseName>]

GO

DBCC SHRINKFILE (N'<DatabaseName>_log’ , 0, TRUNCATEONLY)

GO

ALTER DATABASE [<DatabaseName>] SET RECOVERY FULL WITH NO_WAIT

Timeout issues + log file sizes will be fixed in the next TFS Power Tool release (probably Q1 2011).

[Update March 13, 2011]

With the release of the new TFS Power Tools (March 2011), the timeout issue has been resolved. Note that you must not forget to disable the workaround script to shrink the logfiles.


TFS2010 Backup/Restore Tool

October 19, 2010

Despite there are some known issues with the first version of the TFS2010 Backup/Restore Tool, it has saved me already a lot of time during different TFS2010 assignments. Setting up manually a complete backup plan for all involved databases is not that straightforward for non-database-administrators. I also like the neat integration with the existing Team Foundation Administration Console.

Some other obstacles I encountered during the TFS2010 Backup configuration:

  • System Check failed in the readiness check
    TF255118: The Windows Management Instrumentation (WMI) interface could not be contacted on this computer

    This failure was simply fixed by restarting the Windows Management Instrumentation service.

    RestartWMI

  • Grant Backup Plan Permissions failed in the readiness check
    Account “x” failed to create backups using path \\tfs2010\Backups 2010

    This failure had nothing to do with security or permissions, but the error was simply caused by a space in the network path. The network backup path must not contain a space!

Note that you shouldn’t backup (yet) the SharePoint databases with the TFS2010 Backup/Restore Tool.

You can download the TFS2010 Backup/Restore Tool as part of the TFS2010 Power Tools (September 2010).


Follow

Get every new post delivered to your Inbox.