Change:
import { timeout } from 'vs/base/common/async'; import { CancellationToken } from 'vs/base/common/cancellation'; import { Emitter, Event } from 'vs/base/common/event'; <del> import { getMigratedSettingValue, IConfigurationService } from 'vs/platform/configuration/common/configuration'; </del> <ins> import { IConfigurationService } from 'vs/platform/configuration/common/configuration'; </ins> import { IEnvironmentMainService } from 'vs/platform/environment/electron-main/environmentMainService'; import { ILifecycleMainService } from 'vs/platform/lifecycle/electron-main/lifecycleMainService'; import { ILogService } from 'vs/platform/log/common/log';

Discussion:
Type: <bBug</b(e.g. via group policy) get the "1" badge on the settings icon in the lower left corner telling you about an update The "Main" log after startup shows: Additionally disabling instead makes an obnoxious notifcation pop up on every start/window reload. VS Code version: Code 1.72.0 (, 2022-10-04T23:20:39.912Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: No <details<summarySystem Info</summary </details<details<summaryExtensions (18)</summaryExtensionVersion ------ EditorConfig0.16.4 gitlab-workflow3.53.0 python2022.16.0 vscode-pylance2022.10.10 jupyter2022.9. jupyter-keymap1.0.0 jupyter-renderers1.0.10 vscode-jupyter-cell-tags0.1.6 vscode-jupyter-slideshow0.1.5 remote-ssh0.90.1 remote-ssh-edit0.84.0 remote-wsl0.72.0 cpptools1.12.4 hexeditor1.9.9 remote-repositories0.22.0 rust-analyzer0.3.1238 rewrap1.16.3 vscode-lldb1.8.1 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.72.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
How did you do this, exactly?
We obtained the VSCode ADML from the VSCode 1.72.2 ZIP file (policies folder) and roll out the GPO to all computers in our domain, which is how gets the configuration. Neither the Install Updates (1) badge nor the Update notification popup should be appearing when "Disable Updates" is set (as it shouldn't be checking for them in the first place), yet it continues to do so, despite the configuration applying (as seen in his config file). !
I can't reproduce. When I set it to this is how the setting appears in the settings editor: !

Are you setting it at the user or machine level?
I don't have the setting in my user's , if that's what you mean.
Can you show me the settings editor focused on that setting? With the policy applied, that is. My question was regarding the policy: whether it's set at the user or machine level.
That is also how the setting appears on our editor (the "None" setting). Policies are deployed as a computer settings, as we're using the System installer (MSI), and want it to apply for all users.
Do you have the message?
Yes: !
OK. If you see that, it means it's working. If you restart VS Code, does the Main log still show the same update service output?
We are having the same behavior. The only thing I can think of is that our enterprise installs vscode to D:Program Files (x86)Microsoft VS Code We are running 1.71.0. ! Here is a log output showing that vscode is checking for updates even though it's set to none !
Need your eyes here. Look at the screenshot above: The settings editor shows that we're reading the policy correctly from Windows, since the settings editor shows that UI. But the update service (main process) doesn't seem to read the same value at startup. Do we maybe have a race condition?
Only possible scenario I can think of is following If the native policy service is not initialising when it is asked to initialise Do you think if there is any caching involved while reading the policies? Is it helpful to add log (debug) statement after initialising policies by the policy service?
Either myself or can provide any logs you require. In case relevant, we also use the 64bit System Wide installer ~(.MSI)~ (.EXE) in our org as opposed to the User Install in AppData, but at its default install location
We don't distribute an .MSI package ourselves. Can you clarify if that is really an .MSI or an .EXE?
My mistake, it is the EXE provided in - 64bit System Wide Installer. Deployed with the following switches; contains the following data;
I've trace logging to the NativePolicyService which should help us get more visibility on this.

Could you install tomorrow, then run , set the logging level to and open the log in the pane and show me whatever logs you might have related to ?
Thanks for looking into this further. I will be sure to do this tomorrow. Is there likely to be confidential information contained in the trace logging such as IP's, domain names and user accounts? If so then could I sent the file somewhere less public?
There won't be any PI in there. It will also be very very short, just a few lines, you can easily paste it here. Here's my output: That actually points to something bad in the logging. I've pushed another update to the logging line. Can you try this tomorrow? The actual steps are: VS Code Insiders a command line, launch it as the log in the view for the lines
My output is: Code Insiders version:
This is already very good: , it indicates that we've detected a policy value. Let me add one more trace log to see what's in there. Please try again tomorrow.
FWIW, Insiders downloaded the update anyway:
Can you send me the full log? I'm interested in the timings.
Running normally: Restarting with :
has pushed a few more log statements here. Can you give this a try again on the latest insiders and send us the full logs? Thank you!
Let us know, Also if you're still around!
Oops, sorry, this fell off my todo list. Newest Insiders from right now, all lines with policy or update in it: Full logs:
We think we found the issue. The setting used to be called . We think you might still have a value for , is that true? If you remove that value, is the issue fixed?
Where is that value stored? There's nothing in my
Any updates on this?
(I don't know where the setting is, so I haven't checked further)
Hi . is a user in our domain and so any logs submits by them will be the same as anything I would produce. I am keeping an eye on the thread though in case changes are made (either to VSCode or the ADMX file) and will contribute if required.

you can check the by calling it from the Command Palette (Strg + Shift + P -Search for "Open Settings (JSON)")
Side note for I tested it by using just a registry entry but this didnt work at all. It showed that it is managed by my organisation but it still auto updated.
There is no setting my my JSON config.
Sorry for the delay here. and I found the issue! Many thanks for your patience. Fix will come in the next release.
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Friendly ping! Looks like this issue requires some further steps to be verified. Please provide us with the steps necessary to verify this issue.
Not OP, but I would be glad to verify it on Monday, if Madig doesn't respond in Time.
I now see in the main log on startup. So I guess /verified.