I can’t seem to recreate it, but I know it’s broken whenever I deploy a new computer. So next time I have to image a computer I’ll come on back

Ok so it appears to be working when I queued the tasks from the gui. I did grab the file while something was deploying and the hash was the same this time.
So maybe this only happens when the snapin is queued from the api, doesn’t make a ton of sense, but maybe.

Could also be related to when a host is new perhaps. I will try to be more vigilante in logging the next time it happens if I can’t recreated it by queuing the snapins from the api

ps this would be how I am queuing a all snapins task in powershell

function Start-FogSnapins {
    [CmdletBinding()]
    param (
        $hostid = ((Get-FogHost).id),
        $taskTypeid = 12
    )

    begin {
        Write-Verbose "Stopping any queued snapin tasks";
        $tasks = Invoke-FogApi -Method GET -uriPath "task/active";
        $taskID = (($tasks | Where-Object hostID -match $hostid).id);
        Write-Verbose "Found $($taskID.count) tasks deleting them now";
        $taskID | ForEach-Object{
            Invoke-FogApi -Method DELETE -uriPath "task/$_/cancel";
        }
        # $snapAssocs = Invoke-FogApi -uriPath snapinassociation -Method Get;
        # $snaps = $snapAssocs.snapinassociations | ? hostid -eq $hostid;
    }

    process {
        Write-Verbose "starting all snapin task for host";
        $json = (@{
            "taskTypeID"=$taskTypeid;
            "deploySnapins"=-1;
        } | ConvertTo-Json);
        Invoke-FogApi -Method POST -uriPath "host/$hostid/task" -jsonData $json;
    }

    end {
        Write-Verbose "Snapin tasks have been queued on the server";
        return;
    }
}

function Get-FogHost {
    [CmdletBinding()]
    param (
        [string]$uuid,
        [string]$hostName,
        [string]$macAddr
    )

    begin {
        [bool]$found = $false;
        Write-Verbose 'Checking for passed variables'
        if (!$uuid -and !$hostName -and !$macAddr) {
            Write-Verbose 'no params given, getting current computer variables';
            $uuid = (Get-WmiObject Win32_ComputerSystemProduct).UUID;
            $macAddr = ((Get-NetAdapter | Select-Object MacAddress)[0].MacAddress).Replace('-',':');
            $hostName = $(hostname);
        }
        Write-Verbose 'getting all hosts to search...';
        $hosts = (Invoke-FogApi).hosts;
        Write-Verbose "search terms: uuid is $uuid, macAddr is $macAddr, hostname is $hostName";
    }

    process {
        Write-Verbose 'finding host in hosts';
        [bool]$found = $false;
        $hostObj = $hosts | Where-Object {
            ($uuid -ne "" -AND $_.inventory.sysuuid -eq $uuid) -OR `
            ($hostName -ne "" -AND $_.name -eq $hostName) -OR `
            ($macAddr -ne "" -AND $_.macs -contains $macAddr);
            if  ($uuid -ne "" -AND $_.inventory.sysuuid -eq $uuid) {
                 Write-Verbose "$($_.inventory.sysuuid) matches the uuid $uuid`! host found";
                 $found = $true;
            }
            if ($macAddr -ne "" -AND $_.macs -contains $macAddr) {
                Write-Verbose "$($_.macs) matches the macaddress $macAddr`! host found";
                $found = $true;
            }
            if  ($hostName -ne "" -AND $_.name -eq $hostName) {
                Write-Verbose "$($_.name) matches the hostname $hostName`! host found";
                $found = $true;
            }
        }

    }

    end {
        if ($found){
            return $hostObj;
        }
        return $found; #return false if host not found
    }
}

First let’s try to gather some more information. Leave the snapin as is for now and only schedule snapin tasks for clients and let those run.

1. Does it randomly fail on the same host? So if you schedule the same task on one host ten times in a row, does it run through all the time if it is fine on the first run?

I don’t typically try it more than once maybe twice, if it fails I just run the command manually. But I will give that a try. See if I can’t recreate it on my computer.

2. When it magically fails on a host can you please grab that host and take a look at C:\Program Files (x86)\FOG\tmp. I have not checked the code yet but I would hope the fog-client leaves a copy of that file there on failure. Now check if that file is zero size or truncated or anything like that.

It does not leave a copy, it does put a copy there and if you’re watching it you can copy it real quick or you can stop the fogservice before the hash check if you’re lucky. I think I did that once when I first discovered the issue but don’t recall the result, I remember it being confusing, I guess I’ll have to try this again too.

3. On snapin failure as well pay attention to the apache and PHP-FPM log files to see if there is an HTTP/PHP error on snapin download (see my signature).

Good thought will give those a post.

4. Please post the full fog-client log here in case of a failure so we can have a look. Sometimes there is something we see that leads us to the real problem.

Standby

