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

RBunning said:

Windows ADK is going to be crucial for doing this project as its going to come with the tools you'll need to accomplish this project as well as tools for further Windows customization. The very most important thing with ADK is its how you're going to get ahold of a bare bones copy of WinPE. Assuming you download the WinPE package (or whatever its called) when installing ADK, you'll be able to make WinPE media (say on a flash drive or a .iso image for testing purposes). ADK also comes with tools for you to create/ edit/ customize Windows images (.wim files). Most importantly- you'll need to edit WinPE's .wim if you want to stick a script on to start with WinPE for automating your imaging process (great so you don't need to keep remembering the DISM commands). You can also capture a Windows partition to a Windows image (.wim) which is what you'll be doing if you pursue this method of imaging (and then you can deploy it) both using DISM.

I've gotten ADK downloaded and installed and just made my WinPE bootable USB. I noticed you mentioned something about adding a script to the .wim file to automize the DISM process. I am assuming I should have done this before making my bootable USB? I am not really sure about how to do that, so whatever instruction you can provide will be much appreciated. Or should I just not bother with it for now and instead manually type the DISM commands?

Also, will all I be using ADK for in this process be to create the WinPE bootable USB? I won't be using the provided Deployment and Imaging Tools to create a customized image and apply it to my reference computer, correct? If I am understanding this process correctly, I will just bypass that and instead use WinPE to capture the image off my reference computer which is already setup the way I want it for now.

RBunning said:

Here's what I'm talking about:
Capture Images of Hard Disk Partitions Using DISM
(Skip to step 3: Capture Partition Images Using DISM)

I noticed one of the prerequisites listed on this page for capturing and image using DISM is as follows:

A reference computer. You can create a reference computer by deploying Windows, and then removing the computer-specific information from the system. For more information, see Sysprep (Generalize) a Windows installation.

Will I need to generalize my image as stated in the article? I am a little afraid of Sysprep since last time I tried it it failed me miserably. Granted, I have everything backed up now :)

ahelton said:

I noticed one of the prerequisites listed on this page for capturing and image using DISM is as follows:

Will I need to generalize my image as stated in the article? I am a little afraid of Sysprep since last time I tried it it failed me miserably. Granted, I have everything backed up now :)

Its all up to you if you want to try and work with Sysprep- I've gotten by just fine with this without messing with that stupid thing. The only time I see that you would need to do that is if your computers are connected to a Windows domain. All of the computers are going have the same computer name as the reference machine when you get done with imaging- which would create a hassle with managing them on a Windows domain (you'd have to go back to each one pull it off the domain, rename it, add it back to the domain). Sysprep would strip the Windows install of its name and go back through a specific step of the answer file you created (the generalize step step 4 I think it is), which would then apply whatever settings you setup there and then ask for a computer name. (I don't know if that's exactly what would happen, but theoretically that's what is supposed to happen).

>>Given these aren't on a Windows domain (right?) I would say stay a good 20 feet away from Sysprep- I've had zero success with it with this and I see no reason to try and figure it out when things work just fine without it.

>>Lets say each computer does need its own unique name (maybe for inventorying purposes) you would have to go back to each machine and rename it (however, its not going to be as much of a hassle as it would have been if these computers were on a Windows domain).

ahelton said:

I've gotten ADK downloaded and installed and just made my WinPE bootable USB. I noticed you mentioned something about adding a script to the .wim file to automize the DISM process. I am assuming I should have done this before making my bootable USB? I am not really sure about how to do that, so whatever instruction you can provide will be much appreciated. Or should I just not bother with it for now and instead manually type the DISM commands?

Also, will all I be using ADK for in this process be to create the WinPE bootable USB? I won't be using the provided Deployment and Imaging Tools to create a customized image and apply it to my reference computer, correct? If I am understanding this process correctly, I will just bypass that and instead use WinPE to capture the image off my reference computer which is already setup the way I want it for now.

*>>For testing purposes, manually type the DISM commands to make sure they are all going to work the same. Sometimes something like a drive letter isn't going to be the same and stall the whole process- its better to see that happen right as you go than to automate it with a script and have no clue what happened.

>>When you're doing this, write down each successful command you entered, that way when you go to automate it with a script you don't have to be like 'crap... now what did I type?' (like I was when I first tried this).

>>There are two ways you could go about deploying:
!) Stick the reference machine's Windows image on the USB stick your custom PE is on.
*or*
2) Put a computer on the same network as the other machines. Share a folder on that machine to the network. Reside the reference machine's Windows image on that shared folder and tell DISM to use that image.

