I have a PowerShell script that interacts with a TFVC repo in Azure DevOps. The code uses TF.exe for this interaction using an Azure DevOps username and PAT.

The PAT is valid and has the needed permissions. I am using the PAT as a password for a TF GET command (see example below). However, I noticed that every now and then, authentication will fail "Error TF30063: You are not authorized to access ..." and I overcome this by opening the developer's command prompt and run any TF commands (such as trying to access to the workspace in question) which then prompts me to provide my Azure DevOps credentials (which I do). Then when I run the script again, it all works fine. I cleared all local Windows Credentials in Credential Manager, I also cleared these two directories trying to see how credential caching manifest itself for Visual Studio/TF.exe/Or Developer Command prompt (whichever applies):

• C:\Users{username}\AppData\Local\Microsoft\Team Foundation\8.0\Cache. This was not it as the content of this directory never changed after I reauthenticated in Developer Command Prompt.
• C:\Users{username}\AppData\Local.IdentityService. This directory was repopulated with data, so I assumed authentication in Visual Studio/TF.exe/Or Developer Command prompt (whichever applies) is cached here.

An example from the script:

$tfCommand = "get '$($mapping)'"
$tfCommandOptions = "/recursive /login:$($userName),$($PAT)"
$fullCommand = "& `"$($tfPath)`" $($tfCommand) $($tfCommandOptions)"
Invoke-Expression $fullCommand

Where:

• $mapping is a Visual Studio workspace mapping (between the remote TFVC repo in Azure DevOps and a local folder). This workspace is private.
• $tfPath is the path to TF.EXE

Here is the login example:

$tfCommand = "workfold"
$tfCommandOptions = "/collection:$global:CollectionUrl /workspace:$global:Workspace /login:$global:Username,$global:PAT"
$fullCommand = "& `"$($TFPath)`" $($tfCommand) $($tfCommandOptions)"
$rawMappingResultAsString = Invoke-Expression $fullCommand

I am trying to understand the mechanics of this manual authentication and why is it required every now and then (almost every two weeks or so). If the TF commands have credentials when issued (in PowerShell script), why do I need that additional manual authentication sometimes?

I have a PowerShell script that interacts with a TFVC repo in Azure DevOps. The code uses TF.exe for this interaction using an Azure DevOps username and PAT.

The PAT is valid and has the needed permissions. I am using the PAT as a password for a TF GET command (see example below). However, I noticed that every now and then, authentication will fail "Error TF30063: You are not authorized to access ..." and I overcome this by opening the developer's command prompt and run any TF commands (such as trying to access to the workspace in question) which then prompts me to provide my Azure DevOps credentials (which I do). Then when I run the script again, it all works fine. I cleared all local Windows Credentials in Credential Manager, I also cleared these two directories trying to see how credential caching manifest itself for Visual Studio/TF.exe/Or Developer Command prompt (whichever applies):

• C:\Users{username}\AppData\Local\Microsoft\Team Foundation\8.0\Cache. This was not it as the content of this directory never changed after I reauthenticated in Developer Command Prompt.
• C:\Users{username}\AppData\Local.IdentityService. This directory was repopulated with data, so I assumed authentication in Visual Studio/TF.exe/Or Developer Command prompt (whichever applies) is cached here.

An example from the script:

$tfCommand = "get '$($mapping)'"
$tfCommandOptions = "/recursive /login:$($userName),$($PAT)"
$fullCommand = "& `"$($tfPath)`" $($tfCommand) $($tfCommandOptions)"
Invoke-Expression $fullCommand

Where:

• $mapping is a Visual Studio workspace mapping (between the remote TFVC repo in Azure DevOps and a local folder). This workspace is private.
• $tfPath is the path to TF.EXE

Here is the login example:

$tfCommand = "workfold"
$tfCommandOptions = "/collection:$global:CollectionUrl /workspace:$global:Workspace /login:$global:Username,$global:PAT"
$fullCommand = "& `"$($TFPath)`" $($tfCommand) $($tfCommandOptions)"
$rawMappingResultAsString = Invoke-Expression $fullCommand

