Azure DevOps pipeline specifies "windows-latest" but brownout caused it to fail

Caleb Pourchot 40 Reputation points
2025-06-03T20:39:10.9466667+00:00

I have 2 pipelines in Azure DevOps. Both specify "windows-latest" as the name of the pool to use. However, today's brownout caused one of my pipelines to fail and the results of the run indicate it was trying to use a windows 2019 image.

variables:
  # Azure Resource Manager connection created during pipeline creation
  azureSubscription: '280dc2b1-2806-4ab6-8c90-3dc97c7f4edd'

  # Function app name
  functionAppName: 'landscapejobs'

  # Agent VM image name
  vmImageName: 'windows-latest'

  # Working Directory
  workingDirectory: 'LandscapeJobs'

stages:
- stage: Build
  displayName: Build stage

  jobs:
  - job: Build
    displayName: Build
    pool:
      vmImage: $(vmImageName)

    steps:
    - task: UseDotNet@2
      inputs:
        packageType: 'sdk'
        version: '8.x'
    - task: DotNetCoreCLI@2
      displayName: Build
      inputs:
        command: 'build'
        projects: |
          $(workingDirectory)/*.csproj
        arguments: --output $(System.DefaultWorkingDirectory)/publish_output --configuration Release

    - task: ArchiveFiles@2
      displayName: 'Archive files'
      inputs:
        rootFolderOrFile: '$(System.DefaultWorkingDirectory)/publish_output'
        includeRootFolder: false
        archiveType: zip
        archiveFile: $(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip
        replaceExistingArchive: true

    - publish: $(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip
      artifact: drop

- stage: Deploy
  displayName: Deploy stage
  dependsOn: Build
  condition: succeeded()

  jobs:
  - deployment: Deploy
    displayName: Deploy
    environment: 'development'
    pool:
      vmImage: $(vmImageName)

    strategy:
      runOnce:
        deploy:

          steps:
          - task: AzureFunctionApp@2
            displayName: 'Azure functions app deploy'
            inputs:
              connectedServiceNameARM: '$(azureSubscription)'
              appType: functionApp
              appName: $(functionAppName)
              package: '$(Pipeline.Workspace)/drop/$(Build.BuildId).zip'
              deployToSlotOrASE: true
              slotName: 'stage'

##[error]This is a scheduled Windows Server 2019 brownout. The Windows Server 2019 image will be removed on 2025-06-30. For more details, see https://github.com/actions/runner-images/issues/12045

##[error]This is a scheduled Windows Server 2019 brownout. The Windows Server 2019 image will be removed on 2025-06-30. For more details, see https://github.com/actions/runner-images/issues/12045

##[error]The remote provider was unable to process the request.

Pool: Azure Pipelines

Image: windows-2019-vs2019

Azure DevOps
0 comments No comments
{count} votes

Accepted answer
  1. Suwarna S Kale 3,391 Reputation points
    2025-06-04T03:09:14.58+00:00

    Hello Caleb Pourchot,

    Thank you for posting your question in the Microsoft Q&A forum. 

    The issue you're encountering stems from Azure DevOps' transition away from Windows Server 2019, even when specifying "windows-latest" as the VM image. While "windows-latest" should theoretically use the newest available image, Microsoft's brownout period is causing unexpected failures as they phase out older versions. Your pipeline correctly defines the image variable, but the underlying infrastructure is enforcing compatibility checks during this transitional period.

    The error message explicitly indicates this is part of Microsoft's planned deprecation process for Windows 2019 runners.

    To resolve this, you could either wait for Microsoft to complete their migration (as "windows-latest" will eventually point to newer versions automatically) or explicitly specify "windows-2022" in your YAML to bypass the brownout restrictions. This situation highlights how cloud platform updates can sometimes impact pipelines unexpectedly, even when using version-agnostic labels like "latest." 

    If the above answer helped, please do not forget to "Accept Answer" as this may help other community members to refer the info if facing a similar issue. Your contribution to the Microsoft Q&A community is highly appreciated. 

    2 people found this answer helpful.
    0 comments No comments

3 additional answers

Sort by: Most helpful
  1. Durga Reshma Malthi 5,310 Reputation points Microsoft External Staff Moderator
    2025-06-04T09:16:34.45+00:00

    Hi Caleb Pourchot

    This issue is happening because Azure DevOps is temporarily defaulting windows-latest to windows-2019 due to a scheduled Windows Server 2019 brownout.

    Microsoft is phasing out Windows Server 2019, and during brownout periods, pipelines using windows-latest may unexpectedly run on Windows Server 2019 instead of Windows Server 2022.

    Modify your pipeline YAML to explicitly use windows-2022 instead of windows-latest:

    variables:
      vmImageName: 'windows-2022'
    

    This ensures your pipeline always runs on Windows Server 2022, avoiding future brownouts.

    Hope this helps!

    Please Let me know if you have any queries.

    If you found the information helpful, please click "Upvote" on the post to let us know and consider accepting the answer as the token of appreciation. Thank You.

    2 people found this answer helpful.
    0 comments No comments

  2. Willem-Jan van Kranenburg 0 Reputation points
    2025-06-10T14:42:10.71+00:00

    Hi Durga,

    Why is this happening? According to the documentation of Microsoft at https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops&tabs=windows-images%2Cyaml#software, windows-latest should be windows-2022. Now we have to unexpectedly modify our deployment pipelines causing delays in the deployments of production environments.

    It's not acceptable that when a 'brownout' is set for a specific version, higher versions (which 'windows-latest' should be) are also affected.

    Please make sure that when next "brownouts" happen this does not affect the 'latest' versions

    0 comments No comments

  3. Durga Reshma Malthi 5,310 Reputation points Microsoft External Staff Moderator
    2025-06-10T15:19:22.47+00:00

    Hi Willem-Jan van Kranenburg

    I understand your concern.

    Based on Microsoft's documentation, windows-latest is mapped to windows-2022.

    It could be because of following reasons:

    • Azure DevOps may be caching old mappings for windows-latest in older pipeline runs or even certain projects or organizations.
    • Some pipelines may still be explicitly or implicitly targeting windows-2019 even though the vmImageName is set to windows-latest
    • If your pipeline was created a long time ago, it might be referencing an older agent spec internally even if you're overriding it in YAML.

    But during brownout periods, some pipelines may still experience disruptions.

    The brownout for Windows Server 2019 is part of Microsoft's scheduled deprecation - https://devblogs.microsoft.com/devops/upcoming-updates-for-azure-pipelines-agents-images/

    User's image

    Please follow the Microsoft Hosted Agents for updates to anticipate future changes.

    I suggest you update yaml like this: vmImage: 'windows-2022'. Don't rely on windows-latest unless you’re okay with Microsoft possibly changing it again in the future without notice.

    Hope this helps!

    Please Let me know if you have any queries.

    If you found the information helpful, please click "Upvote" on the post to let us know and consider accepting the answer as the token of appreciation. Thank You.


Your answer

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