@msnyder It should, but I can’t guarantee anything. In the past it would, certainly because of how replication operated. It was an all or none type of thing.

It would delete everything from the /images folder and make the master’s images folder a “copy” on the nodes. Of course this worked, but it left a lot of “unknowns” in the mix and didn’t allow any granularity. For example, if the d1.fixed_size_partitions for /images/someimage changed, but the d1p1.img and d1p2.img file (not reality but for the example’s sake) didn’t change at all, it would delete the WHOLE image and force replication down. While this has it’s upsides, it can also cause a huge strain on network performance considering the files can be very large sometimes. (Pro’s vs. Con’s can be thought here).

With the restructured layout for replication, each file is checked individually within an image and only the “changed” files are deleted and re replicated. This also allows you to say which images you want to be replicated at an individual level. (Granular control). Of course this makes it so deletions aren’t autonomous. That said, I’m fairly sure I have the layout set to search all nodes/storage groups it’s assigned to and remove them from ALL places, but I haven’t looked at the way deletes happen in a fairly long time. Sorry I should know it, but I’m working a full time job, plus updating the source code in FOG, plus building kernels, and maintaining Inits. I think you might understand why I might forget things from now and then.

How did you delete the images initially?

If you delete the images individually (clickon on each image->choose delete) it will ask you if you want to delete the data as well.

If you deleted using the “list/search click checkbox press delete” it doesn’t do this option yet. I’m nervous about adding this capability here and the best approach to handle it just because you’re dealing with real data, so I hope you understand the hesitation.

Oh, even simpler, Turn off “Task Reboot” on the hosts client/service settings. Or even better, just turn off the “force” reboot portion from FOG Configuration Page->FOG Settings->FOG Client - Task Reboot->FOG_TASK_FORCE_REBOOT

The hosts won’t magically try to reboot to perform the task in question.

@st.mu You don’t search users in ldap management.

All ldap plugin does is enable you to login with LDAP user accounts, there’s no searching users. I don’t know where you got the idea that you could find users using this plugin.

Your user attribute should be cn not ‘uid’

@st.mu If that’s the case, shouldn’t your “group attribute” value be ‘member’ instead of ‘groups’

@st.mu Is your Domain on an “Open LDAP” ldap tree?

@Joe-Gill Then you might want to look at Auto Log Off of the FOG Client for those hosts. If the client machines have the new fog client, and the Autologout time is 5 minutes or longer it will log out the machine after X minutes of inactivity. If they’re using the Legacy fog client, it will do “random” log offs even if the user is actively using the machine.

I feel I should add the only reason FOG doesn’t win on “disk to disk imaging” is because of how it’s configured to operate vs an inability to do such a thing. It can most definitely do Disk to Disk imaging, but it’s written to take advantage of mass imaging particularly over network.

@Hanz I’m not understanding what you’re saying @Hanz. FOG hasn’t changed how it handles devices. Only if your device’s mac is shared on other machines it could cause problems as you can only register a mac to a single host.

The primary mac address is not what is used as basis of ensuring the host is registered. Any mac address that checks in and is registered to the host will associate to that host (so long as the mac isn’t being shared across multiple systems.)