SOLVED
Home

1803 (Targeted)?

Highlighted
New Contributor

1803 build 17134 is now available

 

Did it release as Semi-annual (Targeted) or Semi-annual?

windows-10 release-information

 

will it be the approximately 4 months before my rings begin to defer it as semi-annual or are they going to start installing it now if on the semi-annual branch???

32 Replies
Highlighted

The documentation is incorrect.  1803 is semi-annual targeted.  If you have your deferral set to install feature releases as semi-annual it will be several months.

1803-semi annual targeted

1709-semi annual

Highlighted

"The documentation is incorrect."

that's cant be,  Its Microsoft!  they wouldn't release a feature update to 10 million devices and mess up the release communication (LOL)

I need MS to either fix their documentation or standby the release

1803-semi-annual.jpg

 

 

 

Highlighted

Take a look at this. Why is 1803 installed on a client with Semi-Annual Channel?

 

image.png

Highlighted

You aren't alone.  I'm getting reports that 1803 is getting on machines that have semi-annual selected.  It shouldn't even be near that machine.  

Highlighted

Great and now? Microsoft please tell us a solution to stop this.... Thanks.

Highlighted

https://support.microsoft.com/en-us/help/3073930/how-to-temporarily-prevent-a-driver-update-from-rei...

Use that to block it.  (and come on Microsoft , I've lost count how many times deferrals haven't worked)

Highlighted

Hello,

The machines should not have been upgraded with that policy set, with a couple of exceptions

There are two ways this can happen.

  • The dual scan scenario where the polices settings configuration is not set properly, we took changes to address this last summer, by adding a new policy but it’s possible that people have not figured it properly. The fix was to offer a new option but it’s possible that policy is not set.
  • GP that sets Telemetry to Zero Exhaust

Is there a support case where machines were upgraded with that policy set?

 

Darrell Gorter [MSFT]

Highlighted

Even with the dual scan issue these machines are set for "semi-annual".  We are still at semi-annual targeted.  There is no reason these machines should be getting 1803.

 

https://partnersupport.microsoft.com/en-us/par_clientsol/forum/par_win/why-was-windows-10-machine-up...

 

I have two other MVPs on a private list who are behind Windows update who got 1803 and they had semi-annual chosen as well.

Highlighted

Hello, 

the Case No. is 

 

  • Service Request #: 118052418249642
  • Service Request Title: Unwanted Installation of Windows 1803 - GPO with 365 Day delay is setup
Highlighted

Fellow MVP, not behind a domain, therefore no WSUS/dual scan, telemetry on. 

This is not the first time that feature releases have come down when they clearly should have respected the block.

 

 

Highlighted

Hello

We would like to see some log files and registry entries from machines that were upgrade to 1803 where you thought the  feature update to 1803 was deferred.

Please Collect these registry values

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DataCollection]

[HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\DataCollection]

 

and we would like to see the logs collected with this tool

https://aka.ms/wucopylogsexternal

 

Please Send the information to me

Darrellg.removethis.@microsoft.com

Thanks

 

Highlighted

Darrell,

 

Susan forwarded this to me as I have an affected machine. (I started the partner thread she cited.) Win10 Pro 32-bit virtual machine, domain environment, no WSUS. 64-bit machines in the same environment have not upgraded yet. Group Policy Result as follows:

GPresult.png

 

AllowTelemetry is set to Basic as shown in the group policy above:

 

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DataCollection]
"AllowTelemetry"=dword:00000001
[HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Windows\DataCollection]

(Key exists but no values)

 

BTW I did see the note in Group Policy that I have to have AllowTelemetry=1 or higher:

 

SelectWhen.png

However the setting of AllowTelemetry shouldn't matter on Pro anyway since 0 is the same as 1:

AllowTelemetry.png

When I tried to run Copylogs.exe, I get this:

CopyLogsMessage.png

Must be 64-bit-only?

 

Mark Berry
MCB Systems

Highlighted

Hello Mark,

We don't have  a 32-bit version of tool available right now.

Can I get you to file a feedback request using the Feedback Tool

 

  • Category: Install and Update
  • Sub-Category: Windows update

Promote to a bug, Upload Logs.

Send me the Feedback ID or post to this thread

 

Thanks

Darrell

Highlighted

