OctoTfs .. gives me an error when retrieving changes/checin notes

Hi all,

I’m using octotfs, for pushing releases from the new build system to octopus. I run into a bit of problem when getting the checkin notes:

The remote server returned an error: (401) Unauthorized.

When examing the script a bit closer, there is a function which retrieves the items from tfs:

function Get-LinkedReleaseNotes($vssEndpoint, $comments, $workItems) {

$personalAccessToken = $vssEndpoint.Authorization.Parameters.AccessToken
$changesUri = "$($env:SYSTEM_TEAMFOUNDATIONCOLLECTIONURI)$($env:SYSTEM_TEAMPROJECTID)/_apis/build/builds/$($env:BUILD_BUILDID)/changes"

Write-Host "changesUri: $changesUri"

This gives me the url to the api (when I paste that in my browser and login with the agent credentials I get the changes.json in which the correct items are … but

$headers = @{Authorization = "Bearer $personalAccessToken"}
$relatedChanges = (Invoke-WebRequest -Uri $changesUri -Headers $headers -UseBasicParsing) | ConvertFrom-Json

Deze next 2 lines … gives me the
The remote server returned an error: (401) Unauthorized.

So question what I’m I missing in this scenario???



Hi JW,

Thanks for getting in touch!

This is all very new (and largely undocumented) so we’re feeling our way a bit too. I’ve sent an email to the Build team at Microsoft. Hopefully they can help.

Firstly, can you tell me whether you’re using Visual Studio Online or an on-premises TFS 2015 instance?

A few things that spring to mind that could help:

  • What account was your build agent configured with? (or is it the hosted build?)
  • In the Build tab of your build definition, what’s the value of Build job authorization scope?
  • How long does it take for your build to reach this step? (in case the token expires)


Hi Damo,

First of all this “problem” is related to this question “http://help.octopusdeploy.com/discussions/questions/5282-trying-out-new-build-system-tfs2015-some-questions-and-clarificatons

We’re running on tfs 2015 on premises. I can’t seem to find “any” build tab in the build definition. Further the job run rather quickly (under 20s). The build is at the moment configured under an admin acount, to avoid any “eh” authorization problems.


ps. When i look at the new agent pools, and at the user capabliites. I notice that there is a username variable with system in it. It’s all grayed out so no idea if and how I can change it.

The documentation on the ms new build system is to put it miildly not very extensive

Hi JW,

Thanks for the reply.

Sorry, I didn’t realise we had duplicate tickets here. I’ll abandon the other one and just reply to this one.

I made a typo as well - I meant the General tab in the build definition.

It looks very much like a permissions problem, but until I can work out how those permissions get set, I’m not able to help. I have the people at Microsoft looking into it, so hopefully I’ll have a solution soon.

And I know what you mean with the new build system documentation - it’s fairly light. The help pages start here if you haven’t found them already.


Hi JW,

Just a quick update.

The permissions for the build agent should be coming from the Project Build Service Accounts or the Project Collection Build Service Accounts groups. Can you check the permissions on those groups to make sure they are sufficient and haven’t been changed? Out of the box, they should be able to make this API request.


Ha Damo,

I had a look at it:

my build account is a member of the project collection build service accounts, but NOT of project collection service accounts.

The build accont should be a member of both? Don’t think we ever fiddled much with these settings.


Hi JW,

Thanks for the reply.

It’s a little hard to tell, but I suspect the account that gets used is in the correct groups, but the permissions for those groups are incorrect. Note that this isn’t the account you set up the build agent with - TFS/VSO has a separate build account and the personal access token that gets used in the build step is for that account.

Can you check the permissions on the Project Collection Build Service Accounts to see whether anything might have changed or looks out of place? I’ve attached a screenshot showing the permissions I see out of the box.


Hi Damo,

We have the same rights as on the screenshot.

But … ehh “TFS/VSO has a separate build account and the personal access token that gets used in the build step is for that account.”

We’re do i find that specific account. Because the account i thought I needed to check was the account under which the services runs.

Ahh succes!!

I needed to add my build accunt to the “agent pool service account” in the agent pool permissions.

See attached screenshot.

I now have the tfs information in the release information.

So great, thanks for the support.


Hi JW,

Thanks for the reply and I’m really glad you got it working!

Your question about which account was being used was the exact question I asked the TFS team :slight_smile: Looks like you beat them to the answer!

Happy deployments!


My name is Patrick and I’m a developer on the back-end server for the new build automation system in TFS. Sorry you’re experiencing issues with authentication using the new model; we realize that documentation is lacking and we are working to improve it.

I would not have expected the solution you posted (adding to the agent pool service accounts group) to affect any calls to the project collection. Also, I would have expected the account running your build service to be automatically added to the group you have in your screenshot.

  • How was this agent configured? Is it on the same box and configured using the wizard or was it manually configured via the powershell script or command prompt?
  • Did you manually change the windows service account after initially setting up the build machine?



Hi Patrick,

First off, we upgraded our collection from 2013 update 4 to 2015 on a dedicated tfs server. We have a dedicated build server.

We downloaded the new agent from the tfs control panel. Unzipped it to a directory on the build server and excecuted the configureagent.ps1 script.

The script prompted from the different settings. The only thing specific is that we gave it the domain build account as user. Afterwards we did not have to configure it. It also was displayed in the agents for the default pool.

Perhaps something to note, there was no user configured in the agent pook service accounts.

Any other question, please let me know …


Do you happen to have the log files which were generated when you ran the configure step? As part of configuration we are supposed to resolve the account you specified to run the agent service and automatically add it to the appropriate agent pool service accounts group.

I forgot to include the question of whether or not you went from 2013 straight to 2015 RTM or did you upgrade to 2015 RC or a CTP build before moving to RTM?


Hi Patrick,

We did go straight from 2013 > 2015rtm. We did not use a rc or ctp on this server.

I had a look if I could find the logfiles. Perhaps I overlook them, but I can’t find them in the obvious places. ( I might have cleaned them, not sure, basicly I thought everything was fine after running the ps script)

– jw

I would have expected that to work fine. The log files, I believe, should be located in the _diag folder. Hopefully our cleanup task hasn’t deleted the useful logs already.


Hi Patrick,

I allready looked in this directory but it has indeed been cleared. So did have a look at our backups. Think the attached file is the one you need.


agent_20150807-205500-utc.log (6 KB)

So I see the following line from your configuration log:

20:56:04.110523 Successfully added account Identity ea98c956-df6a-4aa9-8487-da39763a38eb (IdentityType: System.Security.Principal.WindowsIdentity; Identifier: S-1-5-21-3012622310-2575601780-1754042684-1158; DisplayName: Tfs Build Service) as a member of the service accounts group for pool default

Are you saying that the end result is that the identity was not a member of the ‘Agent Pool Service Accounts’ group for the default pool?


Yes I noticed that line aswell

… all I can say that in the end I had to add that users to the Agent Pool Service Accounts groups manualy to get the functionality to work.


I’m having a similar problem:

  • Getting a 401 when trying to retrieve work items/changesets.
  • TFS 2015.2
  • This issue wasn’t occurring with an earlier (dry-run) install, but that may have also been 2015.1
  • I’ve double-checked that the service account is a member of the “Agent Pool Service Accounts” group, and it is. I’ve also added the user to the same group for “All Pools” out of desperation.

Any ideas?

Ik ben met vakantie tot woensdag 4 mei.

met vriendelijk groet,

Jan Willem