Windows Update for Business and the retirement of SAC-T
Published Feb 14 2019 12:00 PM 354K Views
Microsoft

Update 7/15/2019: As a reminder to customers on Windows 10, version 1809 using Windows Update for Business with a Branch Readiness Level set to Semi-Annual Channel and a default 0-day deferral, your 60-day one-time built-in deferral period will end on Tuesday, July 23, 2019 and your devices will begin updating to Windows 10, version 1903.

Update 2/28/2019: This change does not affect SAC-T for Office 365 ProPlus customers. See below for details.


In my post last May on Windows 10 and the “disappearing” SAC-T, I explained how we simplified and aligned our Windows servicing terminology with Office, reflecting that there are two Semi-Annual Channel (SAC) releases each year. I also explained that with Windows, there was never actually a Semi-Annual Channel (Targeted), or SAC-T, release; rather, SAC-T merely reflected a milestone for the semi-annual release. Unless you were using Windows Update for Business, the SAC and SAC-T designations had no impact on when your devices would be updated. At the time, we had not yet completed the work necessary to deliver the changes needed for Windows Update for Business to reflect the alignment with Office so we continued to show dates for both the SAC and SAC-T milestones on the Windows 10 release information page.

We have now completed that work. Beginning with Windows 10, version 1903 (the next feature update for Windows 10), the Windows 10 release information page will no longer list SAC-T information for version 1903 and future feature updates. Instead, you will find a single entry for each new SAC release. In addition, if you are using Windows Update for Business, you will see new UI and behavior to reflect that there is only one release date for each SAC release. If you use System Center Configuration Manager, Windows Server Update Services (WSUS), or other management tools, there will now only be one feature update published to WSUS, and this will occur at the time of release. (Note: This change does not impact the availability of SAC-T for Office 365 ProPlus. The SAC-T channel will continue to be an option for Office 365 ProPlus customers. For more information, see Overview of update for channels for Office 365.)

With this upcoming change, Windows Update for Business customers may have a few questions and I’ll try to address those now. To restate what I said above, unless you are using Windows Update for Business, the changes discussed below have no impact on when your devices get updated.

With the release of Windows 10, version 1903, how will my Windows Update for Business configuration and execution reflect the removal of SAC-T?

For releases prior to version 1903, Windows Update for Business customers had two settings they could utilize to designate when feature updates should be installed on their devices. The first was the branch readiness level (SAC or SAC-T), and the second was the deferral period, which specified the number of days after the branch readiness level-based date before an update was offered to a device.

Once your organization’s devices have been updated to Windows 10, version 1903, the configuration of Windows Update for Business will be simpler, enabling you to choose a single deferral value based solely on the SAC release date. That means, if you are trying to set up validation flights in your environment using Windows Update for Business, or stage updates in waves, you will do so from a common release start date, which should simplify the deployment process overall.

I want to clarify; with these changes, we will not change your deferral value. Instead, it will remain as it was configured following the update to version 1903. In addition, while all Windows Update for Business device deferrals will now be based on the release date (you will no longer have to configure this), you will continue to have the option to enroll devices in the Windows Insider Program and choose a pre-release ring, such as Slow, Fast, or Release Preview.

The image below shows the Settings panel as it looks today with Windows 10, version 1809.

wufb-branch-readiness-1809.png

When version 1903 is released, it will look like this:

wufb-branch-readiness-1903.png

As you can see, it shows only pause and deferral settings; Semi-Annual Channel (Targeted) is no longer presented as an option. Again, this change will only be seen once you have deployed Windows 10, version 1903 and will only impact future feature updates after version 1903. Devices enrolled in the Windows Insider Program; however, can already see these changes.

How is Microsoft going to handle the transition to Windows 10, version 1903 for customers who have their branch readiness level configured for SAC?

