@george1421 Thanks its working

Not sure why setting the LDAP plugin manually I couldn’t get it working … but I exported the plugin config from an old FOG instance and imported it in the new one and it worked, so I think you can mark this as solved 😉

@Tom-Elliott thank you very much!
I didn’t consider it to be a MAC address where I absolutely should have 🤦🏻.

So the copying process doesn’t happen but the image is fully useable, I will sort this out manually and consider re-installing the server so it will start doing this automatically…

Thanks again!

It doesn’t work with 6.6.49 too and 6.6.34.

@Tom-Elliott said in fog 1.5.10 post pxe boot problem:

d in almost a decade, so I think you’re FOG version is MUCH newer than that considering the bzImage version is 6.6.44 and the one you " updated " to is 4.1.2

please attempt updating your latest fog version?

i have rolled back to the 6.6.44 bzImage files. im not sure where to get current init.xz files however

ok when you say to update the latest fog version, can you please give me a link or something here?

am i updating a specific part or am i updating the whole fog installation?

the fog wiki says to use these links:

https://wiki.fogproject.org/wiki/index.php?title=Download_Current_Init's_and_Kernels_Command_Line

@LLamaPie Everything has been clean now for about a week. I would consider this at least resolved on our end. Still no answer about when it became compromised exactly. Our hyper-paranoid theory is it may have been a “time bomb”. This could have been on the server for months before popping up. Our long-term solution is keeping endpoint protection in place. I have nothing else to add but if I discover anything I will let everyone know.

@45lightrain ok so lets start with some basics.

a 1GbE link (under theoretical conditions) is 1 Giga bits per second or 128MB/sec or 7.5GB/min raw data. Understand that there is ethernet overhead and you will never achieve 7.5GB/min.

So how is it possible to see speeds above 7.5GB/min on a 1GbE link? Simply data compression. So what you are seeing in the part clone screen is a composite speed including fog server speed sending the data to the network, network transfer time, the client receiving the image, expanding in it memory, and then writing it to disk.

If you are getting 5.5-6.1GB/min in partclone on a pure 1GbE network your fog environment is well designed and network well managed.

I wrote an article a few years ago that has some benchmark tools you can use to see where you can get additional speed out of your setup. https://forums.fogproject.org/topic/10459/can-you-make-fog-imaging-go-fast

So the executive summary is that if you want to go fast.

Think if your imaging as 3 factor triangle. You have server speed to get the image to the network adapter, the speed at which your network can move the image to the target computer, and finally the time it takes for the target computer to intake the image, expand it in memory and write to disk. In the imaging process the fog server typically has the least impact on imaging of the three.

Sorry everyone I haven’t updated on this post, my organization wanted our fog server migrated to our data center on to a vm so my time was reverted to doing that and building an additional one at one of our new hospitals we recently finished construction on. But I plan to get back to working on it this week on my test server I have set up. Once I have it set up I am going to implement it on our production servers, I think I’m very close to implementing this concept and once I have it cracked I will make sure to share this with everyone because I think the option of being able to do this will be valuable to many others. @george1421 @Wayne-Workman

@JJ-Fullmer Thank you for the suggestion! I’m still new to creating GPO’s so I’ll have to figure out how to do that one. Doesn’t seem like it should be too hard. Thank you!

@JJ-Fullmer Good to know, thank you so much 😎💯

@Tom-Elliott

Yes, I even spun up a new FOG VM where the mount points were created before FOG was installed to makesure the FOG installer created all the files and set permissions.

edited - words

@Sab First I would have to say both fog server and fog storage node have to be on the same version. The fog storage node doesn’t have its own database, it uses the fog server’s database. There could be schema changes in the database between 1.5.10 and 1.5.9.

Unless you change the storage group around, its not possible to capture to a storage node (in the default configuration). Only the master node in a storage group captures the image, then it replicates the captured image to all storage nodes. Both the master node and storage node can deploy images.

If I had to guess, I would think that in the storage group the nas fog server is not defined as the master node. If I think I understand what you did to configure this setup.

On the fog error screen it should print out the kernel parameters sent to the FOS imaging engine. There should be a filed marked storage or storage_ip, that will point to the fog server it will try to get the image from. Make sure that is correct for your configuration.

Update to fog 1.6 fixed problem

@JJ-Fullmer Thank you for these suggestions. Yes, I am using an install package when doing it manually. I have looked all through device settings, and while I can find the punching feature, I can’t enable it.
I will look into FOG printer settings as well as FogApi powershell module. Haven’t delved into these yet.
Thanks again.

@mentaluproar sadly, due to the windows updates previously mentioned, which are actually fully enforced in the 2024-08 updates, a domain admin account is pretty much required to join the domain in an automated fashion. Microsoft gives some guidance on creating policies to allow a least privileged account but I haven’t been able to get that to work with fog. Granted, as long as your aren’t granting access to the fog gui to non privileged users, saving those creds in fog is safe and secured.