FOG Newbie: 1st IMG Optiplex & Win 10
-
This will be my first post as a member. I’m new to both these forums and the FOG product. I like what capabilities FOG offers, but I’m having an issue with my very first image.
FOG: 1.3.5 R6067 installed on Ubuntu Server 16.04 LTS
Workstation is a Dell OptiPlex 3040 that was installed with Windows 10 Professional prior to beginning this process.I configured my FOG with the recommended settings as per the User/Admin guides. I sysprepped the Windows 10 Pro image, rebooted it, and captured it with FOG with no issues. I then attempted to deploy the same image back to the machine to verify everything worked as it should. What happened next was a boot loop. I attempted various troubleshooting that included changing the bootfile from undionly.kpxe to undionly.kkpxe to ipxe.efi. I have tried all combinations of Host BIOS/EFI Exit Type and redeployed the image several times.
I am about to leave for the day and my first goal in the morning will be to attempt to perform a clean install and capture another image. I did, however, want to reach out to you good folks hoping you may have some insight in to what may be happening or what settings I maybe should be investigating.
Thanks!
-
We just need to troubleshoot.
Are you using the FOG Client?
Where is the reboot happening, exactly? What’s going on just before?
Can you capture an image without sysprepping, and deploy that successfully?
The boot file isn’t the problem here, I think.
-
Welcome to FOG and the FOG Forums.
first lets get the easy part out of the way. Depending on how the firmware is configured legacy, or uefi that decides which iPXE FOG menu program you set for dhcp option 67 {boot-file}. For legacy/bios mode you send the undionly.kpxe file name, and for uefi mode you send ipxe.efi. If you send the wrong iPXE kernel the menu won’t load correctly. Setting up window 2012 dhcp server for uefi/bios coexistence (i.e. sending the right boot file name based on the pxe booting computer): https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence#Using_Windows_Server_2012_.28R1_and_later.29_DHCP_Policy
As for uefi/legacy. What image format you capture uefi/bios you must deploy to the same. If you capture a uefi image you must deploy it to a uefi computer. You can’t mix and match.
Wayne also touched on the fog client. If you are syspreping the image you must install the fog client and set the service to disabled. We need to do this so the fog client doesn’t start up too soon in the OOBE process. We use the setupcompleted.cmd file to re-enable and start the service. The setupcomplete.cmd batch file is called at the end of OOBE. If the FOG service starts too early in the OOBE process you will get an error like windows unexpectedly restarted or another one I can’t remember the exact syntax. But you will get a botched install. Guidance on FOG Client and sysprep: https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#FOG_Client_with_Sysprep
As for win10, when you sysprep it, instruct sysprep to shutdown the computer when its done. Then pxe boot and capture with fog. If you just shutdown win10, the computer isn’t really powered off, but in an enhanced sleep state, which will break your deployment (or the capture will fail because of a dirty disk [i.e. the disk wasn’t closed properly before capture]).
Exit mode only impacts booting through the fog ipxe menu. On my campus I don’t booth through the FOG iPXE menu, but instead when we image we must press F12 and select pxe boot. This is done to avoid an accidental image of a system if the wrong one was selected in the FOG management GUI. The point is you don’t need to boot through the iPXE menu if you don’t want/need unattended imaging.
As for building your reference image on physical hardware. Typically you will create your reference image on a VM to avoid any hardware specific drivers being baked into your reference image. Then during image deployment (with FOG) you can inject the correct drivers into your image. Inject is not the proper term, its more like placing the files onto the target computer in a place where windows OOBE will find them and install them.
-
@Wayne-Workman I wasn’t aware of the FOG client until after I captured the image. The reboot is happening when attempting to load the OS, whether I allow it to load the FOG pxe menu or load straight from disk.
I will attempt to capture an image without sysprep, I haven’t attempted that yet. I’ll repost here when I do.
-
@george1421 Thank you George, very good info and I appreciate the links!
I captured the image in legacy mode. I would like to get this off the ground using UEFI mode if I can. As I mentioned in my reply to Wayne, I wasn’t aware of needing the client for sysprep, so I will try that as well. I’m still learning (aren’t we all?).
Judging by the information you both have provided me, it sounds like I have a botched image due to a combination of legacy/uefi confusion as well as sysprep/fog client issues. I have a bit of work ahead of me in reinstalling/reimaging/testing.
This has been very helpful, I will repost when I am able (likely Monday).
-
@foggerj said in FOG Newbie: 1st IMG Optiplex & Win 10:
I wasn’t aware of needing the client for sysprep, so I will try that as well. I’m still learning (aren’t we all?).
Just for clarity, the fog client is only needed if you want fog to connect the target system to AD, rename the computer what fog has defined as a system name, and deploy snapins. Its not mandatory to have the fog client installed in the target image. Why we both mentioned it is we have seen issues where/when the fog client IS installed and not properly setup, the rename action takes place before the OOBE setup is complete and breaks the deployment.
If you captured the image in legacy mode, you may not deploy it to a computer in uefi mode. You need to create yoru image in uefi mode, capture it and deploy it to a uefi computer.
If I can give you some advice. Build your reference image in a VM and use MDT (microsoft deployment toolkit) to create your reference image. I know it will take you much longer on the first one to get to a capture. But in the long run you can create a universal image that will work for any hardware (with a few fog tweaks).
-
Problems resolved. Capturing and deploying images works successfully. I believe I had a bad image and mismatched settings (UEFI/BIOS). Thank you for your input Wayne/George, it will definitely help me moving forward.
