@cello said in How to create a Windows 10 Image:

Is it also possible without Sysprep?

It’s a trap!

While there are ways that appear to work without sysprep, you’ll have a much better time if you just use sysprep.
I learned this the hard way. Sysprep has gotten faster and a bit easier (in some respects at least).
If you don’t use it, you’ll end up with windows licenses with the same universal identifiers, which breaks volume license activation tools.
You can also end up with driver problems if the image wasn’t created on the same model computer and you don’t use sysprep.

If I were to sum up our steps for creating a win 10 image (but like @george1421 said it’s a bit out of scope and would take days to answer in full detail, also we don’t use MDT, just to provide another method) I would say

Download iso of latest version of most recent windows 10 H2 release (i.e. 20H2, ltsb versions are also a trap unless truly neccessary) Create an unattend file using windows system image manager (see also https://docs.microsoft.com/en-us/windows-hardware/customize/desktop/wsim/windows-system-image-manager-how-to-topics) I personally took the time a few years ago to ready through all the options available, it’s pretty extensive. But you can also make it pretty basic with setting some simple settings, adding some first logoncommands, and then just make sure you read up on using the ‘reseal’ options to make the sysprep phases go in your desired order. (i.e. I have mine go Audit System - adds (but doesn’t install) network drivers to the driver store -> Audit User - reseals to generalize -> Generalize - removes drivers not added by sysprep and makes the image general for any device -> I have it send to shutdown from here -> I Upload it to fog -> When it deploys it starts the specialize phase -> Then it goes through oobe (which you can make unattended, there are some skip oobe options to be sure it doesn’t show, but you want to be sure all settings that would be set during interactive oobe are set by your unattend.xml created with windows system image manager) Install the iso on a vm (or whereever you want to capture your image from), at the oobe screen after install hit ctrl+shift+f3 to enter audit mode DO NOT OPEN THE WINDOWS STORE (if apps are updated in the store, sysprep won’t run, it’s a whole thing) Add customizations/files you want on all machines (some will be removed by sysprep, figuring it out involves some reading and trial and error) and add the unattend.xml file to “C:\Unattend.xml” and “C:\Windows\System32\Sysprep\Unattend.xml” (I like using both places as a fail safe to be sure its used). I personally use custom powershell modules to automate this whole process, scripting it in some way is a good idea once you get it dialed in. I suggest limiting program installation at this step, I have found its better to use a provisioning method such as snapins and or chocolatey triggered by the firstlogoncommands to add programs, easier to keep them up to date and if something goes wrong with an install it’s not then on every single one of your computers. Run sysprep (i.e. sysprep.exe /audit /reboot /unattend:"C:\unattend.xml") and capture the image to fog Deploy the image with fog and watch the magic happen

Part of the oobe phase can involve auto-logging in as the administartor and running the firstlogoncommands, which is where (if you didn’t add it during audit mode) you can make sure the fogservice is there and will get your computer connected to your domain.

This is all a very high level overview and there may be some steps in between beyond creating scripts and other infrastructure. docs.microsoft.com has many helpful guides for the available unattend.xml options and creating images, I thought I had some of the more helpful ones bookmarked/referenced in internal docs but I can’t find them at the moment. I’ll share them if I find them later and remember.

If you take the time to do it right and get it all setup, it becomes very easy to create new images and deploy them.
You could also easily use fogs scheduled tasks to deploy the image nightly on machines. You’ll just need to dial in the firstlogoncommands to work they way you want it to.

@george1421
Oh and of course the WoL function has to be activated in the bios, but that should be clear to everyone.

@quinniedid I updated this article with the testing from today: https://forums.fogproject.org/topic/14791/feature-request-for-fog-1-6-x-configure-image-capture-to-use-nfsv4-instead-of-nfsv3

@george1421 I was asking for the suggestion made by @fogman4 which seems to be focused on Ubuntu, with a large amount or ram set for ramdisk

@JimmyMac Thanks for letting us know. Done.

@greg-plamondon I’m using Centos 7 too

@tom-elliott Thank you very much Tom, from reading so much, I did not notice that answer, this is what I was looking for, I thank you very much for your time.

@scottybullet

This was very helpful! Thanks for sharing this.
I used it with Microsoft Forms which goes back a SharePoint list, then talks to Microsoft
Orchestrator with all the variables, ex; image name, MAC, etc…

@Poelie Not sure if you specific NAS will work but here is some information you can start working on: https://wiki.fogproject.org/wiki/index.php?title=NAS_Storage_Node

@zc0rp said in HDClone as bootable iso:

Yes i can run the exe because it is an portable edition

Great this then gives us a path or at least an idea. In this post https://forums.fogproject.org/post/103323 it talks about building a winpe image that we can use to boot an OS. (sidebar: I’ve done this for a ghost imager). Starting at step 3 it shows how to build a winpe boot environment. You will place the files into the image path before the image is resealed back into the wim. This will place the files you need in the wim file that will get deployed. Once we get to the boot.wim we are done with this tutorial. There is no need to make the iso because that is only for bios mode.

Once we have the boot.wim file then we can follow this tutorial. https://forums.fogproject.org/post/103331 to setup a winpe boot environment for both bios and uefi using wimboot.

FYI, there is now a tool that can renumber your images for you, here it is:
https://github.com/FOGProject/fog-community-scripts/tree/master/RenumberImageIDs

@jonathanho92 There is no “offline install” which is why we said you need to have an internet connection when you’re performing the install.

FOG uses many different tools, and as those tools are different between OS’s, the installer relies on the OS’s package management tool to download and install them using a more native approach.

This is why we told you there is a need for internet connection.

This is why we never said, at any point in our communications, any set of instructions that could even be perceived as “We have an offline installer”.

It’s why I told you:

To install FOG, you will need an active network connection.

Maybe I should’ve been clearer in stating “Active Internet Connection” but

@danboid Thanks for you detailed write up on setting up FOG!

I just tried to edit the first post but I was denied. Could we ditch this rule please, at least for this post?

I didn’t know the forum has such a rule. @Tom-Elliott Do you know if it’s possible to allow editing own posts for users as well?

Here is another comment: We don’t suggest running the installer via sudo directly because the environment variables is different on some Linux systems (and can cause issues!) compared to switching over to the root user via sudo -i or sudo su -.

@lebrun78 I don’t use the FOG Client so I can’t really speak to its activation of the target computer. But I believe if its enabled in the fog management web ui and you have entered either a OEM key or VLK key in the host configuration for that computer the FOG Client will try to activate it. I believe this is outside of any sysprep process.

I can tell you how I use MDT, sysprep and FOG.

I do use MDT to build my golden image each time using the lite touch process. At the end of imaging I run through a quick quality check to ensure everything is setup as it should be then I run a batch file that MDT drops in a certain directory that calls sysprep and points to a custom unattend.xml file. Sysprep then powers off the computer. I capture it with FOG. Then deploy it. I have a post install script update the unattend.xml file on the target computer with the computer’s name, target OU, timezone, KMS Key, and a few other things. When the computer boots and runs WinSetup/OOBE the target computer connects itself to AD and in the proper OU from the unattend.xml file. At the end of OOBE WinSetup calls the setupcomplete.cmd and runs a command cscript c:\Windows\System32\slmgr.vbs /ato that activates windows.

Hi @george1421 and @Sebastian-Roth , thank you very much for your assistance on this issue. Sorry for delay in replying here as I just completed the testing on my side. Yes changing Kernal Ramdisk size to 275000 worked and I was able to capture the image fine. The image is working perfectly okay now. Many thank and much appreciated, you guys are amazing and very helpful.

@Greg-Plamondon Well that bit of code is held over from the WinXP days and worked in Win7. It no longer works in Win10.

I’ve left that in the code because it shows you how you can poke things into the windows registry from linux (which should not normally be possible).

If you are working on drivers and importing them look at this tutorial. The short read is that you need to use the pnputil.exe command in your setupcomplete.cmd file to load the hardware specific drivers during winsetup. https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed?_=1596483356960