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

Ok. I've created my two diskpart batch scripts. How do I go about adding them to my WinPE image? Do I just cut and paste the files into the mounted image? Which directory do I put them in?

 

The point of the delays are for an onlooker to see where the computer is at with imaging and are totally optional. I would use some sort of delay or maybe add a PAUSE or PAUSE > NL line to the script for testing purposes, so you can see if something fails.

 

*Assuming that you will be referencing them from the startnet.cmd script*

-Copy the script files to <winpemountdir>\Windows\System32.
-If they are batch scripts then save them as <filename>.cmd and reference that from startnet.cmd to get everything rolling.
-OR- copy the commands from the batch script and paste them underneath the wpeinit command.

*If they are scripts for disk formatting:*
-Copy the script files to <winpemountdir>\Windows\System32.
-Save them as <scriptname>.<somefileextension>
-reference the script in the batch file by adding the command to the batch file: diskpart /s <scriptname>.<somefileextension>
*-Scripts for disk partitioning/ formatting need to be their own file

 

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"[/quote] 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 *Smile

 

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

 

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.

 

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

 

@RBunning

I would first want to capture my reference machine's image before I modify WinPE's .wim with the batch scripts and such, correct? I would think that would be necessary; otherwise, the batch scripts would run when you booted to your USB on your reference machine and you would unintentionally wipe your reference machine's drive.

And when I commit a change to the mounted WinPE directory, does that auto-update the boot.wim file in the media folder?

Can the assigned Windows partition letter change dynamically on a given machine? When I first did this on my reference machine, the Windows partition had an assigned letter of E: and the system partition assigned C:. I figured that that would stay the same; however, when I just tried to capture my reference machine's image again, I noticed that the Windows partition is now F: and the system partition still C:. Kind of odd that the Windows partition would change letter...

 

1>>Yes
2>>Yes
3>>Yes

1*>You don't want to keep capturing your image- do that only once when you have it exactly how you want it and are ready to deploy. Then, back that captured .wim up to a separate computer- in case your USB has a problem. Then deploy that image. Generally, always do one run without any scripts to see how things go. Then, automate with scripts (you can even automate the capture process- although you'll need to make a separate custom WinPE).

2*>The boot.wim file (assuming you mounted that specific .wim) will be saved/ updated when you commit the changes to the .wim.

3*>Since WinPE runs from RAM, when the computer restarts that *instance* of WinPE is deleted. If you boot back into WinPE the process starts back over all again- make ramdisk, lay down WinPE's .wim, boot. That then that you boot from is a new *instance* of WinPE, and that new instance has no idea that you assigned a specific letter to a partition, so it goes and automatically assigns letters again. You could go back into diskpart and reassign the partitions' letters. Things are going to change- especially if you have formatted the drive once. The best practice is to monitor these changes and make adaptations in the script. When you figure out what everything is generally changed to, you can adapt to that. The drive letters will remain fairly consistent unless you make a change (the assignment of letters is not totally random, you just need to figure out what they get changed to).

 

I successfully applied an image using the automated scripts a little bit earlier. Yeah!!!

I did realize a couple of minor things I forgot to customize on my reference machine, but whatever. I can quickly tweak those settings since I only have 3 of them left to set up.

One problem I am running into is MS Office not activating properly after applying the image. I keeps popping up with a dialogue box telling me I need to activate it even though I've already entered our library volume license key. Hopefully, I can get that figured out.

A few more questions:

1) When I boot to my WinPE USB, it shows Windows assigned to F: and System assigned to C:. But when I boot normally into Windows and look in Disk Management, it shows Windows as C: and System as not labelled. Why? It's just really odd to me that it's not consistent. My OCD is flaring up haha.

2) When reading about batch files and such, I came across the timeout command. Evidently, you can write something like follows:
Code: timeout /t 30[/quote] Would this effectively work just as well as a pause or using the ping method to delay a script?

3) Is the image I've made using this method hardware independent? Does it capture all the drivers and what not or are those installed by windows update after imaging?

 

Scratch that about MS Office. I wasn't logged in as an administrator and once I did so it activated.

 

Each time you do what, exactly? Modify it?

And is this just exclusive to using an .iso and a disc? Isn't the process the same for a USB generally speaking. If I want to modify my image by adding some batch scripts, I would have to mount the image, modify it, commit the changes and then ultimately rebuilt my USB media, correct?

Or maybe you meant something else and I am not quite following. I think where I'm confused is how you go about getting your image if you are using a CD rather than a USB and how rebuilding your media is any different in this process than if you use a USB.

Do you still use the USB to capture the image of your reference machine and create the .WIM file? And from there you have to copy the .WIM file and stick it in the WinPE media folder? And then build your CD media by using the MakeWinPEMedia .iso command?