As I said above, with version 1903, we will cease to publish both SAC and SAC-T dates. Each release will have a single SAC release date so we will handle this one-time transition in the following manner:

  • Windows Update for Business customers who have configured a deferral based on the SAC-T branch-readiness level (remember, this really is the actual release date), devices will be offered the update once the configured number of deferral days have passed. Thus, no change from previous releases.
  • For devices that have been configured with a branch readiness of SAC, for the upgrade to version 1903 only, we will add an additional 60 days to the configured deferral. This will simulate the delay previously experienced when Microsoft declared the SAC milestone. For example, if your device is currently configured to defer updates 30 days from the SAC release date, for the upgrade to version 1903 (and this time only), we would append a 60-day delay to that configured 30-day deferral–meaning that the device would be upgraded 90 days (60+30) after version 1903 is released. (Note that the additional 60 days will be handled on our service side, and will not be reflected in your device configuration.)
  • For subsequent feature updates after version 1903, your Windows Update for Business configuration deferral value will be whatever it was before version 1903; we are not modifying that value.

For future upgrades beyond Windows 10, version 1903, to establish an additional delay and recreate your deployments rings on the schedule you want, you will need to update your deferral value. Using the same example above, you would change the deferral value from 30 to 90 days. Or, if you want to create a three-ring deployment model, you could have three groups of devices, designated simply with deferral values from the single release date, perhaps 30, 60, and 90 days.

If you’re interested in learning more, or would like to see how you can use tools like Configuration Manager, WSUS, or Windows Update for Business to manage updates, see the Quick guide to Windows as a service. To learn more about Windows as a service, check out the Windows as a service gateway on Docs.

73 Comments
Silver Contributor

"If you use System Center Configuration Manager, Windows Server Update Services (WSUS), or other management tools, there will now only be one feature update published to WSUS, and this will occur at the time of release." I didn't get that part. We were already getting just one release in WSUS. I don't recall seeing SAC-T releases.

Iron Contributor

This is horrible and an ongoing insult to your customers given that you are unable to release a single stable feature release of Windows 10. When will you - Microsoft - release stable software? And you can say, in marketing-speak, that there "never was really a difference between SAC-T and SAC" but the very fact it was enshrined in the software catches you out. 

While the naming of the CBB/SacT was confusing, the fact that all businesses still want a date that we can deem that we're past the beta testing phase of these releases is still needed.

I STILL have not received 1809 on my home Laptop due to icloud software being on there and thusly it's held off until mid Feb.

 

We still need a time in the sand that we all trust your releases.  We don't.  Work on that.

 

And may I say this just makes it more confusing, not less.

Iron Contributor
How is this aligned with Office, which has SAC-T and SAC and Monthly feature update release channels?
Iron Contributor

there was never actually a Semi-Annual Channel (Targeted), or SAC-T, release; rather, SAC-T merely reflected a milestone for the semi-annual release

...

As I said above, with version 1903, we will cease to publish both SAC and SAC-T dates. Each release will have a single SAC release date


When you write all this, you totally pretend like the consumers don't exist (this is typical for your posts in general). There was a SAC-T all right, and it was the date when the new version would start rolling out to the consumers. Now you suddenly never had SAC-T and would stop publishing its date. So what do you call the date on which you start pushing the new version to Home editions (sans Insider rings)? 

 

Also (and this is the main question you failed to address), are you going to start pushing new releases to WUfB and consumers on the same date? It's not clear whether SAC takes the SAC-T place as the "official release" date (i.e. when anybody can download it). For example, 1809 was released to SAC-T on 11/13/2018 while there's no SAC release date at this time. If the change were in place now, would you have released 1809 to SAC on 11/13/2018? 

Copper Contributor

 Any plans on adding additional time for the defferal policy? We could set up the months of support but only 365 days defferal...

Copper Contributor
 

- Yes, they  would have released 1809 to SAC on 11/13/2018 ... (but only if you have no deferrals in place)

 

Look, we have in our GPs this for all our PCs: 

- readiness level: SAC

- deferral period: 180 days

 

So our PCs now update to new version 6 months after its SAC declared date ... so this is cca 8-10 months after SAC-T date.

 

