@Sebastian-Roth I will give that a go and see if it that eradicates the issue. I haven’t seen it happen since I fixed all the snapin hashes and updated the client, but I’ve also only imaged one computer since then.

@swadsworth here’s a link to the location plugin tutorial https://wiki.fogproject.org/wiki/index.php?title=Location_Plugin

@swadsworth What I’m getting at (I tend to ramble and want to share all the details) is that if you’re using a vpn, you shouldn’t need to do anything special compared to a normal setup.

But then I just thought about it a bit more.
You’re running the fog server on a computer in your house, so it will need to go through the vpn to get to the network and then through the vpn to get to all the other computers. This could get hinky, but hey test it first, could be fine. What I would do is, assuming you have a central office/site where the vpn/main network is hosted, setup the fog server on a virtual or physical machine there. But since you’re doing the imaging at your house, setup that device as a node so the imaging can happen theoretically locally.

So if all worked nicely an imaging device would follow this path

---

pxeBoot ->

find configured tftp server (central fog server) ->

download ipxe.efi boot file ->

boot to central fog ->

start image task (through pxe menu or automatically here if already queued) ->

image task connects to local storage node (will require configuring the node priority) ->

Imaging then happens within local network (hopefully, it may still be trying to traverse the vpn to get to the node)

---

However if that doesn’t work as expected and instead still goes over the vpn, then keeping your fog server and devices being imaged on the same local network is better. So for snapin deploying, it would make more sense to have that server on the same network the vpn is on, so that all the clients just go through a vpn -> main network -> fog server and then back again path rather then a vpn -> main network -> vpn -> fog server and then back again path. Your best imaging experience would be all on the same network, but fog client stuff you want to do can work over vpn.

If it gets super complicated, a semi-simple solution would be to just set up 2 fog servers. 1 that you already have that you just use for imaging devices before putting them on the network, then a central fog server on the main network you use for the fog client management. You could just embed a fog client connected to the central server in the image to simplify that part.

I’m sure there’s someone else that has done something similar to what you’re trying to do. There’s a location plugin for example that helps with connecting servers at different sites, I don’t have any experience with it though. I will gladly be of as much help as I can through here as this sounds like a fun setup. But others with more experience with remote locations may need to chime in.

So in my second test to see if this happened again it didn’t happen again. The second surface go 2 I’m imaging got past the part the other one magically became pending.

So there were 2 differences one or both of which fixed the problem

• Manually Re-uploaded the file for the snapin that had a mismatch hash error
• Fog Client 0.12.0 was used instead of 0.11.19

I need to image another different device before I can be really sure.

So now I’m wondering why the new 0.12.0 fog client isn’t being auto updated to on all my clients through the client updater? As I recall from past updates, simply updating the installer on the fog server side should get all the clients to update. Am I forgetting a step? @Sebastian-Roth maybe you have some insights.
I can deploy it through my own software deployment tools if I must.

@JJ-Fullmer I just relooked at the database output and noted that the hostPending field was set to ‘1’. So it did at least say in the database that the host became pending, but it still wasn’t showing in the gui outside of the existing tasks.
I’m currently testing to see if I can recreate the issue or if having fixed the snapin with the hash error solves the issue.

@swadsworth I’m not familiar with using google’s mdm as a domain/domain controller for an internal network. Do you have a way to test if you can get to the fog server over the vpn? i.e. another person at a different location that could help you test or perhaps just setting up your phone as a 4g hotspot and using a different computer to get to the fog web gui through the vpn as a start. I wouldn’t suggest deploying over a 4g hotspot through the vpn, unless you have unlimited data and a small snapin for testing.

Once you confirm that your clients can access the fog server, and that the client is connected and checking in. (install the client on the remote machine then open C:\fog.log and see if it’s checking for snapins, name changes, etc or if it’s getting stuck at the authentication step). Then you can for sure setup groups and use snapins for deploying programs.