Or are you just using a CD to do the whole process: capture the image onto disc using bootable WinPE media (the same CD that you are capturing the image to), put captured .wim file onto computer with WinPE and place file in the Media Folder, then rebuild your CD media with WinPE and the included capture image? (If this is it, then I understand the terminology rebuild. Otherwise, I'm not following what we are rebuilding and why we are rebuilding it)

(Doing it with a CD would require you to burn the .ISO to the CD, right? And DISM will do that with the MakeWinPEMedia .ISO command?)

 

Would this effectively work just as well as a pause or using the ping method to delay a script?

3) Is the image I've made using this method hardware independent? Does it capture all the drivers and what not or are those installed by windows update after imaging?[/quote] 1>> Its going to have a mind of its own. If you took that drive out and plugged it into another computer the Windows partition is going to be a different letter. Generally the first OS to be installed to the disk gets C:\ as that's the fairly common drive letter for Windows. Its going to change when you start into WinPE since that's whole different Windows software where X:\ is the common drive letter. You just have to work with it

2>>timeout /t <sec>:
: D That's so awesome! It works (for me at least)! It effectively works as a delay timer.
-When you use it, it delays and says:
Waiting for <sec> seconds, press a key to continue ...
You can either wait for the countdown to timeout or press a key. It works. For how long I've been trying to find a way to make delays in batch scripts, I'm glad someone has found something that works as a delay timer! I guess I wasn't looking too hard...

3>>All the drivers are going to be exactly what you had installed on the reference machine. So keep that in mind- don't drop this image on a different computer model as it might create a driver conflict. Given Windows knows the hardware changed when you image a different computer, it might go through a 'getting devices ready' stage on the first boot to see if there's any new hardware it needs to get up and running.

 

-My 'reference machine' is a virtual machine and there is no USB involved. I cannot 'plug' a USB stick into the virtual machine (I'm using VMWare). I build a .iso file to work around it. .iso is a disc image and the virtual machine understands that. I can point it to the .iso image and the virtual machine will interpret the image as if it was a CD. I can also mount the .iso in Windows on my host machine, but I can't modify it (CD's are generally ROM). The .iso can either be burned to a CD (that's a tadbit old school, though) or you can make a bootable USB from the .iso using a tool like 'Rufus' (what I would probably do). Also keep in mind that I have a server available to me. What I do to capture an image is I have my custom capture WinPE scripted to connect to my server and capture/ save the Windows image to the server. Since the server is within my network, I can download it to my computer or physically plug a USB stick into the server the get the captured image off of it. Regardless of which route I go, I still get the captured image and place it in the 'media' folder if I'm making a standalone installer. Frankly, it's a lot easier to use the server. I tested the standalone installer only once to make sure it was possible. Its a real pain if there's updates because then after you re-capture, you have to rebuild the winpe media all over again with the image on this (and it takes longer to build the media when the captured image is 9 GB). With the server approach, I can have my scripts on the server, the captured image on there as well. I can modify all of this without needing to rebuild the WinPE media (since all the action is happening on files from the server). My WinPE media is also very lightweight and takes up only 300 megabytes on my computer, since all the large files are on the server.

-I can also create a virtual hard drive (.vhd), connect that to the Virtual Machine, capture the image to the .vhd, then mount the .vhd and pull the image off of that. I opt to keep my .wims on the server, however as the server has far more storage space and it is easier to access.

-Given I have no means to modify the .iso, each time I make a huge modification to my WinPE's .wim (say change commands in startnet.cmd, or change the background) I have to rebuild the media. The makewinpemedia takes care of generating the .iso file and making everything work. .iso's are very convenient as I don't need to keep wasting a physical disc each time I make a change to the WinPE. When I say 'rebuild' I mean totally recreate the WinPE media (the .iso in my case- USB in yours) and remake the .iso. Its really easy since makewinpemedia literally does all of the hard work for me. I just run the command and tell it where I copied WinPE, then I direct it to my previous .iso. When it rebuilds the media, it overwrites the existing .iso, then I have the totally up to date WinPE available to use with a VM.

*>>Rebuilding the media is not at all required if you're using a USB stick, however if you switch to using virtual machines say for testing and playing around, you'll probably want to start using .isos. With a USB stick, you have read/ write access, so if you say modify startnet.cmd (then commit your changes back to the WinPE .wim) or if you just want to add an updated Windows image, you can just stick the new image onto the USB or overwrite the existing boot.wim with the USB. You don't get that level of freedom with .isos. Therefore, if there's anything at all you want on the WinPE media, you'd have to stick whatever that might be in the 'media' folder so it gets added when the media is made.

 

Did this actually work for you in a live environment? It worked for me in my test script, but when I added it to my actual batch deployment script is throws a "not recognized internal or external command" error. Bummer. Seemed like the perfect solution to adding a delay.