Darrell,

 

I submitted feedback without signing in. (I prefer domain accounts and don't link my Microsoft account to most machines.) I told it to submit logs but I did not see the option to "promote to a bug." I did not get a feedback ID but it did create this empty folder:

 

C:\Users\<MyUser>\Documents\FeedbackHub\{b1b0d70e-7d3d-49bb-8d1e-af6c040ee2fe}

 

If you have a list of logs that's not too long, I can just zip them up for you.

 

Mark Berry

Highlighted

Please ZIP and share %windir%\Logs 

Highlighted

Navjot,

 

Thank you for the suggestion. I have emailed Darrell the Windows\Logs folder as well as Windows.old\Windows\Logs.

 

Mark Berry

Highlighted

Is there any News available.

 

I have set a Policy to my Clients that they dont check the MS Update Websites in order to stop the deployment. But this will lead to a lack of security. I want to use the normal semi annual channel with the acutal Build (1709 and not 1803) and defer the Installation like offered in the Policy. I have also set the telemetry to value 0 which is the same like 1 for Enterprise users.

 

Many thanks for any Feedback.

Thomas

Highlighted
We are still looking for more logs if anybody has them.
The one set of logs showed RS4 was available prior to the machine joining WUFB with the deferral policy.
Send me the logs or make them available for download please
Thanks,
Darrell
Highlighted

You don't want to set telemetry to 0 as that ignores the Windows update for business settings.  If you use the don't use dual scan setting - and are behind WSUS you should be fine.

Highlighted
But we use the Dual Scan Settings since over a year and until May everything rund Fine with the Setup. We was on the Semi anual Channel, defered the feature Update for 365 day and had the telemetry on 0.
This worked well for the Step from 1703 to 1709.

What is the correct Setup for Dual Scan and the semi anual Channel, when i need to avoid an unwanted Update to 1803.

I thought i have the correct Setting in my GPO - or iam Wrong with that?

Thanks
Thomas
Highlighted
But we use the Dual Scan Settings since over a year and until May everything rund Fine with the Setup. We was on the Semi anual Channel, defered the feature Update for 365 day and had the telemetry on 0. This worked well for the Step from 1703 to 1709. What is the correct Setup for Dual Scan and the semi anual Channel, when i need to avoid an unwanted Update to 1803.

I thought i have the correct Setting in my GPO - or iam Wrong with that

Thanks
Thomas
Highlighted

@Darrell Gorter wrote:
The one set of logs showed RS4 was available prior to the machine joining WUFB with the deferral policy.

Darrell -

 

Are you referring to my logs? I built this virtual machine from scratch and joined the domain in early February, then set up deferral policy in Group Policy in late February. RS4 was released April 30, right?

 

Is there an article somewhere about what logs to review and what to look for to confirm that deferral is working?

Highlighted

@Susan Bradley wrote:

You don't want to set telemetry to 0 as that ignores the Windows update for business settings.  If you use the don't use dual scan setting - and are behind WSUS you should be fine.


Agreed that AllowTelemetry should be at least 1, but according to the docs (see screen shots in my post above), all editions except Enterprise/EDU/IoT/server treat 0 as 1. In other words, with Pro, it's not possible to block telemetry. You would think that also means it is not possible to ignore Windows Update for Business settings.

Highlighted

You want the policy called "Do not allow update deferral policies to cause scans against Windows update".  Set that to enabled.

 

The telemetry setting of 0 only works on Enterprise as I recall.  Are you running that sku?

Highlighted
hi Susan,
We run the Enterprise Version. Comparing with the explanations above we have telemetry 0 which is the same as 1 in the Enterprise Environment (so i have Unterstand it.)

At the moment i habe stopped all Scans against the MS Update in the Internet. This stopped the search for all Updates. Bit the Problem is that i dont want stop this Kind of Setup. We dont WSUS for deploy Win 10 Updates because the most of our staff works outside of our company. We have make the decission that the Dual scan fits Perfect to us. Bit now it looks for me that Microsoft has overwritten the behavior which Microsoft has offered with the GPO Settings. My question is is this a bug which they will solve or not. And in which timeframe they will help there customers which pay several 100.000 Euros for the company Contest. I have already openend a Ticket See above in the Discussion. But the answer was Not what i have expected. Yes this is May a bug - i dont know what Happens we try to Contact a tier 2 Support. That was the last Reply since last friday. A i fortget the close Incident Message. Its now on hold.

So i Hope the Issue will be solved and i can go back and Scan Updates against Microsoft without installing 1803. the actual State Stopps my daily work.

Thanks for your help and support
Thomas
Highlighted
If you don't use WSUS, if you are choosing "semi annual channel" what number of days did you select for deferral? As I recall even if you set the deferral for X number of days, if you click on "check for updates" this will trigger the install of 1803. Check for updates isn't like the old Windows 7 scan where you would see what would be offered, check for updates actually triggers detection and install.
Highlighted

@Thomas Czekalla wrote:
hi Susan,
We run the Enterprise Version. Comparing with the explanations above we have telemetry 0 which is the same as 1 in the Enterprise Environment (so i have Unterstand it.)

I don't have Enterprise so I'm not speaking from experience, but I understand that differently. The way I read it, it is only possible to set a value of 0 if you DO have Enterprise; in that case, it is NOT treated as a 1. Then, under "Select when Preview Builds and Feature Updates are received," it says, "To configure Feature Updates, you must have a telemetry level setting of 1 or higher." Does deferral work as expected on  your Enterprise machines if you set AllowTelemetry to 1?

Highlighted

@Susan Bradley wrote:
If you don't use WSUS, if you are choosing "semi annual channel" what number of days did you select for deferral? As I recall even if you set the deferral for X number of days, if you click on "check for updates" this will trigger the install of 1803. Check for updates isn't like the old Windows 7 scan where you would see what would be offered, check for updates actually triggers detection and install.

Not for me. No WSUS, Win10 Pro 1709, deferral set to 180 days. On most machines, I can Check for updates all day long and not get offered 1803.

 

Once it IS offered, you're right, it won't ask if it's okay to install it.

Highlighted

I tend not to "check for updates" unless I'm positive I want the thing that might be up there.

BTW I pointed another Consultant who had a client who got 1803 with deferrals in place to this thread.  Is there anyway to have a checking tool to check if what you think will be deferred is going to be deferred?  The state of affairs right now is you never know if 

a. you've set something wrong

or 

b. it's a detection bug.  And given that we have had them in the past we are constantly in a state of questioning.

I've now confirmed that my machine did NOT have the deferral group policy applied before 1803 was released. Although the machine is domain-joined, group policy updates started failing after the machine's NIC lost its Domain profile on February 14. It's unclear if this was due to a Windows update or due to a general failure of Network Location Awareness.

 

Details:  https://www.mcbsys.com/blog/2018/06/windows-10-unexpectedly-updated-to-1803/

 

Thanks to the MS team for reviewing the logs, which led me to restore a pre-update image.

Highlighted

Hi Mark,

 

I have now set the Telemetry from 0 to 1.

After this my policies worked like expected.

Still strange why i worked with 0 for at least one year and all was also fine.

 

Thanks to all for support and help

Highlighted
Solution

Microsoft updated the docs to make it clear, that when Telemetry is set to Zero, the deferral policies do not take affect and you make get the feature updates.

Here are the links to the updated Docs

https://docs.microsoft.com/en-us/windows/deployment/update/waas-overview

Important Devices on the Semi-Annual Channel (formerly called Current Branch for Business) must have their diagnostic data set to 1 (Basic) or higher, in order to ensure that the service is performing at the expected quality. If diagnostic data is set to 0, the device will be treated as if it were in the Semi-Annual Channel (Targeted)(formerly called Current Branch or CB) branch. For instructions to set the diagnostic data level, see Configure the operating system diagnostic data level.

https://docs.microsoft.com/en-us/windows/deployment/update/waas-configure-wufb

Note Users will not be able to change this setting if it was configured by policy. Important Devices on the Semi-Annual Channel (formerly called Current Branch for Business) must have their diagnostic data set to 1 (Basic) or higher, in order to ensure that the service is performing at the expected quality. If diagnostic data is set to 0, the device will be treated as if it were in the Semi-Annual Channel (Targeted)(formerly called Current Branch or CB) branch. For instructions to set the diagnostic data level, see Configure the operating system diagnostic data level.

 

Thanks

Darrell Gorter