API Return object for scheduledtask is malformed (has a tiny typo)

[Tom Elliott]

@jj-fullmer I haven’t looked at scheduled tasks in a very long time (when referencing the API) but I believe you are on the right track.

Essentially the required fields:

taskTypeID
hostID
type

(Type = C or S – C = cron S = delayed)

Of course none of that makes sense so I would recommend:

name = just a nice name
description = optional but maybe something like invoked from powershell api script
type = S or C
taskTypeID = one of the task types
minute = (Only if type c, If S type full date in YYYY-MM-DD HH:ii:ss format)
hour = (Only if type c)
dayOfMonth = (Only if type c)
month = (Only if type c)
dayOfWeek = (Only if type c)
isGroupTask = (1 = is group task, 0 = is not)
hostID = (if a group task, this will be the group id, otherwise this will be the host id)
shutdown = (do you want the host/group to shutdown once the task is complete – 0 = restart, 1 = shutdown)
other2 = (deploy snapins, snapin ID, -1 for all snapins associated, or false to not deploy
other3 = (username to reset, only used if the scheduled task is a password reset)
other4 = (1 = wol enabled, 0 = wol disabled)

Hopefully this helps.

Thank you,

[JJ Fullmer]

@tom-elliott On what api path would you expect that to work?

When I run that on the host/hostID/task path it makes a normal task that shows a start time of the runtime. I haven’t tested to see if it works like a scheduled task or not when that happens.

p.s. The update did the trick for getting scheduled tasks from the api in powershell =D

[JJ Fullmer]

@Tom-Elliott
Here’s what I’m getting

 New-FogObject -type object -coreObject scheduledtask -jsonData $jsonData -vb
VERBOSE: Building uri and api call
VERBOSE: Pulling settings from settings file
VERBOSE: Pulling settings from settings file
VERBOSE: Building Headers...
VERBOSE: Building api call URI...
VERBOSE: POSTing {
    "name":"Deploy Test",
    "type":"S",
    "taskTypeID":"1",
    "runTime":"2020-11-20 15:13",
    "isGroupTask":"0",
    "hostID":"1736",
    "shutdown":"0",
    "other2":"-1",
    "other4":"1"
} to/from http://fog-server/fog/scheduledtask/create
VERBOSE: POST http://fog-server/fog/scheduledtask/create with -1-byte payload
VERBOSE: received -1-byte response of content type application/json
VERBOSE: finished api call


id           : 76
name         : Deploy Test
description  :
type         : S
taskTypeID   : 1
minute       :
hour         :
dayOfMonth   :
month        :
dayOfWeek    :
isGroupTask  : 0
hostID       : 1736
shutdown     : 0
other1       :
other2       : -1
other3       :
other4       : 1
other5       :
scheduleTime : 0
isActive     :
imageID      : 0
host            : #I Omitted this part to keep this shorter and cause its shows ad creds
tasktype     : @{id=1; name=Deploy; description=Deploy action will send an image saved on the FOG server to the client computer with all included snapins.; icon=download; kernel=; kernelArgs=type=down; type=fog; isAdvanced=0; access=both; initrd=}
runtime      : 1969-12-31 17:00

This does create an object in the scheduledtasks table. I can see it in the database, but I can’t see it in the gui. Also, the runtime/starttime is different from what was passed in the json. So something’s going on here. It would be extremely beneficial to be able to get this working. Not just for my own purposes, there have been some other people in the forums asking about it from time to time.

[JJ Fullmer]

PROGRESS!

With this json

$jsonData = @"
 {
     "name":"Deploy Test 2",
     "type":"S",
     "taskTypeID":"1",
     "runTime":"2020-11-20 15:13",
     "scheduleTime":"1605895200",
     "isGroupTask":"0",
     "hostID":"1736",
     "shutdown":"0",
     "other2":"-1",
     "other4":"1",
     "isActive":"1"
 }
 "@

It creates a scheduled task! Huzzah!
However it converts the time I give either to UTC time or as if it was given in universal time.
I got the scheduletime value by making a scheduled task manually and then getting the object. I think that and the isActive were both important. It also doesn’t seem to like it when you have a task with the same name made with the api, but all the scheduled tasks have the same name when made in the gui.
I just confirmed that both those properties are needed for a scheduled task. Just need to figure out how to get the time I expect it to be.

This was the result for reference. It also ignored the minutes in the time I gave.

New-FogObject -type object -coreObject scheduledtask -jsonData $jsonData -vb
VERBOSE: Building uri and api call
VERBOSE: Pulling settings from settings file
VERBOSE: Pulling settings from settings file
VERBOSE: Building Headers...
VERBOSE: Building api call URI...
VERBOSE: POSTing {
    "name":"Deploy Test 2",
    "type":"S",
    "taskTypeID":"1",
    "runTime":"2020-11-20 15:13",
    "scheduleTime":"1605895200",
    "isGroupTask":"0",
    "hostID":"1736",
    "shutdown":"0",
    "other2":"-1",
    "other4":"1",
    "isActive":"1"
} to/from http://fog-server/fog/scheduledtask/create
VERBOSE: POST http://fog-server/fog/scheduledtask/create with -1-byte payload
VERBOSE: received -1-byte response of content type application/json
VERBOSE: finished api call


id           : 78
name         : Deploy Test 2
description  :
type         : S
taskTypeID   : 1
minute       :
hour         :
dayOfMonth   :
month        :
dayOfWeek    :
isGroupTask  : 0
hostID       : 1736
shutdown     : 0
other1       :
other2       : -1
other3       :
other4       : 1
other5       :
scheduleTime : 1605895200
isActive     : 1
imageID      : 0
host         : #omitted
runtime      : 2020-11-20 11:00

[JJ Fullmer]

Actually it seems to ignore whatever I put in runtime and just puts 11:00 today, so maybe scheduletime converts to runtime somewhere?

New-FogObject -type object -coreObject scheduledtask -jsonData $jsonData -vb
VERBOSE: Building uri and api call
VERBOSE: Pulling settings from settings file
VERBOSE: Pulling settings from settings file
VERBOSE: Building Headers...
VERBOSE: Building api call URI...
VERBOSE: POSTing {
    "name":"Deploy Test 5",
    "type":"S",
    "taskTypeID":"1",
    "runTime":"2020-11-20 19:00",
    "scheduleTime":"1605895200",
    "isGroupTask":"0",
    "hostID":"1736",
    "shutdown":"0",
    "other2":"-1",
    "other4":"1",
    "isActive":"1"
} to/from http://fog-server/fog/scheduledtask/create
VERBOSE: POST http://fog-server/fog/scheduledtask/create with -1-byte payload
VERBOSE: received -1-byte response of content type application/json
VERBOSE: finished api call


id           : 81
name         : Deploy Test 5
description  :
type         : S
taskTypeID   : 1
minute       :
hour         :
dayOfMonth   :
month        :
dayOfWeek    :
isGroupTask  : 0
hostID       : 1736
shutdown     : 0
other1       :
other2       : -1
other3       :
other4       : 1
other5       :
scheduleTime : 1605895200
isActive     : 1
imageID      : 0
runtime      : 2020-11-20 11:00

[JJ Fullmer]

@jj-fullmer said in API Return object for scheduledtask is malformed (has a tiny typo):

1605895200

It looks like this is the seconds since epoch you can get with linux date function.
i.e. date --date='@1605895200' returns Fri Nov 20 11:00:00 MST 2020
maybe setting schedule time as a normal date string works too…nope it does not, has to be seconds since epoch.
I think I can work with this though. There is a -unixtimeseconds param on the powershell 7 version of get-date but it looks like it coverts a number to a date not a date to a number. So just gotta do some date math.

$EpochDiff = New-TimeSpan “01 January 1970 00:00:00” $(Get-Date)

$EpochSecs = [INT] $EpochDiff.TotalSeconds - [timezone]::CurrentTimeZone.GetUtcOffset($(get-date)).totalseconds

$EpochSecs

That gets and displays the current time in epoch secs. So at some point I just need to add a function to the module for scheduledtasks where it will take a given datetime object and convert it to seconds since epoch like

function Get-SecsSinceEpoch {
param (
    $scheduleDate = (Get-Date)
)
process {
    $EpochDiff = New-TimeSpan "01 January 1970 00:00:00" $($scheduleDate)
    $EpochSecs = [INT] $EpochDiff.TotalSeconds - [timezone]::CurrentTimeZone.GetUtcOffset($(get-date)).totalseconds
    return $EpochSecs
}
}

Implementing the rest of the scheduled task object would take a bit more time than I have at the moment sadly.
Also credit where it’s due, found this snippet in the comments on this blog post https://jamgotre.blogspot.com/2011/02/powershell-seconds-since-1970.html
I just turned it into a function here. I’m sure there’s gotta be someone else who’s done this before or something and it really should be included in Get-Date if it isn’t already. I just actually submitted an issue so that it might become included https://github.com/PowerShell/PowerShell/issues/14211 I feel special.

[JJ Fullmer]

GREAT SUCCESS!

Here is a working example of setting a scheduled deploy image task on a host with the id 1736 using the FogAPI powershell module (provided you also paste/import this function into your console/session until I eventually add it to the module) I’m also including the verbose output for reference of what’s happening. You can omit the -Verbose part of New-FogObject if you don’t want all the output

function Get-SecsSinceEpoch {
param (
    $scheduleDate = (Get-Date)
)
    process {
        $EpochDiff = New-TimeSpan "01 January 1970 00:00:00" $($scheduleDate)
        $EpochSecs = [INT] $EpochDiff.TotalSeconds - [timezone]::CurrentTimeZone.GetUtcOffset($(get-date)).totalseconds
        return $EpochSecs
    }
}

$scheduleTime = Get-SecsSinceEpoch -scheduleDate (Get-Date 15:30)
$jsonData = @"
>> {
>>     "name":"Deploy Test 7",
>>     "type":"S",
>>     "taskTypeID":"1",
>>     "runTime":"2020-11-20 15:30",
>>     "scheduleTime":"$scheduleTime",
>>     "isGroupTask":"0",
>>     "hostID":"1736",
>>     "shutdown":"0",
>>     "other2":"-1",
>>     "other4":"1",
>>     "isActive":"1"
>> }
>> "@
C:\Users\jfullmer\git\admin_scripts [master ≡ +1 ~3 -0 !]> New-FogObject -type object -coreObject scheduledtask -jsonData $jsonData -vb
VERBOSE: Building uri and api call
VERBOSE: Pulling settings from settings file
VERBOSE: Pulling settings from settings file
VERBOSE: Building Headers...
VERBOSE: Building api call URI...
VERBOSE: POSTing {
    "name":"Deploy Test 7",
    "type":"S",
    "taskTypeID":"1",
    "runTime":"2020-11-20 15:30",
    "scheduleTime":"1605911400",
    "isGroupTask":"0",
    "hostID":"1736",
    "shutdown":"0",
    "other2":"-1",
    "other4":"1",
    "isActive":"1"
} to/from http://fog-server/fog/scheduledtask/create
VERBOSE: POST http://fog-server/fog/scheduledtask/create with -1-byte payload
VERBOSE: received -1-byte response of content type application/json
VERBOSE: finished api call


id           : 83
name         : Deploy Test 7
description  :
type         : S
taskTypeID   : 1
minute       :
hour         :
dayOfMonth   :
month        :
dayOfWeek    :
isGroupTask  : 0
hostID       : 1736
shutdown     : 0
other1       :
other2       : -1
other3       :
other4       : 1
other5       :
scheduleTime : 1605911400
isActive     : 1
imageID      : 0
runtime      : 2020-11-20 15:30

And here it is in the gui

I believe you probably also need to update to the lastest dev version of fog for this to work from windows. Before this change I wasn’t ever able to get or create anything on this api path. But I also didn’t have the correct parameters for the json.

I hope to eventually make this a much more user friendly api powershell function. Something like Set-FogScheduledtask -host $somehost -time (get-date 15:40) -allSnapins -name "just a nice name" -taskType (capture|deploy|snapin|etc) will probably have a lot of parameters, but it will probably be worth putting in the time to make that work nicely so people can easily create scheduled tasks from a command line. Just need to get a couple hours to myself to get it done.

[JJ Fullmer]

@Tom-Elliott When I create a scheduled task via the API, it errors out if the name field has a task that already exists. Which is odd because if you make the tasks manually they always have the same name and it causes no problems. Could there be some check on these api post calls that’s making them not work if the name is not unique? I could probably make it so the name has an incremented number or something, but my first attempts at doing that revealed that there’s either a character limit on that field, or it just doesn’t like it when the host name of the host being imaged is in that field. Thoughts?

[Tom Elliott]

@jj-fullmer The name field is not required for scheduled tasks. For Scheduled Tasks, the name is not set, as far as I remember. So I think the named “scheduled” task should use a unique name for the scheduled task.

[Tom Elliott]

@tom-elliott, @JJ-Fullmer Looking further, the generic premise behind the create/edit route checks if a “name” exists.

I can work to add checks that if you’re building certain types of items.

[Tom Elliott]

@tom-elliott Added a little tiny bit.

Thank you,

[JJ Fullmer]

@tom-elliott So there’s a check if the name exists? But the name is not required? I’ll try creating one without a name and see what happens. I don’t think there needs to be a unique name.

[JJ Fullmer]

@tom-elliott Saw this reply after I wrote mine, I’ll just give updating a go then and see what happens

[JJ Fullmer]

@tom-elliott said in API Return object for scheduledtask is malformed (has a tiny typo):

@tom-elliott Added a little tiny bit.

Thank you,

That tiny bit that allowed non-unique names for tasks and scheduled tasks did the trick!