Run the following code in powershell (after editing it with your network’s subnets) to create a csv that will import all hosts on your network.

# examples, just gotta put subnets minus the final .x in a string array
# Could also be params if this was a function
$subnets = @("192.168.1", "192.168.2", "10.2.114", "192.168.0"); 
$subnets | ForEach-Object { # loop through each subnet
	for ($i=0; $i -lt 255; $i++) { # loop through 0 to 255 of the subnet
		$hn = nslookup "$_.$i"; # run nslookup on the current ip in the loop
		if ($hn[3] -ne $null -AND $hn[3] -ne "") { # does the ip have a dns entry
			$hostN = $hn[3].Replace("Name:","").Trim(); # parse the nslookup output into a fqdn host name
			$mac = getMac /S $hostN; # does the hostname have a mac addr. Can also add /U and /P for user and password if not running from a administrative account
			if ($mac -ne $null) { # was there a mac for the host?
				$macAddr = $mac[3].Split(' ')[0]; # use the first found mac address and parse it
				"$hostN,$macAddr" | Out-File C:\hosts.csv -Append -Encoding UTF8; # add the hostname,macaddress to the csv
			}
		}
	}
}

@Arrowhead-IT Scratch that, it totally worked after a restart. So if you go breaking your permissions just run the script posted and restart and violia!

Everything is working for me now! hooray for the new inits!

@Lee-Rowlett I think you are somewhat correct there. In all my testing I found that it relates to when a user first logs in it installs all the metro apps for that user including cortana. And when you do a profile copy in the system advanced settings control panel it ends up copying some of those installed apps to the default profile which causes the installation of metro apps on a new profile to fail, but there’s no error because the installs think they succeed since the files are already there.
At least I think that has some to do with it. My new script system seems to work flawlessly and it is much easier than my old way of having to change the registry everytime and such.

I would still test your theory for you, just for funzies, but I don’t actually use an unattend.xml. I don’t like sysprep. It breaks my default profile sometimes, and I’ve seen it break other things and it forces you to go back to oobe which messes with my computer naming system. I’ve kinda found it to not be necessary. Yes it resets some security id’s for activation this and that but if you are using windows enterprise volume licensing, that doesn’t cause any problems. In windows 7 I figured out the registry key to change and then just re-inputting the windows key and reactivating gave it a new sid. Windows 8 and 10 just work without issue without doing that. As for drivers, I make my images on a vm so they’re already hardware independent and I use the terminal tool devcon (included in the windows wdk 8.1, I just copy the devcon.exe over to my image vm after installing the wdk on my workstation) to uninstall all the devices in the device manager before rebooting with devcon -r remove *
It goes through the uninstalling of devices much much faster than sysprep does too.

So thank you sir for your help, but I think I got it figured out.

New Module Version Published

Just wanted to let people know that there’s a new version of the API yay!
It’s been published to the psgallery here https://www.powershellgallery.com/packages/FogApi/1903.0.0.22 and it is awaiting a pull request to show up in the fog community scripts git.
It has new functions to help do some common tasks, particularly with snapins. Here’s a list of the current functions.

Add-FogSnapins
Set-FogObject
Get-FogAssociatedSnapins
Get-FogGroup
Get-FogHost
Get-FogHosts
Get-FogInventory
Get-FogLog
Get-FogObject
Get-FogServerSettings
Get-FogSnapins
Install-FogService
Invoke-FogApi
New-FogObject
Remove-FogObject
Remove-UsbMac
Set-FogInventory
Set-FogServerSettings
Set-FogSnapins
Start-FogSnapins
Update-FogObject

I would suggest using the full path of the file in your batch script instead of changing the directory.
And when I say full path, I mean the true full path, not the mounted S:\ drive.
Even if S:\ is being mounted by active directory or is a mapped drive as part of your image, I would still suggest using the full network/unc path.
I would also suggest mounting it with net use and a username and password. This will ensure the system account that the Fog Service uses has access to the files you want
I would also add some logging and other error preventions.

i.e. if S:\ was mapped to \FileServer\Share …

@ECHO off

echo. Create variables to make scripting easier
set sharePath=\\FileServer\Share\Pat

echo. Mount S drive path, replace username and password with share credentials. 
echo. If share is public omit the /USER parameter and everything after it


net use %sharePath% /USER:username password

echo. make sure destination exists, create it if it doesn't
if not exist C:\temp mkdir C:\temp

