Azure-pipelines-tasks: Index Sources & Publish Symbols fails with TF400813: Resource not available for anonymous access. Client authentication required.

[MarkKharitonov]

Required Information

Type: Bug
Enter Task Name: Index Sources & Publish Symbols

Environment

• Server - TFS on-premises?

  • If using TFS on-premises, provide the version: 17.143.28912.1

• Agent - Private

  • If using private agent, provide the OS of the machine running the agent and the agent version:

Capability name | Capability value
-- | --
Agent.OS | Windows_NT
Agent.OSVersion | 10.0.14393
Agent.Version | 2.131.0

Issue Description

Running the task results in the described error. Looking at the task code, the following execution flow emerges:

1. The code reaches https://github.com/microsoft/azure-pipelines-tasks/blob/c5de8d6beb30280eae54e6f0c2a17bb59ad98d92/Tasks/PublishSymbolsV2/PublishSymbols.ps1#L175-L177 and discovers that there is no account name, no PAT and Aad is not used.
2. So, the code executes https://github.com/microsoft/azure-pipelines-tasks/blob/c5de8d6beb30280eae54e6f0c2a17bb59ad98d92/Tasks/PublishSymbolsV2/PublishSymbols.ps1#L19-L20, sending an unauthenticated request to the on-premises Azure DevOps server.

This is strange. I would expect it at least to pass -UseDefaultCredentials. As it is now, the request is aborted, which is totally expected.

In effect, it makes it impossible to publish symbols to the on premises Azure DevOps server.

Task logs

log_6_588891.zip

Error logs

TF400813: Resource not available for anonymous access. Client authentication required. - Azure DevOps Server

[gnimor]

I see the same issue on our on-premises instance

[johnterickson]

@MarkKharitonov @gnimor
Are these new builds that you are having trouble setting up or existing builds that were working break? If so, what was the change that triggered the failure?

[johnterickson]

FYI this is expected

2019-09-25T20:20:57.9148414Z ##[debug]ARTIFACTSERVICES_SYMBOL_ACCOUNTNAME (empty)
2019-09-25T20:20:57.9212102Z ##[debug]ARTIFACTSERVICES_SYMBOL_PAT (empty)
2019-09-25T20:20:57.9257497Z ##[debug]ARTIFACTSERVICES_SYMBOL_USEAAD (empty)

Those are only for overriding the default of token provided to the build agent:

            $Endpoint = Get-VstsEndPoint -Name "SystemVssConnection"
            [string]$PersonalAccessToken = $Endpoint.Auth.Parameters.AccessToken

It looks like the location service used to allow for anonymous access and now doesn't?
e.g. in hosted this doesn't require auth: https://buildcanary.visualstudio.com//_apis/servicedefinitions/locationservice2/951917ac-a960-4999-8464-e3f0aa25b381

{"serviceType":"LocationService2","identifier":"951917ac-a960-4999-8464-e3f0aa25b381","displayName":"SPS Location Service","relativeToSetting":"fullyQualified","description":"","serviceOwner":"00000000-0000-0000-0000-000000000000","locationMappings":[{"accessMappingMoniker":"HostGuidAccessMapping","location":"https://app.vssps.visualstudio.com/A54d02617-2ebd-42b0-b1e2-257059c4c03d/"}],"toolId":"Framework","parentServiceType":"LocationService2","parentIdentifier":"a5ca35eb-148e-4ccd-bbb3-d31576d75958","properties":{}}

[MarkKharitonov]

Well, the anonymous does not work for on-premise. However, I do not understand why even try anonymous. If there is no account name, no token and no AAD, then it must be an on-premise installation. If so, the -UseDefaultCredentials makes much more sense, then -UseBasicParsing.

[gnimor]

Hmm, any idea for fix or a workaround. Currently it is not possible with an On-Premises setup to publish the symbols to the server? This is really a show stopper because we do not want to use a file share for storing the symbols.

[SamGrantham]

After I tested replacing -UseBasicParsing with -UseDefaultCredentials in a test environment there is an additional error downstream of this...

https://stackoverflow.com/questions/52066165/tfs-2018-update-2-failure-using-vsts-symbol-server

“A symbol server is available with Package Management in VSTS and works best with Visual >Studio 2017.4 and newer. Team Foundation Server users and users without the Package >Management extension can publish symbols to a file share using this task.”

The official documentation link is here: https://docs.microsoft.com/en-us/azure/devops/pipelines/artifacts/symbols?view=azure-devops#q-is-this-available-in-tfs

The authorization error is not expected but it also does not change the behavior of the task. I also noticed that the task itself does call this out, though the documentation link it refers to is broken:

It's possible I'm wrong, but it seems as thought if you want to use this task to publish to the server you need to be on Azure DevOps Service.

[MarkKharitonov]

We use a file share. The on-prem Azure DevOps Server is a bastard brother of the hosted. Those companies which made the mistake of going with TFS before the hosted version was even born are now screwed up capitally. The hosted version is constantly updated with goodies, while we get the bugs. This is a source of great frustration.

[MarkKharitonov]

Is there any progress on this bug? Should I open a Microsoft Support case to attract attention? Or maybe spam my entire organisation begging for developers to upvote this issue? Can the poor folks stuck with on-prem get some loving finally?

[petrciml]

I see the same issue on our on-premises instance too

[lg2de]

I faced this problem on on-premises too.
Is there any work-around?

[JunielKatarn]

Same issue here.
Is there at least a workaround?

[JunielKatarn]

@arunkm You seem like the maintainer of this feature.
Can you please comment?