New Deployment Type: schtask

[jaywryan]

Enhancement for deployment type : Scheduled Task. This could be a WithOptions - Option on the FileSystem and RemoteFileSystem Deployment Types.

By FileSystem MyTask {
        FromSource MyTask.ps1
        To \\ServerY\c$\Tasks  
        WithOptions @{
            ScheduledTask = 'true'
            ComputerName = 'ServerY',
            RunAsUser = 'System',
            TaskName = 'MyTask',
            TaskRun = '"C:\Tasks\Mytask.ps1"',
            Schedule = 'Monthly',
            Modifier = 'second',
            Days = 'SUN',
            Months = '"MAR,JUN,SEP,DEC"',
            StartTime = '13:00',
            EndTime = '17:00',
            Interval = '60' 
        }
 }    

[RamblingCookieMonster]

Awesome idea, thanks Jay!

A few considerations that might come up:

• Do we rely on remoting and the new ScheduledTask cmdlets, or allow backwards compatibility with WMI or schtasks?
• Do we make this a separate DeploymentType, with an optional 'To'? I could see scenarios where you deploy tasks independent of the file, and could just point to an existing script. It might also help with readability, where you can quickly see 'By ScheduledTask' (although the large WithOptions scriptblock might give that away too).

Cheers!

[jaywryan]

Thanks Warren! I have been struggling with this, as we do a lot of little scripts and have a Scheduled Task server that runs the majority of these. Trying to work through a Release pipeline model, I've struggled with how to keep this automated and also keep the details of the task itself in version control. I think this would be a great way to achieve both.

• I think it makes the most sense to use WMI, we don't have to rely on antiquated schtask.exe or on new Cmdlets that may not be available down rev. However, I have the least amount of experience with WMI and scheduled task manipulation. I'm sure we can find some framework out there with basic functionality to use though.
• I do see your point to make it a separate deployment type. Tasks could be completely independent from file deployment. For example, I need to change the time for a task to run, it doesn't make sense to do a file deploy WithOptions...

Managing remote scheduled tasks might be out of the scope of what PSDeploy is designed to do, but I do see it as a gap in my processes and would be interested in hearing how other might be tackling these without the use of 3rd party task scheduler like JAMS.

What are your thoughts? do you think this fits well in the what PSDeploy is trying to accomplish?

[devblackops]

@jaywryan Awesome idea about scheduled tasks!

RE: the release pipeline, take a look at this simple repo I created as an example. https://github.com/devblackops/Release-Pipeline-Example

That is intended to manage a single script with documentation, Pester tests, build steps with psake, and deployment steps with PSDeploy. A more detailed write up is here https://devblackops.io/building-a-simple-release-pipeline-in-powershell-using-psake-pester-and-psdeploy/

[RamblingCookieMonster]

@jaywryan - Thanks for the follow-up! Makes sense to me, let's shoot for WMI (maybe CIM, fall back to DCOM?), separate DeploymentType, and we can use the 'To' field as an optional method to deploy the actual script (vs. requiring a separate FileSystem* deploymenttype)

Now... to find time : P If anyone's interested, feel free to fork dev and submit a PR!

[jaywryan]

Perhaps @pshdo Install-ScheduledTask could be a great fit here. I wouldn't want to create a dependency on Carbon but it might be worth using that as a starting point, with Aaron's permission of course.

[DexterPOSH]

@RamblingCookieMonster @jaywryan @devblackops
I like the idea and have some time at hand, so starting work on this now.
Since, I have dabbled with WMI/CIM from my ConfigMgr days, this approach looks good to me.

[DexterPOSH]

I have hit a bummer by just spending few mins with this, the only promising WMI Class found is Win32_ScheduledJob and it represents a job scheduled using the network management schedule service functions (also known as “Job” and “AT command” functions). Note that this is different from the tasks scheduled from the task scheduler.

Win32_ScheduledJob WMI Class has the Create method, whose mof signature is below:

        uint32 Create(
            [in]           string   Command,
            [in]           datetime StartTime,
            [in, optional] boolean  RunRepeatedly,
            [in, optional] uint32   DaysOfWeek,
            [in, optional] uint32   DaysOfMonth,
            [in, optional] boolean  InteractWithDesktop,
            [out]          uint32   JobId
         )

So looking at above signature, I think the deployment type would be a lot more limited.

Having said that, I am going to look at using schtasks.exe for this deployment type if backwards compatibility to Windows Server 2008 R2 is required.

Otherwise at the moment, I am looking at using ScheduledTasks module (CDXML based module which uses the new CIM namespace Root/Microsoft/Windows/TaskScheduler) which ships with Server 2012 and above.

[DexterPOSH]

@RamblingCookieMonster , pushed initial draft of how the script looks.
Had to add a lot of parameter sets in order to give flexibility :

be1d549

Do you think, this is the right approach here ?

[DexterPOSH]

This has been in my fork for a while now and I am just putting the idea on how the DSL should look while using the ScheduledTask deployment type with PSDeploy.

Deploy SchedTaskExampleDeployment {

    By ScheduledTask  {
        #FromSource 'Modules\File1.ps1' # tentative on if this is needed, the taskname explicitly specifies the script or file to execute
        To 'localhost' # specify the node's name to deploy scheduled task to, default is localhost if not specified
        WithOptions @{
            # This is where you splat all the arguments to a scheduled task, lot of parameter sets 
            TaskName = 'StartupSchedTask'
            TaskAction = 'powershell.exe -file .\Modules\File1.ps1'
            RunLevel = 'Highest'
            AtStartUp = $True          
        }
    }
}

Now since there are lot of arguments that can be passed to the Scheduled task creation, I made some changes to the Invoke-PSDeploy to get the parameter set in use from the deployment type and then check if the WithOptions hashtable has valid parameters being passed.

So the idea is in case of the hashtable has conflict with the parameter sets, it will throw an error.