Granted, snapins are really designed around being deployed right after an image rather than software updates, but they can be used for that. Another product (that sadly isn’t free) that might fit your needs for software deployment is chocolatey for business and their new system called chocolatey central management. I haven’t actually used their central management system yet, but it looks cool and has features to work with lots of network configurations. All my snapins are based off chocolatey packages, as we have chocolatey for business and take advantage of the automatic package builder. There is also a free version of chocolatey, it’s just not quite as automated and powerful as the paid version. Just thoughts on some other options if snapins alone don’t do what you need.

@swadsworth If you’re just looking to be able to see whether or not a host is up and maybe deploy snapins and stuff like that, this may be able to be done over the vpn. If you’re thinking of trying to image over the vpn, well it might be theoretically possible but would likely be painfully slow if you can get it to work. I’ve messed with that for fun once or twice and wouldn’t currently recommend it. I know there are others that have accomplished imaging across multiple sites though.

But anyway, provided your vpn is giving users access to the fog server and vice versa then managing through the vpn should work mostly as expected. There is potential for home networking to get in the way, but most likely things should work over the vpn as if the devices were all local. I don’t do a ton of management of devices connecting through the vpn but I do connect through the vpn and then manage devices that are on site all the time. I have tested fog client connectivity through the vpn and found it works pretty well (tested deploying snapins on my computer at home for example). But it’s probably gonna depend on your VPN configuration, I don’t believe I did anything on the fog server to make that work, it just sees the vpn devices as another subnet on the internal network.

That error says that partition 4 is too small. So it seems to think that the image is bigger than the spin 5’s drive.
Looking at your image settings I’d recommend recapturing using partclone zstd at compression level 19. Probably won’t fix this problem, but might speed up your imaging while saving space on the server.

I believe the when fog captures the image it shrinks it down to only what is actually in use, so your scenario should work. Personally, as a fail safe, I use a 80 GB virtual disk size for my images which never had an issue deploying to 120 GB drives. Granted after a while we found that users with 120 GB drives ran out of space just from windows maintenance (updates, caches, etc.), well that and the users never deleting an email in outlook.

So if it’s feasible, maybe try recapturing the image with the virtual drive being smaller than anything in your environment. (80-120 GB perhaps).

TL;DR

Changed the display name of my image.
Deployed said image.
Suddenly some hosts have to be approved.
Hosts are typically added via pxe boot menu. There was a snapin hash error on one host and then it suddenly needed to be approved but didn’t show up in pending hosts list.
Other hosts did show up in pending hosts lists, but all of them had been authenticated through the fog service and working previously.

---

I am on fog 1.5.8.13 on centos 7.

I have discovered some weird behavior and I’m not sure where it’s coming from.

I’m still troubleshooting to find more exact parameters for when this is happening so I’ll do my best to explain.

Scenario 1 - host losing primary mac

I have a bundle of devices in my environment that don’t have integrated ethernet. So I have a solution for using usb/usb-c ethernet adapters that support pxe.
I have a handful of these adapters I use for specific models and such. For example, I’m imaging a microsoft surface go 2, it requires a surface usb-c ethernet adapter to pxe boot.
So I have 1 adapter (they don’t need ethernet once they’re deployed) and I have a function at the very end of my provisioning script that removes the mac address of this usb ethernet adapter, and then approves all the pending macs that the fog client would have found by that point. Thus making it so the host will be found over wifi by the fog client identified by its wifi mac(s). This has worked well for quite some time.

However, right now I just imaged this surface go 2 and somehow before reaching the part of my provisioning process that would remove that, the host has lost its mac address. If I search for the host in the gui (or via the api) it doesn’t show up anywhere. If I try to make a new one, it says a host with that name already exists. So I searched the database and found that the host still exists there, but it has no matching record in the HostMac table. Which is where I’m getting the ‘lost its primary mac’ as the name of this problem.

