@Sebastian-Roth

Well if they don’t match that may be part of the issue. The layout is from two identical Optiplex 7060 with 500GB drives. Top was one that imaged successfully, bottom is what I see when it doesn’t. All should match my golden image which is also an Optiplex 7060 with a 500 GB drive. I’m not sure where the disconnect would be from fogs settings, the image, and what ends up on the machine.

Again I’ve more or less gotten around this by modifying my image. So I figure if this issue is unique to me it’s probably safe to let it go. If it does start poking up from others at least my info would be a good starting point.

@CoxM said in Fog Language/location client auto setup:

set the location and keyboard language on a client post image deployment

Is it possible yes with a post install script that updates your unattend.xml file.

For the most complete tutorial on post install scripts look here how to set them up: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed

Specifically to your question, there is an older tutorial that give you an exact example:
https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script/6

With a few more hints in the post above:
https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script/7

@wrinks Any news on this? Did you get this solved?

We seem to have a similar issue here: https://forums.fogproject.org/topic/13422/sub-menu-features-access/6

🙂 marking as fixed…

@george1421 Thank you for the response and this would explain alot of the reason for slow upload times.
Currnetly backing up a Lenovo T470 with standard SSD drive which is currently using about 350GB of storage on the 500GB SSD drive. It’s taking about 2 hours. That being said we are using pretty much the default setup for Fog Server. So the Image Compression Format Default is PartClone Gzip.

@Sebastian-Roth

I can safely assume my devices are all running the latest version so I created a group policy to replace the settings.json with a fixed copy on a network share. Which is fine for what I need and I will just update my base images to reflect the correct setting.

Thanks for the help

Okay, so after some testing this morning I’m happy to report that I was able to get this working. I was going off the guide on the wiki which had it configured almost exactly like I pasted in the OP, but after some googling I saw people recommending NOT including the bond-primary lines for each of the bonded interfaces. I commented out those lines to test and sure enough it worked. Below is my current network interfaces config:

auto lo iface lo inet loopback auto eno1 iface eno1 inet dhcp auto bond0 iface bond0 inet static bond-slaves none bond-mode 2 bond-miimon 100 address 192.168.214.10 netmask 255.255.255.0 network 192.168.214.0 broadcast 192.168.214.255 gateway 192.168.214.1 hwaddress ether 90:e2:ba:f5:58:ba auto enp2s0f0 iface enp2s0f0 inet manual bond-master bond0 # bond-primary enp2s0f0 enp2s0f1 auto enp2s0f1 iface enp2s0f1 inet manual bond-master bond0 # bond-primary enp2s0f0 enp2s0f1

I think what also helped was a clean reinstall of Debian; when I posted this thread I was attempting to change existing settings from a pretty setup using only one of the network ports. I did a full reinstall and configured the interface bonding FIRST, then once I was confident that was working I ran the Fog installer and used bond0 as the interface. Installation completed without a hitch and I was online. I appreciate the assistance, I definitely learned a lot along the way, but the solution to this problem of mine with multiple network ports ended up being much easier than anticipated once I knew what to do. Now it’s time to image!

@phil-dosi You are right. There seems to be a difference between 1.5.5 and 1.5.6 in that it does not see the partition 2 as re-sizable. I am not sure why that is. The only way to find out I suppose is that you schedule a debug capture task. Boot the client machine up and step through the whole capture process and take pictures of the messages on screen. Especially at the point where it does the resize stuff before the blue partclone screens!

@Tony-Fiorentino Ok now the next steps is to make that dhcp option 67 dynamic. You would typically do this by following the instructions I provided about uefi bios coexistence. But since your dhcp server is older than windows 2012 you still have options without touching your primary dhcp server. You would do this by installing dnsmasq on your FOG server, and then let dnsmasq provide the proper pxe boot information based on the pxe booting client. If you have a single subnet, where your fog server and pxe booting clients are on the same subnet you just need to install dnsmasq and your’d done. If your clients are on a different subnet than your fog/dnsmasq server you need to add the fog server’s IP address in the last position of your dhcp-helper/dhcp-relay service on your subnet router, just like your main dhcp server. Once that is done your FOG server will issue pxe boot information for all subnets.

