I have some knowledge with windows and might be able to help
SetupCopyOEMInf is the right API
And it should be possible to track it's whereabouts using filemon and
regmon.
I would have also investigate more into pkgmgr.exe which sounds as a
possibly possible solution (from its description)
Another possible source of info is through the administration guide. I
know it's possible to sysprep a machine with additional drivers for later
discovery by the PnP mechanism and the same mechanism used there might be
useful here as well
BTW - storage pose additional complexity if you want to boot directly from
the new driver (like in the case of moving to virtio), there are
additional required changes (other than just installing the driver, you
have to tell it to load it before other components (something to do with
the CriticalDeviceDatabse
 -----Original Message-----
 From: Itamar Heim [mailto:iheim@redhat.com]
 Sent: Monday, November 30, 2009 2:33 PM
 To: 'Yuval Kashtan'; 'Yaniv Kaul'
 Subject: FW: Attempts to install a Windows driver from WinPE
 
 fyi
 
 -----Original Message-----
 From: Matthew Booth [mailto:mbooth@redhat.com]
 Sent: Monday, November 30, 2009 5:52 AM
 To: libguestfs(a)redhat.com
 Cc: 'Ayal Baron'; Itamar Heim
 Subject: Attempts to install a Windows driver from WinPE
 
 One of the things we would really like to be able to do for V2V is to
 install a new driver in a Windows guest. There are a couple of reasons
 for this:
 
 * The guest may not be bootable without the driver installed, for
 example because the underlying virtual hardware has changed from vmscsi
 to virtio.
 
 * If the guest can boot, the alternative is to modify the guest to run
 a
 script on next boot. This requires making assumptions about supporting
 software being installed and working correctly on the guest. Certain
 environments, particularly heavily locked-down environments, make this
 an unsafe assumption.
 
 The Windows PE environment looks perfect for this task. It gives you a
 very lightweight Windows OS which can be customised with additional
 tools. It is specifically for doing installations. I spent Friday
 trying
 to use it to install a driver in a guest. Here's what I tried and why
 it
 didn't work.
 
 Installing a driver in Windows is 'driven' by a .inf file. From my
 (admittedly limited) understanding, this broadly describes:
 
 * The files which need to be installed
 * The hardware the driver is compatible with
 
 The files, including the .inf file itself must be copied in to the
 correct places. In addition, information from the .inf file must be
 written to the registry. It is this last part which causes problems.
 
  From reading documentation, it appears that a driver would normally be
 installed using the SetupCopyOEMInf() library call. I wrote a simple
 wrapper round this and installed it in the Windows PE image, along with
 the VirtIO drivers. I booted into Windows PE and attempted to install
 the driver. As you might expect, the drivers were installed into the
 Windows PE image rather than the guest. I then tried setting
 %systemdrive% and %systemroot% to the guest image. This appears to have
 no effect. This is what makes me suspect that the process is primarily
 registry driven.
 
 I started looking around for ways of using a different registry. I
 discovered the Registry Editor PE plugin to BartPE
 (
https://sourceforge.net/projects/regeditpe/) which allows editing the
 registry of a guest. Looking at how it does this, it uses reg.exe to
 load the guests's hives. I confirmed that you can do this.
 Unfortunately
 you don't seem to be able to replace the default hives. The new hives
 are loaded in a different part of the tree, and are therefore ignored.
 
 This is as far as I've got. Still on my list are:
 
 * Ask on various Windows mailing lists how to do this
 * Investigate if the packaged .msi containing the drivers is more
 flexible.
 * Look for other, possibly lower level, ways of replacing making a
 process use a different registry.
 
 Any and all suggestions are gratefully received,
 
 Matt
 --
 Matthew Booth, RHCA, RHCSS
 Red Hat Engineering, Virtualisation Team
 
 M:       +44 (0)7977 267231
 GPG ID:  D33C3490
 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490