Some other notes: I create the hosts and queue them for imaging in the pxe boot menu (Add host full registration option). The fog client is embedded in my image but the service is disabled before capturing the image. The provisioning process starts it on demand as needed till it’s completely enabled for installing assigned snapins. I noticed that this happened when it was attempting to install snapins because it got stuck in a loop since the fog client log kept throwing an ‘invalid host’ error. I use the fogservice to rename the computer and join the domain, which did happen successfully

This happened with fog client 0.11.9, I just saw that 0.12.0 is available and added it to my server so it will start updating my clients. I didn’t see anything in the release notes that leads me to believe it will fix anything though. My current hypothesis is that the client is the culprit of this problem, but I don’t know for sure.

Edit

I don’t want to remove my other notes but before I finished writing this out did a bit more log tracing.
I found the time that these things changes via the fog.log

------------------------------------------------------------------------------
---------------------------------SnapinClient---------------------------------
------------------------------------------------------------------------------
 7/17/2020 1:44:51 PM Client-Info Client Version: 0.11.19
 7/17/2020 1:44:51 PM Client-Info Client OS:      Windows
 7/17/2020 1:44:51 PM Client-Info Server Version: 1.5.8.13
 7/17/2020 1:44:51 PM Middleware::Response Success
 7/17/2020 1:44:51 PM SnapinClient Running snapin 7zipZstd
 7/17/2020 1:44:51 PM Middleware::Communication Download: http://192.168.100.117//fog/service/snapins.file.php?mac=60:6D:3C:3D:41:97|F8:E4:E3:FA:6D:E8|FA:E4:E3:FA:6D:E7|F8:E4:E3:FA:6D:E7|F8:E4:E3:FA:6D:EB&taskid=5397
 7/17/2020 1:44:52 PM SnapinClient C:\Program Files (x86)\FOG\tmp\chocoPkgSnapin.ps1
 7/17/2020 1:44:52 PM Bus Emmiting message on channel: Notification
 7/17/2020 1:44:52 PM SnapinClient Starting snapin
 7/17/2020 1:46:27 PM SnapinClient Snapin finished
 7/17/2020 1:46:27 PM SnapinClient Return Code: 0
 7/17/2020 1:46:27 PM Bus Emmiting message on channel: Notification
 7/17/2020 1:46:27 PM Middleware::Communication URL: http://fogserver/fog/service/snapins.checkin.php?taskid=5397&exitcode=0&mac=60:6D:3C:3D:41:97|F8:E4:E3:FA:6D:E8|FA:E4:E3:FA:6D:E7|F8:E4:E3:FA:6D:E7|F8:E4:E3:FA:6D:EB&newService&json
 7/17/2020 1:46:28 PM SnapinClient Running snapin DeviceForm - Detachable
 7/17/2020 1:46:28 PM Middleware::Communication Download: http://192.168.100.117//fog/service/snapins.file.php?mac=60:6D:3C:3D:41:97|F8:E4:E3:FA:6D:E8|FA:E4:E3:FA:6D:E7|F8:E4:E3:FA:6D:E7|F8:E4:E3:FA:6D:EB&taskid=5393
 7/17/2020 1:46:28 PM SnapinClient C:\Program Files (x86)\FOG\tmp\chocoPkgSnapin.ps1
 7/17/2020 1:46:28 PM SnapinClient ERROR: Hash does not match
 7/17/2020 1:46:28 PM SnapinClient ERROR: --> Ideal: 817B881A4D07DCFF51F67A47D9595DDE59D010FE0C018BDF5B57C502CB83A14F3085AF48987B392E8BF38E2C6B29D094055BDFFB6BBCD5647697D64AA4BDD668
 7/17/2020 1:46:28 PM SnapinClient ERROR: --> Actual: 5271D1B9F35EA9FC2F1E3CE474C20641A15B37A02035E7E8210DFB513518CBC79FDFD25092A41491C2AB02AF8E0913C99819C6066B9883F398D90C5D045E4A1D
 7/17/2020 1:46:28 PM Middleware::Communication URL: http://fogserver/fog/service/snapins.checkin.php?taskid=5393&exitcode=-1&mac=60:6D:3C:3D:41:97|F8:E4:E3:FA:6D:E8|FA:E4:E3:FA:6D:E7|F8:E4:E3:FA:6D:E7|F8:E4:E3:FA:6D:EB&newService&json