echo. copy each file, add /Y to overwrite without any prompt
echo. copying tdpunt...
copy /Y %sharePath%\tdpunt.bat C:\temp\ > C:\temp\tdpunt-bat-Copy.log
echo. copying tundpt.exe...
copy /Y %sharePath%\tundpt.exe C:\temp\ > C:\temp\tundpt-exe-Copy.log

echo. Done!

exit

Use that and then see if the .log files show up after deploying the snapin.

Also, in the web gui snapin config, you should take out the /qn that does nothing.
The snapin arguments section is for custom arguments that you have in your script. Your script doesn’t do anything with the /qn and it could cause issues. The /c parameter is passed to the cmd.exe command which tells cmd.exe to open a prompt, run the command, and then close.
If you had a line in your script like this

if "%1" == "/qn" (
    echo. hey look a parameter, lets do something since it's there!
)

then the /qn would have a point.

Hope that helps a bit.

Thanks,
-JJ

@kbramhall said:

@Tom-Elliott I attempted to go through the installer and saying no to DHCP and DNS but if failed to install tftp-server this time. Attached is the foginstall.log file.0_1450298881023_foginstall.log

I took a look at the install log and noticed this bit

../lib/redhat/functions.sh: line 1: n#: command not found

I’ve seen that before. You need to both make sure that you’re running as the root user and make sure you’re running the install script from the bin folder.
i.e. cd into where you downloaded/untarred the fog installer and then

cd bin
./installfog.sh

I figured out when making the automated update scripts that you can’t run it with the full path like
/home/fog/installFoder/bin/installfog.sh
because it use the trailing … to get to some included scripts. So you have to start the script from its happy home.

Also, what happens when you try to install the packages that failed manually?
I would try them one at a time. It looks like these ones…

yum install tftp-server
yum install xinetd
yum install vsftpd
yum install gcc
yum install gcc-c++
yum install lftp

And I just had another thought, are you sure the firewall is completely disabled? I just remembered a recent experience where a fresh install cent OS wouldn’t do internet things until I flushed the iptables.
Which if memory serves is

iptables -F
or
iptables -f

Hopefully something there helps

In the past I made a script for automating svn updates. Since sourceforge has been making a habit of crashing lately, I decided to start using the git repo instead and adjusted my script to work with git.
I figured others might benefit from it so why not share…

#!/bin/bash
clear
# -------------------------------------------
# Fog Git Updater
# -------------------------------------------
# -------------------------------------------
# Script Purpose
# -------------------------------------------
# This script is designed to run an automated update of the latest FOG Git dev build and it's cron friendly
# -------------------------------------------
# -------------------------------------------
# Some prereqs for this script
# -------------------------------------------
# 1. Already have an existing working install/configuration of FOG 1.0 or later
#
# 2. Have git installed and setup. You can do that by doing....
# 	sudo apt-get install git
#  	mkdir /home/fog/fogInstalls/git
#	git clone https://github.com/FOGProject/fogproject.git /home/fog/fogInstalls/git
#
# 3. A script to echo the encrypted version of your sudo password, create one with this function
#	just put in your password into the following in place of your_super_secret_password (leave the quotes)
#	and then uncomment and copy paste the function into a terminal and then run it with just the name of the function pw
	# pw(){
	# 	touch /home/fog/fogInstalls/.~
	# 	ossl=`echo "your_super_secret_password" | openssl enc -des -a -e -pass pass:PASSWORD`
	# 	echo 'echo "$(echo '$ossl' | openssl enc -des -a -d -pass pass:PASSWORD)"' >> /home/fog/fogInstalls/.~
	# 	sudo chown fog.root /home/fog/fogInstalls/.~
	# 	sudo chmod 700 /home/fog/fogInstalls/.~ 
	# }
# -------------------------------------------
# -------------------------------------------
# Variables
# -------------------------------------------
# -------------------------------------------
echo "Creating Script variables..."
fogInstalls='/home/fog/fogInstalls'
gitPath="$fogInstalls/git"
backup="$fogInstalls/backups"
pw=`sh $fogInstalls/.~` 
# -------------------------------------------
# -------------------------------------------
# Functions
# -------------------------------------------
# -------------------------------------------
perms(){
	sudo chmod -R 775 $1
	sudo chown -R fog.fog $1
}