If that doesn’t help we can go ahead an try monitor the database for changes of the hash. FOG has a deamon running that updates the snapin hashes from time to time. Unlikely but maybe this is causing an issue. You can take a look in that log file (webUI -> logs -> snapin log) and even disable that in another step just to see if it interferes.

I was hoping there is a way to disable it on the server, maybe something in the database or something, because I didn’t want to go through the trouble of recompiling the fog client. The other trick is that I really only use snapins during provisioning right after I image a computer. But I guess if I want it fixed I oughta suck it up.

The only other thing that may be a factor is I also add the snapins to the host and initiate the task from the api during provisioning. So It’s possible that it being queued from api causes this too, we’ll see if that’s the case though since I’ll be testing by deploying through the gui.

@Sebastian-Roth

function Invoke-FogApiChocoSnapin {
<#
    .SYNOPSIS
        a cmdlet function for making fogAPI calls via powershell

    .DESCRIPTION
        takes a few parameters with a default that will get all hosts
        Makes a call to the api of a fog server and returns the results of the call
        The returned value is an object that can then be easily filtered, processed, and otherwise manipulated in poweshell.
        i.e. you could take the return value of the default all hosts and run
            $(invoke-fogapiChocoSnapin).hosts | where name -match "$(hostname)"
        to get the host information for the current computer

    .PARAMETER fogApiToken
        a string of your fogApiToken gotten from the fog web ui. Can be set in the function as a default or passed to the function

    .PARAMETER fogUserToken
        a string of your fog user token gotten from the fog web ui in the user section. Can be set in the function as a default or passed to the function

    .PARAMETER fogServer
        The hostname or ip address of your fogserver, defaults to the default fog-server

    .PARAMETER uriPath
        Put in the path of the apicall that would follow http://fog-server/fog/
        i.e. 'host/1234' would access the host with an id of 1234

    .PARAMETER Method
        Defaults to 'Get' can also be

    .PARAMETER jsonData
        The jsondata string for including data in the body of a request

    .EXAMPLE
        #if you had the api tokens set as default values and wanted to get all hosts and info you could run this, assuming your fogserver is accessible on http://fog-server
        Invoke-FogApiChocoSnapin;

    .Example
        #if your fogserver was named rawr and you wanted to put rename host 123 to meow
        Invoke-FogApiChocoSnapin -fogServer "rawr" -uriPath "host/123" -Method "Put" -jsonData "{ `"name`": meow }";

    .Link
        https://news.fogproject.org/simplified-api-documentation/

    .NOTES
        The online version of this help takes you to the fog project api help page

#>

    [CmdletBinding()]
    param (
        [string]$fogApiToken = '',
        [string]$fogUserToken = '',
        [string]$fogServer = "fog-server",
        [string]$uriPath = "host", #default to get all hosts
        [string]$Method = "Get",
        [string]$jsonData #default to empty
    )

    begin {
        # Create headers
        Write-Verbose "Building Headers...";
        $headers = @{};
        $headers.Add('fog-api-token', $fogApiToken);
        $headers.Add('fog-user-token', $fogUserToken);

        # Set the baseUri
        Write-Verbose "Building api call URI...";
        $baseUri = "http://$fogServer/fog";
        $uri = "$baseUri/$uriPath";

    }

    process {

        Write-Verbose "$Method`ing $jsonData to/from $uri";
        if ($Method -eq "Get") {
            $result = Invoke-RestMethod -Uri $uri -Method $Method -Headers $headers -ContentType "application/json";
        }
        else {
            $result = Invoke-RestMethod -Uri $uri -Method $Method -Headers $headers -Body $jsonData -ContentType "application/json";
        }
    }

    end {
        Write-Verbose "finished api call";
        return $result;
    }
}

@Sebastian-Roth That is the general idea of what happens in the fog log yes. I get a hash doesn’t match error.
I took out the paths when I copied pasted the script, I think that duplicate get-item is just a typo.
I beleive I am trying to not update the file on the server here, instead of trying to re-upload the file everytime I am just getting the correct information about the file (name, size, hash) and trying to force every snapin database entry to match the file’s details correctly. Somehow though I end up with different hash’s during deployment. If I export the snapins, they all look the same in the exported csv as they should. It’s like something happens when the snapin is deployed where it changes.

@Sebastian-Roth That is a internal function in that script. I’m pretty sure that it is the same as the Invoke-FogApi function I have in the published powershell module, so you could find it here https://github.com/FOGProject/fog-community-scripts/blob/master/PowershellModules/FogApi/FogApi.psm1
It’s renamed here to avoid clobberring I think as I may have written the code I pasted as an example here before I made the uninversal module.

See also https://forums.fogproject.org/topic/12915/windows-boot-manager-boot-option-disappears-after-image

My workaround for this happening was to use refind as my default bootloader, which I configure before capturing the image and then again after I deploy the image in scripts to ensure it sticks. That way I have a boot menu that I can pick between windows, fog (required copying latest ipxe.efi file to each machine’s uefi partition), and even options for uefi shell and uefi firmware settings without any special keystrokes. I find it gives a nice balance between faster boot time for users and flexibility in support.

