SOLVED

SCCM applies DoNotConnectToWindowsUpdateInternetLocations registry during OS install task sequence

Copper Contributor

Hi,

 

We are facing problem where SCCM 2203 applies DoNotConnectToWindowsUpdateInternetLocations registry key for windows update policies. I went trough all GPO and there is not any policy which apply this setting, but each new laptop or VM installed through SCCM contains this registry key.

 

I did a test and I build as simple Task Sequence for installing Windows 11 as possible without domain without SCCM Client App. Windows 11 is clear image without any customization, just added install.wim into SCCM. Unatended.xml also does not contains this. So this settings must come up from SCCM itselfs.

 

I went through Default Client Settings and also didn't find any item which could be related. Only what I think could be related is "Enable software updates on clients" which I have "No" because I do not want to manage windows updated with SCCM but standalone WSUS.

 

Any idea why fresh SCCM deployed windows, which is workgroup without domain, contains DoNotConnectToWindowsUpdateInternetLocations registry key? (GP cannot be applied)

 

Edit: When I delete this key manually, it is never added again, so it's really just SCCM install task sequence or something which must add it.

 

Simple TS I used for testing if registry key will be applied.

simpel_ts_win.png

 

Thanks

3 Replies
best response confirmed by TiborM (Copper Contributor)
Solution

@TiborM 

 

My guess is SCCM/MECM sets this preemptively due to the way the Software Update Point operates, because it assumes you'll be using that.

 

To workaround, you could explicitly set the GPO to set the key to 0 (or a PowerShell script for Workgroup machines):

 

Prevent Windows 10 from connecting to any Windows Update Internet locations 

 

Details:

 

You mentioned you're trying to use standalone WSUS instead, which operates outside of SCCM if you do it that way.

 

When you use the Software Update Point role, the mechanism is handled differently under-the-hood. SCCM uses a local WSUS to query the MSFT update catalog, but that's just so the server can grab package content and stage it. The updates themselves are actually delivered to clients via the Software Center, similar to any other app package. Hence, it doesn't need to use intranet locations for updates because CcmExec will query the Disto Point for the package content.

 

This is likely why the SCCM Client Agent shuts it off by default. In past versions of SCCM 2012, the client agent would throw errors if WSUS settings were already defined, and you'd need to manually remove them before it'd properly start reporting to the SUP.

 

Thanks, it looks like. I hope that I could find how to prevent it. But I can manually delete this key on the end of task sequence. The thing is, that this key must be deleted, because it prevent Windows 11 client to show link "Check online for updates from Microsoft Update" in Windows Update settings section. It's another bug in Windows 11 which ignores value of that key. If it exists, doesn't matter the value, link is hidden.

@TiborM Just wanted to post that you're not alone.  I too am seeing this behavior using the built-in "Deploy Windows Autopilot for existing devices" task sequence.  The resulting "fresh and ready for autopilot" image contains the DoNotConnectToWindowsUpdateInternetLocations registry value set to true.  This also prevents all Windows Store apps from downloading with an error stating to ask your administrator to enable windows updates.  Definitely seems like a bug to me but deleting the registry value fixes the issue.

1 best response

Accepted Solutions
best response confirmed by TiborM (Copper Contributor)
Solution

@TiborM 

 

My guess is SCCM/MECM sets this preemptively due to the way the Software Update Point operates, because it assumes you'll be using that.

 

To workaround, you could explicitly set the GPO to set the key to 0 (or a PowerShell script for Workgroup machines):

 

Prevent Windows 10 from connecting to any Windows Update Internet locations 

 

Details:

 

You mentioned you're trying to use standalone WSUS instead, which operates outside of SCCM if you do it that way.

 

When you use the Software Update Point role, the mechanism is handled differently under-the-hood. SCCM uses a local WSUS to query the MSFT update catalog, but that's just so the server can grab package content and stage it. The updates themselves are actually delivered to clients via the Software Center, similar to any other app package. Hence, it doesn't need to use intranet locations for updates because CcmExec will query the Disto Point for the package content.

 

This is likely why the SCCM Client Agent shuts it off by default. In past versions of SCCM 2012, the client agent would throw errors if WSUS settings were already defined, and you'd need to manually remove them before it'd properly start reporting to the SUP.

 

View solution in original post