srvUpdate(){
	# Enter sudo mode aand do some quick server maintenance update fun times
	# First, enter sudo mode by echoing the output of decrypting your encrypted password and pipe that into an apt-get update
	#	Don't worry, it doesn't output the password into the terminal
	#	Now that the password is in once the terminal will keep it stored for the next bunch of sudo commands
	echo "Running Sever updates!..."
	echo $pw | sudo -S apt-get update -y
	sudo apt-get upgrade -y # install any upgrades you just downloaded
}

backupConfig(){
	# Backup custom config and other files
	# Copy the latest versions of any files you've changed that will be overwritten by the update and backup the database just in case.
	# For example you may want to back up...
	# Config.php
	# 	To be on the safe side your config file in the /opt folder that has may have a corrected webroot for ubuntu 14.04 and may have stored encrypted credentials (i.e mysql)
	# 		I think that the installer uses this file and keeps it anyway, but I like to be careful
	# Exports file
	#	Because this runs the installer with a yes pipe, it ends up telling it that the image path is "y",
	# 		simply backing up and restoring your current one avoids the issue of fog not finding your precious images. 
	# Custom pxe boot background
	# 	If you have a custom background for the pxe menu, the bg.png file
	# Mysql database dump
	#	It would be rather troublesome if something went horribly wrong in the update and your database goes kaboom, it's unlikely but backups are a good thing 
	# Just a note, It's a good policy to also have backups of these outside of your server, which you could add to this script with an scp command or something like that
	# -------------------------------------------
	echo "make sure backup dir exists..."
	if [ ! -d $backup ]; then
		mkdir $backup
	fi
	echo "Dumping the database..."
	mysqldump -u root --all-databases --events > $backup/DatabaseBeforeLastUpdate.sql #backup database
	echo "Backing up config and custom files..."
	echo "config.php..."
	sudo cp /opt/fog/service/etc/config.php $backup/config.php
	echo "fog settings..."
	sudo cp /opt/fog/.fogsettings $backup/.fogsettings
	echo "nfs exports..."
	sudo cp /etc/exports $backup/exports
	echo "custom pxe background..."
	sudo cp /var/www/html/fog/service/ipxe/bg.png $backup/bg.png 
}

gitP(){
        perms $gitPath
	echo "git pull...."
	cd $gitPath
	git pull
}

updateFOG(){
	echo "running FOG installer..."
	cd $gitPath/bin
	sudo bash installfog.sh -Y
}

restoreConfig(){
	# Restore backed up files
	# Restore the backed up files to their proper places and make sure they're formatted correct too.
	echo "restoring custom pxe background..."
	sudo cp $backup/bg.png /var/www/html/fog/service/ipxe # Restore Custom Background 
	# I found that I needed to do this in some configurations, but it may no longer be neccesarry...
	echo "Creating undionly for iPxe boot in ipxe folder, just in case..." 
	sudo cp /tftpboot/undionly.kpxe /tftpboot/undionly.0 # backup original then rename undionly 
	sudo cp /tftpboot/undionly.0 /var/www/html/fog/service/ipxe/undionly.0
	sudo cp /var/www/html/fog/service/ipxe/undionly.0 /var/www/html/fog/service/ipxe/undionly.kpxe
}

fixPerms(){
	echo "Changing Permissions of webroot..."
	perms '/var/www/html/fog'
	echo "Changing permissions of images...."
	perms '/images'
	echo "Changing permissions of tftpboot...."
	perms '/tftpboot'
}

# -------------------------------------------
# -------------------------------------------
# Run the script
# -------------------------------------------
# -------------------------------------------
srvUpdate
backupConfig
gitP
updateFOG
restoreConfig
fixPerms
echo "Done!"

@anthonyglamis Fogcrypt is essentially obsolete, yes. You can still put the fogcrypt output into the legacy input but I find the new auto-encrypt to work better. But yes I’m pretty sure that the fogcrypt tool is still there

I hadn’t noticed that the hashes were different before, so I checked mine and they are different. I haven’t had any problems though, so I would say it shouldn’t be an issue.

I created a powershell module for using the Fog API

https://github.com/FOGProject/fog-community-scripts/tree/master/PowershellModules/FogApi

Install instructions are found at that link.
Edit: Discovered how easy it is to publish to PSGallery, published the module here https://www.powershellgallery.com/packages/FogApi/1.2 so it can also be installed with (if you have the latest powershell get https://www.powershellgallery.com/packages/PowerShellGet/1.6.5 ) the command Install-Module -Name FogApi;

