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

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

@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.

@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

@tom-elliott Am I on the right track for the json data needed to create a scheduledtask? Or can we not create scheduledtasks in the api?

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

@jj-fullmer this is expected. Remember, Ms makes powershell and command line case insensitive, but Linux doesn’t.

taskType is the id for scheduled tasks.

tasktype is the full definition. I can make the change so the first is mor definitive though.

I thought this might be the case, thanks for making the change, giving updating a try now

@Tom-Elliott I was playing with creating a scheduled task via the api.
When I do a get on http://fog-server/fog/scheduledtask/current I get a json output but there are 2 taskType definitions. I’m pretty sure the first one should be taskTypeID

{
    "count": 1,
    "scheduledtasks": [{
        "id": "66",
        "name": "Deploy Task",
        "description": "",
        "type": "S",
        "taskType": "1",
        "minute": "",
        "hour": "",
        "dayOfMonth": "",
        "month": "",
        "dayOfWeek": "",
        "isGroupTask": "",
        "hostID": "1657",
        "shutdown": "",
        "other1": "",
        "other2": "-1",
        "other3": "fog",
        "other4": "1",
        "other5": "",
        "scheduleTime": "1605895200",
        "isActive": "1",
        "imageID": "0",
        "host": {
            "id": "1657",
            "name": "ACT-WKS-4263",
            "description": "Created by FOG Reg on October 19, 2018, 8:49 am",
            "ip": "",
            "imageID": "27",
            "building": "0",
            "createdTime": "2018-10-19 08:49:32",
            "deployed": "2018-10-19 08:53:31",
            "createdBy": "fog",
            "useAD": "",
            "ADDomain": "",
            "ADOU": "",
            "ADUser": "",
            "ADPass": "",
            "ADPassLegacy": "",
            "productKey": "",
            "printerLevel": "",
            "kernelArgs": "",
            "kernel": "",
            "kernelDevice": "",
            "init": "",
            "pending": "0",
            "pub_key": "",
            "sec_tok": "",
            "sec_time": "",
            "pingstatus": "<i class=\"icon-ping-windows fa fa-windows green\" data-toggle=\"tooltip\" data-placement=\"right\" title=\"Windows\"><\/i>",
            "biosexit": "",
            "efiexit": "",
            "enforce": "1",
            "primac": "c8:d9:d2:7e:bc:73",
            "imagename": "Base-Stable-1909",
            "hostscreen": {
                "id": null,
                "hostID": null,
                "width": null,
                "height": null,
                "refresh": null,
                "orientation": null,
                "other1": null,
                "other2": null
            },
            "hostalo": {
                "id": null,
                "hostID": null,
                "time": null
            },
            "inventory": {
                "id": "275",
                "hostID": "1657",
                "primaryUser": "",
                "other1": "4263",
                "other2": "",
                "createdTime": "2018-10-19 08:49:33",
                "deleteDate": "0000-00-00 00:00:00",
                "sysman": "HP",
                "sysproduct": "HP ProDesk 600 G4 DM",
                "sysversion": "",
                "sysserial": "8CC8291JLH",
                "sysuuid": "e46956df-5297-6b46-2b4b-db05b32effe7",
                "systype": "Type: Mini Tower",
                "biosversion": "Q22 Ver. 02.02.04",
                "biosvendor": "HP",
                "biosdate": "08\/06\/2018",
                "mbman": "HP",
                "mbproductname": "83EF",
                "mbversion": "KBC Version 07.B4.00",
                "mbserial": "PGVLV0B8JB360M",
                "mbasset": "",
                "cpuman": "Intel(R) Corporation",
                "cpuversion": "Intel(R) Core(TM) i5-8500T CPU @ 2.10GHz",
                "cpucurrent": "Current Speed: 2000 MHz",
                "cpumax": "Max Speed: 2100 MHz",
                "mem": "MemTotal: 7927840 kB",
                "hdmodel": "",
                "hdserial": "",
                "hdfirmware": "",
                "caseman": "HP",
                "casever": "",
                "caseserial": "8C328.000000:103809024.000000:16777216.000000:20520607744.000000:",
                "osID": "9",
                "deployed": "2019-11-11 17:24:19",
                "format": "5",
                "magnet": "",
                "protected": "1",
                "compress": "19",
                "isEnabled": "1",
                "toReplicate": "1",
                "srvsize": "10142164451",
                "os": {},
                "imagepartitiontype": {},
                "imagetype": {}
            },
            "pingstatuscode": 0,
            "pingstatustext": "Success",
            "macs": ["c8:d9:d2:7e:bc:73", "14:4f:8a:d5:d2:ed", "14:4f:8a:d5:d2:ee", "16:4f:8a:d5:d2:ed", "14:4f:8a:d5:d2:f1"]
        },
        "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": "2020-11-20 11:00"
    }]
}