I have primarily been working with the second one. Since you have one USB stick to go around, its convenient- all you have to do is wait for the computer to get into WinPE, then you should be able to unplug the USB stick and start the next machine (since WinPE runs from RAM). However, this tends to be kinda slow depending on your network.

**Regardless of which method you choose, I would recommend that you make a temporary partition on the hard disk ~15 GB or so (depending on your Windows image) and copy the image to that partition, then tell DISM to apply that image. (Don't worry, in my next reply I'm going to further detail what I mean in possibly a mammoth sized reply where I will show you my scripts and explain them). This way, you can decrease the odds of things breaking and stalling when more than one machine tries to download the image. (I still need to further test this method as I literally just though up of it last night- it seems when more than one machine tries to apply the image (as in right from the computer with the shared folder in that approach) the computers seem to go one at a time- waiting for one to finish before the next one goes).

*>In my next reply, I'm going to show you my scripts and detail sticking them into WinPE's .WIM.

RBunning said:

>>There are two ways you could go about deploying:
!) Stick the reference machine's Windows image on the USB stick your custom PE is on.
*or*
2) Put a computer on the same network as the other machines. Share a folder on that machine to the network. Reside the reference machine's Windows image on that shared folder and tell DISM to use that image.

I have primarily been working with the second one. Since you have one USB stick to go around, its convenient- all you have to do is wait for the computer to get into WinPE, then you should be able to unplug the USB stick and start the next machine (since WinPE runs from RAM).

I have done something similar for installing windows updates across our network. I put WSUS Offline and Autopatcher in a shared folder and mapped it as a network drive on all our library computers. I then only have to download the updates one time and can install them all from that shared sources. We have slow Internet, so this is highly convenient and works much better than downloading updates to individual machines.Heck, half the time Windows Updates would just timeout because the connection was two slow to download them on more than one or two computers at a time.

!-For deployment-

How to customize WinPE & automate with a script
First, you'll want to read up on how to mount the .wim so you can edit it. Assuming you have copied WinPE to some folder on your hard disk, go ahead and read the article from the link below (you can skim to where the commands are) (this is all happening (right now) on the computer that has ADK):

Mount and Modify a Windows Image Using DISM

1>>When you're ready, open the 'Deployment and Imaging Tools Environment' as an Administrator and mount the .wim by typing the DISM commands ('Deployment and Imaging Tools Environment' is very convenient since it lets you use all ADK tools you installed right from that command prompt). The specific .wim we're looking for is <folder where WinPE was copied>\media\sources\boot.wim<- mount that .wim to <folder where WinPE was copied>\mount. When DISM finishes mounting the .wim, open Windows Explorer and browse to the mount folder. You'll notice that there's a file structure exactly like that of a windows install (why they call these things Windows images *.wims*).

2>>Browse to \mount\Windows\System32. The file we're after is 'startnet.cmd'- search for it. (I would recommend using Notepad++ for editing this file, either way you are going to need to run your text editor as an Administrator to edit and save it). This file isn't very exciting... just yet. You'll see only one line that says wpeinit - nothing else in this file. Startnet.cmd has all the commands WinPE starts when it starts... Don't remove wpeinit- that loads drivers and stuff, so you don't want to break that. On the next line, you can start scripting just like on a batch script (since it is one).

3>>Here's what mine looks like:

File: startnet.cmd