Importing that module will help you to set up a quick and easy and crossplatform way to manage fog from a powershell prompt.

It is structured based on the api documentation found here https://news.fogproject.org/simplified-api-documentation/
It even autocompletes the parameter options based on that documentation.

So if you read that documentation and see that you can get an ‘object’ you can then take that to the command by saying Get-FogObject -type object -CoreObject objecttype that object type validates/autocompletes to the list of available core objects found in the documentation.

If you install the module and run help Invoke-FogApi it will display a bit more verbose help and documentation on how it all works.

There are a few main functions to use that all make calling the Invoke-FogApi function a bit easier with autocompletion fun times

• For GET api calls : Get-FogObject
• For POST api calls : New-FogObject
• For PUT api calls : Update-FogObject
• For DELETE api calls : Remove-FogObject

Each of these return powershell objects. If you’re unfamiliar with powershell and powershell objects, then this is a good way to learn.
They make it so you can take information and easily find and manipulate their properties.
i.e. if you did a $hosts = Get-FogObject - type Object -CoreObject host $hosts would contain 2 properties, a count of returned objects and an array of all your fog hosts, each with all the information fog has on them. So lets say you want to see all your hosts that have a intel cpu, you can search all the hosts for where the inventory’s cpu manufacturer has ‘intel’ in its value. $intelPCs = $hosts.hosts | ? { $_.inventory.cpuman -match 'intel' } Then maybe you just want the hostids, names, and mac addresses. $intelPCList = $intelPCs | Select-Object id,name,primac; $intelPCList;

PS Objects can also easily be turned into json by piping them into a ConvertTo-Json command. Meaning that you can just change the values of an object’s properties, such as a host’s name, image, etc. And then convert that to json to use as the jsondata in any other command.

I also included a Install-FogService function in the module for good measure that downloads the latest version of the client msi installer from your server and then silently installs it. In theory, you could use Invoke-Command to run that command on remote computers (though you would also have to import the module on each computer).

There is a settings.json file that the module pulls from to get your api keys and servername. It needs to be set manually, but automatically opens in an appropriate editor for your OS if it finds that the settings are still set to default. The default settings are explanations of where to find the values on your server.

Help Info from function code Will be updated overtime, putting here as it is the help info uri listed in module manifest
Invoke-FogApi

<#
        .SYNOPSIS
           a cmdlet function for making fogAPI calls via powershell
        
        .DESCRIPTION
            Takes a few parameters with some pulled from settings.json and others are put in from the wrapper cmdlets
            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.
            The defaults for each setting explain how to find or a description of the property needed.
            fogApiToken = "fog API token found at https://fog-server/fog/management/index.php?node=about&sub=settings under API System";
            fogUserToken = "your fog user api token found in the user settings https://fog-server/fog/management/index.php?node=user&sub=list select your api enabled used and view the api tab";
            fogServer = "your fog server hostname or ip address to be used for created the url used in api calls default is fog-server or fogServer";
                    
        .PARAMETER serverSettings
            this variable pulls the values from settings.json and assigns the values to 
            the associated params. The defaults explain how to get the needed settings
            fogApiToken = "fog API token found at https://fog-server/fog/management/index.php?node=about&sub=settings under API System";
            fogUserToken = "your fog user api token found in the user settings https://fog-server/fog/management/index.php?node=user&sub=list select your api enabled used and view the api tab";
            fogServer = "your fog server hostname or ip address to be used for created the url used in api calls default is fog-server or fogServer";

        .PARAMETER fogApiToken
            a string of your fogApiToken gotten from the fog web ui. 
            this value is pulled from the settings.json file
        
        .PARAMETER fogUserToken
           a string of your fog user token gotten from the fog web ui in the user section.
           this value is pulled from the settings.json file
        
        .PARAMETER fogServer
            The hostname or ip address of your fogserver, 
            defaults to the default name fog-server
            this value is pulled from the settings.json file
        
        .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
            This is filled by the wrapper commands using parameter validation to 
            help ensure using the proper object names for the url 
            
        .PARAMETER Method
          Defaults to 'Get' can also be Post, put, or delete, this param is handled better
          by the wrapper functions
          get is Get-fogObject
          post is New-fogObject
          delete is Remove-fogObject
          put is Update-fogObject
        
        .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-FogApi;

        .Example
            #if your fogserver was named rawr and you wanted to put rename host 123 to meow
            Invoke-FogApi -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
            
    #>

