WIM files and FOG

george1421

@dhruvin-t I’m a bit confused where you are at right now.

Where you first posted today, the fog server saw that you launched the fog client on your reference image and was waiting for you to approve the system. It basically put the system in a hold state "pending’ until you approved it on the FOG server WebUI.

Now lets understand you have a win10 reference image on a VM. Was that system setup as a UEFI system or a BIOS (legacy) system. Its important for 2 reasons.

To PXE boot that system, the pxe boot loader kernel needs to match the mode the reference image computer is running in.
When you deploy your captured image, it can only be deployed to a like mode system (i.e. captured uefi -> uefi target computer, captured bios -> bios (legacy mode) target computer).

Now we have seen some cruddy uefi firmware on some systems (like Lenovo) that don’t transition very well between iPXE and FOS (the linux OS that runs on the target computer) where it will hang just after init.xz…

If this happens and you have a Lenovo or any other brand, make sure your firmware version is up to date.

george1421

@dhruvin-t said in WIM files and FOG:

saying “Cannot change image.
Host is in a tasking.”

This probably means that you have a running task on the FOG server and it won’t let you adjust the settings with a pending tasks. On the FOG tool tray (in the web ui) select tasks icon. It should show you the running tasks. Remove the task if it has failed to deploy. That should release the image settings.

Dhruvin.T

@george1421

I think this clears up a lot of stuff. The VM was built by someone who was let go and now I am going to just rebuild the VM. I will install a fresh MS build 1709 win 10 image with a EFI setting. I will update you guys on what happens next.

Just to confirm machine should NOT be on the domain at any time right?

george1421

@dhruvin-t That is correct, the machine should never attach to AD, or it will get tattooed with things that make cloning not so fun.

While this is a bit off-point. We use MDT to create our reference images. Since we have to create one for bios mode and one for uefi mode, MDT can create 2 identically deployed systems just in different install modes. It also allow us to create updated installs once a quarter with the latest windows updates and then helps us roll out the next CBB release as MS releases it. We just copy over our task sequences to the new OS and can create a new reference image right away. Its something to consider.

george1421

@dhruvin-t Also since you are building a uefi system, then you need to set your iPXE boot loader to ipxe.efi. This would be set in your dhcp server option 67 should be ipxe.efi. If you have this set correct then you should be able to pxe boot into the FOG iPXE menu.

Dhruvin.T

@george1421 said in WIM files and FOG:

ipxe.efi

My current DHCP is set to undionly.kpxe. So I will change that over to ipxe.efi.

Also talking about MDT. I have the latest build MDT installed. Is there a guide you can reference for me to switch over to that methodology? My new VM is almost ready, is MDT something I install on the VM itself?

george1421

@dhruvin-t MDT “server” is loaded on a dedicated computer. It can be a desktop OS or server OS. You will use the MDT “server” to configure your task sequences, load your dvd images, and preload any drivers you might need for image boot. There are plenty of how-tos on the internet for MDT. This one is not bad. Just be aware that with each release of Windows 10, there seems to be an update required for MDT.

https://www.techrepublic.com/article/how-to-set-up-microsoft-deployment-toolkit-step-by-step/

I develop my reference image on a VM, in MDT you create a boot image (.ISO). You need to boot from this image to start to create your target computer (once your task sequences are setup). I just copy that .ISO file to our NAS and then configure the VM to mount that .ISO image on the DVD rom of my reference image and then boot from that.

My boot order of the VM is DVD, Network, then hard drive. My reference image VM has 70GB hard drive 4 vCPU and 6GB of ram. I needed the 3 extra vCPU and RAM when we were building Win7 images with all of the windows updates that needed to be applied. I just stuck with that for Win10 development and it hasn’t caused me any pain.

There is more, but its a bit off topic of your original post.

Dhruvin.T

@george1421

I already have this setup on a dedicated beefed up box in my cubicle!! Its sitting on a win10 machine though.

george1421

@dhruvin-t You have MDT or your reference image already setup?

Dhruvin.T

@george1421

I have the MDT setup. However when I open it, its asking me for a wim file.

Now I downloaded a ISO image from MS licensing portal. I have been trying to use the MDT. So my thought process is as follow

Use the fresh ISO that I installed from MS and make a bare VM out of it. Install all my apps for the company on it, remove unnecessary stuff off of it and then sysprep the image to convert it into ISO and put it in MDT.

But I changed my route because my boss agreed to let me use FOG. So since you mentioned that FOG needs the image before the sysprep, I am creating this new VM so I can import the image into fog. After it gets imported into FOG, I was going to sysprep and put it in MDT. How does this sound?

You guys have been great help! Really appreciate your input and help with this.

Dhruvin.T

@dhruvin-t said in WIM files and FOG:

then sysprep the image to convert it into ISO and put it in MDT.