------------------------------------------------------------------------------


------------------------------------------------------------------------------
--------------------------------PrinterManager--------------------------------
------------------------------------------------------------------------------
 7/17/2020 1:46:28 PM Client-Info Client Version: 0.11.19
 7/17/2020 1:46:28 PM Client-Info Client OS:      Windows
 7/17/2020 1:46:28 PM Client-Info Server Version: 1.5.8.13
 7/17/2020 1:46:28 PM Middleware::Response Module is disabled globally on the FOG server
------------------------------------------------------------------------------


------------------------------------------------------------------------------
--------------------------------PowerManagement-------------------------------
------------------------------------------------------------------------------
 7/17/2020 1:46:28 PM Client-Info Client Version: 0.11.19
 7/17/2020 1:46:28 PM Client-Info Client OS:      Windows
 7/17/2020 1:46:28 PM Client-Info Server Version: 1.5.8.13
 7/17/2020 1:46:28 PM Middleware::Response Success
 7/17/2020 1:46:28 PM PowerManagement Calculating tasks to unschedule
 7/17/2020 1:46:28 PM PowerManagement Calculating tasks to schedule
------------------------------------------------------------------------------


------------------------------------------------------------------------------
----------------------------------UserTracker---------------------------------
------------------------------------------------------------------------------
 7/17/2020 1:46:28 PM Client-Info Client Version: 0.11.19
 7/17/2020 1:46:28 PM Client-Info Client OS:      Windows
 7/17/2020 1:46:28 PM Client-Info Server Version: 1.5.8.13
 7/17/2020 1:46:28 PM Middleware::Response Success
 7/17/2020 1:46:28 PM Middleware::Communication URL: http://fogserver/fog/service/usertracking.report.php?action=login&user=QA-TAB-6105\AdlAdmin&mac=60:6D:3C:3D:41:97|F8:E4:E3:FA:6D:E8|FA:E4:E3:FA:6D:E7|F8:E4:E3:FA:6D:E7|F8:E4:E3:FA:6D:EB&newService&json
------------------------------------------------------------------------------

 7/17/2020 1:46:28 PM Service Sleeping for 98 seconds
 7/17/2020 1:48:07 PM Middleware::Communication URL: http://fogserver/fog/management/index.php?sub=requestClientInfo&configure&newService&json
 7/17/2020 1:48:07 PM Middleware::Response Success
 7/17/2020 1:48:07 PM Middleware::Communication URL: http://fogserver/fog/management/index.php?sub=requestClientInfo&mac=60:6D:3C:3D:41:97|F8:E4:E3:FA:6D:E8|FA:E4:E3:FA:6D:E7|F8:E4:E3:FA:6D:E7|F8:E4:E3:FA:6D:EB&newService&json
 7/17/2020 1:48:07 PM Middleware::Response Invalid host
 7/17/2020 1:48:07 PM Middleware::Communication URL: http://fogserver/fog/service/getversion.php?clientver&newService&json
 7/17/2020 1:48:07 PM Middleware::Communication URL: http://fogserver/fog/service/getversion.php?newService&json

 7/17/2020 1:48:07 PM Service Creating user agent cache
 7/17/2020 1:48:07 PM Middleware::Response Module is disabled on the host
 7/17/2020 1:48:07 PM Middleware::Response Module is disabled globally on the FOG server
 7/17/2020 1:48:07 PM Middleware::Response Module is disabled globally on the FOG server

So right after a snapin hash didn’t match suddenly everything is disabled and invalid. (the snapin hash not matching relates to a separate issue that makes no sense when updating snapins via the api that use a snapin file that already exists, but I have a separate failsafe that gets that installed so don’t worry about that right now). This error isn’t unfamiliar to me but I can usually ignore it. I looked at my personal provisioning process logs and there wasn’t anything running at that time as an api call to the fog server or anything like that.

