@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.

After a few days of testing on a local network just using the onboard ethernet port going to a router this is already a heck of a lot easier than the previous imaging solution that I banged my head against for a month. Bare metal is definitely the way to be and I greatly appreciate the insight. I would have torn what remains of my hair out trying to figure out making that work with Virtualbox.

Going from here, trying to get the final set up the way I described in my original post, it sounds like I need to look into the DHCP configuration to move the imaging to the two additional ethernet ports and off eno1, is that correct? Right now I have eno1, enp2s0f0, and enp2s0f1. eno1 will be supplying internet and I presume the other two will be on different gateways reaching out to the switch where the target PC’s will be connected to. Would this be something I can achieve using the built in tools?

@drumnj said in Deploying BIOS Boot Order to multiple computers (booting to network 1st):

You said you return yours to “normal” boot (I take it hd 1st)

What I was referring to here is with Dell and CCTK you can set a flag in the bios that basically says on the next reboot boot to the network. On reboot+1 boot what ever the default boot device is.

So if you wanted to do an unattended imaging but your normal boot device was the hard drive you could push out a FOG snapin that called cctk on next boot-boot to the LAN, then schedule a fog deployment. If the fog client is installed it will reboot the target computer and then start imaging right away.

@Qweeqweg the change from using an account named “fog” to an account named “fogproject” is recent. in spite of directions, people kept creating and using an account named “fog” as their user account when setting up the server.

@Sebastian-Roth Alright, good to know for the future. Since I didn’t have a clear fix, I blew up the VM and am starting from scratch. There were only two images anyway.

Thank you @george1421 for giving me such a complete answer. My greatest concern was looking as if I had attempted something like a cold boot attack, but if something onboard such as IME is going to show logs then I really wouldn’t bother. It’s not worth finding out if they care to distinguish, so thanks for your advice.

In regards to potentially angering people like yourself, I’m grateful you were still fair to me! I didn’t take any steps that were contrary to IT’s mandate, we are after all a team. Maybe they will approve the request. 🙂

FOG was a means to satisfy a curiosity (NDI) but will prove to be much more useful and fun with my own half-broken Desktops. Have a good one!

@dongtuuyenblackpeony Sounds very strange because the iPXE menu/task execution simply is selected via the MAC address of the client machine. That should be no different whichever state the machine is in. For example, you could even wipe the whole disk or install Linux on the drive and it should still behave same on the PXE boot!

Sorry, don’t want to sound rude but have you used FOG to capture/deploy images before? Just want to make sure you know the process.