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
Microsoft

Yes, it was hard to determine, thus the reason we made the changes to simplify that are the topic of the blog above. Now everything can be calculated off the one release date.

 

From your scenario descriptions, I believe your still on 1803, ( 1809 no longer has SAC-T as a branch option) , so you will not be updated to 1903, but to 1809.

 

For the "loads of SAC-T" devices still on 1803, please check the update status? Have they downloaded the update, but waiting for the user to initiate the update, or reboot the device? The device won't move forward until the reboot, which the user can control, unless you enforce that.

 

JW

Copper Contributor

@John Wilcox so are you saying if I have 1809 devices configured with SAC-T 0 day delay they won't get 1903 at all? Are you saying I have to force my device down to SAC to get 1903? I just forced down to SAC / 0 day delay for my test group, searched for updates, still no 1903, most likely because your adding a 60 day delay to SAC as a default.

 

The blog above says 

 

  • 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.

So, should I not be receiving 1903 on SAC-T with 0 day delay right now?

Silver Contributor

I saw 1903 in WSUS the day 1903 was announced (a few days ago).

Copper Contributor

@John Wilcox it may make sense to also communicate the availability of new feature updates can vary based on Microsoft's "limited release" and hardware support. I was using an Inspiron 9380 /w WUB 0 day delay, and still no 1903. Moved to a Surface Laptop 2, same WUB 0 day delay policies, and I got 1903 immediately. This can make things frustrating when calculating the servicing delay's, as we essentially are unable to control a proper initial release and testing based on the published dates if the updates are only made available to select hardware automatically.

Microsoft

Hi Chris,

 

Missing some details, so let me give you most likely things to look at.

1) Inspiron  , which branch readiness config did you have, SAC or SAC-T.  If SAC, then remember, we are adding +60 as a one time event, thus it will be 60 days

 

2) What did you configure for the Surface specifically, or did you mean its just default?

 

3) If a device is default, ( new device old device never changed, or has been restored) it is not the same as a deferral of "0". Instead, it is managed via the WU intelligent role out process, which is non-deterministic by device

 

4) If the device has a compat block, ie there is a known conflict not yet resolved, we will not update the device into the bad state, even at the deferral period.  You can see the known and tracked issues/compat blocks on the release history page

Copper Contributor

SAC-T 0 Day delay policy, Modern Desktop managed through Intune. Both devices were under the same management / policies SAC-T 0 day delay. I have quite a few not receiving it, Surface Laptop 2 received it immediately. I'll assume it's a blocking issue on the other devices that's going through resolution as we speak, thanks.

Copper Contributor
If I'm on Windows 10 Enterprise 1803 and on SAC with 0 days deferred. When will I get 1809?
Copper Contributor

@John Wilcox , currently the maximum deferral period for Feature Updates is 365 days. For Windows 10 Enterprise can this be extended to the full length of the supported lifespan, so two years?  While my organization hopes to get to an annual upgrade cadence, we're not there yet (still on 1703, moving to 1809 by the fall), and limiting us to only half the supported period forces us to block connection to Microsoft update servers and deploy updates via other channels.  Thank you!

Brass Contributor

Hello,

 

We have now 2x policies set via Intune Software Update Rings:

 

1st SAC with deferral = 120 days => targeted to company devices & excluding SAC-T devices;

2nd SAC-T with deferral = 7 days -> targeted to specific group with devices & excluding SAC devices;

 

Now devices in 2nd policy updated to 1903,

Do we need to change policy and create Intune Software Update Rings only for SAC, so we will have:

1st SAC with deferral = 60 days => targeted to company devices & excluding SAC-T devices; (changing here to 60 days, as deferral will have another 60 from service)

2nd SAC with deferral = 7 days -> targeted to specific group with devices & excluding SAC devices;

Or we can continue keep using SAC-T via Intune?

Copper Contributor

GOOD RIDDANCE - the targeted version was the unstable one with sufficiently tested updates and features. After years of Targeted unstable retail updates screwing up millions of computers you finally accepted the fact that you cant rush feature without proper research and testing time - especially in business environment. From experience I also highly recommend a 7 day deferral of feature updates on top of that to avoid any last minute or post release screw ups and fixes.

Copper Contributor

***EDIT***