I am trying to understand the mechanics of this manual authentication and why is it required every now and then (almost every two weeks or so). If the TF commands have credentials when issued (in PowerShell script), why do I need that additional manual authentication sometimes?

• visual-studio
• azure-devops

• You didn't show the script so readers like me can only guess that it wasn't written properly. – Lex Li Commented Apr 1 at 19:46
• See updated question. Thanks. – Yousef Imran Commented 2 days ago

2 Answers 2

To start, some credit to @alvin-zhao-msft as for what he put in his answer is correct (regarding OAuth, PAT authentication support in TF.EXE, etc.) and helpful but wasn't the exact answer I was looking for.

The actual answer (or part of it) is found here How to logout of tf.exe and login through another account with 2FA enabled?

Essentially, TF.EXE maintains its own source connections (independent from VS, at least by means of personal trial and error on my end). These connections also seem to contain the cached credentials (as I assume because once I removed them, I was asked to authenticate again when running commands like tf workspace myworkspace)

Although that answer doesn't exactly specify how to remove such connections (to clear cached credentials), Copilot helped me in this regard:

tf settings connections /remove:serverURL

I couldn't find this specific command in Team Foundation version control commands and I believe the /remove switch can take a list of serverURLs because when I cleared all connections and ran tf settings connections again I get:

The collection must contain at least one element.
Parameter name: serverUrls

Which indicates that parameter takes a list of serverURLs. Since all lists in other tf commands are semi-colon separated, I would assume this list is also semi-colon delimited. I haven't tried.

I hope this explains the mechanism by which TF.EXE caches credentials to source control.

Additional information for people to research and investigate:

