TFS 2017 build agent in untrusted domain

This week I was faced with a scenario where a TFS build/release agent was used to deploy software from TFS Release management. This agent was running in the same Windows domain as the servers where the software needed to be deployed. The TFS server itself was running in a different Windows domain. Because of security considerations (these are production servers we’re talking about), these two Windows domain did not have a domain trust configured between them.
Continue reading

Advertisements

Using environment variables in build vNext

The new build system which was introduced in  Visual Studio Team Services (VSTS) and TFS 2015 has been gaining more popularity lately, and (in my opinion) rightly so. It simply works far better than the old XAML builds. I’ve been converting quite a few XAML based builds to the new build system. While doing this, I (inevitably of course) came across quite a few custom build workflows and tasks. Some of these were easily converted to build tasks that are available out-of-the-box, while others required some custom tasks. When creating a custom build or a custom build task, you’ll at some point need some build-specific information. This is where environment variables become necessary. Since I wasn’t too familiar with the concept (I’d heard of them, but never really used them) I decided to dig a little deeper.

Continue reading

Creating a custom Build.vNext agent

I’m always up for trying new bits of technology. And to be honest, as a consultant I think it’s an absolute necessity to know what is out there. Fortunately, exploring new technologies is fun!

Recently Microsoft has made Build.vNext publicly available on Visual Studio Online. You can read Brian Harry’s blog post here. Build.vNext gives us a much simpler build system than the old Xaml workflow based system. It’s also fully extensible (more about that in a later post) and  fully web-based. Also, the infrastructure has changed: instead of the Build controller – Build agent(s) architecture there is now the concept of build agent pools. These pools can be shared across collections, so you no longer have to deal with a separate controller for each collection.

Visual Studio Online provides a hosted build agent pool. This is great because you don’t have to deal with your own infrastructure. However, if you need to customize your build agent then you’ll have to install your own agent, which you can then connect to VSO.

I thought I’d give that a go and try to build a MVC 5.0 (which is also in preview) app while I’m at it. MVC 5.0 is included with the Visual Studio 2015 preview. In this post I’ll show you how to configure a build agent and connect it to VSO. In a next post, I’ll walk you through the process of creating a vNext build definition for building a MVC 5.0 app.

To get started, we need a server with Visual Studio 2015 RC installed. The fastest way to do that is to get one from Azure. Log in to http://manage.windowsazure.com and create a new virtual machine. There is a template available for the Visual Studio 2015 RC.

imageIn the next couple of screens, choose a username and password for logging on to the machine. The other options can just be left as defaults. Once your machine is completed, connect to it using Remote Desktop.
image Once logged in, I want to create a local user for running the build agent under. Go to Server Manager, Tools, Computer Management and open the “Users” node under “Local Users and Computers”. Now right-click and select “New User” and fill in the details.
imageNow that we have the prerequisites in place, we can get on to the more interesting stuff. First, we have to download the bits for our new build agent. On your new server, open up a browser and log on to your VSO account.  Click the little gear icon on the top-right to go to the VSO Control Panel, then go to the “Agent pools” tab and click the “Download agent” button.
imageThis should give you a zip file which contains everything you need to run a VSO build agent.
imageDownload and extract the zip file to your local machine. I put mine in “C:\VsoAgent”.
imageNow all that we need to do is configure our agent. This is done using PowerShell. Open up a PowerShell window in Administrator mode by shift+right click on the PowerShell icon and selecting “Run as Administrator”.
image Then, change to the directory where you downloaded the bits.
imageSet the execution policy to “Unrestricted” so that you can run the script to configure the agent.
imageNow, run the configuration script for the agent. It’ll ask you a bunch of questions regarding the configuration of the agent. You can customize if you want to, or just accept the defaults. In my example, I’m configuring the agent to run as a Windows Service so that it will start up when the server starts. Make sure to connect to your VSO account (don’t include the “/DefaultCollection” bit in the URL!) and provide the local account you created to run the agent if you choose to run the agent as a Windows Service. If all goes well, you’ll get a message telling you that the configuration of the agent succeeded.
imageIf you look in the VSO Control Panel, you’ll see your shiny new agent listed, along with it’s capabilities.
image 

That’s it! Your build agent is now ready for use. Happy building!

Bulk update TFS work items using the web interface

Sometimes there is a much simpler solution to a problem than you originally thought. Or maybe sometimes you just like to do things the hard way (I’m sure most engineers have experience with this 😉 ). In any case, it’s good to know the simple solution, for when you really need it.

Last week I posted about bulk updating TFS work items using Powershell (original post). However, it turns out there is a really simple way to do bulk updates using the TFS Web UI. This can be very helpful when you want to update (one or multiple) field values for many work items at once. I didn’t know about it, so I thought I’d post it here.

Start by creating a query in the TFS Web UI. Here, I created a simple query that selects all Features.

image

Then, select the work items that you want to update. Use Ctrl+Click to select multiple items, use Shift+Click to select a range or just hit Ctrl+a to select them all. Then right-click and select “Edit selected work item(s)…”:

image

You’ll then be presented with a screen where you can select which fields to update and which value to update to. You can also put a comment which will be put in the history field of the selected work items:

image

Once you click “OK”, your items will be updated! If you have a lot of items to update you’ll have a nice “Please wait” screen to stare at… Generally, it won’t take very long though.

image

When finished, your work items will be updated. Don’t forget to click the “Save results” button to save your work items!