I was running this to get an idea of what I need to create a scheduledtask object.
I tried doing a POST call to http://fog-server/fog/scheduledtask/create as well as http://fog-server/fog/host/1657/task
(using my module it was New-FogObject -type object -coreObject scheduledtask -jsonData $jsonData and New-FogObject -type objecttasktype -IDofObject 1657 -jsonData $jsonData -coreTaskObject host)
with the json data being

{
        "name": "Deploy Task",
        "description": "",
        "type": "S",
        "taskTypeID": "1",
        "minute": "",
        "hour": "",
        "dayOfMonth": "",
        "month": "",
        "dayOfWeek": "",
        "isGroupTask": "",
        "hostID": "1657",
        "shutdown": "",
        "other1": "",
        "other2": "-1",
        "other3": "fog",
        "other4": "1",
        "other5": "",
        "scheduleTime": "1605895200",
        "isActive": "1",
        "imageID": "27",
        "runtime": "2020-11-20 11:00"
}

Trying to do the first scheduledtask object call I just get a 500 error. The task object task makes a active task, it says that the start time is at the runtime I give, but it doesn’t show up in scheduled tasks it shows up in normal tasks.

I think the problem may be in https://github.com/FOGProject/fogproject/blob/d9e7a329a6ec6384593c75df3026ca0b46efa00f/packages/web/lib/fog/scheduledtask.class.php around line 40, but I’m not really sure.

@george1421 @Rivybeast
Just some guesses (can’t really test any of this cause I’m working from home today)
but I would think you can make a session with that command I shared plus some json data. Probably need a name and an imageid in the jsondata (maybe you also need interface?), so something like

$mcSessionData = @{
    name = "sessionName";
    imageId = '27'
}
$data = $mcSessionData | ConvertTo-Json;
$mcSession = New-FogObject -type object -coreObject multicastsession -jsonData $data;
#now you have the details of the multicast session in an object/variable and you can add hosts to it via multicastsessionassociation

I would suggest creating a session the way you normally do, and do a Get-FogObject -type object -coreObject multicastSession to see what fields are filled and how in the one you make yourself. And then once you have hosts assigned to the session do a Get-FogObject -type object -coreObject multicastSessionAssociation to see what the association object looks like.

If you do that and post the output here I can help a lot more with creating everything. There may also be need to use the -type objectTaskType multicastsession api path. I just don’t use multicast sessions often so I don’t know the structure off the top of my head.

But typically the way things work in fog is you have an object like multicastsession and then the multicastsessionassociation object has the id of the session and the id of a linked object like a host. But it might be a linked object of a multicast task. Once all that is known (and somebody in this forum probably already knows it) then I can help you make a script for creating sessions and adding hosts to it (maybe I’ll make some helper functions and add them to the module). You could theoretically make a script that runs on a schedule or trigger that checks if the multicast session ended and makes a new one.

@george1421 I don’t know off the top of my head sadly. I don’t do much with multicast. But multicastsession is one of the apiobjects. So @Rivybeast you can give my powershell module a try. Once you’ve got it setup (i.e. Install-Module FogApi; Set-FogServerSettings;)

You could mess with the multicastsession coreobject.
A quick test I go this

 $test = New-FogObject -type object -coreObject multicastsession
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: removing body from call as it is null
VERBOSE: POSTing  to/from http://fog-server/fog/multicastsession/create
VERBOSE: POST http://fog-server/fog/multicastsession/create with 0-byte payload
VERBOSE: received -1-byte response of content type application/json
VERBOSE: finished api call
C:\Users\jfullmer\git\admin_scripts [master ≡ +1 ~3 -0 !]> $test


id             : 4
name           :
port           : 0
logpath        :
image          : @{imageTypeID=; imagePartitionTypeID=; id=; name=; description=; path=; createdTime=; createdBy=;
                 building=; size=; osID=; deployed=; format=; magnet=; protected=; compress=; isEnabled=;
                 toReplicate=; srvsize=; os=; imagepartitiontype=; imagetype=}
clients        : 0
sessclients    : 0
interface      :
starttime      : 0000-00-00 00:00:00
percent        : 0
stateID        : 0
completetime   : 0000-00-00 00:00:00
isDD           : 0
storagegroupID : 0
anon3          :
anon4          :
anon5          :
state          : @{id=; name=; description=; order=; icon=}
imageID        :

Which may give you some more ideas. The output at the end may be some of what you might be able to specify in the json data of a post call (New-FogObject). @Tom-Elliott May be able to help more as far as what data is needed to create a multicast session in the api.

Based on these quick tests though I’d say there’s some high hopes.

@sebastian-roth

