microsoft
VSCode Extension Management via Intune Blocked
Does this issue occur when all extensions are disabled?: N/A
- VS Code Version: 1.96.3
- OS Version: Win11 Ent
Steps to Reproduce:
Apologies if this isn't the correct place to put this, but the GitHub conversation on VSCode (https://github.com/microsoft/vscode/issues/84756#issuecomment-2451939478) extension management was locked down 18 hours ago and I can't reply.
If you wish to use Intune to centrally manage your extensions, you can successfully import the ADMX file and configure the properties, but there's a snag.
If you look at this: https://call4cloud.nl/upload-admx-failed-intune-import/#6_0x20101_131329 and this: https://learn.microsoft.com/en-us/windows/client-management/win32-and-centennial-app-policy-configuration
registry entries generally into: Software\Policies\Microsoft
are blocked unless there is an exception. We need an exception for VSCode pretty pls, or we can't manage this via Intune.
Be great to see if there is an exception created for the VSCode ADMX registry path so we can utilise the ADMX via Intune. We patch VSCode via Intune with PatchMyPC and its never a great user experience when staff are being prompted to install updates but cannot due to no local admin permissions.
Oh, yes. I'll also add that the field in Intune seems to cap out at 1023 characters, so you can't have too many things in your stringified json. Not sure if the admx can request more space in the field. ty
Thank you for the feedback!
Is this an exception needed in InTune App, or from the VS Code application side? @CW-Willow could you double check if admx can have more than 1023 characters when you find the time? Just limiting to 1023 characters sounds very limiting.
fyi @joaomoreno
It's (likely) Intune MDM. Either the web service is refusing to send it, or the Intune agent on the Windows endpoints is refusing to apply it. The internals of that whole process are a bit voodoo (no offense to that team) :)
1023 chars is all we've got
The exception is for the Windows or Security team to enable the Software\Policies\Microsoft\VSCode path to be writable by policies otherwise it just gets blocked by Intune. Alternatively create a new key instead of being within Microsoft (internal requirements may prevent this I'd imagine?). In the meantime we can write a platform script to apply the settings through Intune so its not the end of the world for it though
The 1023 length is an admx limitation on the field type. The field should be a multitext input to a Multi String key instead to allow a much higher limit. Firefox had the same issue a few years back on their extension settings policy
Sandeep has just made a change such that there should no longer be the 1023 limit.
@TheAutisticTechie @CW-Willow I would love if one of you can try VS Code Insiders from tomorrow (Tuesday) and let us know if this is now better for you.
The exception is for the Windows or Security team to enable the Software\Policies\Microsoft\VSCode
I am still reaching out to the right team. Sorry for the delay here.
@TheAutisticTechie
The 1023 length is an admx limitation on the field type. The field should be a multitext input to a Multi String key instead to allow a much higher limit. Firefox had the same issue a few years back on their extension settings policy
I think all inputs has the same limitation, is not it?
@sandy081 Inside Intune, like most of ADMX style configurators, you're not likely to be able to override the 1023 character limit. If you look at settings such as Edge's URL blocklist, it's an array of entries. It's the only sane way of proceeding.
I highly suggest we do as @TheAutisticTechie says (thank you) and make VSCode handle an array of rules (which is all the JSON is today anyway). Not only will it save admins having to JSON Stringify things into consoles, but it will solve such issues properly for systems into the future.
Big long lists:
Edited like this:
[it's an example, we don't really block Google :) ]
@CW-Willow Thanks for the reply. Yes, we are going towards what @TheAutisticTechie suggested. But we have come across following doc - https://learn.microsoft.com/en-us/windows/win32/sysinfo/registry-element-size-limits that says
Long values (more than 2,048 bytes) should be stored in a file, and the location of the file should be stored in the registry. This helps the registry to perform efficiently.
Anyway, we are planning to support multitext input which I tested that it supports long values approx > 10kb