Best way to create W10 Pro reference computer and deploy the image

RBunning said:

!>>If you can't do network approach, DON'T put the reference machine's Windows image on WinPE's .wim. Instead copy it to <folder where WinPE was copied>\media before rebuilding the media. Make sure the USB stick has enough space on it to hold the image

Sorry, a few more random questions just to clear up a few things.

I was reading back through some of our discussion and came across this, which kind of confused me. I'm not sure what is meant my copying the reference machine's Windows image to <folder where WinPE was copied>\media. Isn't that folder only on the computer that I have installed ADK? ( Maybe this falls under your former post where you said you mixed up some .ISO stuff with some USB stuff. I don't think it applies in my case from what I can tell.)

And out of curiosity, what is meant by putting the reference machine's Windows image on WinPE's .wim? When would you do this and how does that work, exactly? Do you just mean adding it in the the root folder of the copied WinPE file on the computer I'm using ADK on? You're not actually merging two images are you?

When I make my WinPE USB media and then plug it into my reference machine, what exactly occurs when I capture the image? Does it just capture it and add the file to the existing WinPE USB media? I would think it's the latter unless I'm misinterpreting things.

Maybe breaking down this command will help me understand the back end stuff:

Code:

Dism /Capture-Image /ImageFile:c:\my-windows-partition.wim /CaptureDir:C:\ /Name:"My Windows partition"

The /Capture-Image and /Name parameters are self-explanatory. What does /ImageFile do in this case? On the TechNet site, it says that it specifies the path of the image file. This is the location of where the captured .wim will be placed on my WinPE USB, correct? And the /CaptureDir would be the directory I want to capture on my reference computer?

If that's all correct, then when I capture the directory on my reference computer does it just stick the file in the root folder on my WinPE USB? (I should have checked this out when I first tested it)

And lastly, when I make a WinPE USB media I noticed that when I open up my USB and view the files it just shows all the files related to my WinPE image. However, if you mount the image like we did to modify the startnet.cmd file, it looks much like a regular windows OS file structure. Is there some internal process that occurs when I boot to my WinPE USB media on my reference machine that mounts the image to make it usable? Or is that not necessary at all? I'm just a little curious on how some of this behind the scenes stuff works :)

ahelton said:

... :)

Oh, that's fine- don't hesitate to ask questions.

1>>Yeah, mainly all of that is confusing since I really messed up there when explaining that. Actually, you have an opportunity here to further explore what I meant with it *potentially* since you're modifying your WinPE.

-See, when making a disc image, you have to rebuild the WinPE media each time (unless you have some sort of program that can pop open the .iso and modify the file structure directly, which unfortunately I don't). Given I don't have the means to modify the .iso directly, if I wanted to test having an 'all in one' installer (no server needed) I would need to find another way to get the image onto the WinPE media. I have to rebuild the media (make the .iso again). It's a simple command 'Makewinpemedia /iso...'. When you go to build the WinPE media with the Makewinpemedia command, it takes the files found in the 'media' folder from wherever you copied WinPE, copies that to the media and then makes the media bootable. That's why your USB stick has the same file structure as the 'media' folder. See, in order to get the Windows image carried onto the .iso when I go to do things like this, I need to make sure that I include the image in the 'media' folder so when the command starts copying files, the image gets carried along. Sorry I made things a little confusing there, however if you get involved with virtual machines and testing this stuff with them, this will be a very helpful thing to know (you technically can't 'plug' a USB stick into a virtual machine. This isn't always the case, though). Try this out by backing your captured windows image up off of your USB, including it in the 'media' folder, then rebuild the media. The image should be carried onto the USB automatically

-You should never put the image into WinPE's .wim because WinPE's image will then become too large and you won't be able to create the ramdisk that WinPE would need to run (since WinPE runs from RAM, you'd need like 16 GB of RAM (I think) to actually make this work that way). I don't advise doing this ever. But, if you were to- you'd need to first mount WinPE's .wim found at <PE copy dir>\Media\Sources\boot.wim. Then in the folder where you mounted the image (it'll have a file structure similar to a windows installation) you'd need to copy the windows image to some folder there. Then, you'll need to commit the changes to WinPE's .wim using DISM /commit-image /mountdir:<wherever you mounted>. Lastly, you'll need to either rebuild the WinPE media or copy WinPE's .wim from <PE copy dir>\Media\Sources\boot.wim and overwrite WinPE's .wim on the USB found at <USB letter>\Sources\boot.wim. See, when you mount a .wim to a folder, it opens up the image at the given index and copies everything to a given folder. You're technically openly editing the .wim. Committing changes back to the .wim is like clicking the save button- the folder-where-mounted's file structure is coped back to the .wim and it's saved.

-Since WinPE runs from RAM, after it creates the ramdisk, lays down WinPE's .wim to the ramdisk and then boots from it, the USB stick is treated as a USB stick- just like if you had plugged it into any other computer. WinPE is not running from your USB- its running from the ramdisk it created. Therefore everything on the stick is just files and folders to WinPE- nothing is important to it. Everything important for WinPE is in RAM. Therefore, when you go to capture your image, it captures the install at the specified 'capturedir', creates a .wim wherever you specified on the USB, then writes the image as it captures it to the USB- just like if you were writing files to the USB say if it were plugged into another computer.

Example time:
Lets say your install you want to capture is C:\, the USB is G:\

If you run this capture command, the image will be copied to the root of the USB stick:
DISM /capture-image /imagefileG:\image.wim /capturedir:C:\ /name:"Example"
Since only the drive letter of the USB is specified, the root is where it's saved. Let's say you wanted to make a specific folder on the USB then save the image there, here's the commands you'd need to type:

G: <--first command, switches to the USB stick
mkdir Drop <--Second command, makes a new folder named Drop on the root of the USB
CD G:\Drop <--third command, this switches to that new folder
DISM /capture-image /imagefile:image.wim /capturedir:C:\ /name:"Example" <--since the folder is selected, a full path is not required for the /imagefile. This command will save the image to that Drop folder. If you didn't select that folder, you'd have to type [...]/imagefileG:\Drop\image.wim[..]

Most of this is just understanding how the windows command processor works. When you understand that, you'll get all of the shortcuts.

Breaking it down:
The /imagefile lets DISM know that the desired file you'll be saving the capture to is what DISM knows as an image file. That way, DISM knows what it needs to do with the files it reads from the capturedir and what it needs to do in order to construct the image. Frankly, the file extension doesn't even need to be .wim (I would reccommend it is though)- i just did a tested this by capturing to an image titled 'test.test' and it captured the image. Other commercial imaging solutions might use their own extension for the capture like .img.

ahelton said:

Can you use .bat or does it need to be .cmd?

Either extension is acceptable. For the sake of keeping things consistent, I would use .cmd