wpeinit
CLS <-- I start by clearing the screen- I should have actually started with @ECHO OFF since these first two lines that get printed look sloppy
ECHO Initializing unattended installer mode for Windows 10<--Unnecessary messages I decided to make when doing this
ECHO Establishing network drive for pulling script
@echo off
wpeinit<-- huh... I didn't realize I typed this again. It doesn't matter- you can type it a thousand times in your script- it needs to run only once
REM ****** Renew IP<-- remark- doesn't get printed to screen
IPCONFIG /RENEW<--Trying to delay the script a couple seconds. I don't know if this is needed- but I would recommend it (if you do network approach)
@ECHO Mapping Net Drive
Net use N: "\\COMPNAME\UNC\TO\FOLDER\CONTAINING\WIM" PASSWORD /USER:COMPNAME\USER<<This command connects a network drive from the preceding UNC. This allows easier access to the folder on my network computer that has the actual scripts that format the drive and apply the image. For a totally automated, hands off deployment with this approach, you have alot of extra stuff to type*
N:<<Switched to network drive
ts.cmd <<This script is in that same folder this network drive points to. I strongly recommend you use this approach (the network approach). All the action happens on this script I can freely edit from the other PC. As long as is pointed to here and the machine has access to it- if something goes wrong you don't need to keep rebuilding the WinPE meida, since you can easily modify the script from the other machine.
**Manually test these commands too before you put them in the script- make sure they work

4<<As long as you have tested and made sure that the commands work, put them in the startnet script, save it and use DISM to commit the changes to the .wim (covered in technet article). Don't unmount! If you want to modify this file again, its easier to just keep committing changes without an unmount than having to remount each time.

5<<Rebuild (make the USB stick again) the WinPE media.

!**In my next reply, I'm going to show what I meant by the temporary partition and show deploying.

!>>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

!-For Deployment-

Here's that script referenced from startnet.cmd:

File name: ts.cmd

@ECHO OFF
COLOR 17 <<There is alot of unnecessary stuff here, like comments and changing the color . I'll cut out this stuff with an ellipsis from here on...
...
diskpart /s diskSetup1.dpsf<<To get all of this to work, you'll need to write a script to format the disk (not difficult). These scripts are shown below
...
COPY "Z:\install.wim" "R:\DI.wim"<<This command copies the image and saves it to the temporary partition on the hard disk. If you aren't using a network drive, you'll need to poke around to find which drive letter is you're flash drive. In this case, Z: is the drive holding the image and R: is the letter used to designate the temporary partition where the image is copied to (see the diskSetup1 script below).
...
Dism /apply-image /imagefile:R:\DI.wim /index:1 /ApplyDir:C:\<<Dism is used to actually apply the image. It applies the copied image from that temporary partition to the partition designated by the letter C (see diskSetup1 script). When this finishes, Windows is technically installed, however we aren't done
diskpart /s diskSetup2.dpsf<<Diskpart is re-entered and a second script is run. This script deletes the temporary partition and expands the C partition to all remaining unpartitioned space on the disk (see diskSetup2 script).
C:\Windows\System32\bcdboot C:\Windows /l en-US<<VERY important step. Very very important- don't forget to do this! This creates the boot files. You'll get and error 'bootmgr is missing' if you forget to do this!'
Net use Z: /delete<<Now we're done. In this example, I used a network drive, so I disconnected it here.
...
PING 127.0.0.1 > nul<<These are used to create a delay before the machine restarts.
PING 127.0.0.1 > nul<<I would recommend doing this
EXIT<<Whenever WinPE is exited, the machine restarts
EXIT<<I add several of these to make sure it works
EXIT<<You should need only one EXIT command

!*>A problem I have noticed when doing the USB approach- It might fail since WinPE may have been using different drive letters. If you get an error on the lines of 'No operating system found- Please disconnect any drives that don't have an Operating System', boot back into WinPE and see if it works again (if not, adjust the script to make it work)