This lead me to think, wait is this task still active?
So I checked the gui and lo and behold it was. For some reason I could get to host through the link in the tasks screen but not anywhere else. It said it was pending and needed to be approved…
It did not show up in the pending hosts and the hostPending field in the database was empty as far as I could tell. Here’s the database host record query for reference (with some private info ‘redacted’)

 select * from hosts where hostname = "qa-tab-6105";
+--------+-------------+-----------------------------------------------+--------+-----------+--------------+---------------------+---------------------+--------------+-----------+---------------------+-----------------------------------------------------------------------------+------------+------------+------------------+----------------+------------------+----------------+------------+------------+----------+-------------+------------------------------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------+---------------------+--------------+--------------+-------------+-------------+
| hostID | hostName    | hostDesc                                      | hostIP | hostImage | hostBuilding | hostCreateDate      | hostLastDeploy      | hostCreateBy | hostUseAD | hostADDomain        | hostADOU                                                                    | hostADUser | hostADPass | hostADPassLegacy | hostProductKey | hostPrinterLevel | hostKernelArgs | hostKernel | hostDevice | hostInit | hostPending | hostPubKey                                                       | hostSecToken                                                                                                                     | hostSecTime         | hostPingCode | hostExitBios | hostExitEfi | hostEnforce |
+--------+-------------+-----------------------------------------------+--------+-----------+--------------+---------------------+---------------------+--------------+-----------+---------------------+-----------------------------------------------------------------------------+------------+------------+------------------+----------------+------------------+----------------+------------+------------+----------+-------------+------------------------------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------+---------------------+--------------+--------------+-------------+-------------+
|   1737 | qa-tab-6105 | Created by FOG Reg on July 17, 2020, 12:35 pm |        |        27 |            0 | 2020-07-17 12:35:12 | 2020-07-17 12:41:47 | fog          | 1         | domain.site         | OUstring                                                                    | user       | password   |                  |                |                  |                |            |            |          |             | secretKey                                                        | secretKey                                                                                                                        | 2020-07-17 14:09:29 | 0            |              |             | 1           |
+--------+-------------+-----------------------------------------------+--------+-----------+--------------+---------------------+---------------------+--------------+-----------+---------------------+-----------------------------------------------------------------------------+------------+------------+------------------+----------------+------------------+----------------+------------+------------+----------+-------------+------------------------------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------+---------------------+--------------+--------------+-------------+-------------+

So I guess that this all relates to hosts suddenly being unapproved

Other Hosts suddenly requiring approval

During imaging

Another host that we imaged yesterday is a more standard desktop. It did not lose its mac address but instead suddenly required approval in the gui. It was also giving the ‘invalid host’ error.
This one appeared in the pending hosts lists, got approved and then continued through its provisioning via the fogservice as normal.

Randomly (seemingly at least)

While troubleshooting the surface go scenario, checked the pending hosts in the web gui again and found 3 active/deployed hosts suddenly needing approval.
Sadly their fog logs didn’t go as far back to be able to see if they perhaps had the same snapin hash error before becoming invalid.

Other notes

The only other thing I can think of that might be worth noting is that I did change the display name of the image all of these hosts had associated with them. When each of them had to be approved they also had lost any image associations. Could changing the display name of an image cause such problems. I also overwrote the image file on the server manually but that’s something I’ve also done a million times before. We have 3 images, a dev, stable, and previous. New images are uploaded as dev, then tested, if it’s stable we move the image files to the stable folder and keep a previous version of stable as a fail safe. Then we just add what version of windows 10 is in the image on the display name. i.e. the current one is Base-Stable-1909. Before renaming it it was Base-Stable-1809. The image id and all that stayed the same so this shouldn’t have caused any issue, but that’s the only thing I can think of that we changed before this happened.

@JJ-Fullmer said in FOG 1.5.4 API host module settings:

