Network install Windows 10 (8/7/Vista too) at home

Discussion in 'Windows Operating Systems' started by elvis, May 25, 2020.

  1. elvis

    elvis Old school old fool

    Jun 27, 2001
    Here's how I install Windows 10 at home over the network. Got bored of digging for USB sticks every time I wanted to install and test something. This guide should work for Windows Vista, 7, 8 and 8.1 as well, although I haven't tested it.

    It all runs off Linux, however the tools are open source and apparently run on Windows. If someone else wants to write a Windows-equivalent guide, please go for it. I've got a Linux server/NAS that hosts all of this, but you could definitely run it off an Raspberry Pi, a Linux VM, or even something like FreeNAS I assume.

    Things you'll need to follow my exact guide:
    1) A Linux install

    2) An SMB server to host files to the installer. I use Samba on my Linux box, but it doesn't have to be the same machine.

    3) Some sort of network deployment tool - I'll write a post later on about my iPXE setup with examples, but something like FOG makes that easy. I'm using PXE boot which usually requires legacy boot compatibility, but I'll try to update this for UEFI users at some point.

    4) syslinux memdisk - allows loading of a small ISO into RAM over PXE/network:

    5) The wimlib tools installed. Under Debian/Ubuntu/Raspbian, the package is called "wimtools", and provides the script "mkwinpeimg" that builds the WinPE environment:

    6) A valid Windows10 ISO. I build mine from existing Win10 machines and the Microsoft-provided "Media Creation Tool":

    7) A command script for the Windows install client to kick off the network installer. Mine is called "winpe.cmd" and lives in the same directory as all of this (I'll go through what the commands do a bit further down):

    echo Wait 10 seconds for network to start
    net use i: \\\win10pxe /user:guest guest
    With the "wimtools" package installed, and the Windows 10 installer ISO in the same directory, I wrote and run this script. Comments inline explain what it does. Change the *DIR variables at the top to match your system.

    ## Specify the base dirs
    # BASEDIR where your ISO and cmd live
    # INSTALLDIR where the extracted installer goes (export this via SMB and reference in the .cmd)
    # TEMPDIR to mount the ISO to
    # PXEDIR where your PXE content and WinPE image will live
    ## Break on no argument
    if [ -r "${1}" ]
      echo "Using ${1}"
      echo "Please specify a valid Win10 iso file to build from"
      exit 1
    # Delete existing winpe image
    rm -f "${BASEDIR}/winpe.iso"
    # check for mounted ISO, unmount if it exist
    umount -f "${TEMPDIR}" 2>/dev/null
    # make necessary dirs
    mkdir -p "${INSTALLDIR}" 2>/dev/null
    mkdir -p "${TEMPDIR}" 2>/dev/null
    # mount the ISO (needs root/sudo)
    mount -o loop "${BASEDIR}/${1}" "${TEMPDIR}"
    # sync the ISO contents to the installer dir
    rsync -avrhP --delete "${TEMPDIR}/" "${INSTALLDIR}/"
    chmod -R a+rx "${INSTALLDIR}/"
    umount -f "${TEMPDIR}"
    # Create the WinPE image
    mkwinpeimg --iso --windows-dir="${INSTALLDIR}" --start-script="${BASEDIR}/winpe.cmd" "${BASEDIR}/winpe.iso"
    # copy the WinPE image and memdisk to your PXE dir
    rsync -avrhP "${BASEDIR}/winpe.iso" "${PXEDIR}"/
    rsync -avrhP /usr/lib/syslinux/memdisk "${PXEDIR}"/
    # Fix permissions for read-only all users
    chown -Rc www-data:www-data "${PXEDIR}"
    chmod -Rc a-rwxst,a+rX "${PXEDIR}"
    You'll need to execute this with root/sudo perms, as it needs to mount the ISO. You could alternatively skip that and manually extract the Windows installer ISO contents with 7-Zip or Windows10's native ISO browsing abilities if you like, and modify the script to expect all of that stuff done.

    Once that's done you'll end up with a "winpe.iso" and "memdisk" binary in wherever your PXE dir is. My winpe.iso is 365MB in size, using Windows 10 1909 as the source. Your target system will need at least that much RAM to hold the ISO in memory, as well as whatever the installer itself takes up. Let's say 512MB as a safe bet, although if you're running Win10 you've probably got a lot more anyway.

    The "winpe.cmd" script (see above) is baked in by the script, and the commands do the following on boot:

    "wpeinit" - sets a machine up for preboot, gets IP information from DHCP. Sadly this can continue on before an address is received, so I add a pause in there and ask the user to wait 10 seconds. There's probably a more elegant way to do this.

    "ipconfig" - print out my IP details for sanity

    "net use i: \\\win10pxe /user:guest guest" maps the "win10pxe" share on my NAS to i: drive. The share has no credentials on it, but the command requires a username and password, so I have dummy guest/guest values. This share contains the extracted Windows installer ISO contents.

    "i:\setup.exe" - Calls the Windows installer to start.

    "cmd.exe" - this should never execute, as the installer should kick off, succeed, and reboot the system. However this is here should something fail at the end so that you can troubleshoot what happened.

    Let's see it in action. Firing up a VM to test, setting it to PXE boot, we get my iPXE menu (I'll document that in another post, you can use any PXE tool you like such as FOG, WDS, whatever):


    It loads the memdisk binary and the winpe.iso, boots and you see the Win10PE splash:


    Then the winpe.cmd executes:


    And the Win10 installer fires up:


    And the rest is follow your nose.

    I'll add more stuff later about the other moving parts (DHCP, PXE/iPXE, Samba, etc). If anyone modifies this for other stuff like FOG, let me know how you go.
  2. NSanity

    NSanity Member

    Mar 11, 2002
    Dilbery and elvis like this.
  3. Dilbery

    Dilbery Member

    Nov 19, 2005
    Sydney, NSW
    elvis likes this.
  4. OP

    elvis Old school old fool

    Jun 27, 2001
    WDS /MDT are certainly much better options for places with Windows Server and AD. They also offer far better customisation, automation, driver/application injection, etc.

    This guide is aimed at home users who don't have that sort of infrastructure in place. It can be served off an RPi if you like.
    NSanity and Dilbery like this.
  5. shredder

    shredder Member

    Dec 26, 2001
    New Zealand
    You're a good teacher elvis, it's really cool that you pass on what you know. Isn't it. We all want to be able to do the next-level techy things you do. So these types of tutorials are gratefully received by many I'm sure.
  6. pfrcom

    pfrcom Member

    Aug 23, 2009
    3114, Melbourne
    FWIW if you use a Linux system to download Win10 from the M$ site, it's quite straightforward to get any Win10 ISO - skips all the M$ bulls-hit re media creation tool, license keys etc.
    Dilbery likes this.
  7. Aetherone

    Aetherone Member

    Jan 15, 2002
    Adelaide, SA
    Doing something similar for my retro machines (except an XP winpe) so I gotta ask - are you serving this ISO up via tftp or http or?
    My ISO is a similar size but transferring it over tftp is pretty damn slow (100% GbE network, any machine spec from p3 to 5960x). Slow enough that with a modern rig USB3.1 SSD to NVMe, I can damn near finish the install before the tfpd transfer is done.
  8. OP

    elvis Old school old fool

    Jun 27, 2001
    HTTP via iPXE. So I chainload UNDI-only PXE into iPXE, and then that enables HTTP for anything (kernels, initrd images, ISOs, etc). Other things are there too - it even enables iSCSI and cool stuff like that (which I've never tried, but could be very handy for low-memory systems - I'd like to try it for older OSes like Win95/98/2K one day).

    Speedup from TFTP to HTTP is quite substantial. More than that, HTTP is far more reliable (files over 50MB do tend to drop out on TFTP more frequently than I'd like).

    If you want, I can document the whole PXE/iPXE side of things.
  9. OP

    elvis Old school old fool

    Jun 27, 2001
    If anyone wants further documentation on this, let me know.

    Back in November last year I installed LanCache:

    Much to my joy it's doing an amazing job of caching not only regular Windows Updates, but also any BITS traffic now (which includes the Windows 10 Media Creation Tool).

    So my home Win10 installs are now:
    * Network boot to PXE, load up WinPE
    * Install Win10 over SMB in next to no time (much faster than a USB2 thumbdrive)
    * Install Windows updates cached from LanCache

    When I go to update my Windows 10 ISO via the Microsoft Media Creation Utility so I can use the scripts at the top of this page to regenerate the winpe.iso file, that too is largely cached and comes down very fast.

    I might do a separate thread on LanCache, although it's relatively straight forward to set up thanks to docker. The only custom bit I have is I used a separate DNS server, and write a BASH script to configure all the forwarding domains I want rather than just point all DNS traffic in my house to LanCache (that allows me to use DNS over HTTPS and other custom BIND/DNS stuff without being forced to use the basic DNS server in LanCache).

    A couple of small-to-medium business clients of mine are asking about various caching options but without the need to shell out for Windows Server and AD (one in particular that is a consumer PC sales/repair mob, and even with WSUS don't want the hassle of configuring systems via local policy or registry hacks that don't belong to them). This setup will be what I'll roll out to them in order to speed up their operations without per-machine configuration.
    Aetherone likes this.

Share This Page