Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a bunch of powershell scripts that are kicked off via scheduled tasks at various times.

The script are run multiple times with different arguments. Also admins unfamiliar with scripting needed to be able to change the parameters without have to edit the code.

Due to this requirement I passed the parameters in via arguments to powershell.exe in scheduled tasks. But this immediately became unwieldy because now to change a script's parameters you have to go into task scheduler and edit the args to powershell.exe which now look like this (actually even longer):

-command "& 'C:\some\file\path\' -param1 'C:\some\file\path\' -param2 'C:\soawme\fawdile\pawawasth\' -param3 'C:\some\fisdfle\pasdfth\' -param4 'some arg'"

So now what I want to do is have each script just take in one editable config file where the parameters can be changed by the admins. I could also organize the parameters more easily- have a "global" params config file all scripts use and than script specific config files.

I thought I would use json in the config files and was thinking about doing something like this:

edit: forgot to add my json files would look like below:

{
    "folder1":  [
                    "string",
                    "C:\\sldks\\dsf\\sdf\\sdf\\sd\\fsdf\\"
                ],
    "folder2":  [
                    "string",
                    "C:\\jiji\\sfef\\igig\\igg\\"
                ],
    "CSSFile":  [
                    "string",
                    "\\\\some\\netqwork\\path\\"
                ],
    "DBServer":  [
                     "string",
                     "myserver"
                 ],
    "DB":  [
               "string",
               "DB"
           ],
    "SqlQuery":  [
                     "string",
                     "SELECT * FROM myTable"
                 ],
    "UID":  [
                "string",
                "root"
            ],
    "PWD":  [
                "string",
                "123456"
            ]
}

$jsonObject = ConvertFrom-Json (cat $PathToMyExternalJsonFilePassedInFromTaskShedualer)

    function Set-ParamType ($jsonNode) {
        switch ($jsonNode[0]) 
        {
            'string' {return [string]$jsonNode[1]}
            'int' {return [int]$jsonNode[1]}
            'switch' {return [switch]$jsonNode[1]}
            default {"Debug: Unknown type"}
        }  
    }

    $folder1  = Set-ParamType($jsonObject.folder1)
    $folder2  = Set-ParamType($jsonObject.folder2)
    $CSSFile  = Set-ParamType($jsonObject.CSSFile)
    $DBServer = Set-ParamType($jsonObject.DBServer)
    $DB       = Set-ParamType($jsonObject.DB)
    $SqlQuery = Set-ParamType($jsonObject.SqlQuery)
    $UID      = Set-ParamType($jsonObject.UID)
    $PWD      = Set-ParamType($jsonObject.PWD)

This way in the scheduled task I have only one argument to pass in (the path of the config file). This seems to work, but I wanted to ask if there was a better\saner way to accomplish my goals. Is there something foolish about this approach I'm not seeing?

share|improve this question
    
Is there something foolish about this approach I'm not seeing? Having admins "unfamiliar with scripting" change your script parameters seems pretty foolish to me, yes. –  HopelessN00b Apr 30 at 17:29
1  
I use a batch file to wrap my powershell command when running in task scheduler. That way the script is separated from the parameters and I don't have to mess with the task scheduler (which is nice when it runs under a different user context. –  uSlackr Apr 30 at 18:59
    
The admins aren't scripting their entering parameters akin to "run a report on this server and put it here" more like an end user application. I thought about batch files too, but thought config files would be more manageable? This started as a few small scripts, but is growing into a framework for generating network reports. –  red888 Apr 30 at 19:15
    
I don't find that JSON particularly accessible, but you know your use case better than I. –  uSlackr Apr 30 at 19:42
    
I'll stick with what I'm doing for now and see if I run into problems. The only reason I'm using json is because I thought it would make extending parameters simpler as powershell 3.0 has a parser. Admittedly not as accessible as the familiar ini file format –  red888 May 1 at 13:05

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.