@Jamaal Glad you got it figured out, sorry I didn’t see this early as adding it to the host splat that you convert to json adds it to the json data that @Tom-Elliott references here. I will make a note about adding something with setting modules to my module in the future

Look, I made a note https://github.com/darksidemilk/FogApi/issues/1

@Jamaal Glad you got it figured out, sorry I didn’t see this early as adding it to the host splat that you convert to json adds it to the json data that @Tom-Elliott references here. I will make a note about adding something with setting modules to my module in the future

@Jamaal I believe that the wake on lan is enabled by default, so you don’t need to do anything to include it when creating the deploy task via the api.

@zfeng I believe there are some powershell tools for that and I have built a powershell module for the api (see links in my signature). I haven’t done anything CICD with it but I imagine that’s something that could be figured out. I mean I kind of do something like that with my images having powershell modules and scripts in git that build and capture my image, but it’s not automated with a CICD design as I like doing it a bit more manually to make sure everything runs smoothly.

TL;DR
The quick answer is the ‘useAD’ property of a host in the api checks that box, but will not pull your default settings when done through the api. So you need to provide all domain join info.

@Jamaal Good day sir! Sorry for a delayed reply, haven’t been on here in a bit, had been trying to stay active during my quarantine but eventually my infant son won all my attention while I was home. But I am now back at work and am excited to see someone with a powershell api question =).

I took a look at that old post and @scottybullet and I should clearly be friends. Looks like he posted some powershell api stuff before I published my module publicly.

So as @Sebastian-Roth mentioned, check out the powershell module (check the links in my signature). If you use that as a dependency of your script you’ll have a good time. If this leads to some more functions needing to be added to the module to make it easier we can make the functions and get them added.

So let me see if I got this straight.

You have microsoft orchestrator (I’m not actually familiar with that product, but I think I get what it does from context)

1. You want other employees to put info about a new computer into that product in some way
2. That product sends that info to a powershell script
3. The script adds the computer to fog and queues it to start imaging with wake on lan as soon as you plug it in to the network.

Currently it isn’t auto joining the domain but you want it to.

Well sir I believe the answer may be pretty easy. I usually add fog hosts using the pxe boot menu
Firstly, something built in fog is setting default AD settings at http://fog-server/fog/management/index.php?node=about&sub=settings (select Active directory defaults). I pull that info when I register a host in the pxe boot menu and then edit it during a provisioning script to put things in the right OU. But I just realized that doesn’t matter because it doesn’t pull that information when you create from the API, but it’s still a feature that exists and there may be a way to leverage it in your situation but we’ll come back to that if we need to.

Ok so first let’s create a host

# you can also just do name, description, and macs and add the rest after with a set-fogobject command
$HostJson = @{
    "name"=  "testHost-1"
    "description"=  "a test"
    "macs" =  @("11:22:33:44:55:66")
    "imageID" = "29"
    "useAD" = 1 
    "ADDomain" = "yourDomain.com"
    "ADOU" =  "OU=OUname,OU=ParentOU,OU=GrandParrentOU,DC=yourDomain,DC=com"
    "ADUser" = "domainUsername"
    "ADPass" = "plainTextPassword"
    "enforce" = 1
}
#note that "useAD" = 1 checks the join domain after deploy box
#note that "enforce" = 1 checks the force rename and join even if user is logged in box
#note that the password is in plaintext via the api because you are already authenticated to get to this point, this is why I prefer to pull from the existing default so I don't pass the password in plaintext anywhere. 

#convert to ps object to a json string
$json = $hostJson | ConvertTo-Json
$newHost = New-FogObject -type object -coreObject host -jsonData $json

Sidenote: @Tom-Elliott or @Sebastian-Roth is it possible to pull the default domain settings include username/password from the fog settings via the api? So that to add domain join info through an api call doesn’t require a plaintext password, or maybe some other solution, like making it so the defaults are pulled if a host created with the api has that join after deploy/useAD box checked?

