1

I’m wondering, from an IT standpoint, what are the best practices to store scripts that are run regularly on an endpoint? Should they be stored locally, or should they be stored on a network location eg. a network share? Not sure how Intune and other RMMs work

I have Action1 set up on all my endpoints. The current workflow looks like this: A powershell script gets pushed to the endpoint, this is what sets up the scheduled task. This first powershell script is stored inside Action1 —> The scheduled script runs a VBS wrapper → The VBS wrapper runs the 2nd powershell script that does what I need it to do. Both the VBS wrapper and the powershell script launched by it are stored in a network share accessible to all endpoints, read-only permissions.

How dumb or suboptimal is this? How would this workflow look in a corporate environment managed by an RMM such as Intune or Action1 or ManageEngine?

7 Spice ups
2

Realistically, having them stored on a network share is what I’ve seen in most of the AD-based places I’ve worked.

It means that a malicious actor could infect all of your PCs at once if they were able to gain write access to that file somehow, but it means that they can’t abuse an individual machine as easily using it.

I’d personally be more concerned with the PS being wrapped in VBS. It would be much better to sign the script and run it directly, assuming you have your execution policy set to only allow scripts that you’ve signed.

Not only is VBS deprecated, but MS is actively planning to disable (and eventually fully remove it) in the future: https://techcommunity.microsoft.com/blog/windows-itpro-blog/vbscript-deprecation-timelines-and-next-steps/4148301

7 Spice ups
3

I only use VBS for no console flash. -WindowStyle Hidden does flash the console for 1-2 seconds and it’s very annoying to me.

Oh btw, I remember some genius came up with a lolbin-based malware called ShrinkLocker entirely based on BitLocker and VBS. Now reading that, that was just beautiful. Some crazy smart people exist out there.

4 Spice ups
4

Why do you need PS->VBS->PS.

Can’t the first PS script that sets a schedule use a runonce on install to pull and execute the others, then you wont need VBS or to wait for A1 to trigger - similarly to how I suggested you use a loop in your script to see if it’s been run, then not run again. Write something in to create the schedule, confirm this has been complete, then pull and execute the next lot (which could in theory sit on a website, perhaps behind an API or token that is unique to your scripts).

You wont need to have multiple scripts in A1, you can modify your base code later to add or remove others, pull as needed and not rely on any push or triggers. If only specific machines get specific program or whatever it is your pulling, put some code in to ensure the machine has X before deploying or has product Y before trying to update.

As an aside, while scripts should be on a network share (or website/ftp for pull), for your protection, you should also keep copies of, including built-in versioning in something like Gitlab, which if you use vs code, integrates your saves with a local copy and a sync.

2 Spice ups
5

The RunOnce reg key gets auto-deleted after it triggers whatever it’s to trigger.

2 Spice ups
6

Your either misreading or assuming i mean the registry key.

I’m suggesting, like the ‘has the script run’ check that doesn’t run it again, add something in to check if this is the scripts first run.

For example, if the script looks in C:\scripts and there is not a file called ‘firstruncomplete.txt’ then run command, download script2.ps1 and execute it, followed by script2.ps1 and so on, once all scripts are complete, save a file called firstruncomplete.txt

So if it runs again, it will see the file and abort.

3 Spice ups
7

I fail to see how your suggestion would hide the powershell console flash which the VBS script does

2 Spice ups
8

this is very similar to your question from yesterday

4 Spice ups
9

So your issue isn’t script best practises any more, you’re hung-up once again on a minute detail, which if you’re concerned you can still do it your way, PS->VBS–> PS, but adding something like mentioned above to do it all via a single script.

I was offering you a suggestion to keep your number of scripts down and taking in to consideration VBS will be at some point, revoked.

I notice though you aren’t bothered about the flash you might get from your initial script that sets a schedule.

3 Spice ups
10

Oh my bad, I didn’t read your suggestion carefully. I’ll try it on a VM.

2 Spice ups
11

Btw let me ask you: In your experience (looks like you’ve been doing this for decades), where do companies store their scripts that they run on endpoints like employee’s laptops? Do they store them on a network share?

2 Spice ups
12

Usually in SYSVOL under Scripts. It’s the default location for GPO’s, so all domain-connected computers have a central repository built in.

3 Spice ups
13

So this place doesn’t exist if my PC isn’t part of a domain network?

2 Spice ups
14

Correct, as it’s a folder created on the DC and shared out by default.

2 Spice ups
15

I see. I suppose the standard user doesn’t have write access to it, right? Can they even see the folder, or is it hidden? And if it’s hidden, the scripts can still run out of it and live inside it, right?

2 Spice ups
16

It’s read-only, every machine has access to it, and it isn’t hidden at all. \ \company-dc1\SYSVOL

2 Spice ups
17

If scripts are needed, @Nonya covered where, but this is only applicable to local domain joined machines, not workgroups or Entra devices, those, if needed will be stored elsewhere.

A standard user, if they knew how, could see the share - by definition of it being a user script it needs to at least be readable by the user, the share isn’t usually hidden.

In an AD instance the machine needs to be on the network to run it.

For Entra the machine needs internet access to the script location.

For the company I work for, I can’t think of many scripts that get run in the way you’re attempting.

And yes, I’ve been in this a long time, none of what I suggest to you is to be derogatory, disrespectful or otherwise negative, it’s my way of thinking, which is usually outside of the box and to best practises, I am not a fan of overly complicated.

KISS Principal.

I will add that scripts are less necessary if you can use GPO or Intune policies, that said, it’s unknown what your scripts do, so i can’t give a specific answer to offer ways to get your goals, other than giving you my view on your scripts.

3 Spice ups