Other scripts:

File name: diskSetup1.dpsf<<The file extension .dspf is totally unnecessary. It can be .txt. I just like making my own file extensions.

list disk
select disk 0<<The hard disk might be a different number- please test before you script
clean<<Wipe everything from drive
create par primary size=700<< Creates a primary partition. The size is in Megabytes. Please always make the system partition first!
format quick fs=ntfs label="System"<<Format partition and give it a name
assign letter="S"<<Force the letter S to this partition (never use X! That letter is reserved for WinPE)
active<<Important- mark this partition as active
create par primary size=43276<<This primary partition is where Windows will go. The size doesn't matter as long as there is 15 GB for the temporary partition. This example has this partition set at ~42.25 GB as it was done on a virtual machine
format quick fs=ntfs label="BOOT"<<Format it. You can label it whatever you want "Windows" or "OS". I just chose "BOOT" for some reason
assign letter="C"<<Force the partition's letter to be C. Always do this on the par. where Windows will be applied
create par primary size=16762 id=27<Here's that temporary partition right there. Its 15 GB right on. That ID number is supposed to designate it as a 'recovery' partition, however I've noticed it hasn't been doing that recently. Always make this par. last!
format quick fs=ntfs label="IMAGE"<<Formatting stuff
assign letter="R"<<Force a letter for this par. I would use R.

File name: diskSetup2.dpsf<< Test before you script

list disk
select disk 0
list par<<Shows all the partitions created from the first partitioning script
select par 3
detail par<< Shows information on the partition (important for determining you have the right par. We want that temporary one so we can delete it)
delete par<<Delete the temporary par.
list par
select par 2<<Select Windows partition
extend<<This will extend it to all unpartitioned space on the disk

That's a lot to read through and I hope it helps

If you use USB stick method, put the Windows image in <folder where WinPE was copied>\media. You'll then have to poke around in WinPE to find out which drive letter is used for the USB stick. You can put the scripts in the root .wim image. That way, in the scripts you can call them by saying X:\script name. Rebuild WinPE media...

>>If you have the Windows image copied to that temporary partition, you should be able to unplug the USB and move it to the next machine when DISM starts applying the image.

ahelton said:

I have done something similar for installing windows updates across our network. I put WSUS Offline and Autopatcher in a shared folder and mapped it as a network drive on all our library computers. I then only have to download the updates one time and can install them all from that shared sources. We have slow Internet, so this is highly convenient and works much better than downloading updates to individual machines.Heck, half the time Windows Updates would just timeout because the connection was two slow to download them on more than one or two computers at a time.

If you're internet is slow, that doesn't exactly mean this will be slow (although it sounds like you might not have that great of a network to start with, so...). Try the USB stick method and see how you like it.

RBunning said:

Its all up to you if you want to try and work with Sysprep- I've gotten by just fine with this without messing with that stupid thing. The only time I see that you would need to do that is if your computers are connected to a Windows domain. All of the computers are going have the same computer name as the reference machine when you get done with imaging- which would create a hassle with managing them on a Windows domain (you'd have to go back to each one pull it off the domain, rename it, add it back to the domain). Sysprep would strip the Windows install of its name and go back through a specific step of the answer file you created (the generalize step step 4 I think it is), which would then apply whatever settings you setup there and then ask for a computer name. (I don't know if that's exactly what would happen, but theoretically that's what is supposed to happen).

>>Given these aren't on a Windows domain (right?) I would say stay a good 20 feet away from Sysprep- I've had zero success with it with this and I see no reason to try and figure it out when things work just fine without it.

>>Lets say each computer does need its own unique name (maybe for inventorying purposes) you would have to go back to each machine and rename it (however, its not going to be as much of a hassle as it would have been if these computers were on a Windows domain).

Nope, not on a domain. I'll steer clear of Sysprep. I just wasn't sure by what it mean when it said you had to use it to remove certain computer specific information. I can easily change the name of the computers afterwards since I only have 4 of them.