So what I will do right now to be prepared for the new change (and to be good to forget about it :) is this:

- change GPs to this:

  - readiness level: SAC-T

  - deferral period: 300 days

 

And that's it - I can forget about all this (with hope, Microsoft will be able to stabilize each version after 300 days :) 

 

 

 

Silver Contributor

I haven't used WU for Business policies, but from this blog i gathered that SAC-T won't be used anymore (after 1903), so having SAC-T policy won't have any effect after the 1903?

Copper Contributor

SAC-T Policy after 1903:

  - readiness level: this will disappear from GPs

  - deferral period: this will stay and you will have to adjust it to meet your needs - otherwise new release after 1903 (first will be 19H2) will be installed as soon as it is RTM

Steel Contributor
Will refresh media continue to be released, or will that also be a one-and-done release with each feature update? Since Windows 10 began, volume ISOs and WSUS KBs were refreshed to the latest build number and re-released once they hit CBB/SAC.
Microsoft

Hi Oleg,

 

If your not using WuFB deferral, then this has never and will not going forward have any impact to make any change for you.

JW

Microsoft

Hi ajc196

 

Already are. Starting with 1807, we have been publishing monthly media refresh for 1803 and 1807 every month to MSDN and VSS.

 

JW

Microsoft

Hi  Vadim,

 

We only have 2 releases each year, ( release = new features/functionality/APIs ). We call these the SAC releases, for Semi-Annual Channel.

That is why there never was a "SACT" and "SAC" release.    SACT referred to the phase of deployment where we are publishing only to "targeted" devices, versus all, and aligns the common guidance shared between Office and Windows for managing a deployment rollout.

 

I cover this here: 

 

In that blog, you will also find links to the shared Office and Windows recommended servicing model.

 

There is only one release date for each SAC. For devices connected to the update service, using WuFB, we begin updating them based on the values the users have configured their devices. We don't have separate release dates, consumer vs other.

 

For commercial customers that self manage, they get the same release, but determine when and how it will get published to their users via their management tool of choice, SCCM, home grown or other.

 

Copper Contributor

It is not enough for a deferred date of 365 days.
For Enterprise and Education environments, please extend it to about 730 days.

Silver Contributor

But spring releases are only supported for 18 months. You will stay without security updates for a while in such case.

Silver Contributor