MariaDB [fog]> SELECT ilID,ilHostID,ilStartTime,ilFinishTime FROM imagingLog WHERE ilHostID=(SELECT hostID FROM hosts WHERE hostName LIKE '%dr-wks-2943%');
+------+----------+---------------------+---------------------+
| ilID | ilHostID | ilStartTime         | ilFinishTime        |
+------+----------+---------------------+---------------------+
|  987 |     1581 | 2017-11-06 16:43:25 | 2017-11-06 16:44:58 |
| 1353 |     1581 | 2020-11-17 18:13:37 | 0000-00-00 00:00:00 |
+------+----------+---------------------+---------------------+
2 rows in set (0.07 sec)

@sebastian-roth Yes to both. It’s just the reporting and history that didn’t work.

Last night I queued up 3 computers to be re-imaged.
They all imaged but one of the hosts didn’t get an updated image history.

The imaging log report looks like this for the 3 computers

The one that didn’t get a history update has a duration that is really just the time it started.

This may be related to my other ongoing post https://forums.fogproject.org/post/139217 I’m working with @Sebastian-Roth on, but this seems like a separate issue.

Sadly that 27k downloads was a glitch on the psgallery site.
But I still did do some updating to fix a couple bugs I just found. Nothing major, just a couple tweaks to fix pending mac address handling

Released Version 2004.2.2.4

https://www.powershellgallery.com/packages/FogApi/2004.2.2.4
Release notes - https://fogapi.readthedocs.io/en/latest/ReleaseNotes/ (see versions 2004.2.2.1 - 2004.2.2.4 for changes)

@george1421 I have seen some strange behavior with 1’s and 0’s related to the hostPending field in the database that I’m still working out with @Sebastian-Roth . I believe there’s some notes buried somewhere in my post here https://forums.fogproject.org/topic/14607/weird-host-behavior-some-disappearing-losing-primary-mac-some-suddenly-needing-approval where I discovered I had some hosts says pending = 1 some pending = ‘1’ and then pending = 0 and pending = ‘0’.
I ended up making all of them string values (‘1’ or ‘0’ rather than 1 or 0).
It doesn’t seem to be universally true throughout everything but I have seen it.

@nehsa
Also, I also want to know how to make a scheduled task via the api. I’ve messed with that idea and haven’t been able to figure out the json needed. My workaround has been to schedule a reboot in windows using a combination of powershell date math (to figure out seconds till a given time) and shutdown.exe /r /t $seconds then I stop the fog service on the host (so it doesn’t reboot the host) and queue the task for right now.
It would be much more elegant to do a delayed scheduled task.

I think the required fields may be something like

 {
     "taskTypeID": 1,
     "type":"S",
     "scheduleTime":"1585616580"
}

I have that commented out in some code but sadly didn’t write down what that time meant… but regardless I’m pretty sure it didn’t actually work. I think I probably just scheduled a task and did a get call on tasks to see what it looked like. If I didn’t, that’s what I should have done…
@Tom-Elliott might have some insight on scheduling a task via the api

@Sebastian-Roth All the computers I imaged in the last week seem to now think they’re pending.
Perhaps we could find some time next week to troubleshoot this together?

@Sebastian-Roth These weird suddenly pending asset issues are still happening. I’m about to start re-imaging all our computers. May provide more data to debug the problem, or maybe it’ll fix the problem, we’ll see.

@fog_newb I suggest bookmarking https://github.com/FOGProject/fogproject/commits/dev-branch
So you can do a quick check for updates on the dev-branch anytime

@Sebastian-Roth So, just so I’m documenting the right thing.
Should I update the field’s documentation here https://docs.fogproject.org/en/latest/management/host-management.html#primary-disk
With a note (and a link to this forum post) that you can put either the devname or the exact blocksize/sector count with the linux command to find said sector count. Is that command accessible in the fog debug console? It looks like in windows you can use the powershell command get-disk | select Number, "FriendlyName", Size to list available disks by number and friendly name and display the blocksize. So it can be found fairly easily in Windows and Linux.

Is just adding a note by the field enough, or should there be a separate page explaining nvme selection?

@jaumeramos Remind me where you found the printermanagerhelper. I remember that being added a few years back but couldn’t find it when I was updating the documentation, so I wasn’t sure if we still were including it.

@sebastian-roth It’s beautiful!
Thanks for figuring that out!

@huecuva That is an interesting update for sure. I believe graphics cards have a bios of some sort and sometimes there’s some option rom boot option related to the gpu in the computer’s bios setting. It would make some sense for the graphics drivers to also update the bios or boot option roms on gpus.
What GPU’s do you have? GPU’s of the gtx 10xx series and newer have a ‘studio’ driver option that’s supposed to be the sort of ‘stable’ branch option. If your cards can use that, maybe using that as a standard could help if it’s not something you’re already doing?