OAuth scopes in Azure DevOps 2025H2

In a continuation of a long running series, here is a scope dump from TFS Azure DevOps 2025H2, the latest as of the time of writing. Again, some endpoints might be cloud only.

They are eating their own dog food

The built-in build/release tasks of TFS Azure DevOps have manifests, too. And those manifests are right there in the database!

Punished for spelling out

Amazing discovery/public service announcement of the day: between v15 and v16 of the Azure DevOps' .NET client API, the definition of GitHttpClient and its base (where most of the methods are) underwent some changes that might be breaking.

I want to break free

Sometimes, one has release tasks in Azure DevOps (formerly known as TFS) that don't complete synchronously.

Project vs. collection

Some time ago, I've discussed the identity of the account that TFS agent jobs are using to connect back to TFS via the distributedTask PowerShell context variable, or the equivalent System.AccessToken release variable. Back at the time, I've concluded that the identity behind that token was "Build Service (CollectionName)". Well, just today I've encountered a case where a release was running under a different identity - "ProjectName Build Service (CollectionName)". Both coexist.

Sequential vs. semantic

This is about the naming of releases in Azure DevOps (formerly known as TFS and VSTS). The default pattern of release names has been, as long as I can remember, sequential within the definition's scope: "Release 1", "Release 2", etc. That's been a minor pet peeve of mine for a while, and now we've come up with a technique to change this format to something more informative. Specifically, one can name releases with respect to the current product version, as every reasonable project team would want to.

OAuth scopes in Azure DevOps 2020

Here's another OAuth scope dump from the latest on-prem instance of Azure DevOps.

The same caveat applies: some of those might be cloud only.

It's AzDevOps all the way down

Oy vey. Some posts ago, I've mentioned that all TFS Azure DevOps collection databases had the same schema, haven't I? Well, not quite.

c:\>TFS

Today, we're going to take a look at another wonderfully disjoint area of TFS Azure DevOps administration - command line clients. There are four Microsoft provided ones (that I know), and another that's probably the best of them all.

Select from TFVC

More TFS Azure DevOps schema exploration. This time, source control. Specifically, the classic TFS source control, also known as TFVC. No Git this time, that is a discussion for another day.

So I have an innocent desire to run a report off the content of some files in source control. The question is, how are they stored? There are four tables of interest:

Internal extensions in TFS

Some of the TFS Azure DevOps functionality that comes out of the box is internally organized the same way third party extensions are. You can even see their manifests:

use Tfs_Configuration;
select p.DisplayName, p.PublisherName, e.ExtensionName,
    e.DisplayName, e.ShortDescription, cast(Content as varchar(max)) as Content
    from Gallery.tbl_Asset a
        inner join Gallery.tbl_Extension e on a.ReferenceID=e.ExtensionId
        inner join Gallery.tbl_Publisher p on e.PublisherId = p.PublisherId
        inner join tbl_FileReference r on a.FileId = r.FileId
        inner join tbl_Content c on r.ResourceId = c.ResourceId
    where AssetType = 'Microsoft.VisualStudio.Services.Manifest'
    order by e.ExtensionName, a.Version desc

I can see multiple versions of the same extension there, my TFS instance went through several version upgrades; on a freshly installed copy there would probably be only one.

Let me know, TFS

Today's obscure corner of the TFS REST API to explore would be - notifications. Some time ago, I've noticed that SOAP is no longer an option on the collection-level Notifications screen, but it's supported internally. If it's supported internally, then it must be supported by the API. Indeed it is, there's a REST API endpoint for subscription creation, and one of the parameters is called "channel", and it's supposed to be an instance of ISubscriptionChannel. That's where the docs go blank, except mentioning that it has a type property.

OAuth scopes in TFS 2019

Now that I have a TFS Azure DevOps 2019 box, let's dump the scopes from that one, too.

The same caveat applies: some of those might be cloud only.

TFS 2019 and commitment issues

My JavaScript TFS extensions broke in TFS Azure DevOps 2019. All my complaints about TFS API surface being underdocumented came to their logical conclusion: no docs means no API commitment, no commitment means the team behind the API gets to make breaking changes with no guilt.

Let me count the ways things broke:

Federating TFS tables across collections

UPDATE: the outlined logic will break if your TFS instance has a mix of pre-AzDevOps collections with recently (2019+) created ones. Details here. The linked gist was updated, too.

As I've mentioned earlier, Team Foundation Server stores its data in multiple databases - one database per team project collection, and also a global database called Tfs_Configuration. How is one supposed to run cross-collection queries, then?

Constrained and dignified

Another day, another TFS Azure DevOps discovery.

I was facing a minor usability issue. We have an extension with several custom menu commands for release definitions pipelines. Out of those, two only make sense for server administrators. For anybody else, they'd error out anyway. The menu was getting crowded, so I wanted to see if I could make the admin-only commands hidden for non-admin users.

All TFS clients

The TFS API continues to be sorely underdocumented. This time, let's talk about the .NET one for a change. You're supposed to first construct a VssConnection, then get a client class or several. There's a separate client for source control, a client for work items, one for build/release tasks, etc. Here are all client classes that I could find in TFS 2018u1:

Who am I and what are my rights (in TFS)?

Some time ago, we've discussed OAuth in TFS. Recently, I've been attacking a related problem - we have a valid OAuth-based connection (a VssConnection object), it can invoke some REST endpoints via OAuth, but which ones? Turns out, the allowed scopes are stored within an OAuth token, it just takes a bit of parsing to retrieve. The following line on an ASPX page returns the scopes for a token:

string Scopes = new System.IdentityModel.Tokens.JwtSecurityToken(Token).Payload["scp"];

There's a sample gist for that.

All OAuth scopes in TFS 2018.1

Some time ago, I've discussed dumping all OAuth scopes in TFS, both documented and undocumented.

Now I have a TFS 2018 update 1 instance, and here's the OAuth scope dump for that version. Notable addition: wiki.

UPDATE: same for TFS Azure DevOps 2019.

The same caveat applies: some of those endpoints might be VSTS-only.

Uploading extensions to TFS

When creating a TFS extension, one ends up uploading it to the server all the time. Doing so through the Web UI is tedious, so here's a script for that.