Mirage offers many great functionalities which can be applied to different types of hardware. With Mirage you are able to do hardware migrations (e.g. from a hardware vendor to another), single image management (one image for different types of hardware), disaster recovery (e.g. from a hardware to a VM) and of course Windows migrations.
But all of these operations need one crucial thing to work: device drivers.
Without the correct drivers for your hardware many operations will fail. For example, Mirage will not be able to migrate a client to a new hardware if no suitable drivers are available. The good thing though is that Mirage will never render a system unbootable as it actively checks if all boot critical drivers are available. But Mirage will not check if you have, for example, the proper network or sound card drivers available instead Mirage will warn you if you do not have a matching driver profile for your hardware.
What is a driver profile? Mirage uses driver folders and driver profiles to dynamically provide drivers to a type of hardware.
A driver profile consists out of two things: (1) matching rules to specify to which hardware / endpoint drivers should be provided and (2) which drivers out of the driver folders should used.
From my experience driver profiles should be created with matching rules that are as specific as possible because wrong driver profile rules may result in unnecessary traffic (drivers will be downloaded to devices which do not require them) and wasted disk space on the endpoint. Also you want to make sure that each device only get the drivers meant for this specific device. This is to prevent that untested/unwanted drivers may be installed on a device.
Most of the time I use a combination of the following rules:
- Vendor (e.g. Hewlett-Packard)
- Model (e.g. HP Compaq 8200 Elite)
- Version / Part of the serial number (if you have the same hardware model in different revisions)
- Operating system (e.g Win7 (x64))
As profile name I use a combination out of the values above, for example: HP Compaq 8200 Elite – Windows 7 x64.
Driver folders are more or less the same as a folder structure in your file system to sort and store your drivers. My personal preference is to set up the folders in the following format:
- Operating System
- Operating System
If you use Mirage only for Windows migrations you can disregard the operating system folder as you are only using one OS. A productive structure may look something like this:
Of course the driver library is also deduplicated. So if you import a driver more than once it will not consume more space on the Mirage volume because of dedupe.
For Mirage you need “raw” device drivers with an inf and a cat file. Most of the times, if the customer does not provide some specific drivers, I rely on the the SCCM driver packs offered by the hardware vendors. Most vendors, including Dell, Lenovo and HP, offer ready to go driver packs. While these driver packs are designed to be used with SCCM/MDT they are in “raw” format and can also be used by Mirage.
- Dell: Driver CAB files for Enterprise Client OS Deployment
- Lenovo: Microsoft System Center Configuration Manager (SCCM) and Microsoft Deployment Toolkit (MDT) Package Index
- HP: Driver Packs
Driver profile, driver folders and drivers combined
If you combine all three components the result is called the driver library.
Mirage driver library at work
The driver library is downloaded in almost all Mirage operations. To be specific:
- Windows migration
- Hardware migration and restore
- Machine cleanup (Layer enforcement with remove user applications option set)
- Base layer assignment, update and provisioning
- Apply driver library
When a driver library download is triggered the drivers, which are dynamically matched using the driver profile, are downloaded to the endpoint to the following location: %windir%WDLDrv. This folder is also added to the DevicePath registry key (For more information see Configure Windows to Search Additional Folders for Device Drivers).
Now, when Mirage starts the plug and play driver detection (e.g. during a migration, base layer update, etc.) Windows first looks in the Windows driver store for suitable drivers. If no driver was found it looks for a suitable driver in the locations listed in the DevicePath registry key. In this case %windir%WDLDrv.
By the way, the “Apply driver library” option only triggers the download but no plug and play driver detection. Also every driver library download operation is optimised. If the drivers already downloaded they will not be downloaded again because Mirage’s deduplication functionality is used.
Prioritise drivers in the Mirage driver library
Sometimes, even if the correct drivers are available in the driver library, Windows does not detect/install the driver provided by the driver library and instead uses a basic Windows driver. This happens because for some drivers it is specified that the basic driver is sufficient and therefore after a driver is found in the Windows driver store no search will be done in the DevicePath locations.
Setting the following registry entry on your endpoint (or base layer) will enable driver search in both locations (Windows driver store and DevicePath) regardless if the driver configuration specifies that a basic driver out of the Windows driver store is sufficient.
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\DriverSearching] "SearchOrderConfig"=dword:00000000