Topics created by Richard Wise

My solution for this problem has been to use the api the remove usb macs when my provisioning script is done. I have it working by using the client.
The basics are

Computer gets registered with usb adapter My custom provisioning starts and the fog service is started which will add pending macs I leave the usb adapter plugged in until my provisioning is complete (so software install and whatnot happens over ethernet not wifi) Last step of provisioning uses a powershell api function to remove any existing usb macs (I have a saved list in the powershell of macs in my code) Adapter can then be removed and used on the next device

My custom functions uses my published fogapi powershell module, particularly this function https://fogapi.readthedocs.io/en/latest/commands/Remove-UsbMac/
Here’s a link to the code on github https://github.com/darksidemilk/FogApi/blob/master/FogApi/Public/Remove-UsbMac.ps1
The function also handles making a new mac the client found be the primary mac if the usb mac is the current primary.
If you’re not using the client, you could also create a custom automation to find the mac addresses of the machine during a postscript/firstlogon/provisioning step and have it use https://github.com/darksidemilk/FogApi/blob/master/FogApi/Public/Add-FogHostMac.ps1 to add a new unique mac then use the remove-usbmac function to remove specified usb macs.

If you’d like more info or examples I’d be happy to help, just wanted to offer a quick overview of a possible solution.

@Richard-Wise Ah ok, then set this value in the web ui FOG Configuration->FOG Settings->(Expand all)->FOG Boot Settings->PXE MENU TIMEOUT change the value to 0

@richard-wise Right that is usually the case when windows is involved. There are a couple of ways to side step the issue.

Not use windows at all. Use Notepad++ on windows Once the file gets to linux unaltered, use the linux command dos2unix to scrub out any remaining Windows bits left behind.

With that said, well done on the debugging!!.

The problem is your Windows DHCP server is already handing out Boot info.

Your client sees this info and tries to boot from it immediatly.

ProxyDHCP can only step in and help out if the Network boot info isn’t passed on yet.

Chad’s instructions for checking the package name and for removal both worked great. We are extending power from a box that’s on our generator to the phone switch room and adding a UPS for the phone switches, so we will be able to verify the DHCP issue has been resolved shortly. Thank you for posting up those commands.