@alexsanderngaongo Try connecting a dumb mini switch between that machine und your building switch. Quite often this makes a difference. From there we can start losging into what’s causing this.

@Derek-Newbold Good to know that php-fpm is installed and running! (Speaking of running processes, what does CPU and RAM usage look like (for processes such as apache, mysql, php-fpm, etc) when you try to do something that takes a long time for you?)

Odd that you’re experiencing performance issues despite this. Though number of clients could contribute to this.

If you have a bunch of hosts/clients, it’s also possible your database has grown quite a bit over time which can slow things down a bit.

@dangquan091

Sysprep your windows before capturing.

*Open CMD (As Administrator)
*Enter command: cd C:\Windows\System32\drivers
*Enter command: sysprep /oobe /generalize /shutdown

System will shutdown. DO NOT BOOT INTO WINDOWS! capture image!

Source: https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/sysprep-command-line-options

@Sebastian-Roth Thank you so much! we will work on it 🙂 i will report back asap.

There were some issues with NVME drives in the past that have since been resolved. I do recommend updating to the latest version for best results.

If it’s just SATA SSDs then it will function just as if it’s a spinning disk in how it’s treated in terms of image capture and deployment.

@johnny_verdane

Defogging: FOG does modify iPXE binaries by adding a boot script embedded into iPXE. That script is here: https://github.com/FOGProject/fogproject/blob/master/src/ipxe/src/ipxescript Its used to chain to default.ipxe on the tftp server. If you look in that script on the fog server that is how it gets to boot.php. With iPXE boot loader you can transfer files over tftp, http(s), nfs with the way FOG has it compiled. FOG uses the http protocol to load FOS Linux because http is faster than tftp and is routable across subnets. But you don’t need http or apache to boot your only custom linux, tftp will work just fine. You could use the rom-o-matic site to build your custom iPXE binaries and not even need to setup that build environment for iPXE https://rom-o-matic.eu/ Just understand that you can use the FOG iPXE binaries too, you just need to add your iPXE code to default.ipxe in the tftpboot directory of your tftp server. Its just one less thing to mess with.

Security: One of the advantages of the buildroot approach is that since your OS will run out of memory its a bit stateless. If the running environment becomes compromised, when you stop the system or reboot the compromise will not be saved since everything runs out of RAM there is no persistence. Plus since the initrd is packed you can’t simply drop a file in its boot media. The bad guy would have to unpack the inits, make the modification and then repack the inits. While its not hard to do, its not easy either.

Anyway, it sounds like you have a fun and challenging project. I wish you the best.

@Derek-Newbold ok here goes…

firewall: yes those ports are correct. With just a comment. Remember that a FTP session is a two way street. Port 21 is used as the command channel and the remote site will connect back to the master fog server over port 20. FTP is a well known protocol so your firewall guys should already know this.

Location plugin. I was going to say nope, we don’t have anything… but then I look on the FOG Project wiki page: https://wiki.fogproject.org/wiki/index.php/Location_Plugin

What fog has issues with is changing the imaging LAN ip address after FOG is installed. As far as FOG is concerned that second interface is invisible. So its address can be assigned by dhcp, there or not it doesn’t matter as long as when its connected the fog server can reach the internet to download any packages needed from the host OS’ repo. Now don’t get me wrong you “can” change the fog server’s IP address after fog is installed but there are a number of places you need to change and then rerun the installer to fix the rest.

Well the answer isn’t clean no matter which route you take. You have to remember that FOG doesn’t really care about user data or host OS. FOG (FOS Linux) is linux based so it really can’t step into the MS Windows world other than copying files to and from a MS Windows mounted disk. FOG (FOS) has no concept of user’s profile data.

With that said I can think of 2 routes. One involves FOG and the other is strictly a Windows activity.

For the MS Windows only solution use USMT (MS Windows User State Migration Tool). You run this from inside windows as an admin to backup and restore user profiles to a network file share. It works well for both same system user migration such as when the same computer is upgraded from Win 7 to Win10, as well as a different system migration between two computers. You can use USMT interactively of deploy the USMT Save State and USMT Load state functions via a FOG snapin or any other package deployment tool like PDQ Deploy.

Now for a FOG only solution. This task would be done with one of FOG postinit scripts. Where the script would mount the windows 😄 drive and rsync the c:/users directory to a remote NFS file share before the image is deployed to the target computer. Then after the image has been pushed use a FOG postinstall script to rsync the files back to the c:/users directory. This is not a very clean solution because ms windows won’t have the connection between the windows user account and their home directory.

Thanks for the information. Relieves some of my worries.

@Hanz Amazing, thank you! worked a treat.

The access Control Plugin was exactly what I was looking for. Thanks! I didn’t know about the plugins.

@jrprajapati What do you mean by directly? No three second delay?

Is this a fresh install? Which version of FOG? Is the client registered already?

Please open the following URL in your browser and post the text you get here: http://x.x.x.x/fog/service/ipxe/boot.php (put in the FOG server IP instead of x.x.x.x)

@Olduser What the image sysprep’d? Did you include the 9020 drivers into your golden image? But the likelyhood if you sysprep’d the image then the native win10 drivers will probably work on the 9020. Other issues, is the 7760 in uefi or bios mode? The same goes for the 9020? You can only capture and deploy uefi based images to uefi base target computers. You can’t mix bios hardware with uefi captured images.

@Razuel remote management is what it sounds like. Public facing meaning the fog server is accessible from the internet.

While technically possible to image, it really wouldn’t be the best experience. By remotely managed we simply mean you can change the host name, tell it to join a domain, configure printers, set up snapins, and that kind of thing. I wouldn’t recommend imaging over the internet as it would be constrained by your internet upload speed and the remote sides download speed.

Usually download speed is fine anywhere but upload is typically limited much more so.

@george1421

Thanks, I’ll give a look at it this weekend.

@george1421 nevermind i found what i was looking for…this is all i wnated to do

FOG image queue size too small
By default, FOG unicast is set to image no more than 10 machines at a time. Other devices will be placed in a queue and wait for another machine to complete. If you want to increase this queue number, you have to do it in two places.

First, under Storage Management > Select your Default Member > Change the figure in Max Clients to the desired number.

Second, under FOG Settings > Expand General Settings > Change the figure in FOG_QUEUESIZE to the desired number.

@Roger-Saffle There is nothing you need to do with fog, its your final destination OS that has control of the disk once it is launched.

FOG Image format wise there is no difference between a HDD, SSD, or NVMe drive once fog captures it. Once FOG deploys the image you will not be able to tell the if the source image was from a ssd, hdd, or vmdk file.

As a test deploy the same image to the 3 different disk structures (hdd, ssd, nvme drive). On the hdd you should get 50-90MB/s sequential speed using crystal disk mark. For the ssd you should get 350-520MB/s sequential speeds depending on your sata attached ssd. For the NVMe drive 700-900MB/s sequential transfer rates. All from the same source image.

@george1421 the next time I need to change something in the golden image I will test these scripts. Thank you.

@blainey Replication needs FTP (random ports for the data channel) and HTTP.