Also, here’s my ranting on unattend and sysprep that I can’t seem to stop myself from interjecting.

There are also multiple places you can put the unattend.xml file to get it to be used. I put it in 2 places C:\unattend.xml and C:\windows\system32\sysprep\unattend.xml I could have swore you had yours in a panther folder when I first read this, but it looks like I read that wrong or you edited while I was writing. I reference the one in the root of C in my call to sysprep and have it in the sysprep folder as a fail safe because it is a place that sysprep looks for the file. Is the unattend file doing what you expect? You have some winpe commands and partition creation commands in there. Are you using winPE in your process or is that just from the guide you found?

There are many ways that you can use sysprep and fog. The way I do it is

Install windows 10 onto vm
Hit Ctrl+shift+f3 at the oobe screen to enter audit mode
Run my base customization script (copies some custom files, copies some network drivers, installs some basic default programs)
Run my cleanup script (defrag, cleanmgr, sfc, dism, chkdsk, provision the metro/uwp apps to my liking…I’m thorough…)
Copy the unattend file and run sysprep with sysprep.exe /audit /reboot /unattend:C:\Unattend.xml

My unattend file is then set to run the Audit System pass, the Audit User pass, then the generalize pass and then shuts down. At that point I capture the image. I use the reseal property in unattend.xml to control which phase comes next.

Then when I deploy the image, it is a generalized image with no drivers but with lots of customization built in. Right after the image deploys the unattend file continues in specialize phase where, among many other things, the network drivers I copied earlier that apply to the hardware get added to ensure network connectivity. Then the oobe phase starts where all the oobe wizard stuff gets skipped because it is all already answered and then I use the firstlogoncommands section to start up a custom provisioning powershell module/script that sets everything up across a few reboots. I use the built-in admin user during those firstlogon setup pieces, I find that much easier and more reliable then setting up a separate user, the builtin admin usually has a better time with initial setup and having admin rights to do everything you want to, you can always disable the admin account once all is done.

That may all sound kinda complicated, but once you get it set up and scripted, it’s pretty simple.

My point in sharing all this, is you mentioned your new, and I want to let you know that there’s not just one way to handle all this. It’s good that you’re wanting to use sysprep at least. I was once a misguided soul and tried to find ways around it.

I see that you used a website to generate the answerfile. It looks like a decent starting point. I would reccomend making the whole thing yourself using the windows system image manager. It’s not quite as easy, but you’ll be able to see how much more you can do. https://docs.microsoft.com/en-us/windows-hardware/customize/desktop/wsim/windows-system-image-manager-technical-reference. Once you download the adk you can extract your windows 10 iso somewhere and load it up into the system image manager and start messing with it.

I could go on and on, but I don’t want to scare you away. Hopefully I haven’t already. It is completely possible to use somone elses or a web generated unattend file and image with fog without breaking any windows licensing or custom ids. I just felt, once I read through the documentation and gave it a try, that it was worth it to make it myself the official windows way. And I found that they have a lot of documentation on the topic. Here’s some more to look at, docs.microsoft.com is your friend in this adventure.

https://docs.microsoft.com/en-us/windows-hardware/customize/desktop/unattend/
https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/sysprep--system-preparation--overview

So if the root problem you want to solve is fog joining the domain I think I see an issue, but could be missing something. So in your script that starts sysprep you have it copy a setupComplete.cmd. I also see that you have it disable the fog service. Does setupcomplete re-enable and start the fogservice back up? If it is starting backup are you getting any error messages in C:\fog.log on the imaged machine?

@Quazz

@Quazz said in Git commit fcf4695 Setting up MySQL user and database..........................Failed:

@JJ-Fullmer Thanks for the instructions; that worked!
Some notes on the situation for me:

Woo Hoo!

Root password was set BUT only for ‘localhost’, but the host localhost did not have any type set (whereas the others had mysql_native_password)

I think that this may have also been the case for me. I certainly remember having set a root password but after fixing everything my only conclusion was that I must have not. But I did also notice that my mysql.user table had 3 different root users for localhost, 127.0.0.1, and 1 other I can’t remember right now. Mine were all set to the mysql_native_password plugin as well. It looks like a solution is in the works here already, but just wanted to add that note that the root problem might be the authentication problem.