Although i'm not sure how it works exactly. Maybe it can't install a release when it is not supported anymore, even if deferred setting is applied at that point (otherwise it would install say 2003 (2020.03) update on 2022.04.xx when it was supported only till 2021.09.xx, so you will miss 6 months of security updates (although you would get a TON of them after this update and release update itself will be humongous and will take hours to install probably). And the it will wait for two years to install 2020.09, which should be supported for 30 months (Ent/Edu). So it will install 2020.09 on 2024.04.xx and it won't be supported already either at that point (1 year without security updates even).

Microsoft

Hi Bruce

 

See here

 

Office and Windows common servicing model is covered there.

 

JW

 

 

Iron Contributor

That just says you "aligned"; it doesn't explain why Office still has a SAC-T with separate dates.

It's not a common servicing model if SAC-T is only disappearing from Windows, but not Office.

Microsoft

Hi Bruce

 

Here is the key section.   

What does “targeted” mean?

In my March 2018 blog post on the organizational culture shift of moving Windows 10 deployments from project to process, I discussed the phases of the common servicing framework: plan & prepare, targeted validation, and broad deployment.

Targeted, therefore, refers to the initial phase of a release, the phase wherein your IT team (or the IT team here at Microsoft) makes the release available only to specific, “targeted” devices for the purpose of validating and generating data in order to get to a broad deployment decision.

Both Office and Windows share the same guidance, with a Targeted Validation Phase.  That as not changed, even for Windows.  The confusion I wrote about then was that there were  separate releases. Its the same release (SAC) that starts with a temporary Target Phase.

Office has the same, you have the Target Channel ( SACT) and non target channel (SAC ) both have the same features.

 

John

 

 

Iron Contributor

But Office has SAC-T and SAC with published dates four months apart (not an invisible 60 days).

What guidance will Windows have in future about a "Targeted Validation Phase" (e.g. end date)?

Brass Contributor

Edit: Ignore this

It would be good if we could delete our comments.

Copper Contributor

@John Wilcox Many schools are only depending on Windows Update for Business (typically in workgroup configuration, no A/D etc) in order to be able to use a given W10 version for 1 schoolyear. It was my understanding that using the spring release with SAC + 365 days was ideal; release arrives march / april in SAC-T. release to SAC happened a few months later. Add 365 days after SAC and a school was all set. Now they risk that PC's will start to upgrade during the last few months of the schoolyear during exams etc. Totally unacceptable. Schools need more than just 365 days deferral. Using the fall release is even worse.

 

Currently the only thing that is workable for schools is using LTSC.

Copper Contributor

And while we at it, a deferral policy for drivers would be nice too. We do not need to have the latest drivers on all machines, we want to roll them out in rings too. 

Iron Contributor

Hi John,

 

I quote  "SACT referred to the phase of deployment where we are publishing only to "targeted" devices, versus all"

This implies that 'targeted' is something very small, insignificant and in general for those who selected it themselves for testing purposes (and therefore it's their fault if they run into issues while using a preliminary release). 

 

Yet if you look at your own screenshots, they say that SAC-T is ready for most people. Which includes all consumers on Home, as they don't have an option to defer.

 

But thanks for publicly confirming that SAC-T was just another public testing ring, like fast, slow and RP :)

Copper Contributor

LTSC (formerly called LTSB) available via volume licensing is the only sustainable way to use Windows 10 for schools, SMB's and maybe even larger corporates but very few people know about it's existence and Microsoft put's it away as an OS for use in ATM's etc which is ridiculous. Most people just want a clean & stable OS without all the crap and that's what LTSC brings you: no Edge, Cortana, Store, Games (promoted apps). LTSC also is faster & consumes less battery. The enforcement of the feature upgrades is unacceptable; Apple for example offers a new OS approx every year BUT they let the user decide IF & WHEN to install it AND the upgrades just work. What I'm seeing here in our market is schools for example moving to chromebooks except for those applications that specifically require the Windows platform. Bravo Microsoft!

Brass Contributor

@John Wilcox 

In my opinion this is a step backwards.   It has been the recommendation from the begging to move to a continual release model adopting  with the adoption of incremental release periods.   This has been a model that has worked from the begging whether it is named CB \ CBB or SAC-T \ SAC-B , the point is that we know when we are at day zero.  We also know we still have a version that may have not been tested across the business ecosystem and that 4 to 6 month later we will be notified of Business ready version.   We also know we have this time to address issues with vendors.  

I do not see how this new change to remove Sac-T is being made to align with Office 365 when Office utilizes a First release \ targeted channel as well . https://docs.microsoft.com/en-us/officeupdates/update-history-office365-proplus-by-date

Seem to be a disconnect here.  Specially if you view the image that illustrates the release history for Office 365 ProPlus  or if you look at the version information from the Office aplication itself. 

 

ProPlusSAC_T.gif

 

image from Outlook Desktop application. 

ProPlusSAC_T2.gif

Brass Contributor

Another #SAC-T build released in Office 365 ProPlus yesterday,  again adding more confusion to how removal of SAC-T from windows  is in alignment with Office 365?  Am I the only one confused ? 

SACT1902.png

Microsoft

Hi Christian, @Christian Zenzano 

 

See my 02-17-2019 07:55 PM   response to Vadim above. 

 

Windows continues to share the same servicing framework as Office, with a Targeted phase of deployments. This done with each windows release.

There are only the 2 SAC releases. There never was separate SAC and SACT releases.  Our guidance still has a Targeted phase, that is SACT.

This is true for Office,  the difference is in the update deployment update. With Windows, you get the image day one and manage
your update roll out plan and schedules your self with SCCM, etc. With office, you subscribe to one of the 3 channels, but the framework and concepts are the same.

JW

Is there any thought to having a way to set a policy that says "I don't want release 1903 until a specific date"?   I'll give a specific example.  I work for a tax firm that there is no way we want a feature release to be installed in March.  Right now I have SemiAnnual chosen, with a X number of days pushed out after it's been declared SAC.  In the new era I'm going to need to make sure my deferral days are pushed off enough.  Conversely I often plan in terms of solid maintenance windows.  July 4th holiday for example is a day I can blow up the network and most folks don't care.  If there was a way to set a policy that says "install this feature release on this day" that would be grand.

Microsoft

Hi Vadim @Vadim Sterkin 

 

That certainly is not what I would want you to take away from the guidance.  We update  millions devices during the target phase before moving to broad and make it fully available. Full availability is the final phase  of our rollout process. Your targeted phase ( if you self manage ) takes as long and as many devices as you need to make your full deployment decision. 

 

With 1803 is was 250 million   and is documented here 

 

Microsoft

Hi Susan,  @Susan Bradley 

 

Yes, absolutely, you have a couple of options in the product today to do that.

1) You can set the deferral value to a number of days from release that will move the update beyond your black out period