The interactive authentication screen you get from running a TF command in a Developer Command Prompt or Developer PowerShell for the first time seems to be dependent on the Visual Studio version you are using. Claude.ai suggested that TF does relay on Visual Studio to generate OAuth tokens using some internal libraries and logic when creating its (TF's) source connections as mentioned above. Following this path I found this article Enhancing your Visual Studio authentication experience which clarified more about my setup. I do use VS 2022 (a higher version than the on in the article) and inspect my settings I am suing Windows authentication broker as the default authentication mechanism. And although the Azure DevOps instance is not connected to Microsoft Entra ID, the anization is on Azure and the users are on Entra ID (which perhaps what Visual Studio is communicating to when obtaining an OAuth token on behave of my Azure DevOps username and password since I am using the same credential in both, DevOps and Azure Entra ID). Especially since AzureCloud is listed in the "Registered Azure Clouds" in Visual Studio > Tools > Environment > Accounts.

I didn't want to spend more time researching this issue but I hope this post adds more details that might be helpful in the future.

Update

Given your latest update that your Azure DevOps Organization is not connected to MS Entra, you can still use an OAuth token as described here, but it requires user sign-in and MFA to authorize the Azure DevOps app to work on behalf of a user.

A workaround is to execute your PowerShell script within an Azure DevOps pipeline running on a self-hosted agent. This allows authentication via $(System.AccessToken), an OAuth token tied to the pipeline service account, eliminating the need for user intervention.

Here is the sample pipeline for your reference.

pool:
  name: Default
  demands:
  - Agent.ComputerName -equals Windows11-04 # Pickup the machine from the self-hosted agent pool to run the PowerShell script

steps:
- checkout: none 
  persistCredentials: true # Skip checkout resources while storing the $(System.AccessToken) for subsequent tf commands to use in the PowerShell script
  
- powershell: |
    Set-Location "E:\Source\Workspaces"
    Write-Host "================ Creating new TFVC workspace on the agent machine ================"
    tf workspace /new PipelineAgentWorkspace-ADO-$(Build.BuildId) /comment:"PipelineAgentWorkspace-ADO-$(Build.BuildId) created by the pipeline on the agent machine for TFVCProject" /collection:$(System.CollectionUri) /loginType:OAuth /login:.,$(System.AccessToken) /noprompt
    tf workspaces

    Write-Host "================  Mapping E:\Source\Workspaces\TFVCProject-$(Build.BuildId) with the remote TFVC repo  ================"
    tf workfold /unmap /workspace:PipelineAgentWorkspace-ADO-$(Build.BuildId)  $/ /collection:$(System.CollectionUri)  /loginType:OAuth /login:.,$(System.AccessToken) /noprompt
    tf workfold /map /workspace:PipelineAgentWorkspace-ADO-$(Build.BuildId) $/TFVCProject "E:\Source\Workspaces\TFVCProject-$(Build.BuildId)" /collection:$(System.CollectionUri) /loginType:OAuth /login:.,$(System.AccessToken) /noprompt
    tf workfold "E:\Source\Workspaces\TFVCProject-$(Build.BuildId)"
    
    Write-Host "================  Fetching the code from the remote TFVC repo into E:\Source\Workspaces\TFVCProject-$(Build.BuildId)  ================"
    tf get /loginType:OAuth /login:.,$(System.AccessToken) /noprompt
    Get-ChildItem "E:\Source\Workspaces\TFVCProject-$(Build.BuildId)" -Recurse -Depth 2 | Format-Table FullName

    Write-Host "================ Deleting the TFVC workspace on the agent machine  ================"
    tf workspace /delete PipelineAgentWorkspace-ADO-$(Build.BuildId) /loginType:OAuth /login:.,$(System.AccessToken) /noprompt
  displayName: Run TFVC commands

You haven’t provided details about your current workflow or script, but assuming you're trying to authenticate using a Personal Access Token (PAT) to execute Team Foundation Version Control (TFVC) commands in a PowerShell script on your Windows machine, please note that:

tf.exe does NOT support PAT-based authentication, and there are no plans to add support for it. This is also reflected in Microsoft's roadmap on Removal of TFVC in new projects

Over the past several years, we added no new features to Team Foundation Version Control (TFVC).

However, we gradually plan to phase out TFVC in all new projects and anizations, or in projects that do not have any current usage of TFVC.

With that being said, you may consider using an OAuth token (/loginType:OAuth /login:.,[OAuth token]) instead of a PAT. And to avoid interactive sign-ins when running a script, this token should be generated for a service principal (app registration) rather than a user principal. The service principal should belong to the Microsoft Entra ID (formerly Azure Active Directory) that your Azure DevOps anization is connected to, should be added into your Azure DevOps anization like a user with the access to your Azure DevOps TFVC repositories.

Below is a sample PowerShell script to generate an OAuth token and use it for authentication with tf.exe.

# Generate OAuth token for the service principal to access Azure DevOps anizations connected to the tenant
$tenantId= "20247162-xxxx-xxxx-xxxx-8ee25c8bdd23"
$applicationId = "1d538fc0-xxxx-xxxx-xxxx-778595c8319e"
$clientSecret = "xxxxxx"
$scope = "499b84ac-1321-427f-aa17-267ca6975798/.default" # Azure DevOps Enterprise App in AAD
$grantType = "client_credentials"
$body = @{
    client_id = $applicationId
    scope = $scope
    client_secret = $clientSecret
    grant_type = $grantType
}
$response = Invoke-WebRequest -Uri "https://login.microsoftonline/$tenantId/oauth2/v2.0/token" -Method POST -ContentType "application/x-www-form-urlencoded" -Body $body | ConvertFrom-json
$token = $response.access_token
$token

Set-Location "E:\Source\Workspaces"
$anization = "<YourADOOrgName>"
# Create new TFVC workspace mapped with the remote repo
tf workspace /new LocalWorkspace-ADO /comment:"Local workspace for TFVCProject" /collection:https://dev.azure/$anization /loginType:OAuth /login:.,$token /noprompt
tf workspaces
tf workfold /unmap /workspace:LocalWorkspace-ADO  $/ /collection:https://dev.azure/$anization  /loginType:OAuth /login:.,$token /noprompt
tf workfold /map /workspace:LocalWorkspace-ADO $/TFVCProject "E:\Source\Workspaces\TFVCProject" /collection:https://dev.azure/$anization  /loginType:OAuth /login:.,$token /noprompt
tf get /loginType:OAuth /login:.,$token /noprompt

Refer to this document for more details.

Use service principals & managed identities - Azure DevOps | Microsoft Learn