Unable to Import Azure DevOps 2019 Repositories

Hello all,

I am currently having an issue with importing Azure DevOps 2019 Repositories into my new SonarQube 10.4. I’ve successfully added my on-prem DevOps server to SonarQube and all projects load, however I receive the message " Could not fetch repositories for this project. Contact your system administrator, or update your personal access token (which redirectedto http: localhost:9000/projects/create?mode=azure&resetPat=1). I’ve tried multiple users creating a PAT with no luck.

A little more background: This is a newly built Rocky Linux 8.9 server running SonarQube 10.4, Java 17 and Postgresql 14. We have an old version of SonarQube (8.9) running on a Windows server but the previous DevOps Engineer left every version in place when upgrading and it’s caused a mess which has prevented me from upgrading that server to LTS 9.9. New build it is.

Any direction or where to look to resolve this would be most appreciated.

Thank you,

Hey there.

The logs (specifically web.log) should contain more details. You can also raise the log level in the global Administration > System > Log Level if needed.


I checked the log and discovered that I was getting this error message Unable to contact Azure DevOps server for request [http://devops:8080/tfs/company/_apis/projects?api-version=3.0]: [No route to host].

So with that I checked google and found two other Sonarcommunity posts, but they both are working under https and we’re utilizing http:// for our internal-only DevOps 2019 and they don’t exactly match what’s happening here. It doesn’t appear we are on html/2 from the first post which you replied to Colin. I did follow the steps and run the Curl -X command in the second link and received the following error: TF400813: Resource not available for anonymous access. Client authentication required. - Azure DevOps Server

Thank you,

This sounds a bit like firewall rules in between your SonarQube server and your Azure DevOps 2019 server (no route to host indicates the request never left your server).

Did you run your curl from the same machine as your SonarQube server, or from your own machine? I’d be surprised you made it as far as an authentication issue if you issued the command from the same network location as your SonarQube server.

Hi Colin,

The curl request was run on our SonarQube server.


Have you configured anything special in your conf/sonar.properties file – like proxy information? Or is it pretty vanilla?

Hey Colin,

It’s pretty Vanilla. We’re utilizing Postgresql on localhost so that and the creds are setup, I setup LDAP by comparing it to our previous sonar.properties file from our older machine.

I did also just disable the local firewalld and tested again and ran into the same thing and confirmed that it was allowed through our GAV as well so there shouldn’t be anything else blocking those requests.

I’ve done some more digging and found that some instances of PAT not being passed along appropriately so I ended up editing access on the DevOps server directory %ProgramData%\Microsoft\Crypto\RSA\MachineKeys for our service account running DevOps. With that I’m now seeing the PAT pass in the developer tools but still getting the could not fetch repositories error.


That’s pretty… suspicious.

Is the error the same in the backend logs? [No route to host]?

The web log for today is very empty. I ended up revoking and re-issuing the PAT around 10 AM EST this morning so received a “Invalid personal access token” before I re-added it and there’s been nothing new in the web logs since then even though I added the new PAT and tested by logging out/back in > Projects > Create Project > From Azure DevOps

As an update the only thing that was written to the web.log file yesterday is this:
web.log (6.5 KB)

Also, I believe that the PAT may have been working the whole time and my above change was unnecessary and potentially distracting from the issue. Here is a screenshot from Administration > General Settings > Configuration > DevOps Platform Integration and this has shown green since I had SonarQube up and running which indicates that the PAT is accepted.

We can close this out. I never found a solution so I ended up working around on my old windows version and blew away the old configuration/installation paths and then re-installing so we are running on 9.9 LTS currently.