PowerShell – Save Scheduled Tasks

You can use Group Policy Preferences to create a scheduled task and deploy it via GPO. This is probably the quickest way to get what you're looking for.

If you're entitled to System Center licensing, you should also explore System Center Orchestrator.

edit: I was so surprised that there were 4 previous answers that didn't mention GPO as a possibility, that I wrote a blog post with a quick rundown of how to do this.

What you're doing makes sense; no one need fiddle with the script (which may introduce code issues), or with the scheduled task (which may require that they know the "run as" account's credentials, and is also fiddly especially to those unfamiliar).

Having the configuration file path passed in as a parameter also makes sense; that way you can reuse your script with different configurations easily; so you're not restricted to a single "set of parameters" at any one time, but can have a set of parameters (configuration file) per scheduled task.

Possible Issue

Your JSON includes the data type; e.g."folder1": ["string","C:\\sldks\\dsf\\sdf\\sdf\\sd\\fsdf\\"]. Why? You'll have defined the types in your PS file anyway (if required); in your config you just want to hold the data without requiring that your admins know that "string" means "text" / without having to think about it. i.e. just have "folder1": "C:\\sldks\\dsf\\sdf\\sdf\\sd\\fsdf\\".

There are some additional considerations:

• JSON vs XML vs INI vs Database vs Other. What sorts of files/technologies are your admins most familiar with / what do they find it easiest to manipulate? Personally I'd use XML for this; PS is just as comfortable with it, but the advantage is your admins can open it in a browser and immediately see whether it's valid XML or not (i.e. if they've missed a closing tag / misspelt something). That said, this depends very much on your team's abilities/preferences/tools.

• Validation. What happens if someone enters bad data, or corrupts the file format (e.g. misses a bracket), or corrupts the file (e.g. saves in ANSI instead of UTF8 / whatever)? Make sure your script has something to handle this; and also consider how you'd find out; i.e. as well as "don't run if the config has issues" you want a "report an issue so that I can investigate & fix it if the config has issues".

• Character Escaping. In the above example you'd had to escape your file path: C:\\sldks\\dsf\\sdf\\sdf\\sd\\fsdf\\ instead of C:\sldks\dsf\sdf\sdf\sd\fsdf\. Would admins know to do this / know which characters to escape for the config file's format? If you have a (generic) tool for editing such files which takes the pain out of this that'll save you some concerns; otherwise see point above on validation.

• Security. Are the folders containing your scripts and your config files appropriately secured; otherwise people can manipulate your code to do what they like whilst running under the task's "run as" account. If the people editing config are different to those editing scripts it's likely best to keep them in separate directories to limit what each person can do.

Most of those things would still be considerations if passing parameters; so your way's definitely a step up regardless of the above considerations; but if you're looking to make something really friendly and robust, taking the above points into account will help.