dpinst.exe is a Driver Package INSTaller that comes from the Microsoft Windows Driver Kit

Different versions of the WDK are compatible with different versions of the Windows client OS and their equivalent server OS.

Microsoft Windows Driver Kit 7.1.0 (WXP)
Microsoft Windows Driver Kit 8.0 (Vista)
Microsoft Windows Driver Kit 8.1.u1 (Win7, Win8, Win8.1)
Microsoft Windows Driver Kit 10.0.10586.0 (Win7, 8, 8.1, 10)
Microsoft Windows Driver Kit 10.0.14393.0 (Win7, 8, 8.1, 10) but doesn’t come with a new dpinst.

There are different versions for 32bit and 64bit OSes.

dpinst32.exe: installs and uninstalls driver packages.
By default, the tool searches the current directory and tries to install all driver packages found.

Usage: <path>\dpinst32.exe [/U INF-file][/S | /Q][/LM][/P][/F][/SH][/SA][/A][/PATH Path][/EL][/L LanguageID][/C][/D][/LogTitle Title][/SW][/? | /h | /help]

  /U INF-file    Uninstall a driver package (INF-file).
  /S | /Q        Silent (Quiet) mode. Suppresses the Device Installation Wizard and any dialogs popped-up by the operating system.
  /LM    Legacy mode. Accepts unsigned driver packages and packages with missing files. These packages won't install on the latest version of Windows.
  /P     Prompt if the driver package to be installed is not better than the current one.
  /F     Force install if the driver package is not better than the current one.
  /SH    Scans hardware for matching devices and only copies and installs those drivers for which a device is present. Only valid for Plug and Play drivers.
  /SA    Suppress the Add/Remove Programs entry normally created for each driver package.
  /A     Install all or none.
  /PATH Path     Search for driver packages under the given path.
  /EL    Enables all languages not explicitly listed in the XML file.
  /L LanguageID          Tries to use the given language in all UI. Useful for localization tests.
  /SE    Suppress the EULA.
  /C     Dump logging output to attached Console (Windows XP and above).
  /D     Delete driver binaries on uninstall.
  /SW    Suppresses the Device Installation Wizard, the operating system might still pop-up user dialogs.
  /? | /h | /help        Shows this help.

If a dpinst.xml is in the same path as the .exe when invoked, the dpinst.exe will use the values in that .xml. I use:

<?xml version="1.0" ?>
<dpinst> 
	<!-- equivalent to /sa -->
	<suppressAddRemovePrograms/>
	<!-- The following search and subDirectory elements direct DPInst to search all subdirectories (under the DPInst working directory) to locate driver packages. -->
	<search> 
		<subDirectory>*</subDirectory> 
	</search> 
	<!-- The following language element localizes its child elements for the English (Standard) language. The child elements customize the text that appears on the DPInst wizard pages. -->
	<language code="0x0409"> 
		<dpinstTitle>Device Driver Updater</dpinstTitle> 
		<welcomeTitle>Welcome to the Device Installer!</welcomeTitle> 
		<welcomeIntro>This wizard will walk you through updating the drivers for your device.</welcomeIntro> 
		<installHeaderTitle>Installing the software for your device...</installHeaderTitle> 
		<finishTitle>Congratulations! You finished installing your device drivers.</finishTitle> 
	</language> 
	<!-- equivalent to /sh -->
	<scanHardware/>
</dpinst>

The important bit in this .xml is that it tells dpinst to recursively scan all subdirs at the location specified for all drivers.

By using that .xml along with this command in a post-sysprep or even mid-sysprep script I can force the computer to install drivers when I want to, instead of waiting for Windows to do it at its leisure:

<path>:\dpinst.exe /path "<the path to the drivers I want to use>" /q /se

DPInst will only install those drivers needed by your hardware, provided of course the necessary driver is in your path. Once completed, the script then deletes the folder(s) that held the original drivers, thus freeing up space.

I prefer to use DPInst to install drivers coming out of sysprep, instead of injecting with dism, pnputil or other methods because with each driver you inject, whichever method you use, the registry bloats and can in extreme cases cause the OS to become unstable; yes I’ve done this while prepping a HW-agnostic image ready to drop onto any of 26 very different platforms. This is an MS documented problem with at least Windows 7. I haven’t looked back on the methodology so I don’t know if it can still be an OS killer on Windows 8.1 or 10.

Installing drivers mid- or post-sysprep means I have a large 1-3GB repository to install from that is included in the image, but it means the devices are ready on my terms.

Server

• FOG Version: RC30
• OS: CentOS 7.2.1511

Client

• Service Version: n/a
• OS: n/a

Description

Building another new FOG server, this time with RC30 then importing the image export from another RC30 server.

I visit each image definition and must update its primary storage group, just like I had to with RC26 and again with RC30 I must do this twice for each image definition before the check mark persists.

And yes I included a refresh, (F5, CTRL+F5, logout, browser exit, relaunch , ad nauseum) to be certain that it indeed did not take hold on the first attempt.

I have a growing hatred for Dell systems.

To add PXE boot capabilities to an Oracle VirtualBox machine you must add a version-matching ExtensionPack (.vbox-extpack)).

For Oracle VirtualBox 5.1.10, download from Index of /virtualbox/5.1.10 then add it to your Oracle VirtualBox via menu Preferences > Extensions

I mean following the steps I outlined above is how I got it to finally work. Assume a save and a hard refresh on a separate tab to achieve each = . Considering what I found with the storage group association of images yesterday I figured I’d try toggling some settings, and that included the Search vs List option.

It wasn’t until I performed a Search from the Images page that the LIST option setting began to work as intended.

Again, this is on an absolutely from-the-ground-up installation of CentOS followed by RC26. The only thing introduced other than my standard configuration was the importing of exports.

