• Hello all, how do I import my WIM files into FOG? I have a WIM file which I sysprepped.
    My next step is to inject the drivers for models of PC we use in prod. Once I am done with that (prrly tomorrow) ill have to inject the WIM into FOG. Any help is much appreciated!!

    Also is there an easier way to inject the drivers into the wim post sysprep other than the commands below?

    Dism /Get-ImageInfo /ImageFile:C:\test\images\install.wim


    Dism /Mount-Image /ImageFile:C:\test\images\install.wim /Name:“Windows Drive” /MountDir:C:\test\offline


    Dism /Image:C:\test\offline /Add-Driver /Driver:C:\drivers\mydriver.inf

    Any help is greatly appreciated.

  • @sebastian-roth Hello yes you can mark this as solved! I also want to point out that @george1421 has been great help with my troubles with getting Fog to work. He went above and beyond to help me get sorted. Really appreciate the hard work you all are doing! Thank you once again and happy holidays!

  • Moderator

    @Dhruvin-T Any news on this? Can we mark this solved?

  • Moderator

    @dhruvin-t The unattend.xml file is called by windows OOBE before it starts. Thats why you placed it in the /Windows/Panther directory. That is the first place OOBE looks for the file. It will be automatically loaded if found.

  • @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?

  • Moderator

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

    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.

    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)

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

  • Moderator

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

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

  • Moderator

    Now to test deploy your image.

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

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

    1. 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.
    2. 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.
    3. Then you build your reference image and perfect it as you need it.
    4. 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.
    5. 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.
    6. Move the unattend.xml file into the panther directory
    7. Sysprep the reference image, having sysprep power off the reference computer when its done.
    8. 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.
    9. 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 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.

  • Moderator

    @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">
                    <PathAndCredentials wcm:action="add" wcm:keyValue="1">

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

  • Moderator

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

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

    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.

  • Moderator

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

  • @george1421

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

  • Moderator

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


    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.