I had a similar problem with 1.5.8 and centos 7 and also mariadb 5.x

In my case it turned out that I was running mysql with an empty root password. Which I don’t recall doing but may have occurred via the auto-accept/-y install when I initiatilly installed fog on this server. Should really not use -y the first time you run the installer, which is probably what I did many moons ago from habit in auto-updating to stay on the latest dev version. For updates once all is configured, -y should be fine.

So can you login to mysql as root either with mysql -u root or does that fail and you can instead login with a password mysql -u root -p

Or do neither of those options work and maybe you’re locked out of mysql? I got locked out. If you are, don’t worry, we got you. Here’s how @Sebastian-Roth helped me reset the root password and afterwords everything worked again

#stop the mysql service
systemctl stop mariadb
# open mysql in safemode in a foreground task and use & to get back to your shell
mysqld_safe --skip-grant-tables &
# you may need to hit enter twice
#login to mysql in safemode as root
mysql -u root

#look at what your usertable says for funsies
select user,password,host,plugin from mysql.user;
# You should see your root user(s) if it exists and the fogstorage and fogmaster users
# Now update the password in the table to something else, note that for me this didn't actually 
# set a password but made it blank
update mysql.user set password=PASSWORD("newpassword") where User='root';
update mysql.user set plugin='mysql_native_password' where User='root';
# flush the privileges to save the changes
flush privileges;
# exit the mysqld_safe command line
\q;

#shutdown the safemode mysql
mysqladmin -u root shutdown

# start the native mysql service up again
systemctl start mariadb

#try to login normally again, add -p and use what you think your password was or what you might have changed it to just now if it doesn't work
mysql -u root

#update the root user password with the proper command
SET PASSWORD FOR 'root'@'localhost' = PASSWORD('yourPassword');
# flush the privileges to save the changes
flush privileges;
#exit the mysql shell
\q;

#restart mysql one more time to be safe
service mariadb restart

#attempt to login with the now set root password
mysql -u root -p

If the last login works as expected, give the installer another try and see if it works now. Once I had that password reset and working I was able to run the latest dev-branch installer without issue.

I copy pasted the function into my console and tested it with a snapin that was assigned to just my computer and it did in fact queue it to deploy.

This could be altered to quickly deploy to a given list of hosts or groups as well. Giving you a quick command line method for deploying snapins to hosts in a variety of ways.

If this is something that would achieve what you’re going for let me know and maybe I can add in the functions to the api module so they just exist and then you have a deployment tool via command line, which is typically quicker in my humble opinion

@mousepl Are you thinking you would want to be able to do this on the fly, or would you want to deploy the snapin on all hosts that have it assigned to it?
By on the fly I mean, select specific hosts from the snapin then deploy, that would be a bit more difficult to implement, but maybe adding a button for deploying on all hosts with a snapin is possible.

If you’re familar with powershell or willing to learn. You could create a function/script that does this with the api module.

i.e.

# install the module
Install-Module FogApi;
# Follow the setup instructions found in the links in my signature. i.e. get the fogapi token and user api token from your web gui
Set-FogServerSettings -fogServer 'serverName' -fogapitoken 'insertServerAPItokenHere' -fogusertoken 'insertFogUserAPItokenHere'

Assuming those steps are done for the user running the function

function Start-SnapinDeploy {
[CmdletBinding()]
param(
    #define the snapin name you want to deploy
    $snapinName
)
#get all the snapins from the server
$allSnapins = Get-FogSnapins;
#get all the host/snapin associations from the server
$snapAssocs = Get-FogObject -type object -coreObject snapinassociation;
#get the snapin you want to deploye in a single object
$snapinToDeploy = $allSnapins | Where-Object name -match $snapinName;
#find all the hosts that have that snapin associated
$hostsWithSnapin = $snapAssocs.snapinassociations | Where-Object snapinID -match "$($snapinToDeploy.ID)"
#loop through the hosts that have that snapin assigned and start a task for that snapin for each of them
$hostsWithSnapin.hostID | ForEach-Object {
    $hostID = $_;
    $json = (@{
        "taskTypeID" = 13
        "deploySnapins"=$snapinToDeploy.ID
    } | ConvertTo-Json);
    New-FogObject -type objecttasktype -coreTaskObject host -jsonData $json -IDofObject $hostID;
    }
}
# call the function to deploy a snapin named office365
Start-SnapinDeploy -snapinName 'office365'

I may be off on the json creation as I haven’t tested a single snapin deploy, so the required body data might be different. I just kinda altered the way I use the start-fogsnapins function https://github.com/FOGProject/fog-community-scripts/blob/master/PowershellModules/FogApi/FogApi/Public/Start-FogSnapins.ps1 for this example. I typically only use fog snapins for the initial deployment at imaging.

But as you can see from the example, while things are linked together, the linkage is really meant to go from host to snapin. Snapins are really meant to be deployed at imaging time, which is why they are all queued when you a image a host. The idea being to include software provisioning with your OS images. The feature request you described would be useful I agree, but one might argue that that makes more sense for a software deployment tool, where fog is an imaging tool.

It can be used as a software deployment tool, but that’s just not how it’s designed.

That’s all really just a disclaimer to say it may be a bit for this to show up as a new feature. It’s possible and it would be useful. I’m all for anything linked in a database having linked buttons in each spot in a gui. But creating that button may just be easier said than done, but may eventually be done.

You could in theory create a gui using the powershell module and built in powershell command show-command and some dynamic paramters that grab all the available snapins, it would take a bit of work but you could make a gui prompt with drop downs/multi-selector for fog host(s), snapins, then a deploy button. Point being, just because it isn’t in the web gui, doesn’t mean the capability doesn’t already exist.

I hope that helps

@rmishra1004 is this happening on all hosts or just this one? Have you tried hitting the ‘reset host encryption keys’ on the host in the webgui?
If you copy past the url that fails, what happens? I believe you should see an error message like this

{"error":"im"}

when going to it in a browser

@george1421 While I agree and understand how it all works. I have found that we did get an increase in speed when we setup the aggregated adapter on the storage node. Even with just one client going. But perhaps that’s really just agreeing with your statements. As like on a highway if it was 1 lane, you often slowdown cause of the other slow drivers and perhaps I just opened up a metaphorical passing lane for fog images to go the full speed limit at. You do also have to consider all the switches it goes through and yada yada. And of course it’s all more complicated. Point being, I didn’t get a 2x boost when we aggregated the server link, but we did get a boost, so I wouldn’t deter anyone with the equipment capable of it from giving it a try.

@george1421 On the node that was showing that speed I have a bonded/aggregated link. So the node has a 2 Gbps link. Then the nvme storage has a theoretical write speed of 2.3 GB/s which is a theoretical speed of 138 GB/min (I don’t expect to see that kinda speed of course, just cool to think about, and shows that’s certainly not a bottleneck). I think that the 11 GiB/min I see now on 1.5.8 is probably closer to the actual speed I’ve been experiencing the whole time.

I just wanted to make a matching forum post for my github issue here

https://github.com/FOGProject/fogproject/issues/373

rEFInd, while a really cool tool, is not universally compatible.

Sometimes when a computer attempts to boot to hard drive from the pxe menu it gets stuck trying to load refind. Sometimes different configurations in the refind.conf file can help, but in a mixed hardware environment it’s not uncommon to not be able to find a universal answer.

Some of these hardware compatibility issues have been brought to the attention of the refind developer but he eventually figured that it sounded like a low number of computers, personally I find the opposite. We used to use rEFInd as a custom boot manager built into our images, but it had enough problems that we’ve moved to grub2win a grub 2 based windows efi compatible solution. I have attempted to add a chain load option to this copy pasting the boot files to the fog webserver to no avail. So while perhaps an efi version of grub2 might be an alternate option I haven’t found a way to get that working just yet.

In doing some testing with the ipxe shell and reading their documentation (https://ipxe.org/cmd/exit) the exit command can take parameters of 1 or 0 to send a error (1) or success (0) to the bios/firmware. Theoretically sending the 1 would tell the firmware to try the next boot option. I was able to exit the ipxe shell and boot to my local disk with exit 0 and exit 1 where just exit goes to black nothingness. I attempted to add this command to the bootmenu options of fog, but it didn’t work for me straight through the pxe menu.

I also messed with sanboot a bit, but couldn’t find a way to list what local drives the ipxe shell sees. The documented examples of 0x80 0x81 0x82 etc were not recognized.

Point is, there needs to be another option for booting to the hard drive on efi systems when refined doesn’t work. There are some possibilities out there.