Updating to RC27 did not fix this.
= result is no list displayed for hosts or images ( I have no groups, snapins or printers )

However …

1. FOG_DATA_RETURNED was now blank. Previously it stated 0.
   = result is no list.

2. Set FOG_VIEW_DEFAULT_SCREEN to Search
   = result is no list.

3. Set FOG_VIEW_DEFAULT_SCREEN to List
   = result is no list.

4. Set FOG_DATA_RETURNED to any value
   = result is no list.

5. Set FOG_VIEW_DEFAULT_SCREEN to Search
   = result is no list.

6. Set FOG_VIEW_DEFAULT_SCREEN to Search and a FOG_DATA_RETURNED value
   = result is no list.

7. Set FOG_VIEW_DEFAULT_SCREEN to List and a FOG_DATA_RETURNED with no value
   = result is no list.

8. Performed a SEARCH from the Image page while no images listed
   = returns list of matching image

9. Cleared the SEARCH box and revisited HOSTS page
   = returns the list

10. visited Images page
    = returns the list

@Tom-Elliott This depends on the motherboard / BIOS.

I have several models of Lenovo set to UEFI, but allow booting to both. I can drop a Legacy/CSM or UEFI image onto these systems and they will boot either OS fine.

In fact I just Legacy PXE booted an M73z with undionly.kpxe to transfer an OEM UEFI image. It transferred and booted fine and runs as a UEFI OS.

Re-testing with RC27.

Using the installer with switch -E does not work. /etc/exports is still changed.

Changing to blexports=‘0’ correctly blocks the installer from changing /etc/exports .

sed -i.bak "s|blexports='1'|blexports='0'|g" /opt/fog/.fogsettings

BitLocker requires either Trusted Platform Module (TPM) 1.2, TPM 2.0 or a USB flash drive (Windows 10 Pro and Windows 10 Enterprise only). There is even a way to disable the TPM requirement through Group Policy; though I haven’t tried it.

The OS does not need to be installed as a UEFI system to be able to use BitLocker.

The real question is, what do you mean that you can’t enable BitLocker? What are you trying to do with it and how precisely?

Okay, so the wall o’text is more or less expected with this RC and the fixes you had me perform. Now it is the dump that occurs periodically via the console instead of the original text I posted.

… but is that wise? To dump status information like that to an unmanned console interface where any Tom, Dick or Jane walking by can see? Not that any Tom, Dick or Jane will be walking by my servers, but the point is that potentially sensitive information could be displayed without anyone being logged in.

Hmm, something else that’s interesting happened.

When I first performed steps 1-4 … the page would refresh and look the same as it did when I first went to it, except for three images. These three images came back with the green checkmark in place of the tick box. I happened to have performed steps 1-4 on these three images twice.

Rebooting and checking again, those same three still have the tick but all others didn’t. Performing steps1-4 again on the recalcitrant images and they finally came back with the green check mark and it survived a reboot.

Clickety-click. Barba-trick. Done, plus a server reboot for good measure and woah! Holy wall o’text Batman.

Not syncing Image between nodes
Image Name: <Image #1 name>
There are no other members to sync to.

Not syncing Image between nodes
Image Name: <Image #2 name>
There are no other members to sync to.

… eventually leading two mismatched rows of

+------
+---

Then an <enter> from me brings up the login prompt.

Now is that expected?

… but I have no snapins.

Do you mean that for each image I should:

1. Edit image definition
2. Select Storage Group
3. Select the Primary Group Selector tick box for ‘default’
4. Select Update Primary Group

?

Server

• FOG Version: RC26
• OS: CentOs 7.2.1511

Client

• Service Version: n/a
• OS: n/a

Description

Day 2 with the same brand new build from scratch of OS and FOG and I’m seeing this unusual text appearing on my non-logged in console.

Checking if I am the group manager.
I am the group manager
Starting Image Replication.

We are group ID: 1. We are group name: default
We are node ID: 1. We are node name: DefaultMember
Attempting to perform Group -> Group image replication.

There is nothing to replicate.
Please physically associate images to a storage group.

This is a standalone server, no storage nodes; as I’ve always created, so the configuration is documented rote.

Storage Node and Storage Group are all FOG default-generated by the installer. Images are associated okay. In fact everything about the FOG server appears to be working as intended, but this text.

Now typically I would work by telnet/SSH, but I happened to have left my console open and noticed this.

Figured out why I missed it again. It is another example of the perils of using pictures instead of text and of quoting text inaccurately.

Searching for either ‘FOG_VIEW_DEFAULT_SCREEN’ or ‘FOG View Settings’ doesn’t find it, but using the incorrect ‘FOG View Setting’ (missing the s) does find it.

Ahh, there it is.

Huh… wonder how I missed that one?

Server

• FOG Version: RC26
• OS: CentOS 7.2.1511

Client

• Service Version: n/a
• OS: n/a

Description

I had some time to kill so I built a FOG server from scratch, performing a fresh install of CentOS 7.2.1511 then installing RC26 in order to prove my documentation is still good. And there was much rejoicing.

Once the entire install process was complete I imported users, groups, hosts and images exports OK, then:

FOG View Settings
= FOG_VIEW_DEFAULT_SCREEN = LIST (default=search)

Clicking on USERS, HOSTS, GROUPS or IMAGES brings me to the SEARCH page only. I can still manually go to the LIST All link, but this setting is not behaving as intended.

-E did not work. It modified it anyways.

Server

• FOG Version: RC26
• OS: CentOS 7.2.1511

Client

• Service Version: n/a
• OS: n/a

Description

Is there a way to prevent the FOG installer from overwriting an existing /etc/exports file ?

Cool… loving the love.