Check your group policies with a fine tooth comb people! I did a gpresult on a machine that upgraded too soon and found a misapplied policy was the culprit. Sorry for the false alarm. 

Iron Contributor

@epasco 

From which version? I think that makes a difference at present.

Copper Contributor

@Bruce Roberts looks like we done goofed. I found a misapplied group policy that explains the behavior. False alarm on my part.

Microsoft

No worries @epasco

 

Glad We ( you ) got it figured out.

We were checking systems on our side, and had not found an explanation yet. 

 

Thanks for closing the loop so we didn't continue to chase this down. Appreciate it. 

 

John

 

Copper Contributor
I'm still wondering about this If I'm on Windows 10 Enterprise 1803 and on SAC with 0 days deferred. When will I get 1809?
Iron Contributor

There is no rationale for Microsoft to force customers to upgrade anything ever.  It's our business, not theirs.  OK, stop support and don't update versions, but that's our risk to accept or not accept.  I must be able to maintain the software on my business' computers in the best way that helps my business succeed.  Operating systems are too critical to the proper operation of applications and peripherals to change continuously.  If we're paying for an "Enterprise" version of Windows with SCCM, then we should be able to manage our configurations to comply with our requirements, not Microsoft.  We must have all bloatware removed and control handed to our IT departments.  Nothing, and I mean NOTHING, should ever automatically install on the equipment WE own without our express approval.

 

To be clear, we do upgrade before each channel expires but sometimes one can't do that for every system and we certainly don't want users going to Windows Update and upgrading out of order.  It is an onerous task for businesses to waste resources and lose productivity by migrating functional computers to LTSC just because Microsoft refuses to allow us to turn off SAC.  There is just no good reason for this meddling in our affairs.

Microsoft

@rejohnson 

 Welcome to te servicing community, glad you found us.

You are correct, it is your business, which is why you always control the update cadence and process for your devices, in your case with SCCM.  You choose when to update the devices you are managing and with which update. 

Simple as that.

 

 

 

 

 

 

 

Iron Contributor

If only that were true!  If a user on a SCCM-managed PC runs "Check for Updates" they will get updates and upgrades, which includes the most recent version of Windows 10, 1903, if they were on a version at least one year behind..   But Enterprise is supposed to be supported for 18 months.  There is NO control over this.  Group Policy should allow paused upgrades for 18 months, not 365 days.  Also, users should not be able to install anything from Windows Update if their computer is managed by SCCM.  Finally, we should still be able to CHECK for updates without installing them.  I don't get that one at all.

 

Thanks.

Silver Contributor

I guess SCCM has different approach, although i thought it should use same mechanism as WSUS in the background. Our PCs which are updating from WSUS are doing nothing if you press Check for updates (1803 version). We have to approve every feature update for them to start upgrading.

Brass Contributor

@rejohnson 
You can block users from checking for Windows updates via group policy if you weren't already aware.

 

Microsoft

@rejohnson 

 

As you can see, good community here that can/will help you.

 

What I said is true, and if you think/feel you are not seeing that behavior, ask here, as it probably means there is a management/configuration options you not aware of.

 

As I said, you have complete control over when and to what a device gets an update. Depending on the management tooling you are using, if you are self managing, and you need to extend for the full 18 months, you simply don't update the device until you choose to and approve it.  

You can control, disable you users checking for updates, or having direct access to Windows update.

If a device is connected to and using Windows Update service, there are still options you choose for when and how a device will get updated, that you control and manage, though it does not have all the options you might have with a different on prem management tool. 

 

Lastly, to your Check for Updates feedback,  already in the product.

 

If you are on RS4 or later, Checking for updates will tell you there is a new feature update, and you then have a separate action to install it.   Starting with 1903, this behavior extends to monthly updates as well. 

 

Feels like we are on a roll here with your issues and asks. 

check.jpg

 

 

 

Copper Contributor

Request Id: aa16984e-4423-4a72-b9b5-b0f488683500
Correlation Id: f84ed276-c3b8-49ec-b25a-f0903ad5ec51
Timestamp: 2020-06-02T18:41:16Z
Message: AADSTS900561: The endpoint only accepts POST requests. Received a GET request.

Copper Contributor

HOLA BUENAS TARDES

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