Hyper-V 2019: Installing a second server, drivers included (throwback)

July 2021:

Below is a blog post I wrote and re-wrote several times over the past 18 months at least. I have since decided to go in a different direction with hypervisors and the purpose of the this spare/old core i7. I’ve decided to publish this anyway as-is for reference in the future. And a reminder to myself to finish stuff. For context this was supposed to be about my second old PC acting as something of a DIY backup server for the main server which is the R520 (and was running Hyper-V Server 2019 at the time).

I’ve had this rough draft of this “extracting drivers from windows” post for almost as long as I’ve had the blog (which is only April 2019 but still seems like a while).

I still recently finished that post – a version of it anyway – but this post my in fact take it’s place.

I’m going to make this post of an actual log as I record the things I do as I do them. And to be clear I don’t actually know if this is going to work or how it will end before I start the process.

The plan is to take this relatively old i7 PC from ~2010 and turn it into a second Hyper-V server. I’m hoping to make it Hyper-V 2019 but I can always fall back to 2016 or 2012R2 if I really have to.

The motherboard is a BioStar T5 XE v5 (don’t make them like that any more). The plan – though probably unnecessarily complex – is to install a copy of the Windows 10 on to the PC and then install whatever latest drivers I can find along with letting the OS install what it finds. Once that is done I can simply export all the drivers to a folder structure.

Since Windows 10 and Server 2019 are essentially the same OS I can then install server 2019 and import all the drivers. I can also integrate those exported drivers into an installation source for 2019 for future installs (probably an ISO, maybe something else like a VHD).

The second half of this plan is installing the drivers for my SAS RAID card – the famous brand/model combination of the LSI 9211-8i – so that doesn’t have to be worried about later.

The LSI 9211-8i is famous as chipset because it has been released under so many different brands/names over the past 10 years or so and because it’s the first thin you would look for when you want to flash such a card to “IT Mode”.

I actually already flashed the this particular card to IT mode. It actually wasn’t that hard as I just followed along with a youtube video. I will probably make a separate post just about that card and the process at some point.

Despite the age of this CPU, I was able to install Windows 10 relatively easily (the SSD and 16 gigs of RAM didn’t hurt).

Once all the drivers were installed, including really old nvidia card (GT-something) and the SAS card I ran a command something like this to back up the drivers

dism /online /export-driver /destination:D:\MyDrivers

Actually there were only 14 drivers that were backed up. Which seems like a small number to me.

On my newly installed Hyper-V OS, the importation of these fourteen drivers would go like below, this time using the built-in Windows 10 command pnputil. This is because DISM can only export drivers from a running OS, not import. Luckily there’s pnputil.

pnputil /add-driver c:\driverbackup-pnputil\*.inf /install /subdirs

This is kind of self-explanatory but I’ll go thorugh it anyway:

• /add-driver – well this tells it you’ll be adding drivers
  • this is followed by the path to the location of the drivers
  • and I specify *.inf files. This is where the really information contains. INFs are magic on their own, aren’t they? Ya. That’s a thing people say.
• /install – well as I said. It’s pretty nice command
• /subdirs – this is what tells it go through all the subdirectories “recursively”. Which is just a fancy way saying “keep going through all the subdirectories you find until you out”. Or like clicking that “look in subfolders” checkbox in the “update driver” box of device manager. If that’s how you wanted to look at it.

And if you’re wondering, pnputil can also export drivers. In fact exported drivers via pnputil would look indistinguishable from the folder tree generated by DISM. Okay you weren’t wondering. Nobody any place was wondering that.

From here I have two options (I can do either or both, actually): integrate the drivers into both WIM files or just install Hyper-V Server and then import the drivers into the already running OS. I likely will integrate them into the Hyper-V install anyway. But more on that later.

As it turns out Hyper-V server is such a relatively stripped down OS anyway so drivers already installed don’t necessarily save a lot of time.

It’s actually quite easy to integrate a folder structure worth of drivers into a install source – both the install.wim and boot.wim – but due to some recent frustrations I may or may not do that this time. Another post I will come back to.

Here are the rough series of steps:

1. With Windows 10 installed export the drivers using DISM or similar
   1. make sure extra devices like USB 3 PCI card, RAID card and video card are installed and working
   2. save exported drivers for later
2. install server 2019, just a plan vanilla OS install from the equivalent of an optical drive
3. once minimally setup, import the drivers using UPnPUtil or similar
4. Once all updates are installed the system is rebooted enough times start connecting hard drives
   1. This is supposed to be only intermittently powered on for back up purposes
   2. since performance isn’t a main priority a thin provisioned volume can be used with a spare drive specified
   3. this will essentially be something equivalent to RAID 5
5. This backup server won’t have the equivalent space of the main server so there’s a chance full backups won’t be possible if the amount data on the main ever reaches high enough levels
   1. I don’t know if I’ll back up to VHDX files on the back up and hyper-compress-7zip the files
      1. uncompressed these VHDX files are easy to mount in the file system if I needed to retrieve something or the server failed in some way
   2. or if I’ll just back up data directly the VDisk volume for easy, thoughtless retrieval
   3. I think I’m leaning toward the VHDX files with compression

Since it’s probably good to have a plan before starting, such a thing I’m going to try and imagine how I want this look when it’s done:

• Power on back up server, it logs itself in
  • A batch file (PS script, whatever) starts after about 10 seconds
    • the file copies will only go in one direction
    • the back up server will “pull” the files from the main server
    • most likely this be used with robocopy
    • Perhaps some kind of functionality with determine which VHDX file the particular robocopy is going into
    • and perhaps the script will be smart enough to detect when space is running out and create a new VHDX file of appropriate size as needed
    • when the file copy operation is complete the PC will either be shutdown or just left with a “push any key to power off” prompt

I think that’s actually all I need it to do. I would copy of the VHDX files with the OS drive of various important VMs as well.

The whole purpose of the second machine is both is have a second copy of the data on the server as as making the process of getting the server back up and running as painless as possible.

References and Resources

• An explanation of Hyper-V networking thanks to altaro.com
• Hyper-V Server 2019 post about setting up storage pool
• Hyper-V server 2019 post about first-setup, networking, RPD etc
• Day 31 of my 100 days of code has some information (day 32 has some info too)
• I also wrote a post about the R520 in particular
• General information on deploying storage spaces (MS Docs)
• PowerShell reference for disk-related tasks (MS Docs)