Azure DevOps: Visual Studio fails to connect to legacy {org}.visualstudio.com projects with "requested operation is not allowed" error.

Fredrick Johan van der Merwe 0 Reputation points
2026-09-29T10:36:50.5766667+00:00

Hi all,

I am unsure where the correct place to post this would be.

We have started experiencing "Server was unable to process request. ---> The requested operation is not allowed." errors when trying to connect to repositories hosted on Azure DevOps.

What we have attempted:

  • Unlinking and relinking accounts.
  • Clearing the credential caches on the affected devices.
    • Also removing the credentials with the Credential manager.
  • Completely re-installing Visual Studio.
  • Reverting to the Windows version before the issue.
  • Confirmed via a swap test that the issue follows the specific device, not the user account
    • An affected user's account connects successfully on an unaffected device, and vice versa.
  • Verified HTTPS connectivity to both the legacy and dev.azure.com endpoints via curl
    • Succeeds without error on affected devices.
  • Confirmed WebView2 Runtime version and Windows build are consistent across affected/unaffected devices.

Reproduction steps:

  1. Open Visual Studio (2019, 2022, or 2026) on an affected device.
  2. Go to Team Explorer -> Manage Connections.
  3. Double-click an affected project / Right click -> Connect.
  4. Receive error dialog. Screenshot 2026-09-29 122524

Any advice on how to resolve this would be greatly appreciated.

Azure DevOps
Answer recommended by moderator
Fredrick Johan van der Merwe 0 Reputation points
2026-09-30T08:19:02.1533333+00:00

As the issue appears to be with the legacy URLs.

We have decided to migrate all legacy URLs to the new format, which appears to have permanently resolved the issue.

Was this answer helpful?

0 comments

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-09-29T10:37:20.1366667+00:00

    This pattern points to a device-side connectivity or authentication path issue in Visual Studio rather than an Azure DevOps account or repository permission problem, because:

    • the failure follows the device, not the user
    • browser/curl access works
    • dev.azure.com/{organization} works, but legacy {organization}.visualstudio.com connections fail in Visual Studio
    • reinstalling Visual Studio and clearing credentials did not change the behavior

    Recommended next steps:

    1. Fully sign out and clear browser state used by Visual Studio.
      • Go to https://aka.ms/VsSignout.
      • Clear browser data with Ctrl+Shift+Delete.
      • Remove cookies, cached files, and autofill data.
      • Clear Microsoft Edge data specifically, because Visual Studio uses Microsoft Edge cookies.
      • Close all browser windows and all Visual Studio instances.
      • Test again, preferably first in an InPrivate window.
    2. Remove and recreate the Azure DevOps connection inside Visual Studio.
      • In Team Explorer, remove all existing Azure DevOps connections.
      • Delete cached credentials from Windows Credential Manager.
      • Restart Visual Studio.
      • Add the Azure DevOps connection again using current credentials.
    3. Check for proxy, firewall, or VPN differences on affected devices. The documented causes for Visual Studio connection failures include:
      • corporate proxy or firewall blocking TLS traffic
      • VPN interference
      • local proxy misconfiguration
      • DNS resolving to the wrong endpoint
      • IPv6 enabled on the machine when the network does not support it
      Specific checks:
      • Temporarily disconnect any VPN and retry.
      • Verify the corporate proxy/firewall allows *.visualstudio.com, *.azure.com, dev.azure.com, and *.dev.azure.com on port 443.
      • If the error path references 127.0.0.1, check whether a local proxy is configured but not running.
      • Compare DNS resolution on affected vs unaffected devices.
      • If IPv6 is enabled, test whether disabling IPv6 changes the behavior.
    4. Check for TLS/SSL negotiation issues on affected devices. Visual Studio connection failures such as secure channel errors and forcibly closed connections can be caused by:
      • proxy or firewall blocking certain TLS versions
      • TLS 1.3 being enabled on the machine when the network does not support it
      • group policy restricting allowed SSL algorithms
      A safe validation path is:
      • compare TLS-related policy and network security appliance behavior between affected and unaffected devices
      • confirm security appliances support TLS 1.2 and above
      • ensure required Azure DevOps endpoints are allowlisted
      Warning: disabling TLS 1.3 is a machine-level change and should be treated as a temporary test only because it changes system security behavior.
    5. If the issue is only with legacy {organization}.visualstudio.com connections in Visual Studio, test by reconnecting using the modern organization URL format https://dev.azure.com/{organizationName} wherever possible. The documented Azure DevOps URL format to verify is https://dev.azure.com/{organizationName}.
    6. If the problem remains, collect diagnostics and escalate.
      • Create a browser trace of the failed sign-in attempt.
      • Include the exact error, affected vs unaffected device comparison, and the steps already tried.
      • Open a Microsoft Support request.
      • Community escalation is also available through Azure DevOps Developer Community.

    Given the troubleshooting already completed, the highest-value checks are:

    • proxy/firewall allowlisting for legacy and current Azure DevOps domains
    • VPN/local proxy differences
    • DNS and IPv6 differences between affected and unaffected devices
    • TLS policy or security appliance differences on the affected machines

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.