@george1421 Thank you for all the info I am going to start working on this.

@george1421 Didn’t see any packets except for a single UDP packet every 2 seconds or so after the client checked in and loaded up into partclone. Turned out there’s some hardware issue with the server I had been using. Thanks for your help!

Hi,

for all the surface cramp i always used this one with success without any special settings:
https://www.amazon.com/Microsoft-3U4-00001-Surface-Ethernet-Adapter/dp/B00N3JHBFM
There is also another one, but i can just talk for the one with the skewed usb sheating. I don’t know if the other one has the same interiority:
https://www.amazon.com/Surface-USB-Gigabit-Ethernet-Adapter/dp/B06ZZNPHQX

Regards X23

Fixed! thanks for the prompt responses, love this forum, you guys are always so helpful!

There is a bug in 1.5.0 with the new UI that is causing this slowness. The issue is fixed in 1.5.1 (due to be released soon).

Went back to Fog Node’s instead of Windows and it’s working as expected now. You can resolve this.

@george1421 Thank you very much! I was able to modify the script to fit our setup. Everything is working smoothly now.

Thanks again!

@george1421 Thank you so much! This has resolved my issue.

@jon-fuentes The disk space error message is an incorrect one. The issue is partclone is not passing enough information back to FOG on why it aborted. The answer is probably sprawled across the partclone screen just above the screen shot you provided. The fog service only can tell that partclone aborted for some reason and the “guess” was the hard disk on the fog server is full. Rerun your imaging again and watch what message partclone displays.

Also you might consider upgrading your version of FOG sooner or later. FOG 1.5.1 is waiting for release so you might want to hold off for a bit to upgrade, but you should upgrade once 1.5.1 there are quite a few disk imaging fixes in 1.4.4 with a handful more in 1.5.1. So you should consider upgrading to make your imaging a bit smoother.

nevermind

With a quick teamviewer session this issue has been resolved. The issue was just the sequence of install and ensuring eth0 was up before installing FOG.

@amadrigal Just want to bring up my initial thought about maybe OpenVZ not being able to properly handle multicast in the first place. Can you try setting up another test FOG server as KVM instance just to rule out that possible issue!?

@george1421 Oke! Say it when you found something.

@msi Never mind. After I re-ran the installation from the Git. Problem solved.

Is there a way to reduce how often the fog node’s are checking back into the master server’s mysql?

@kafluke said in How do I schedule FOG image replication for after hours?:

@george1421 thank you so much! These are even the exact times that I needed to set the job for! You da man! This can be marked resolved now.

That is why I get paid the big bucks… oh wait… never mind.

@tesparza the file you are running doesn’t appear to be the installer. It appears to be a self extracting archive that contains the installer. Once you give it a path, it should place all of its install files there, including a DXSETUP.exe, which would accept /silent.

My suggestion is to either find a different version of the installer, such as an MSI, or to take the extracted files and create a snapinpack out of them.

Just going to add in here that when I want to see how busy my HDD’s are during tasks, I use nmon. Can run as normal user and press d to view disk activity percentage. Very friendly to a newb. Press n to also view network stats and c to view CPU as well.

If I was you, i’d bring a computer over to the same physical switch that your FOG server takes the image on. See if it sustains a better speed or not to determine if network routing is to blame or not.

@george1421 That is sent to you. Let me know what you find.

Thanks,

Just for an additional bit of information. Your reference/golden image should never be connected to AD before you sysprep it. Even if it was connected to AD, then removed from AD before system. The first time you connect a computer to AD the target computer will be tattooed causing every image created from that golden image problems down the road.