image

Note: Using this feature it is possible to set field values which are not allowed (e.g. for the “State” field). When you do this, you’ll notice that your work items will turn red, indicating that they’re not valid:

image

When you do try to save, you’ll be presented with an error message:

image

Happy updating!

Bulk update TFS work items using PowerShell

Today I was faced with a question that persuaded me to try a bit of technology I haven’t used too often yet. I had to set a specific field to a specific value for a large amount of work items. Of course there are multiple ways to achieve that, like using Excel or writing a little application using the TFS API. I decided to brush up on my PowerShell skills and write a script for this purpose.

One of the cool things about PowerShell is that it lets you load any .Net assembly by using the Add-Type cmdlet. You can then use the classes defined in that assembly inside your PowerShell session. This opens up a wide range of possibilities, one of them being that you can use the TFS API from PowerShell!

So, let’s start by loading the TFS assemblies for working with the TFS Work Item store. These are the assemblies for TFS 2013:

Add-Type -AssemblyName "Microsoft.TeamFoundation.Client, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
Add-Type -AssemblyName "Microsoft.TeamFoundation.WorkItemTracking.Client, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"

Tip: if you don’t know the Public Key Token, you can find out by using “sn.exe”:

image

After the TFS assemblies have been loaded, we can get a reference to the TPC:

$tfs = [Microsoft.TeamFoundation.Client.TfsTeamProjectCollectionFactory]::GetTeamProjectCollection($tfsUri)

And then the $tfs object can be used to access the required services (the work item store in this case):

$workItemStore = $tfs.GetService([Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItemStore])

From then on, the rest is easy and pretty much similar to using the API as you would from C#. You can find the entire script on my GitHub: TfsBulkUpdateWi.ps1

Happy PowerShell-ing!

"Failed setting account on COM permissions" and "Unhandled Exception" when installing TFS 2015 using local machine accounts

Recently the folks at Microsoft released the first CTP for Team Foundation Server 2015. Eager to check out the new features I fired up an Azure virtual machine and tried the installation. I like to have full control over what is happening, so I decided to run the “Full Server” (called “Advanced” in TFS 2013) wizard:

image

I had created local accounts for the TFS service account and the build service account (“tfsservice” and “tfsbuild”). In the appropriate screens in the installation wizard, I entered them as “.\tfsservice”:

image

and “.\tfsbuild”:

image

When clicking “Test” I got some nice green checkmarks, so I figured all was OK.

However, when continueing with the installation it went sideways… Of course, these are CTP bits so this can be expected. First I got an error telling me that “VsoJobAgent.exe” had stopped working:

image

And then the configuration wizard failed at the “Configure services” stage:

image

When digging into the logs I found two messages related to accounts and permissions:

[Error @11:39:03.930] Unhandled Exception: System.Exception: The windows service logon account '.\tfsbuild' is not a valid account. Please make sure you provide the correct account. 
[Error @11:39:03.930]   at Microsoft.TeamFoundation.DistributedTask.Agent.AgentConfigurationHelper.Configure(IResourceManager resourceManager, Dictionary`2 settings, String agentName, String workFolder, String windowsServiceLogonAccount, String windowsServiceLogonPassword, String sharedServiceIdentityName, String sharedServiceIdentityPassword, Boolean force, Int32 maxWorkerCount, ServiceStartMode startMode) 
[Error @11:39:03.930]   at VsoAgent.AgentManager.ConfigureAgent(IResourceManager resourceManager, Dictionary`2 settings, CommandLine commandLine) 
[Error @11:39:03.930]   at VsoAgent.Program.Main(String[] args) 

and:

[Error @11:39:12.974] Failed setting account on COM permissions 
[Error @11:39:12.974]   System.Security.Principal.IdentityNotMappedException: Some or all identity references could not be translated. at System.Security.Principal.NTAccount.Translate(IdentityReferenceCollection sourceAccounts, Type targetType, Boolean forceSuccess) at System.Security.Principal.NTAccount.Translate(Type targetType) at Microsoft.TeamFoundation.Admin.ConfigureSetComPermissions.Run(ActivityContext context)

This made me think that maybe I need to provide the full computer name when specifying the accounts, so I gave that a try:

image

image

This time the configuration completed successfully!

image

Happy previewing!

Using icons from TFS

Recently I wanted to use some icons from the TFS user interface in a user manual that I was writing for a client. Of course there is the option to take a screenshot, but then the background is included and that didn’t look very pretty. And I like pretty ;-).

So I went looking for where those icons actually come from. I fired up the Chrome developer tools (hit F12) and poked around a bit with the inspector in the TFS web UI. There I eventually found the CSS for the build succeeded icon:

image

Notice the “-3696px” and “-16px”? This is a technique called CSS sprites. Essentially, that means that you take a small piece of a larger image file and show that. In this case, that larger image file is “tfs-icons.png”. And now it’s starting to get interesting… You can find this file in the directory where TFS is installed on your application tier. In my case (the default), this was “C:\Program Files\Microsoft Team Foundation Server 12.0\Application Tier\Web Services\_static\tfs\12\_content”. In there, you’ll find all icons used in the TFS web UI. Some of them are displayed using CSS sprites, others are just regular images.

Most of the icons can be found in the “tfs-icons.png” file. I used Paint.net to cut out the ones I needed. Just beware you don’t distribute them as part of your own product.