I mean convert it into a WIM.

Also, I still install the FOG client but disable the service when I do the capture from FOG right?

george1421

@dhruvin-t The next steps are for you to move your unattend.xml file into place (typically the c:\windows\panther directory) and then run sysprep and use the command line parameter to tell sysprep to power off the reference image once its done. This ensures that all of the files and partitions are released by Win10. If you miss this step then FOG will complain about the disk being busy and/or dirty.

You should also make sure that you have that VM registered in FOG before you sysprep just to avoid any missteps during setup.

george1421

@george1421 Actually before you sysprep the image I want you to update/modify your unattend.xml file.

add this section to your unattend.xml file.

    <settings pass="offlineServicing">
        <component name="Microsoft-Windows-PnpCustomizationsNonWinPE" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <DriverPaths>
                <PathAndCredentials wcm:action="add" wcm:keyValue="1">
                    <Path>C:\Windows\DRV</Path>
                </PathAndCredentials>
            </DriverPaths>
        </component>
    </settings>

Ref: https://forums.fogproject.org/topic/8889/fog-post-install-script-for-win-driver-injection/3

Dhruvin.T

@george1421 said in WIM files and FOG:

@george1421 Actually before you sysprep the image I want you to update/modify your unattend.xml file.

Hello George, im slightly confused. Didnt you mention to not run sysprep when registering image into fog?

Also at what point do I actually start the full registration and capture to fog? And when you mentioned get my VM registered, you meant just doing pxe boot and approving the host right?

I just want to get it right this time around. Thanks for the unattend link, really helpful!

EDIT: Also, MDT says I need a .wim file to create an unattend file.

george1421

@dhruvin-t Well lets take a step back here. (I always use the same VM for building images so I don’t need to do this step).

Your VM used for imaging needs to be known the FOG. Its much easier when you create the virtual machine you immediately pxe boot it and register it will FOG. That will create the host definition.
You need to create an Image definition in the Web Gui to provide a container to capture the reference image into. Once your image definition is created then go into the host definition you just registered and make sure the image is set to the definition you just created.
Then you build your reference image and perfect it as you need it.
Install the FOG Client, but set the service to disable. The host will not go into a pending state since you already registered it in step 1.
This step isn’t required but is helpful especially if you are still developing your reference image, take a vm snapshot of your reference image. If something needs to be tweaked in your reference image you can rewind it to this point re-sysprep it and then capture it again with fog.
Move the unattend.xml file into the panther directory
Sysprep the reference image, having sysprep power off the reference computer when its done.
In the FOG Gui schedule a capture task for your reference image. Go into the host definition and select basic tasks and then capture. Make sure you check the box to power off the reference computer when capture is done.
PXE boot the reference computer. It will automatically start capturing the image bypassing the FOG iPXE menu. It should power off when done.

There is also an excellent post in the FOG wiki that covers this: https://wiki.fogproject.org/wiki/index.php?title=Booting_into_FOG_and_Capturing_your_first_Image

george1421

Now to test deploy your image.

Create a new VM with similar characteristics (the same not required).
PXE boot the VM and register it with FOG.
Power off the target VM.
Go into the FOG GUI and associate the new target VM with the image you captured in the previous post.
Now go into basic tasks and schedule a deployment.
PXE boot the target computer. It should start deploying right away.
At the end of imaging the target computer will reboot and it “should” start windows OOBE right away.

Dhruvin.T

@george1421

I pxe booted and got this error now… this is on the new VM … not having any luck today. Please see the link below.

really disappointed lol

george1421

@dhruvin-t First question where the heck did the FOS image bzImage4134 come from? This should be just bzImage. Is this a new FOG install?

Dhruvin.T

@george1421 said in WIM files and FOG:

@dhruvin-t First question where the heck did the FOS image bzImage4134 come from? This should be just bzImage. Is this a new FOG install?

a wiki mentioned to update the firmware and when doing so, you have to give it the latest firmware name. hence 4.13.4 > 4134

Dhruvin.T

@dhruvin-t

hey George

first of all I want to thank you for going above and beyond yesterday to help me out with the issues. I got the image to sysprep today after it was failing yesterday and it turns out that because Twitter and Facebook were installed, it failed to sysprep. After uninstalling those apps, I was able to kick it off. After it shut off, I created the capture task on the web portal and pxe’d the VM. It successfully captured the image and now am able to see the image on the web portal.

My next step is to test out the image by deploying it to a fresh VM. After the test, next steps would be to go through and figure out the driver issue. If the image deployments succeed, I was going to build a new reference image in the MDT like we did yesterday but way more detailed and options to join the PC to the domain. What do you think about my plan?

Again I want to thank you very much for helping out yesterday.

WIM files and FOG

165

11.6k

17.1k

154.6k