I am fairly sure this is a ‘feature’ of windows 10 with the intent of helping users that had changed their boot order to boot to install media and then don’t have to worry about going back into the bios settings and changing it to the new boot manager.
When I get a moment (like that will ever happen) I’ll try to universalize my bootmgr configuration powershell functions a bit and share them. Probably will put them in the fog community scripts git or add them to my fogAPI module, the former might make more sense, so they’re findable outside of a single blog post. If I remember I’ll try to make some time to do that tomorrow.

Here is the code I use to create a snapin after publishing a chocolatey package to my repo.
I added the hashes after the problem started and it sometimes helps but it seems the behavior is slightly unpredictable and the hash record on fog still changes somehow.

        Write-Verbose "making sure package $global:packageName exists as fog snapin";
        if ( (Invoke-FogApi -uriPath "snapin/search/$global:packageName" -Method GET).count -eq 0){
            Write-Verbose "snapin does not exist, creating new snapin";
            $snapinScript = Get-Item "path\to\chocoPkgSnapin.ps1";
            $hash = ($snapinScript | Get-FileHash -Algorithm SHA512).Hash;
            $fileSize = $snapinScript.Length;
            $json = @{
                "name"="$global:packageName"
                "file"="chocoPkgSnapin.ps1"
                "args"="-pkgname $global:packageName"
                "reboot"=""
                "shutdown"=""
                "runwith"="powershell.exe"
                "runwithArgs"="-ExecutionPolicy Bypass -NoProfile -File"
                "protected"="0"
                "isEnabled"="1"
                "toReplicate"="1"
                "hide"="0"
                "timeout"="0"
                "packtype"="0"
                "storagegroupname"="default"
                "hash"="$hash"
                "size"="$fileSize"
            } | ConvertTo-Json;
            Invoke-FogApiChocoSnapin -uriPath 'snapin/new' -Method POST -jsonData $json -verbose;
        }
        else {
            Write-Verbose "Snapin already exists";
        }
        Write-Verbose "Updating hases for all snapins";
        $snapinScript = Get-Item "path\to\chocoPkgSnapin.ps1";
        $hash = ($snapinScript | Get-FileHash -Algorithm SHA512).Hash;
        $fileSize = $snapinScript.Length;
        $snapins = Get-FogObject -type object -coreObject snapin;
        $snapins.snapins | Where-Object file -match 'choco' | ForEach-Object { $data = @{
            "id" = "$($_.id)";
            "name" = "$($_.name)";
            "file" = "$($_.file)";
            "runwith"="powershell.exe";
            "runwithArgs"="-ExecutionPolicy Bypass -NoProfile -File";
            "args" = "$($_.args)";
            "protected"="0";
            "isEnabled"="1";
            "toReplicate"="1";
            "hide"="0";
            "timeout"="0";
            "packtype"="0";
            "reboot"="";
            "shutdown"="";
            "size"="$fileSize"
            "hash" = "$hash";
        } | convertto-json; 
        Update-FogObject -type object -coreObject 'snapin' -IDofObject $_.id  -jsonData $data -uri "snapin/$($_.ID)/
        Write-Verbose 'Done!';
        return;

Some of the snapins return 500 errors when I attempt to loop through them all and update their hash records.
Since that isn’t working I’m really hoping there’s some way to disable the hashing function, even if it’s some hackish way in the database or something.

@RobTitian16

I realize this is a few month’s old. But you might want to check out and or contribute to the fog module I have in git and published in the powershellgallery, there’s a forum post with more info here https://forums.fogproject.org/post/120746
Also did you have a chance to try the code I posted back in september and see if that worked? Because it works for me.
And looking again at your code I would ask what the value of $useAD is, is it 1 it should be 1. And I would also try piping the object into convertto-json, I’ve had better luck with that, I think it parses it different i.e. $CreateHostJson = $HostJson | ConvertTo-Json I would also encapsulate everything in quotes on the splat.
The only other thing that might be an issue is the ADPass. When you get the password via the api it is returned in plain text (because you already authenticated with api keys, so it’s not like just anyone can grab it). When you input the password in the gui you put it in plaintext and it encrypts when you hit save, I don’t think the same thing happens if you set it through the api. My solution has been to always enable the default AD settings when adding a host via the gui or the pxe menu. But it sounds like you’re adding the host through the api. The “useAD”=“1” in the json should be causing the checkbox for the ‘join domain after deploy’ to be checked. Sadly when you check it from the api it doesn’t pull the default domain settings. You might try creating the host without the AD settings and then sending just the AD settings in an update/put command. If you copy paste the already encrypted password from a working host in the gui, that might do the trick as it seems to pass whatever you put in that field to be in plaintext.

So point is, try adding the domain stuff with an update api command after creating. And use the code I have in the example to help if needed.