Might be interesting to see if there’s anything in your apache (or php-fpm logs if you have them) logs. (can be found under FOG Configuration -> Log viewer)

These are all great automated methods for when you know in advance which models you’ll have and will support.

But say you work repair service where every possible model under the sun gets dumped for you to fix, then you need a broader solution.

To that end, we find Snappy Driver Installer to be very useful, not perfect, but it works very well.

I can confirm this issue on git 8277

@lukebarone The postdownloadscripts were likely unable to do anything if your drive was full.

@Joe-Gill You should have no problems running a node on CentOS.

@Stilty Probably caused by this issue https://forums.fogproject.org/topic/7935/r5767-host-is-not-registered-invalid-mac-after-i-set-an-image/3

You want to sysprep (with generalize switch) before capture, not after deploy.

If you want clients to get the OOB experience, you can simply go back into audit mode on first boot of windows after deploy, install drivers, etc and sysprep (without generalize switch) to make it ready.

That said, it’s not necessarily what is causing your issues.

Trying to do 40 units at the same time over unicast will be very very slow, slower than doing them in small batches.

Fastest way in your situation is multicast as Sebastian said.

Can you post default.ipxe here?

Just going to start over here.

Looks like a problem with the location plugin!

@duanekaeb On Windows 10 when you run “defrag” on an SSD it will run “trim” on it instead, so yes, it is.

You may want to schedule a chkdsk as well.

It’s probably best to do a fresh install on the new server and then export the relevant data to it (database, hosts list, snapin list, image list, images, etc) Should give the least issues.

@onenetwork You might have to set dodhcp to N as well.

Or you could alter the submask= value to try and let FOG handle it.

@kralon Can you also check the specific host (or hosts) page and see if it’s active in their settings too?

@Benjamin_D It’s probably just easier at that point to just start off with a storage node setup. There are some articles about it on the wiki and we can help you if needed as well of course.

@Tom-Elliott I think people are confused because in certain software/circles, to image a system is to capture the image, not deploy it.

I think most people will operate from the perspective of the client device since they’ll be present at it to use Quick Image. This is also how the terminology is used in the WebGUI for scheduling tasks.

At the end of the day it’s all semantics, and if I’m not mistaken well documented on the wiki.

edit: Perhaps something like “Deploy image to this client device” is a decent way to phrase it?

@sebastian-roth I’ve never used this, but as far as I’m aware, old password tools tend to still work even on Windows 10 (provided they’re local accounts and not Microsoft accounts ofc)

2nd will work fine, in fact, it might even work better.

Main thing to look out for for virtual setups is the NIC setup. Other than that it should be essentially the same as a physical setup.

@Junkhacker That’s fair, but perhaps it would be useful for the long run to have consistent terminology accross all of FOG, that is to say if “Quick image” represents “Deploy image to this host” from the WebGUI ( sort of ), then that should be named something similar.

I understand where newbies’ confusion is coming from, is all.

Couple of things to check:

1. Is the original machine in BIOS or UEFI mode?
2. Is the target machine in BIOS or UEFI mode?
3. If both are in UEFI mode, you may have to manually add the boot option in the UEFI of the target machine.

@predator Hi, SELinux must be set to permissive for now in order for certain FOG central services to work correctly (such as NFS).

There have been some attempts to create SELinux profiles instead, but given how often things can change, this is obviously a more cumbersome way of going about it.

You should use both commands. First one will make it so when you reboot, SELinux is in permissive mode, second one sets it in current session so you don’t have to reboot.