Setting up dnsmasq literally takes about 10 minutes with my tutorial. It is the way to go when your dhcp server doesn’t support dynamic boot files.

@blainey While reading through the whole topic again and again I get the impression that it might be easier than expected. I think Eduardo is right about what he calls “hairpin NAT” but I think the term might be a bit missleading. When you use 10.10.1.4 as storage node IP the clients within the 192.168.1.x network try to contact their default gatway to reach out to that. Those requests come into your gateway on the wrong interface and usually get dropped.

On the other hand. I can tell the Master server the node ip is 192.168.1.2.
This results in replication not working but imaging via the local node is successful.

What if we tackle it from this side. I guess it still won’t be easy but can give it a try. Set the storage node IP in the web UI storage node settings to 192.168.1.2. Now with that you “only” need to make sure two things:

the Linux OS on your main FOG server needs to know how to reach 192.168.1.2 -> ip route add 192.168.1.0/24 via 10.10.1.4 dev eth0 (probably you need to set a different network interface than eth0 - just the one where 10.10.1.3 is configured to) you have port forwards and rules on the gatway to allow FTP traffic through -> this might be a bit of an issue because FTP uses random ports as well as connections going both ways depending on the FTP mode used (active or passive - not sure which one we do really)

This setup will only work if the gateway doesn’t do NATing. If it does we need to find a different solution.

@Sebastian-Roth

it worked ! Many thanks I did not even noticed this tab!

@george1421

Hi,

My skills in english are fair but that’s all, that’s may be why my message was not clear enough.

To resume :

-We had a NAS LUN linked to the legacy FOG Server
-We rarely do unicast deploy, 95% are multicast.
-Running 3 or more multicasts start causing slowdowns on the WebUI.
-Sometimes we have up to 10 simultaneous multicasts. Very have rarely more, even
with 23 classrooms on the main site.

As the nic used to access the WebUI is the same as the one that flood the images through the network we thought that we could mitigate this phenomenon using storage node.

We are note stuck to a model or another, we are still searching for the best compromise.

Now we have/had a second issue it’s image export/Import. We plan to use replication at the end but for the first load which represent several TB sync through a wan link is not possible.

It seems this issue is now solved, the remaining “problem” is only cosmetic, but may be I did something wrong, it was the first time I moved images from storage to another and tried the export/import.

@Sebastian-Roth

Full rebuild on dev-branch works.

Thanks for looking into this so deeply!

I figured it out with your help. Thank you for your help.

I am not sure why the code changed after I changed the AD username/password in fog settings, because it seems the host continued to use the original. This was seen under the host->active directory. I added all 50 computers to a group and changed the setting for the group which changed the settings for all 50 hosts. It seems like the global setting should have done this, but it didn’t.

@ddenney0004 What exactly happens when you schedule a task from a storage node?

@Deimos From what you are saying I am wonder if you aware of the fact that FOG does not have persistent group settings. It’s more or less just a tool to push a setting to several hosts at once but it does not stick to the group itself.

@Nabeel Did you configure your dhcp server to supply dhcp options 66 and 67? For dhcp option 66 that needs to be the IP address of your fog server. For dhcp option 67 that should be undionly.kpxe for bios based computers and ipxe.efi for UEFI based systems.

If you need to support both systems in your environment then once you prove that the above options work you can review this article: https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence#Using_Windows_Server_2012_.28R1_and_later.29_DHCP_Policy

@george1421

Sooooo as stupid as this sounds but I have a solution / workaround.

Reduce the number of CPU’s on the VM to 1
Enable migrate to a physical computer with a different processor version

Changing either of these setting causes the speed to bottom out at 21mb/m leaving the setting at this results in 230mb/m capture speed.

OK, thought it might be possible…appreciate the reply.