2) You can activate a temporary pause to an update, which would move you past your blackout, but not change the deferral for the next update.

 

We also want to make this more straight forward so that you could "schedule" black our periods and we could be intelligent based on when you have these down times and when you don't in future improvements. This would work well for your case where your blackout time does not change.

But that still is an inexact date in time - take for example 1903 which will come out...…?   So it's always a date in time/release info that I have to be aware of and keep an eye on the deferral dates I have set to ensure they push it out past my don't you dare update days.

Copper Contributor

John, 

I agree with Susan.  As LAN Admin in a financial institution and since we are federally regulated for Safety and Soundness, this uncertainty element for patches is really bad.  If it wasn't bad enough Microsoft's updates are all bundled together in to one massive download making it impossible to troubleshoot when a patch breaks something like a core piece of software, but now we won't have a clear date far enough in advance to test; that is unacceptable!!

 

After 1609 I setup a IBM Tivoli server on site to help make updating more manageable in our own timeline and test groups so we can mitigate issues if needed. 

Sounds like I need to set the Update Service on all of our company's workstations to manual or disable until Microsoft figures it out.  

 

And also, What is up with Xbox app still being forced on Windows Pro???  Believe it our not Companies don't let their employees play Xbox at WORK!  

    -You'd think with all the Telemetry data you're gathering from Win10 machines this point would be clear.

Copper Contributor

Hi @John Wilcox,

 

From the perspective of K12 schools out here in Belgium which I happen to deal with a lot , I couldn't agree more with @Susan Bradley as her situation is quite comparable.

 

Schools are happy to deploy feature upgrades but NOT when Microsoft selects to do so. For them the summer holiday is an ideal period for example. Apart from that -imho- Microsoft needs to realize that -this is an understatement- not every customer is:

 

1. working in an A/D environment but rather using a simple workgroup concept

2. even less customers are using WSUS or have the knowledge to use / manage it

3. even less are using deployment rings (not necessarily because they don't like it; they simply don't have the resources)

 

In fact most are just after a lean, mean (= not bloated) & stable Windows OS and not waiting for yet some other feature they most probably don't need. Your telemetry probably does confirm that if you look at the number of Enterprise LTSB/LTSC deployments out here even given the fact that it is still a widely unknown version for most -volume licensing- customers (unfortunately). Please don't reply that LTSB/LTSC is for ATM's or that they need to look for Windows 10S.

 

To add to the confusion it is still totally unclear as to how things work: a school that will deploy version 1903 with 365 days of deferral (the maximum available) becomes a sitting duck as of march 2020. Depending on how fast Microsoft effectively rolls out version 2003 chances are that somewhere in the April-June time frame they get the feature upgrade forced upon them with the potential of causing all kinds of issues (remember 1809 ?). It could even happen while students are taking their exams and using those PC's. That's just not acceptable.

 

