WIM files and FOG

Dhruvin.T

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.

george1421

@dhruvin-t Your plan sounds solid. As we discussed yesterday you can either have the unattend.xml file connect the computer to AD or you can have the fog client connect the target computer to AD.

In my case I let the unattend.xml file do it. The reason is our AD is a bit complex. So all of our computers don’t go into just one OU. The OU is dynamically calculated based on the subnet where the computer is being installed to, what the image type is (office, vs lab), what type of device it is tablet, laptop, desktop, server. All of that info is calculated to produce the OU and computer name. All of this magic is done in a FOG post install script (what you haven’t done yet) and then the product of the calculations are used to update the unattend.xml script.

Here is one on setting up for driver injection, it is Dell centric. It CAN be used for other system too.
https://forums.fogproject.org/topic/8889/fog-post-install-script-for-win-driver-injection

This one here is a bit more advanced. The interesting points are the sed script to change the host name and OU by patching the unattend.xml file during the post install script.
https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script

Some other of my tutorials you might want to read is:
PXE booting into the MDT ISO image(that iso that we copied from the MDT server to your VM Host can be pxe booted from FOG)
https://forums.fogproject.org/topic/6284/booting-mdt-2013-litetouch-with-fog

Dhruvin.T

@george1421 Unfortunately with all those scripts, I kind of got lost and didnt want to break anything. So my plan is to specify a network share location within the unattend file for the drivers and call it a day. Now do I need to do anything post imaging in FOG to have it call the unattend file or does windows automatically get the unattend file and launch it?

WIM files and FOG

202

11.6k

17.1k

154.6k