[Azure DevOps] Windows-2016 environment removal postponed until July 31, 2022 #5403
Comments
|
Noob here, our yml config is already using
|
|
@kningyi please remove everything below the (name and demands) and you should be good to go |
|
IMPORTANT NOTE FOR THOSE OF YOU STILL STRUGGLING WITH WIN2016 BROWNOUT NOTICE. CHECK EVERYTHING! NOT JUST YOUR PIPELINE CODE, CHECK PIPELINE TRIGGERS POOLS. CHECK RELEASES POOLS, CHECK ALL THE POOLS EVERYWHERE ON YOUR DEVOPS ACCOUNT. WHAT WILL HAPPEN IS YOU WILL EVENTUALLY FIND SOMETHING STILL SET TO USE WIN2016 POOL. ONCE YOU FIND ALL OF THEM YOUR ACCOUNT WILL NO LONGER GET THE BROWNOUT NOTICE EVEN DURING THE SCHEDULED TIMES. SO IF YOU ARE GETTING THE NOTICE ITS NOT YOUR WIN2017 POOL, OR WIN-LATEST IN THE YML, ITS SOMETHING ELSE, AZURE NOTICES ARE DOING A TERRIBLE JOB ON THIS WITH THEIR WORDING AND WHERE THE NOTICE APPEARS. THE NOTICE MEANS YOUR AZURE DEVOPS ACCOUNT IS STILL USING WINDWOS POOL SOMEWHERE, YOU DID NOT CHECK EVEYWHERE. |
|
I have a release pipeline (the one in the Releases tab) that gets triggered after a pipeline from the Pipelines Tab that I use for deployment to azure. This deployment keeps failing because of the 2016 error. In the normal build pipeline I was able to set the vmImage but I don't see any way to access the yaml or change the image in the release pipeline edit page. How can this be done? I have tried searching this up plenty of times with no luck. Edit: lol I can't believe that alluded me for so long. In case anyone else is looking. When you edit the release pipeline its under the tasks tab and then the category "run on agent". Looks like 2019 was recently made the default finally. |
upgrade to `windows-latest` per instructions from actions/runner-images#5403
upgrade to `windows-latest` per instructions from actions/runner-images#5403
|
Isn't Windows Server 2016 going to get security updates until 2027 and this "motivation" is simply misleading? |
|
As discussed in #5238
The brownout error message still says April 1 and points to an old ticket with out-of-date information. |
|
We are having a pipeline which runs on 2016 Agent Specification. After changing the Agent Specification to 2019 or windows Latest we are getting below Error |
I agree 100% with this. According to Microsoft's own documentation, Windows Server 2016 will continue to get security updates until Jan 12, 2027 when it will finally stop receiving it which would justify for Microsoft to remove support for it on pipelines or start these brownouts. |
@Ziya137200 @kningyi please remove the line (26) with the reference to pool 'Hosted VS2017'. |
As the windows 2016 hosted runners is deprecated, the best practice is to replace it with windows-latest. Any new PSMDProject shouldn't use the 2016 host anymore. See GitHub Issue: actions/runner-images#5403 Windows 2016 hosted runners were scheduled for full removal on April 1, 2022. However, we are still seeing significant usage from customers and we want to give them more time to migrate to the new runners. In order to give customers another chance to move to either windows-2019 or windows-2022 we will delay the removal of windows-2016 until June 30, 2022.
|
I keep getting this error in my release pipelines and cannot figure out where to go to fix it. I am not using YAML but CLI. |
|
I get this message the whole day. Could you move your maintenance window out of work-hours next time? We'd appreciate it. Additionally our systems are not using any windows-2016 related element, so the error itself makes no sense... |
|
@mohitook if the systems don't use then you won't see the message. Maybe some of your jobs are using windows-2016 as it was the default image some time ago? |
For reference see: actions/runner-images#5403
For reference see: actions/runner-images#5403
|
Hello. |
|
@rushfrisby what error do you have? Windows-2019, for example, has a reduced set of installed .Net frameworks: |
|
@miketimofeev |
|
@rushfrisby, Could you bump .Net version to 4.6.2? |
|
@rushfrisby I ran against this issue.
Those were my steps to correct the issue. |
|
EDIT: Okay, this comment can be disregarded. The problem was resolved for us. We resolved this by updating one of our native C/C++ dependencies. It builds and passes CI running on the new Windows image. Original commentWe have a project that started experiencing CI errors in the new image, even when we installed older Visual Studio Build Tools with Chocolatey. So newer Visual Studio isn't the culprit. atom-community/atom#428 Note: Building on the new image caused the problem. We have been testing on the Does anyone have any idea what else is different about the new CI image environment that would have caused this? Right now it's looking like a subtle difference of behavior in some native C++ addon code we build for a Node module or two. (Async code that never returns, if I understand correctly.) |
miketimofeev
changed the title
|
The new retirement date is set — July, 22 |
miketimofeev
changed the title
|
The retirement date is shifted to July, 31 |
|
LOL, can you guys please, please, please stop shifting the retirement date :) every time we need to tell our developers to stop using Win2016 as Agent type, and each time you guys postpone the deadline slowly people start using it again (I know their own fault), and we need to start warning them again, but we (and also Microsoft) are loosing our credibility on when they are actually decommissioned. |
|
@melchiorbc sorry for the inconvenience, hopefully, this is the last one 🤞 |
|
Two more brownout dates are set:
|
|
Windows 2016 environment is finally deprecated in ADO. |
Image has been deprecated actions/runner-images#5403
…is deleted The Windows 2016 images have been deprecated for a while now and regularly browning out. There's no viable replacement for testing that we can generate a usable `--backend=vs2017` project, so we cannot migrate this to anything else. The deprecated images are finally fully removed. See actions/runner-images#5403 And now we get universal red CI, we cannot just wait for the brownout to end to get a tiny little bit of final testing. Simply remove the jobs so that we can tell if all the CI that actually runs, is passing.
…is deleted The Windows 2016 images have been deprecated for a while now and regularly browning out. There's no viable replacement for testing that we can generate a usable `--backend=vs2017` project, so we cannot migrate this to anything else. The deprecated images are finally fully removed. See actions/runner-images#5403 And now we get universal red CI, we cannot just wait for the brownout to end to get a tiny little bit of final testing. Simply remove the jobs so that we can tell if all the CI that actually runs, is passing.
…is deleted The Windows 2016 images have been deprecated for a while now and regularly browning out. There's no viable replacement for testing that we can generate a usable `--backend=vs2017` project, so we cannot migrate this to anything else. The deprecated images are finally fully removed. See actions/runner-images#5403 And now we get universal red CI, we cannot just wait for the brownout to end to get a tiny little bit of final testing. Simply remove the jobs so that we can tell if all the CI that actually runs, is passing.
``` [error]The Windows 2016 environment is deprecated, consider switching to windows-2019 or windows-2022 (windows-latest). For more details, see actions/runner-images#5403 [error]The remote provider was unable to process the request. ``` Also increase a macOS timeout.
|
|
same error. I use windows-2019 |
Hi Mike, are you sure of this? Up to today we still see jobs using the "vs2017-win2016" Microsoft Hosted Agent image. |
|
@melchiorbc could you share a few links, please? I don't need access to pipelines, will take a look at telemetry by those urls |
|
@miketimofeev I checked and I do see now the jobs trying to use 'vs2017-win2016' do get cancelled by Microsoft stating this is a deprecated environment, only people are still able to pick the 'vs2017-win2016' in their pipelines from the dropdown with VM types (which is confusing). |
|
@melchiorbc this is fixed now, sorry for the inconvenience |
and others
Breaking changes
Windows 2016 hosted runners were scheduled for full removal on April 1, 2022. However, we are still seeing significant usage from customers and we want to give them more time to migrate to the new runners. In order to give customers another chance to move to either windows-2019 or windows-2022 we will delay the removal of windows-2016 until July 31, 2022.
To raise awareness of the removal, we will have rolling 24-hour periods where the image will be unavailable for customers. During these "brownout" periods, customers will see an error message indicating that the image is slated for removal on July 31, 2022. The schedule for those brownout periods is as follows for Azure DevOps:
See the original announcement at #4312
Target date
July 31, 2022
The motivation for the changes
Windows Server 2016 Active support ends on 11 Jan 2022 and Windows Server 2022 VM image is going out of beta later this year.
As part of our ongoing efforts to keep GitHub and Azure Devops hosted runners updated and secure, the Windows 2016 virtual environment will be removed from GitHub Actions and Azure DevOps.
Possible impact
Workflows targeting the Windows 2016 image will fail.
Virtual environments affected
Mitigation ways
Change your workflows to use windows-latest, windows-2022, or windows-2019
The text was updated successfully, but these errors were encountered: