@sjensen FOG 1.5.0 is years old and I can’t remember if multicast worked perfectly fine in that version or if there was an itch with that in 1.5.0.

@george1421 Obrigado

It’s been a few days and I just wanted to thank everyone for the replies. I am giving the scripting a whack and will report back if I make some progress with it.

@ddavis The MAC address is still used as unique identifier by FOG as being the most reliable. Changing that would mean working with the code. Feel free to work on this considering all the things mentioned on github: https://github.com/FOGProject/fogproject/issues/198

The question is what your goal is in the end. Should those devices be imaged and then handed out and never some back? Or do they stay in your network and re-imaged from time to time? If so which kind of network connection will they use in the future?

There are two other routes you can look into:

Register the device with the the USB adapters MAC address and let it do the imaging. Rename the host manually or by OOBE. Install the fog-client service and enable that after deployment so it will automatically register other MAC addresses like wireless, approve those. Some USB adapters have the capability to pass-through the MAC address. This feature allows the MAC address of the native ethernet network device on the system to be used for imaging. Depends on the hardware you have.

@sebastian-roth Thank you! I am going to give this a shot.

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

@chris-whiteley said in API Help:

The only thing I can’t figure out is how to make that host be associated with a SnapinID. For instance, I want it to be associated with a SnapinID of 1. How can I do that?

While I haven’t tested lately I would think you should be able to create a snapin association like this:

curl -X PUT -d '{"snapins":[1]}' http://x.x.x.x/fog/host/33/edit

Assuming the host you want to associate the snapin (ID 1) to has host ID 33. Don’t forget the API tokens in the call.

@kevinnew22 You need to explain what sda and sdb in your case are. Both are named “virtual disk”. Which one is iSCSI and what is the other one based on?

When you want to extend your image space it’s usually best to mount the /images folder on a separate disk. So in this case you would create a partition on sdb, format with a filesystem and move your images over to that new disk - e.g.:

use at your own risk!!

parted -s /dev/sdb mkpart primary 0% 100% mkfs.ext4 /dev/sdb1 mkdir /images_new mount /dev/sdb1 /images_new/ mv /images/* /images_new/ mv /images/.mntcheck /images_new/ umount /images_new/ rmdir /images_new/ mount /dev/sdb1 /images/

As well edit /etc/fstab to mount this nuew partition on boot up as well.

Okay, I will dig into this. Thanks!

@alzen Well when you run sysprep it kind of resets the computer back to a neutralized condition. You can preset some values using an unattend.xml file you reference when you run sysprep. If you have ever installed windows directly from the dvd drive you know it asks a bunch of question before windows is setup. The unattend.xml file can be used to answer those questions ahead of time so it skips asking the installer the questions. This asking questions bit is part of OOBE (Out Of Box Experience) that is managed by WINdows SETUP. When you run sysprep it cleans out the system of drivers and settings that are important for that specific model of computer and reset its back to a discover new hardware mode.

In my case I have 1 golden image for 15 models of hardware. I use a FOG feature to copy the correct drivers over to the target computer during imaging then when winsetup is running it finds the drivers and adds them to the windows configuration. WinSetup will only run when you reset the computer using sysprep.

@george1421
Very Thanks!

@george1421 alride thanks for the help. i will get to work then 🙂

@Tom-Elliott said in Create Basic Snapin:

batch script to directly call the npm binary. Right now, the way your batch file is written, it expects the npm to be set in system path. If you know it’s installed in C:\npm\npm.bat I would

Thank you @Tom-Elliott and @Sebastian-Roth. It worked as regular user not as administrator.
I have used another solution that is psexec that is a tool that runs the script at all the machines.

@george1421

I figured it out. /dev/nvme1n1

I wasn’t sure how Linux named NVMe’s.

i think i’ve found the solution .

i just made a new ipxemenu entry with my winpe and force via API , the default parameter to 1 to this menu entry i can find in coreobjects pxemenuoptions.

i’ll keep you informed

@nerdstburns If the host is turned off and wake on LAN (WOL) works in your environment, then it will just be started automatically and do the image deployment. You can have it reboot after the task (default) or let it do a shutdown via adding shutdown=1 as Kernel parameter (general FOG settings or individual host settings).

When you use the FOG web UI to schedule a normal deployment task you see the selection:

Schedule instant (default selection) Schedule delayed (one shot at a certain time) Schedule cron-style (repeating task as often as you like it to happen, once a day or every other hour or whatever)

@vemoya Well 3 GB/s is on the bottom edge of acceptable (in my book). There may be some tuning needed to do in your infrastructure. Its not horrible just a bit slower than expected.

Just be aware with 3 ongoing unicast images you will saturate a 1 GbE link (125MB/s or 7.5GB/min theoretical max) This isn’t a fog issue specifically but a limitation of 1GbE ethernet. You can supplement this by adding additional network cards in your FOG server and then creating LAG links between your network switch and the FOG server. Even if you create these LAG links between the FOG server and switch, if your switch to switch links are 1GbE links that will become your next bottleneck. Again this isn’t a FOG issue, but a byproduct of using a FAST imaging solution. Also if you are imaging more than 2 computers at a time, its best to have an SSD or RAID array in your FOG server and not try to serve multiple unicast streams with a single spindle HDD. That single HDD will not be able to feed the data fast enough to the network adapter.

You mentioned multicasts. This is a great solution to push out one image to many computers, but it also has its drawbacks. You need to ensure your network is capable of multicast imaging (again not a fog issue). If your target computers are on the same subnet as the FOG server that is the easiest solution. You just need to turn on IGMP Snooping on your network switches and then multicast away. Just remember the slowest computer in your multicast group sets the pace for the group. But if properly setup you can multicast 30 computers in about the time it takes to image 2 computers (serially) using unicast imaging.