Some device drivers used in hardware include executables along with hardware drivers. Some devices (graphics and audio) include them more frequently, particularly drivers that have been modified and re-branded by major manufacturers. These executables can prove problematic when utilized during a full, unattended installation of an operating system by a PC imaging process. Some drivers insist on the use of their included installation program, which can usually be circumvented, and almost all of them are useful, applicable, or compatible with only one make or model configuration of PC. If a business is applying a uniform image to PCs with disparate make or model configurations, the installation of the driver's executable will either:
At best, this wastes PC resources with an unnecessarily running program. At worst, it can generate faults and deviate valuable human resources in its remediation.
Some of these drivers actually require an associated executable in order to be configured properly and completely. Their number is very small and if the driver is prepared well, will include instructions for the installation of the executable in its INI file, and the driver will be installable in an unattended fashion. Many of these executables take the form of a CPL or control panel add-in and possibly an associated system tray icon. Are these hardware-specific applications necessary? Many of these types of applications relate to options for graphics controllers, Wi-Fi connectivity, sound controllers and hotkeys on laptops. The vast majority of the time, they supplant functions already represented by the operating system, with branding opportunities and user-friendly graphical interfaces. In a business setting, they are almost never necessary to operate the hardware, even if they may be desirable. For IT managers, it is favorable to minimize the quantity of applications that may require support, balanced with the actual benefit that those applications provide. So, how should these hardware-specific applications be applied in the context of an operating system deployment (if they are necessary or sufficiently desirable)? The answer is simple even if the process can be complicated. Use a bona-fide application deployment methodology. Most modern OS deployment packages either include or work with a separate application deployment feature. Products such as Microsoft's SCCM or Symantec's Ghost Solution Suite include such functions natively. As mentioned, there are third-party options available and many allow application packages to be generated in a several different styles for application to a Microsoft OS natively (such as MSI) or to utilize some installation method (such as EXE). The bottom line is this: Don't try to force your operating system deployment methodology to do something that it's not designed to do well.