Azure DevOps Issue Tracker Not Working

We’re moving our build system from TeamCity to Azure DevOps. We’ve successfully configured the build and had it create a release/deploy within Octopus. We are also able to push Build Information. The problem comes when trying to enable the AzDO Issue Tracker in Octopus. When it’s disabled, we’re able to create releases as expected & the build info page displays commits. When we enable it, we get:

Error while fetching work item references from Azure DevOps: The server returned a sign-in page. Please confirm the Personal Access Token is configured correctly in Azure DevOps Issue Tracker settings, and is authorized to read scopes 'Build' and 'Work items'. 

When it’s disabled and I run the connection test, I get (weird that it talks about Jira but whatev):

When I enable it, I get:

The PAT has full access (for now, for testing):

Here’s the full configuration showing we’re using the URL:

We’re running v2021.3 (Build 8275).

I found these similar issues but the fixes suggested don’t seem to apply:

What else can we try to get this working?

Hi @josh_centerx,

Thanks for reaching out on our community forum. I’m sorry that you’ve been having problems with the ADO tracker.

Would you be able to send me a screenshot of the configuration you have in ADO for the Octopus connection? Also, this is likely not the cause, but to be extra safe, would you try the connection with your ADO Base URL set as instead of


Tried the trailing slash. No difference.

Octopus connection screenshot below. I think this is what you’re asking for? As noted, we’re able to push build info & create releases just fine until we enable the issue tracker. At that point, only pushing build info works. The create release fails with the same error we see on the build info page. I’ve included a snippet of the build log below also.

Channel: 'Dev' (this is the default channel)
  #   Name         Version         Source           Version rules          
  --- ------------ --------------- ---------------- -----------------------
  1   Deploy Dev   2022.01.1-dev   User specified   Range: PASS Tag: PASS  

Creating release...
There was a problem with your request.

 - Azure DevOps: Error while fetching work item references from Azure DevOps: The server returned a sign-in page. Please confirm the Personal Access Token is configured correctly in Azure DevOps Issue Tracker settings, and is authorized to read scopes 'Build' and 'Work items'.

Error from Octopus Server (HTTP 400 BadRequest)
Exit code: -7
##[error]Error: The process 'C:\hostedtoolcache\windows\octo\7.4.3576\x64\octo.cmd' failed with exit code 4294967289
##[error]Failed to deploy release The process 'C:\hostedtoolcache\windows\octo\7.4.3576\x64\octo.cmd' failed with exit code 4294967289
Finishing: OctopusCreateRelease

Hey @josh_centerx,

Thanks for that info. Would you be able to send over the complete build log for a successful and failing build/release from ADO? I’m not sure why you’d be successful without the tracker enabled but fail when it’s enabled.

Also, for clarification, are you using the ADO for issue tracking and code repo or do you use other tools like GitHub/Jira? Is your goal to include work items?


We use ADO for issue tracking and code repo. No GitHub/Jira. Yes, we want to set up the work item integration.

We tried to do this with TeamCity but ADO code repo & issue tracking & TC for CI wasn’t a supported scenario. Ref:

What’s the best way to send you a complete build log? I don’t really want to post it on a public forum.

Also, just to eliminate one more thing, I was able to use the PAT to read a work item via Postman.

Hey @josh_centerx,

Thanks for the clarification on your setup. For the success/failing build logs, you can DM me the logs, upload with a secure upload link (authorized for your email only), or send the logs to, and we can continue the thread there. I’m okay with whatever you prefer.


Good news/bad news situation…

I think I figured out one problem. There was a leading zero in our versioning scheme (i.e., 2022.01.x instead of 2022.1.x). AzDO “helpfully” removed the leading 0 from the nuget package version in the feed so I think that’s why Octopus couldn’t find it.

I ran some new builds but now am getting the “looping logins” error (Error while fetching work item references from Azure DevOps: 500 (InternalServerError). “Unable to complete authentication for user due to looping logins”) that was reported in one of the tickets I linked to before from the Build Info screen in Octopus.

With the issue tracker enabled, I still get failures in the build to create a release.

Forgot to mention before, we’re using the Azure package feed for the nuget packages we build, not the Octopus internal registry.

I’ve uploaded two build logs. 551 was successful with the issue tracker off. 552 failed & the only diff was enabling the issue tracker.

Hey @josh_centerx,

Something came to mind when reviewing our ADO tracker documentation. Were you pushing build info via the create Octopus release step in your Azure pipeline? If so, you’d want to disable that as it can cause conflicts with the Tracker. Our docs page has more info - Azure DevOps work item tracking integration - Octopus Deploy.

I hope this helps.


No, I’m using the build info step to send build info not the legacy setup

Ok, so at least that possibility is out. A colleague noticed that the build logs you sent were performed on different machines. Do you think that could be contributing to the errors? Can you force build on one machine so we can test if this is related to the build machine?

I doubt it. We’re using the Microsoft hosted agents so there’s not much control on the individual machine. It’s been repeatable across multiple runs tho

Hey @josh_centerx,

Can you recreate the personal access token inside Azure and try using a completely new token? I know that you had sent a screenshot showing full access, but with the initial access token error and the looping login, it seems token or access permission related.


I did that yesterday when I went & validated the token worked via Postman just to be sure.

Is there a way for me to validate the version of the extension installed? I noticed a comment in the github repo about supporting spaces in project names from November but the DLL on our server is from April. We have a space in our project name, so that could impact us. Can extensions be updated independently of the main software?

Hey @josh_centerx,

You should be able to see what version of the plugin you’re using on your plugin management page in ADO. The plugin is updated and versioned separately from Octopus. You could also try uninstalling the plugin and reinstalling/reconfiguring since we aren’t making any progress with troubleshooting.

Sorry, I meant the “Azure DevOps Issue Tracker” version included with Octopus, not the Octopus extension in Azure DevOps.

Ah I see. That is included in Octopus as a whole but it’s not really a separate thing like ‘tracker’ makes it sound. The extension in ADO is really the ‘tracker’, it just communicates with Octopus server and allows for ADO to push related build info to Octopus.

Ah, well, the extension is 4.2.492 (Latest) from October so it wouldn’t have the fixes from November 2021 either, right? Seems like we can’t use the feature until the code from this PR becomes available, right? Adding multi connections by johnsimons · Pull Request #44 · OctopusDeploy/AzureDevOpsIssueTracker · GitHub

Hey @josh_centerx,

I’ll have to reach out to the development team to get some clarity on that but I will get back to you as soon as I hear from them. I’ll also ask if they have any advice on your errors, maybe we can get pointed in the right direction.


Hi Josh,

Just stepping in for Brent from the Australia based team!

After some discussion with the engineers, we have decided to release a build which should contain a fix for this issue early directly to you, so that you can get unblocked.

The build is 2021.3.10526 and is currently making it’s way through our testing before it becomes available in GA. It’s looking very promising but as it’s currently making it’s way through our testing suites, there could be some undiscovered issues and so additional caution is advised.

Before upgrading, please make sure to take a full backup of the Database and Master-key

It includes a number of improvements regarding performance and diagnostics and should allow us to better see what’s going on if the issue isn’t directly resolved.

Please feel free to let me know if you have any questions or concerns!

Best Regards,