To add to the confusion it is still totally unclear to me and my customers what Microsoft means with 18 months of support; If a version is supported for 18 months then I'd expect the maximum deferral period available to be 548 days not 365 days. I'd greatly appreciate some light being shed on this.

 

Moreover Microsoft has announced in september 2018 that it will "support" the "09" autumn Enterprise & Education releases for 30 months rather than 18 months for all other versions. So for those versions I'd then expect a maximum deferral period of 913 days ? I'd greatly appreciate some light being shed on this as well.

 

I also wanted to express -reading this article https://www.ghacks.net/2019/03/06/will-microsoft-remove-advanced-update-options-in-windows-10-1903-p...- my regret that Microsoft seems to have decided to remove the Advanced Update settings (like the deferral setting). For many K12 customers this means extra complexity as many of them are not even familiar with local GPO's or messing around in the registry.

 

The local education volume licensing program out here is called MS-KIS (Keep it simple) ; at this stage however we couldn't be any further away from keeping things simple...

 

Thank you

Silver Contributor

I haven't used deferral setting before, but i thought it is a number of days since the official release, not since the last feature update installed on your system. Then there shouldn't be a problem in March.

 

Also, deferral is for the next update to defer (pause), not a setting when to install next update for the current update (i think). And group policies are not dynamic, they can't know what version you are using at the moment and stretch the deferral number accordingly. This would need some other method to control or just allow any number in that policy no matter what version with how much of support is used. But i think MS doesn't want a lot of very old versions in the wild, so they have made it 365.

Copper Contributor

@wroot exactly; deferral setting is as of release date and indeed it is for installing a new Windows version (hence the name feature update not to be confused with so called quality updates). So if MS releases 1903 in March 2019 and a customer defers the next feature upgrade for 365 days then he'll get version 2003 in / as of March 2020 but I'd be curious to learn about the 18 & 30 months support explanation from @John Wilcox 

 

Something else I experienced on one of my own systems is the following: (@John Wilcox I'd appreciate you shedding some light on this as well.)

 

I had a 1703 Pro system with deferral set to SAC + 365 days, then it got a feature upgrade to 1709 back in February 2019. I was expecting to get 1803 however since 1803 in february 2019 was "ready for business / SAC" ever since july 10th 2018 ???

 

 

Silver Contributor

Well, in my understanding it should work like that: if you set it to 365 days then in 2020 March you would get 1903 version, not 2003 as release date for 2003 would be 2020 march and it would be deferred for 365 days based on your policy, so it would be installed in 2021 actually.

Iron Contributor

Hi @John Wilcox 

I quote (emphasis mine):

Your targeted phase ( if you self manage ) takes as long and as many devices as you need to make your full deployment decision. 

With 1803 is was 250 million   and is documented here 

 

This continues to highlight the problem with your narrative. Microsoft releases SAC-T to 250 million devices, but it's not a release, it just some preliminary milestone.  At the same time, Home edition owners don't self manage updates. Microsoft manages updates for them, hence 'you' is not [completely] applicable here. 

 

That's why I'm saying that SAC-T was just another testing ring. Certainly, it's not in your narrative and perhaps, it's not even on your mind (albeit it should be). Yet this is the reality. The known issues sections for SAC-T as well as update history pages for subsequent CUs used to tell and continue telling the story of multiple issues being raised immediately after SAC-T (e.g. 1809). Thanks to all these testers who you pretend self manage updates :)

 

I'm sure you know how many of those 250 mil devices getting 1803 were running Home editions. Would you like to disclose this information?

 

Copper Contributor

Hi @wroot 

 

I think you are not reading my message correctly: a customer who installs 1903 (presuming it's available) in March 2019 & sets the deferral to 365 will get 2003 as of March 2020 which is not desirable. Even he'd deploy 1903 in july 2019 with deferral set to 365 he'd be getting 2003 as of... March 2020. Since MS release typically in March/April & Sept/Oct this is causing great trouble for schools.

Silver Contributor

I'm just trying to clarify this for myself. As i've said i haven't used deferral policies (i'm talking about GPO for Windows Update for Business). From what i have read in this blog post and other comments i gathered that it works the other way that you describe.

 