So that above code would add a new host with the domain information and stores the host info in a variable. You could then queue the image of the host with (I should really make a function for this)

$jsonObj = @{
    "taskTypeID" = 1
}
$jsonData = $jsonObj | ConvertTo-Json;
# create the image task on the newhost 
New-FogObject -type objecttasktype -coreTaskObject host -jsonData $jsonData -IDofObject $newHost.ID;

@Greg-Plamondon another suggestion. We had enough issues with pxe boot compatibility acorss different devices that we embed a custom bootloader that has an option for booting directly to a local copy of the ipxe.efi file. We use grub2win and just have its installation as part of our provisioning scripts that are started by sysprep firstlogon. Found this to work better than trying to get custom nvram type settings, this way you get it individuallized per hardware but also using a universal config file.

I don’t have the ignore mac on client/imaging
Setting built in to those functions, but you can take a peek at the code to see whrte you are setting the primary property there is also a property for ignoring mac on client. I’m on my phone at the moment so can’t go test and get for sure answers. But it’s either a part of thr maclist array of a host or a different property. Point is you can for sure set that. If you give me a bit more detail I will gladly try to give you further examples on how to do it with the powershell module

@John-Sartoris check out the powershell api module. See my signature for links.
I have some functions that may already do what they want or can at least get you in the right direction. Check out these ones

Get-PendingMacsForHost

Approve-FogPendingMac

Deny-FogPendingMac

A new version has been published!

I haven’t yet completed all my goals. But about half or more of the functions have at least one example in their help file and there is now an online home for the documentation.

You can find the published listing here
https://www.powershellgallery.com/packages/FogApi/2002.2.1.2

The documentation is now at https://fogapi.readthedocs.io/en/latest/
and the module’s code is now in its own repository at https://github.com/darksidemilk/FogApi

Hopefully more updating still to come in the near future.
I have thoughts and plans on creating a custom class for ‘fogObjects’ returned from the api to make things more universal throughout and make creating pipeline functions easier. Want to make it so most functions have 3 parameter sets that include performing the operation by id, name, or by object. We’ll see when I get to that.

Due to current global pandemic conditions I find myself with some extra time to work on this. I do also have an infant, so not a ton of time, but more than I usually have to work on these kinds of projects.

I am currently thinking I will focus on the following things in the module but would love input on any features people would like in an API module out of the box.

• Creating a readthedocs or github pages based webpage for help files integrated with powershell’s get-help {function-Name} -online functionality. i.e. https://github.com/darksidemilk/FogApi is a rough draft
• Moving the api to its own repo following best practices for powershell modules. https://github.com/darksidemilk/FogApi.
• Update the build script to utilize the new structure and documentation needs
• Make sure each existing function has documentation, especially including examples
• Make it compatible with Powershell 7 (ideally without losing powershell 5 compatibility)
• Once compatible with powershell 7, add more cross platform compatibility for linux and mac (though I don’t have a way to test mac functionality) on all existing functions
• Add Functions for more common fog tasks (Hoping to get some requests to know where focus is best spent)
• Make it so the return object will work with the small api changes in fog 1.6 by making it just return just the content as the count is automatically included in a powershell object or changing the return object in some way that isn’t a breaking change. i.e. it currently returns something like

count: 100
hosts: {hostJsonContent}

in 1.6 I understand it will change to

count: 100
data: {hostJsonContent}

So I may utilize some method to make it so everything returns an object with count and data or just data or something based on what fog version you have. May also add additional 1.6 options if time permits (I understand there are join functions, and options to return just a specific parameter/member of an object or objects, or at least those were the plans 2 years ago)

• Make it so there’s more pipeable commands. i.e. you put some host in a variable and then just pipe it to actions

Get-FogHost -hostname computername | Add-FogHostMac -macaddress "12:34:56:78:90"

This would probably take quite some time to add

We’ll see how much of this I’m able to do in the undetermined amount of time this pandemic has me at home all day.

@abulhol Any luck with the new Nuc?