Sysprep - Winload.efi is Corrupt or Missing
-
@RobTitian16 Yes that is the idea.
BUT, I would start with a golden image created on a VM, that way you won’t have intrinsic drivers already in the image. In our case we always load the Dell WinPE driver cab into the reference image via MDT. This gives the WinPE environment the base drivers it needs for the OOBE startup.
-
@george1421 Great stuff - thanks once again, George. I’ll give this a go this afternoon/tomorrow and test it out.
Unfortunately I can’t use a VM to create the image. For some reason whenever I do it’s not uploaded as a UEFI system and I run into countless errors with Bitlocker when the image is deployed. The only way I’ve been able to get around it is to use a physical system. I haven’t really had time to find out why this is the case, unfortunately. -
@RobTitian16 Bitlocker???
Hint, don’t turn it on until after the image is on the target system. Save your self some pain. The VM doesn’t have a TPM chip probably.
-
@george1421 Sorry, I meant when deploying the image and trying to turn it on. For some reason when using a Hyper-V VM to upload an image to the FOG server, it will not be pushed out as a UEFI image (and thus Bitlocker cannot be enabled).
-
@george1421 Hi George,
Just a quick one: my company is using different builds depending on what their job title is (i.e. software developer, tester, IT Support, etc.) and each of these builds has a completely different configuration with software, changes to the registry, etc. Is it possible to simply capture these builds as they are with the necessary software already installed (using a method like dism), add those wim files into MDT along with the Dell cab files and create the image for FOG that way?
It seems your method in the link can only be used for golden images and you install/configure the software afterwards through scripts, etc. Unfortunately for us we can’t do that as there’s a lot of fiddling about with things like Visual Studio (and installing custom scripts, etc.).
-
@RobTitian16 Your golden image can be as setup as you need. My recommendation would be for you to use MDT to build your golden image with all of the windows updates applied, install your applications that can be installed before deployment and exclude applications that cannot be prepackaged because they build an install unique guid (like managed antivirus applications). Then sysprep the image capture then deploy with FOG.
If I did this on my campus I would check into the options for unattended install then setup MDT to install these images automatically during reference image build. If you can get the remaining tweaks done by scripting you can integrate those scripts into the MDT build too. I know it takes time to setup the first time, but then after that you can churn out new reference images by just starting the MDT task sequence.
On our campus we have 2 base images. One is a windows thin image which is windows, .net, vc++ libraries and the fog client. Then we have a fat image that includes the thin image content plus all of our standard office applications (office, java, av, flash, acroreader, etc). We use the lite touch method to create both images every quarter.
Now there is another philosophy you can use. Deploy a thin image and then use either snapins or some other deployment tool (like PDQ Deploy) to push out your standard applications.
Any route you take the key will be to see if you can install the applications using a silent or unattended install command line and then identify the tweaks you need to do to the application and script those during the install. This is all for the reference image build or post imaging deployment.
And one last thing, in your unattended.xml file, if you have the copyto key set any changes made to the administrator account on the reference image will be copied to the default user account when sysprep is run. That way any tweaks make to the administrator account will be reflected in the new profile when users first login.
-
@george1421 Thanks, George.
I’m a little confused with the installation of the applications and MDT. Is this done within MDT itself? What if I’ve already built it on the Dell laptop? How would I then get the image across to MDT to apply the driver cab file and the registry change you mention in the guide?
Were there any guides/resources you used to get acquainted with MDT? -
@RobTitian16 You can’t shake a stick at the internet without finding a guide on how to setup MDT. Google is your friend here.
https://www.404techsupport.com/2016/01/setup-mdt2013u2/
The idea/concept is to setup your golden image on a vm using mdt to build it. Configure that image, then capture and deploy with FOG.
-
@george1421 Hi George,
I’m just taking a look at this now (I became swamped with other things, unfortunately and thus the FOG server was forgotten for a while).
I just have a few questions about your instructions in: https://forums.fogproject.org/topic/7391/deploying-a-single-golden-image-to-different-hardware-with-fog/5?loggedinSpecifically, you say at the end of part 1 that you have a batch file that runs sysprep with the required parameters. Is this set-up as a task in MDT before you capture the reference image using MDT itself? Or, is it separate from everything we’ve done in MDT so far, and is done just to capture the image with FOG?
Also, in part 2 you say to set-up the Windows directory like so:
/images/drivers/{hardware_type}/{os_type}/{arch}/{driver files}
However, the CAB file just comes with WinPE x86 and WinPE x64 folders (with network and storage folders containing the drivers in each, respectively). Do we simply create folders like the below, and copy the drivers from the WinPE x64 and WinPE x86 folders into each one?
C:\Drivers\LatitudeE6410\win10\x64\{all driver files from dell cab}
If so, couldn’t we just use a single folder for the drivers instead? The CAB file doesn’t seem to specify what systems it can be applied to.
-
Q1 Batch file: This is an independent batch file from MDT. We do a few clean up actions just before sysprep and power off. We do this via a batch file and at the end of the batch file it runs the sysprep command with a consistent syntax. That way we get the same exact action every time we build a master image and then sysprep it. It could be done manually by copy and paste, but its much easier to run the batch file. We do have the sysprepit.cmd file as well as some branding stuff installed as a MDT package. That is how it gets copied over to the reference image as a MDT package.
Q2 CAB file: Understand there are 2 different cab files in play here. We install the winpe cab file in the reference image since that contains the core drivers we need post deployment. The driver path /images/drivers/{hardware_type}/{os_type}/{arch}/{driver files} is the extract of the model specific cab file. If you give me a specific dell model I can point you to the proper cab file.