You install 1903 (say in April), your GPO was set to 365 days (not important when, could be even before 1903). So it will always count 365 days since the official release of any feature update coming in the future. This means that 1909 would be installed in 2020 September, 2003 in 2021 March and so on. Every feature update would be postponed for a year. But that means that you would still get two updates twice a year on March and September, they just will be a year old every time.

 

But you say that it counts 365 days since the last feature update installed. This doesn't sound right and not what i have heard.

 

Unless you mean that you don't have a way to not have updates installed twice a year or during spring or fall. That i understand and i always advocate for MS to stop doing feature releases twice a year and go to once a year practice. Though i fear they might start doing even more often updates in the future. If it was just once a year, say in March, then you would set it to 180 days and every update would be installed during summer. But when there are two updates per year it is impossible to have one policy to work for both of them. You would have to have two policies and switch them twice a year. One for the spring update to defer for 180 days and one for fall update to defer for 270 or so.

Copper Contributor

@wroot Nope: if you install 1903 in april 2019 & set deferral to 365 days you will get a feature update as of March 2020 (365 days after 1903 has been released presuming 1903 will be released in March 2019) It won't happen immediately for everyone as MS does it progressively per region & per hardware config they feel reasonable sure about.

 

I did not day it counts 365 days from the last feature update installed. Where did you read that?

 

The 365 days deferral setting basically prevents from getting 2 feature updates a year but that's not what real world customers are after.

 

Presuming that participants in this thread are above average ICT administrators & looking at the confusion in their minds I can only conclude @John Wilcox that MS still has a lot of explanation to do in human understandable language. I greatly depend on the Windows platform for my business and it's hard to see K12 moving over to Chromebooks -in great part- because of 1) the MS complexity , 2) as always the cost and read this well: 1) comes before 2)

 

 

 

Copper Contributor

@Clipper87 ,you are wrong, @wroot has it right.

 

Look at this example:

We talk about Win10 Pro here, we have 365 days feature deferral set (and no SAC deferral, because after 1903 it will be no such option/policy) and currently 1803 installed, ok?

 

