@Sebastian-Roth HI Sebastian, just to let you know that this is something internally that keeps setting a proxy server, a bit of software or GPO I am struggling like crazy to find it, but every time I change the proxy when I log in , it is there again. I can find no GPO that is responsible, an absolute mystery to me, Microsoft and our third line support, but we will get there eventually or die trying.

@astrugatch Check gut George’s great tutorial here: https://forums.fogproject.org/post/69605 Make sure you use the “Part 2b” stuff for UEFI.

@andrewhancock91 I am on the road right now und will be for the next two weeks. Not easy to give you all the details not having my laptop with me. First you should start by searching the forums for “https fog-client” and see if you can find my older posts about why this part is tricky. It’s not a no-go but it will need good planing and manual adjustment - could even compile your own custom fog-client package… For switching back to HTTP for now you’d edit /opt/fog/.fogsettings file, find the line httpproto=https and remove the “s” at the end of “https”. Save and re-run the installer. That should be it. Make you read all you can find on this topic before diving into this again. If you have many hosts with fog-client installed and communicating to your current FOG server already you break this switching your apache config to a different certificate! Feel free to ask here if you can’t find those forum topics.

ill take a look next time i capture. i make sure the actual image size is the compressed, used data from the drives i capture, in the terminal using dh -u. we use a custom sccm image that is based on the stock windows install, which has bitlocker disabled.

@dario-vettore Try testing aß suggested in the wiki: https://wiki.fogproject.org/wiki/index.php?title=Troubleshooting_a_multicast Are you sure there is no firewall between FOG server and the clients??

i successfully ran the update to 1.5.7. Now i think there is an issue with the network interfaces. I set eno1 for management, and eno2 for imaging/dhcp. I was told on here that it should have been the opposite, but it has been working fine. now this morning i wasnt able to get to the webui from the eno1 network, but was able to on eno2. the port on the switch is set to the correct vlan. i unplugged the cable from eno2, then i was able to get online with eno1. could this have happened during the update? UPDATE so i had to re-apply the netplan file after rebooting the server. everything seems fine now. i can access the webui from both connected interfaces.

This old topic is solved ! I was setup a new FOG stable server on a debian (on a new disk) and snapins works flawlessly. Solved ! ;)

Thank you to all for your answers. I think, i will use the safe approach : i will clone my existing Golden Win 7 image in Virtual Box. With the cloned image, i will install Ubuntu with Grub and upload the new “Golden Dualboot Win7/Ubuntu image”. In my ref image, i do … nothing 'cause all conf", softs and scripts are run at the post-deployement … I will try this approach and “i will be back” with the results. Thank you for “the right way” ;)

@slipke Well if you wanted to do it in the auto reg it will be a bit harder than manual registration, but here is the curl call in the fog.auto.reg program. https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.auto.reg#L73 Before that curl call you will need to collect the serial number of the machine. The trick is the serial number is saved in the smbios in different locations for different manufacturers. If you look at this post it shows you how to get the serial number for the two chassis types I had to interact with: https://forums.fogproject.org/topic/6304/fog-2-0-request-advanced-host-naming/2 It also shows how to create a complex computer name based on several factors on the fly. So you will need to compute/collect the serial number and pass it along with the other arguments to the php file mentioned in the curl call. And then in the php code read that variable and place it in the hostname variable instead of the mac address. If you wanted to do this using the manual registration fog.man.reg where it asks for the user to input the host name into $host just use the dmidecode value to copy the serialno value into the host variable. https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.man.reg#L161

[Mod Note] duplicate post from here: https://forums.fogproject.org/topic/13807/error-update-database-after-capture-image

@p4cm4n said in Associate all new hosts with Snapin: assign template host to template group, assign properties to template host. No don’t do this because it will create a loop. The names have to be exactly the same that is all. Every host added to the template group will cause the database trigger to fire copying the host template settings over to the host just added to the group. nothing that was ‘set’ is actually ‘deployed’ but rather with the sql hack/trigger, its just a property of the host Its possible that the settings are made in the database but because of database caching the FOG application may not see the changes until the cache is refreshed. So are you saying that the settings on the template host are not being copied over (like OU or some other parameter field) or is this a question about the snapins not installing?

@aborn Good day. Did you get any resolution for this problem? I have Fog 1.5.7 on CentOS 7 with the specified partition sizes. All other settings as default, firewall and SELinux are disabled. My image name is W10E. I get the same results as you did, also with the image files appearing in the /images/dev folder, then in /images/W10E and then disappearing again. I sort of got around it by copying the /W10E folder to /W10E (copy), wait for /W10E to disappear and then rename the copy as /W10E. And I can deploy this image, absolutely no problem. Many thanks rarcher2

Would just like to add to this - I recently ran into this same issue again. Racked my brain trying to figure out what I did wrong or what setting could have possibly changed. Here’s what I found out. I was using the above PC again after cleaning and prepping to capture another image. This PC was already registered in FOG. I deleted the host and attempted to PXE boot again and everything went smooth as butter. Looks like there’s an issue booting if the device is already registered. I’m not sure what the issue is, but deleting the host and re-registering solved it.

I have the same problem here, i have an Ubuntu client with multiple disks and partitions, and when I try to capture the image i have the same errors, I tried a lot of options without success.

I guess I would have to ask you a question of what are you trying to accomplish by not having FOS Linux reboot after its done with imaging? What is your goal here?

@GaboGrobier We just recently hat another question on Mac OS X in the forums: https://forums.fogproject.org/topic/13795/server-fog-configuration As well use the forum search. Feel free to ask more specific questions here.

@Sebastian-Roth I don’t think it’s necessary unless you just want to do it for kicks. I abandoned it and went with CentOS 7 and was able to get up and running

@rathan While you can. You shouldn’t. Apple has made imaging a dead workflow through a number of things, the most important being the T2 chip preventing netboot/external boot. MDM and DEP is the appropriate way to now provision MacOS devices. Erasing would be done via CMD+R in recovery or by pushing an erase and install from your MDM.