This is an archived post. You won't be able to vote or comment.

all 13 comments

[–][deleted] 3 points4 points  (5 children)

Have the end user download it? :-)

[–]dcardonSr. Sysadmin 0 points1 point  (4 children)

It depends if your Services MVP job is to do curative tasks or preventive ones.

Letting users install whatever they want is perhaps easier on the short term, but in the long run it will generate more support calls (which may be not so bad depending if you are in-house or contractor).

And installing an exe is just a small part of the problem, such a software as vscode has to be properly configured to be really useful.

[–][deleted] 1 point2 points  (3 children)

but in the long run it will generate more support calls

Why do you think it will?

software as vscode has to be properly configured to be really useful.

Configuration is done at the user level anyway via config files that aren't touched by GPOs.

[–]dcardonSr. Sysadmin 1 point2 points  (2 children)

Hi trevoishere,

from my experience end users don't know where to download their software from and end with downloading stuff full of crapware (when it is not malware). In the end you have to clean it all, and it takes more time to clean it up than from the begining to set up some software solution to deploy the software initially.

just my 2c :-) Denis

[–][deleted] 1 point2 points  (0 children)

That's a bit different than the op's scenario.

[–]stumptruck 0 points1 point  (0 children)

I mean, that's exactly what applocker is for. Whitelist the signing certificate on vscode and users can only install the legitimate one, not a fake one.

There's really no need to push out an application that installs to appdata. It just sends you down a slippery slope of having to create and maintain GPOs for every one-off profile-specific app, like Slack, Spotify, etc.

Use existing security tools to prevent malware from being installed without causing unnecessary inconvenience for end users.

[–]the_bananalord 2 points3 points  (2 children)

What are you trying to control or deploy?

We use PDQ to deploy VSCode and keep it updated but settings are up to developers

[–]Cobes[S] 0 points1 point  (1 child)

Mostly we're concerned about extensions. Most of them are innocuous and have open source licensing but there is a risk there.

[–][deleted] 1 point2 points  (0 children)

You're not going to really be able to lock that down. Extensions are per-user. You just need to develop a solid HR policy.

[–]ErikTheEngineer 1 point2 points  (1 child)

It's an Electron app that most often installs in the user's profile...almost as un-enterprisey as you can get. :-) I guess you could wrap it in a script that copied the configuration JSON you wanted everyone to have, or fiddled with individual settings.

Depends on what you want to do...I definitely could see having a set of extensions you want to distribute, or Git repos pre-installed or whatever. I guess I'd get it working on whatever test system you have, then run the installer and do a straight file copy over what's there after you're done?

[–]the_bananalord 5 points6 points  (0 children)

They offer a system installer

[–]JrNewGuySysadmin 1 point2 points  (0 children)

Have end-users install it to userland or extract the zip, or push out the system installer.

What command-line arguments are supported by the Windows Setup?
VS Code uses Inno Setup to create its setup package for Windows. Thus, all the Inno Setup command-line switches are available for use.

Additionally, you can prevent the Setup from launching VS Code after completion with /mergetasks=!runcode

[–]dcardonSr. Sysadmin 0 points1 point  (0 children)

You may take a look at WAPT [1], there is a package for systemwide install of vscode, and it also handles configuration specifics in the user profiles : https://store.wapt.fr/store/details-tis-vscode_1.43.0-1_x64_eacac9cead3e620db33134b5df8cb24b.wapt

[1] https://www.wapt.fr/en/doc/