Here are (expected) release dates of those versions:

  1803(currently installed): 30.4.2018
  1809: 13.11.2018 ( deferral 365 means, it can't be installed before 12.11.2019 )
  1903: 04.04.2019 (for example; deferral 365 means, it can't be installed before 03.04.2020 ))
  1909: 20.10.2019 (for example; deferral 365 means, it can't be installed before 19.10.2020 ))
  2003: 01.04.2020 (for example; deferral 365 means, it can't be installed before 30.03.2021 ))
  2009: 10.09.2020 (for example; deferral 365 means, it can't be installed before 09.09.2021 ))


So the result is :
- every half year (around april and october) you will be updated to "one year old" release (for example on 3.4.2020 you wil get 1903)
- you will not be able to "skip" versions and install once a year (now you can do this - for example, with SAC and 365 days set you can install 1709 in summer 2018 and then-next summer- when 1809 is out+tested you change policy to no SAC and 180 days and you get 1809; then you set again SAC and 365)

Silver Contributor

In this blog post their refer to release date of SAC as a starting point of defer period. As every SAC has its own release date i get that Windows 10 would pull release date from Windows Update and then apply defer value to this. 

 

I can't provide you excerpt of paragraph as paste refuses to work here on movile. It boggles my mind that we have to use this utter buggy, ugly, slow platform to collaborate..

 

Silver Contributor

My god it just posted my message without letting me to finish it..

The paragraph starts with "Once your organization's devices"

Copper Contributor

@Adam Sova Thank you for your explanation; it looks indeed I've been misunderstanding the deferral concept to the extent that I thought that the deferral period applied to the release date of the installed version (a new version will not be installed up until 365 days of release of the current verion) instead of the release date of the upcoming version (a new version will not be installed up until 365 days after that new version has been released)

Your explanation is the first that I'd call "human understandable" yet the problem for schools continues (if they don't build a clean image every summer based on the 03 version)

 

Taking back your example:

 

School did a clean 1803 install back in april or summer 2018 with deferral set to 365 meaning that the next version (1809) will not be installed up until 365 days after 1809 becomes available. So that effectively gives the school the possibility to use 1803 for 1 full schoolyear (sept 2018-june 2019) without feature upgrades happening during that schoolyear IF they build new images every summer based upon the 03 release.

 

If they don't build a new image every summer and just continue to use that 1803-please correct me if I'm wrong- then 1809 will be installed somewhere after november 12 2019 in the midst of the schoolyear; not acceptable. Next -if they continue to use that 1809- 1903 that was released march 2019 will be installed march 2020 again in the midst of the schoolyear.

 

So the next best thing to do for schools if not using the Enterprise LTSB/LTSC edition is to build a new image every summer using the then current 03 version.  That would avoid feature upgrades during the schoolyear.

 

I can now understand the 18 months suport period: in the example if 1803 was cleanly installed march 2018 it could be used up until september 2019 and that's 18 months.

 

I still wonder about the 30 months support for the 09 Enterprise & Education ( see this article) in relation to the 365 days deferrral; any idea what that could mean in human understandable language ? An example where a customer installs a clean Enterprise 1809 with deferral set to 365 (?) would help to understand!

 

LTSB/LTSC -imho- continues to shine because it should not be taken for granted that schools have the resources to build new images every year let alone to live through feature upgrade cycles twice a year. After all they've been used to work with an OS for say 5 year's in a row with all previous Windows versions... The OS is just a platform not a goal on it's own for most user's but MS seems to think different here.

Silver Contributor

Having to rebuild all machines with curren't years 03 update seems like a lot of work. Unless you already do this every summer before the new school year. Then yeah, rebuilding it with current 03 every summer kind of makes it 1 update per year.

 

I guess 30 months support is designed for those using ConfigMgr/WSUS to distribute feature updates. They can wait longer than 365 days.

Copper Contributor

@wroot 

>I guess 30 months support is designed for those using ConfigMgr/WSUS to distribute feature updates. They can wait longer than 365 days.

 

I don't know so curious for anyone to comment. That apart: ConfigMgr/WSUS out here in K12 (some 2.000 schools) probably represents less than 3 to 5% of schools using it not necessarily meaning that they know how to use it so my guess based on my daily interactions is that probably 1% of the K12 uses it and knows how to use it. That's the reality whether we like that or not. I hear from colleagues in other countries much the same story in general with of course the usual exceptions to confirm the rule:-)

Brass Contributor

Hi

If my device is in SAC, and have 1803. And device has Intune policy with  70 days deferral for feature update. To which version device will be updated?

 

//Alexander

Microsoft

Good Morning Alexander,

 

When your managing a device updates with WuFB, ( in your case via Intune ), you will get an update, when there is a new version that meets your updates criteria, which you have said is 70 day deferral. There will only be one release at a time when your criteria is met, and it will always be the next chorological release from the one you are on, so you'll next get 1809.

 

JW

Copper Contributor

@John Wilcox Are the dates listed here confirmed dates for Enterprise release of Feature updates? https://docs.microsoft.com/en-us/windows/release-information/

 

I have 180 days in SAC-T configured, and I still have devices in 1803. If I go by the date of Nov 13, 2018 (1809) + 180 days I end up with May 12, 2019, however I still I have loads of devices at 1803.

 

You also list May 21, 2019 for 1903, I have SAC-T configured for some test devices with 0 day delay, still no 1903.

 

It's super hard to determine exactly what updates i'll be getting with configured deferrals if I don't have an EXACT date that the deferrals are counting up from. You should really release some sort of enterprise calculator where I can plug in deferral times and it will clearly show myself what patches my machines should be getting.

Version history
Last update:
‎Jul 15 2019 10:50 AM
Updated by: