1803 (Targeted)?

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

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.

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.

---

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

---

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?

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?

---

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

---

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?

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.

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

Navjot,

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

Mark Berry

Please ZIP and share %windir%\Logs 

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

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

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:

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:

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

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

Must be 64-bit-only?

Mark Berry
MCB Systems

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

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.