• Issue
  • In prov_schedule.exe.log - This log is located in \\core\ldmain\log
  • In provisioning.log - This log is located in \\core\ldmain\log\provisioning. 
  • or
  • or
• Resolutions
  • Issue - Scheduler service being stopped
  • Resolution
  • Issue - Computer is not showing up under All Devices in the Console
  • Issue - Corrupt Template
  • Resolution
  • Issue - Template is trying to perform an invalid action
  • Resolution
  • Issue - LANDesk is trying to find a provisioning task from a failed distribution
  • Resolution
  • Issue - Too many PXE Reps to update with the Provisioning information for the device
  • Resolution
  • Issue - Templates may include Distribute Software actions to packages that contain a large amount of additional files
  • Resolution
  • Issue - User cannot see the devices in the console
  • Resolution
  • Issue - Task Handler Proxy crashes in Event Viewer (TaskHandlerProxy.exe.log will show unable to find user in the database as well)
  • Resolution

Note: In LANDESK Management Suite 9.6 or 2016 the software distribution architecture has been completely redesigned, and the case of templates taking a long time to start should be improved or eliminated.

Issue

The provisioning task is failing to load. It will attempt to load the template and retry for 40 attempts and then the job hangs and the client stays in the WinPE screen or brings back the template section window.

In 2016, the LDPROVISION.LOG file in WINPE has the following error:

“Not able to obtain a client certificate. Aborting provisioning”

Logs on the core may indicate a few different errors:

In prov_schedule.exe.log -This log is located in \\core\ldmain\log

Template is not flattened, will attempt to flatten.
Flattening  template failed.

In provisioning.log - This log is located in \\core\ldmain\log\provisioning. 

Unable to find the history task

or

Unable to find template for computer idn ###

or

Unable to find computer

Resolutions

Issue - Scheduler service being stopped

• If the scheduler service is not running, provisioning jobs will not start.
• DCOM errors can cause the scheduler service to stop.

Resolution

• Change the service to run as a Domain Administrator and start the Scheduler service. Once this is done, the provisioning task should work.
• Reset the password for the admin account that was running the LANDesk and LANDesk1 COM+ objects. This prevents the scheduler service from failing which prevents the provisioning template from running.
• Start the scheduler service

Issue - Computer is not showing up under All Devices in the Console

If the LANDESK Inventory Server service is stopped on the Core Server, the device will not show up in the LANDESK Console when the Mini Scan runs when WINPE loads.  If this is happening the Provisioning.log file will show the "Unable to find computer" error.

The Inventory service is set to ignore Mini Scans which will cause new computers to not show up in All Devices in the Console and consequently prevent templates from running.

• Make sure the "Ignore Mini Scans" option is set to 0 in the Advanced Settings for the Inventory service in Configure Services.
• Start/Restart the LANDESK Inventory Server and Managed Planet Core Scan Processor services on the Core Server.

1. Determine the TaskID from the log, Go to your Core and delete that task.
2. Delete client from database
3. PXE boot client, or run a manual inventory scan from the device
   A Manual scan can be initiated from WinPE by running X:/Windows/System32/Startnet.cmd from a command prompt
4. Run the provisioning task

Issue - Corrupt Template

A corrupt template can prevent correct scheduling. One cause if this is if a template is imported, the drop down boxes are not filled in as they were pointing to objects from the previous core. For example, Software Distribution actions do not have a package specified. Same with Configure Agent actions. Also any actions with scripts will have this issue.  Another way to determine if your template is not configured properly is by reviewing the Provisioning.log on the core. If you see the following:

INFO    PROV_SCHEDULE        8/18/2011 5:06:50 PM    : Action LANDesk.Provisioning.Business.PAction_Distribute_software
INFO    PROV_SCHEDULE        8/18/2011 5:06:50 PM    : Got package ID 60, requesting snippet
INFO    PROV_SCHEDULE        8/18/2011 5:06:50 PM    : Requesting snippet for packageId 60
INFO    PROV_SCHEDULE        8/18/2011 5:06:50 PM    : Requesting SWD snippet with task IDN 2214, package ID 60
ERROR    PROV_SCHEDULE        8/18/2011 5:06:50 PM    : Exception encountered trying to get snippet (LANDesk.ManagementSuite.SoftwareDistribution.Business.PackageNotFoundException): This package has been deleted.
ERROR    PROV_SCHEDULE        8/18/2011 5:06:50 PM    : GetSoftwareSnippet failed

Resolution

• Recreate the template, or make sure that all dropdown boxes and options are configured in the template and all included templates.
• If you are getting the error where you are unable to get the Software Snippet, you will need to go into your Provisioning Template and make sure that all software packages are available and working. Determine which package is failing and resolve the software package. Save your template and retry the provisioning task.

Issue - Template is trying to perform an invalid action

Error when attempting to save template - "Cannot save changes to the template . Verify that the template name you have chosen is not already used by another template. Database Error."

Resolution

If you are adding included templates to a main template you will want to start with adding the included templates one at a time until you find the problem template. Then address the specifics of that template and what it is doing. Try to recreate a new template that duplicates the problem template and see if you get any errors while saving the template.

Example Customer Situation:

The problem template was one that used the Update Registry action item and the Registry Operation of Import File. Because the file that was being imported was a combination of different registry export files, and remarked out descriptions had been added to the file, the template would return error: "Cannot save changes to the template . Verify that the template name you have chosen is not already used by another template. Database Error." The initial problem came from the fact that the original template did save when maybe it should not have, which caused the provisioning task to fail and the Prov_Schedule.exe.log file to show "Flattening template failed". Once we isolated the issues with the remarked out lines in the reg file and removed them, the template saved and the provisioning task worked properly.

In the customers environment, having the remarked out comments failed, but in a test lab the customers reg file worked fine. After getting the reg file to import and save, we found that the script failed on the reg file when trying to run it. What we discovered is that in his situation, the header in the reg file that says: "Windows Registry Editor Version 5.0" was causing it to fail, but I was unable to duplicate any of his problems in my lab. This seems to be a unique situation and may or may not apply to other customers that are having the 40 of 40 retries issue.

Issue - LANDesk is trying to find a provisioning task from a failed distribution

• The provisioning log will show  "Unable to find the history task".
  

Resolution

1. Delete client from database
2. PXE boot client, or run a manual inventory scan from the device
3. Run the provisioning task

Issue - Too many PXE Reps to update with the Provisioning information for the device

If there are a large number of PXE representatives in the environment, this error will occur as the core tries to update them all with the needed information. If it cannot complete in time for the 40 retries, the task will not start. However, if you keep waiting the template may start.

Resolution

Reduce the number of PXE reps and remove all PXE Reps that are not active.

Issue - Templates may include Distribute Software actions to packages that contain a large amount of additional files

Software packages that contain a large amount of additional files will require the core to hash the files and prepare manifest files each time a new template is run.
This can cause significant slowdown.  As an example, Microsoft Office 2013 can contain ~ 570 files if the files are included as additional files to the main setup program.
It is recommended to package something like this into a single file or into a few files.  This should significantly speed up the distribution process.

Due to the Software Distribution architecture changes in LDMS 9.6, this issue and most other issues with templates taking a long time to start should be eliminated.

Resolution

Issue - User cannot see the devices in the console

The user that is selecting the template cannot see the devices in the Console that are being imaged.

Resolution

Give the user that is running the template the All Devices scope or create a scope that sees the devices and assign it to the user in the User Management tool.

Issue - Task Handler Proxy crashes in Event Viewer (TaskHandlerProxy.exe.log will show unable to find user in the database as well)

Resolution

Add the account that is configured in the scheduler service into the LANDesk Administrators group and add the account into the console. Once you can see the user in the Console (in the "User Administration" module) run ResolveUserGroups.exe and CreateLandeskRights.exe as an admin from the ManagementSuite Directory. Verify that the User is configured as an LDMS Admin and then restart the scheduler service.

Issue

Imaging a device with a LANDESK Management Agent installed can cause the devices that receive the image to overwrite each other in the database.

Cause

LANDESK inventory looks at a Unique ID/Device ID when inserting the scan. This ID is created when the agent installed on the device.

Resolution

It is strongly recommended that the LANDESK agent not be included in an image.  The recommended way to install the LANDESK Agent with imaging is to use LANDesk Provisioning and include a Configure Agent action in your provisioning template.  Besides causing duplicate devices, the LANDESK agent is often updated and adding it to the image will quickly cause your image to be outdated.

If the agent must be included in an image or Non-Persistent VDI image, the unique identifiers must be deleted out of the registry prior to the capture of the image.  Before creating an image of the machine do the following:

LANDesk Management Suite 9.0 and later

1. Install the LANDESK agent, then STOP all LANDESK related services
2. Delete the following Registry Keys for 32bit clients:

           HKLM\SOFTWARE\Intel\LANDesk\Common Api\UniqueID
          HKLM\SOFTWARE\LANDesk\Common Api\UniqueID

          HKLM\SOFTWARE\LANDesk\Inventory\LogonHistory\Logons
          HKLM\SOFTWARE\LANDesk\ManagementSuite\WinClient\SoftwareMonitoring\MonitorLog contents

          Delete the following Registry Keys for 64 bit clients:

          HKLM\SOFTWARE\Wow6432Node\Intel\LANDesk\Common Api\UniqueID

          HKLM\SOFTWARE\Wow6432Node\LANDesk\Common Api\UniqueID

          HKLM\SOFTWARE\Wow6432Node\LANDesk\Inventory\LogonHistory\Logons

          HKLM\SOFTWARE\Wow6432Node\LANDesk\ManagementSuite\WinClient\SoftwareMonitoring\MonitorLog contents

     3. On Windows XP, delete C:\Documents and Settings\All Users\Application Data\LANDESK (delete the entire directory and subdirectories)

     4. On Windows 7, 8, and 8.1, delete C:\ProgramData\LANDesk (delete the entire directory and subdirectories)

In addition, it is a good practice to ensure that the image does not contain any DRIVERS.DB3 file.

See Community discussion for additional tips and information:

http://community.landesk.com/support/message/61210

How To:

In this scenario, we have several NEW machines including different models to be provisioned and we need to deploy a different image according to the model. This scenario will show us how to collect the model of the computer in the registry within WinPE environment which will be reported back to the Core Server in the temporary inventory of this machine.

We will then use this value in the inventory to create some conditions in the provisioning template to deploy 1 image or another based on this value.

Step by Step:

     Step 1: Create a batch file with the following code

FOR /F "tokens=3*" %%a IN ('reg query "HKLM\HARDWARE\DESCRIPTION\SYstem\BIOS"  /V SystemProductName  2^>nul') do miniscan.exe /send="Custom Data - Model = %%a %%b"

     NOTE: This code is designed to collect the device model name from a registry key, and then use miniscan.exe available in WinPE to report a custom data back to the Core Server to be available on the inventory of the device being provisioned.

     Step 2: Save this batch file onto a share folder

     NOTE: I called it "\\<CORESERVER>\TEST_SOFTWARE\SystemProductName.bat"

     Step 3: Go on your provisioning template and go in "OS Installation section"

          a. Add a first action "Download Preferred Server" to download the batch file created in Step 1 into WinPE.

               NOTE: Do not forget to specify the Read credentials for the corresponding Preferred server (In my example, I defined a preferred server called "10.1.1.210")

          b. Add a second action "Execute File" to execute the batch file

          c. Now the value appears in the inventory of the new device:

          d. We can use an "if conditional" action to deploy one or another image depending on this inventory data:

          NOTE: see How to use Conditionals in LANDESK 2016 Provisioning to know how to use the conditionals (In this article, it actually explains how to deploy an image based on an inventory value, but for a computer which was already existing on the Core Server, hence the inventory data were already there).

• Description
• Resolution

Description

In order to perform imaging in Ivanti Endpoint Manager, the WinPE image used during the imaging process must contain drivers for devices such as the network adapter or hard drive controller.

Additional drivers for Intel network cards, Intel hard drive controllers, and Intel USB3 have been included in the WinPE image for convenience.

The drivers for the WinPE image should match the version of the network boot image file being used (32-bit for boot.wim and 64-bit for boot_x64.wim), not the OS being deployed.

Resolution

First, note the driver versions that are required for each version of Windows PE.

The following document should be consulted to see which version of PE is used in each version of Management Suite: About Windows PE versions used in Ivanti Endpoint Manager

• From the console go to Tools > OS Deployment
• On the Operating System Provisioning window select the Preboot dropdown
• select Manage Drivers in WinPE Image.

• Select the WinPE Image that you want to manage drivers in.
  • The default selection (boot.wim) is the WinPE image used for 32-bit vBoot and PXE.
  • Others would be used to modify bootmedia.wim

• The image file will be processed to open the WinPE image and gather the list of drivers currently in the WinPE image file.
• Select add or remove to manage drivers.
  • Drivers that were included by Microsoft in the WinPE image cannot be removed. If the driver list is blank it indicates that the image file is mounted by another process and must be un-mounted before drivers can be added.You can do this by typing imagex /unmount in the command line. If nothing unmounts or this does not resolve the issue, check console.exe.log for an error in deleting a temporary file. (Path example, C:\Users\ldadmin\AppData\local\Temp\2\imgtmp\Apply) Navigate to this file and rename it. The image should open now and you should see all of the drivers and be able to add them as well.

• When adding a driver a driver name must be provided. Using a name that easily identifies the driver and hardware is recommended for ease of use as additional drivers are added and removed. Browse to the location of the INF for the driver. Note: The driver must match the version of the OS in the WinPE image, not the OS being deployed. The driver for the boot.wim must be a Windows 7 32-bit driver. The driver for the boot_x64.wim must be a Windows 64-bit driver.
  • For LDMS 9.6 and 9.6 SP1 are using WinPE 5.0 based on Windows 8.1.    Windows 8 drivers should be used in this case.

• After the necessary drivers have been added, select Finish and the drivers will be injected into the image.
• After the image has completed processing it is necessary to update existing PXE representatives.

Additional Resources

• Additional information about the WinPE version and required driver versions for each version of Ivanti Endpoint Manager can be found at WinPE Version Information by Ivanti Endpoint Manager Version
• Drivers can be manually added to boot.wim by following these instructions How to use DISM to manually inject drivers into the Boot.wim

A video showing how to deploy a profile using a provisioning template.

• Description
• Resolution

Description

In order to perform imaging in Ivanti Endpoint Manager, the WinPE image used during the imaging process must contain drivers for devices such as the network adapter or hard drive controller.

Additional drivers for Intel network cards, Intel hard drive controllers, and Intel USB3 have been included in the WinPE image for convenience.

The drivers for the WinPE image should match the version of the network boot image file being used (32-bit for boot.wim and 64-bit for boot_x64.wim), not the OS being deployed.

Resolution

First, note the driver versions that are required for each version of Windows PE.

The following document should be consulted to see which version of PE is used in each version of Management Suite: About Windows PE versions used in Ivanti Endpoint Manager

• From the console go to Tools > OS Deployment
• On the Operating System Provisioning window select the Preboot dropdown
• select Manage Drivers in WinPE Image.

• Select the WinPE Image that you want to manage drivers in.
  • The default selection (boot.wim) is the WinPE image used for 32-bit vBoot and PXE.
  • Others would be used to modify bootmedia.wim

• The image file will be processed to open the WinPE image and gather the list of drivers currently in the WinPE image file.
• Select add or remove to manage drivers.
  • Drivers that were included by Microsoft in the WinPE image cannot be removed. If the driver list is blank it indicates that the image file is mounted by another process and must be un-mounted before drivers can be added.You can do this by typing imagex /unmount in the command line. If nothing unmounts or this does not resolve the issue, check console.exe.log for an error in deleting a temporary file. (Path example, C:\Users\ldadmin\AppData\local\Temp\2\imgtmp\Apply) Navigate to this file and rename it. The image should open now and you should see all of the drivers and be able to add them as well.

• When adding a driver a driver name must be provided. Using a name that easily identifies the driver and hardware is recommended for ease of use as additional drivers are added and removed. Browse to the location of the INF for the driver. Note: The driver must match the version of the OS in the WinPE image, not the OS being deployed. The driver for the boot.wim must be a Windows 7 32-bit driver. The driver for the boot_x64.wim must be a Windows 64-bit driver.
  • For LDMS 9.6 and 9.6 SP1 are using WinPE 5.0 based on Windows 8.1.    Windows 8 drivers should be used in this case.

• After the necessary drivers have been added, select Finish and the drivers will be injected into the image.
• After the image has completed processing it is necessary to update existing PXE representatives.

Additional Resources

• Additional information about the WinPE version and required driver versions for each version of Ivanti Endpoint Manager can be found at WinPE Version Information by Ivanti Endpoint Manager Version
• Drivers can be manually added to boot.wim by following these instructions How to use DISM to manually inject drivers into the Boot.wim

Problem

You are preparing to provision a new device model and need to setup HII driver detection.  Hardware Independent Imaging (HII) is an action you can add to a Provisioning template.  HII scans the target machine and identifies the hardware ID of all devices.  It then matches these hardware ID's to drivers in the HII driver library.  Once a match is made, the driver is copied to the device's hard drive and stored in the LD Driver Store (C:\Windows\lddriverstore).  HII then calls on DISM (if running in WinPE) or Windows API (If running in Windows) to actually install all the drivers.

HII allows you to use one OS image with multiple devices containing multiple hardware modules and still install appropriate drivers for each model.  It is important to note that HII does not actually install any drivers.  It's function is to first detect hardware IDs and match up drivers with matching Hardware IDs, and then copy said drivers into the driver store on the target device.  DISM or Windows API is relied upon to perform the actual installation.

Solution

In order to populate HII drop-down menus with the make and model of the new device, follow this article:

HII driver assignments: Device Make or Model is not showing up in HII

1. Run your provisioning template on the new device without including any HII action.  We want to see which devices are installed using default Windows drivers and which devices require HII drivers to install.
   1. After the provisioning template runs and the device boots to Windows, look in Device Manager and identify the devices which are not installed.  There will probably be fewer devices than expected.
   2. Download drivers for these devices and manually install them.  Make a note if which drivers install successfully.
   3. On your core, copy these drivers into the HII library folders and rebuild the library:
      
      
   4. It is advisable to only add drivers to your HII library that are necessary for each make and model.  Adding unnecessary drivers increases the scan time when running HII and also could result in unexpected drivers being assigned
      1. Remember that HII matches drivers based on the Hardware ID.  Multiple drivers can have the same Hardware ID.  By keeping the HII library clean of unnecessary drivers we reduce the chance of an unexpected driver being matched and passed to the OS to install.
   5. Run your template again including HII actions.  In most cases, all drivers will install properly.  If you identify that different drivers than expected are being installed, first determine if there is any effect to operation.  If the different drivers work fine, then there is no need to take further action.  If you do need a different driver to install, then go back to HII and assign that driver to the make, model, and hardware device in question.

More Information

In your provisioning template, you can check a box to install unsigned drivers.  DISM is used to install unsigned drivers and DISM only runs during the WinPE pass of HII.  Unsigned drivers will not install during the Windows pass of HII:

Issue: Unsigned drivers not working in Hardware Independent Imaging (HII)

To add a driver to the HII driver store, you need the .inf file for the driver.  This is the file HII uses to populate the driver information.  Copy the .inf file and any other applicable files (.sys etc.) to the driver library.  If your driver is an .exe or another install package, try unpacking it with 7Zip or similar to locate the .inf file.  If no .inf is available for your hardware, you can create a software distribution package for the file and then assign this package in HII:

HII will only install Driver Packages during the Windows pass of HII.  It will not install driver packages during the WinPE pass.

Error Message

DrvLoad: Unable to load X:\InstalledDrivers\...\e1d6432.inf (Error 0x80070002)

Issue

When WinPE is attempting to load a driver, it fails.

Cause

When going through an OSD or Provisioning task, WinPE uses drvload.exe to access drivers. If drvload.exe is unable to load a driver successfully for use, different actions can fail, including making network connections which are required for performing OSD and Provisioning tasks.

Resolution / Workaround

• Load the drivers' .inf file onto a thumb drive and attach to the machine that is booting into WinPE.
• Identify the thumb drives assigned drive letter
  • Open a New Console

• Type diskpart then press Enter.

• Type list volume then press Enter. This will display assigned drive letter.

• Identify the drive letter for the thumb drive.
• Type exit and press Enter.

• Next try mounting the driver from the thumb drive using the command: X:\Windows\System32\drvload.exe [usbDriveLetter]:\[path_to_driver]\[driver_name].inf

Example:The driver in this example is located in the root of C:\

X:\Windows\System32\drvload.exe C:\e1c6432.inf

• If the driver is compatible, the console will display: DrvLoad: Successfully loaded [usbDriveLetter]:\[path_to_driver]\[driver_name].inf

Example:

DrvLoad: Successfully loaded C:\e1c6432.inf

• If the driver is not compatible, the console will display an error.

Example:

DrvLoad: Unable to load c:\BadDriver.inf (Error 0xe0000100)

• If manually attempting to use drvload.exe to load a driver fails, this must be corrected before OSD or Provisioning tasks can work.

Initializing the network stack after installing NIC drivers

• After loading a NIC driver successfully, you will need to initialize the network stack.

netcfg -WinPE

• Run IPconfig after this completes verifying an IP address has been acquired.

Possible causes of a failure

• The test may have selected the wrong file.
• Dependent files may be missing that are needed as a reference by the *.inf file.
  • .dll, .cab, and .sys files may be dependencies for the driver. Try adding them if available.
• The driver file added may be corrupted. Try re-downloading and testing.
• The driver selected may be incorrect. Try a different driver.
  • Windows Blue drivers have been seen to work in some circumstances where Windows 8.1 x86 drivers did not.

Applies to LANDESK Management Suite 9.0[, 9.5

In LANDESK Management Suite 9, LANDESK introduced new Hardware Independent Imaging (HII) tools. These tools can be used in conjunction with OSD or Provisioning to apply drivers for particular hardware devices when deploying a generic Windows image.

Hardware Independent Imaging Components

HII Driver Repository

This is where the actual driver files are stored. This can be ANY machine with a UNC and HTTP share available to client machines. It is recommended that the HII Driver Repository be located with a high-speed, low-latency connection to the Core Server. The drivers can be organized in any manner and should include the inf files and all supporting files. The location of the HII Driver Repository is configured in the LANDESK Management Console.

The "master" HII Driver Repository can be replicated to Preferred Servers as needed. The Preferred Servers do not have to have both UNC and HTTP shares available as long as clients are configured to use the available share.

For more information on the HII Driver Repository see HII Driver Repository

HII Driver Database

Once drivers are placed in the HII Driver Repository, and the HII Driver Repository Manager configured to point to the drivers, the HII Driver Repository Manager will generate the HII Driver Library Database. A progress bar will indicate the progress of the database creation and when the database is complete. The HII Driver Database is not updated automatically so it should be updated anytime new drivers are added to the HII Driver Repository

The driver library is created at the root of the HII Driver Repository and is named drivers.db3. This file is distributed to clients and used to determine the correct drivers and the associated files necessary for any given hardware device and the corresponding driver.

For more information on the HII Driver Library Database see HII Driver Database

HIIClient

HIIClient is the client side application that is run in order to get drivers installed on target devices. HIIClient will use HTTP by default, but can be configured to use UNC. No other configuration is necessary.

When HIIClient runs it will automatically detect the Windows® version (Windows XP®, Windows 7®) that is installed, the architecture that is installed (x86, x64) and all the individual devices connected to the client (Hard drive controller, video card, sound card, chipset etc.). HIIClient will then use the HII Driver Database to find the best matching drivers available in the HII Driver Repository. The best drivers are determined by a number of factors and should match the drivers that Windows would choose. Only the best matching and most recent driver for each device is downloaded.

The drivers are downloaded from Preferred Servers (if configured) and then installed on the device. The installation method for the drivers varies depending on the Windows version being deployed. For more information about HII Client see HIIClient

Preferred Servers

With LDMS 9 SP3, HII has been improved to allow the use of Preferred Servers via HTTP or UNC and download speed has been improved. All Preferred Server configuration requirements are the same as for LANDESK features that use Preferred Servers.

Because HII runs in WindowsPE, some special considerations are worth noting. Windows PE will assign a random hostname to the device when it boots. Also WindowsPE will not have any domain access or credentials natively. This means that it is very important that any Preferred Server that will be used by HII have the client Read-only credentials configured. For more information on Preferred Server configuration see:

LANDESK Content Replication - Preferred Server (Target) Configuration

How to Configure a Preferred Package Server

How to set up a HTTP share for a Preferred Package Share

Important Information

The HII tools use information contained in driver files and information obtained from devices in order to match up the right drivers and devices without requiring the user to manually configure or match up anything. In order to do this, LANDESK pulls information from drivers files in accordance with standards published by Microsoft. Occasionally device manufacturers will take shortcuts or have an error in a driver file. When this happens it can cause LANDESK to match the wrong drivers to a machine and can result in problems. In every case if the Windows were pointed to the driver, it would also incorrectly identify the driver as applicable and install the driver.

To reduce the potential impact of such errors, it is recommended that drivers be obtained from official sources whenever possible and any errors should be reported to the device manufacturer or vendor. Large packages of drivers (aka driver packs) have been found to often contain many errant and corrupt drivers that can cause problems. Additionally driver harvesting utilities often do not gather all the necessary information or files for a driver and can produce problematic drivers as well.

How to Troubleshoot Self-Electing PXE Services

LANDesk Targeted Multicast Service

The LANDesk Targeted Multicast Service (TMCSVC.exe) is responsible for all PXE Elections.  When a device is elected, the TMC Service running on that device will install both PXE services and will keep all PXE files up to date including boot.wim and netboot files.  It will check for updated files on the core according to the set polling frequency (15 minute default).  TMCSVC.exe uses multicast packets to poll it's subnet.  These packets do not need to leave the subnet so it is usually not necessary to allow multicast traffic on your routers, but any local firewalls, endpoint security or similar products must allow multicast.

PXE Rep Scoring

When determining which device will be elected as the PXE rep, a scoring process takes place.  This is an automatic process that happens in the background.  However, you can influence the score of individual machines by modifying this registry key:

HKLM|SOFTWARE|Wow6432Node|LANDesk|ManagementSuite|WinClient|CSEP

The keys are not there by default so create any missing keys.

Set the PXE_SVC_SCORE dword to a numerical value.  Configuring this reg key will set the starting point used to calculate the score of the device for the PXE Rep election.

The higher you set this value the more likely the device will be elected as the PXE Rep.  A value of 25 is usually sufficient, and 100 will essentially lock that machine in as the PXE Rep.

When is this useful?

PXE Service is giving "Subnet Error"

Reference PXE Service is giving "Subnet Error"

PXE Service is "Crippled"

If the CSEP registry key specified above also contains a "PXE_SVC_CripReason" string, this indicates the PXE Service has determined that it is 'crippled' and is informing CSEP that it cannot act as the PXE Rep.  Common causes for this crippled state would be failure to download the boot.wim or netboot files.

To solve this issue, troubleshoot the failure indicated in the dword.

Multiple NICs or WiFi-only Devices

A device with more than one NIC or a device with only WiFi will not be elected as PXE Rep, even if it scores higher than other devices.

Other Common Issues

• Device is elected, but PXE services will not run?
  • Make sure the Certificate for this device is approved.  Devices without an approved cert may still be elected, but the services will be prevented from running.
    • Pre-SU2 there is no warning or logging about this condition so it is vital to check Client Access on the core and approve certs:
      
    • After SU2 is applied, you will see a message indicating the elected device does not have an approved certificate in Self-Electing PXE Services.  Devices in this condition will be allowed to function as a PXE Rep for one hour.  After the hour expires, a new PXE rep will be elected.

Relevant Log Files

Tmcsvc.log

• C:\ProgramData\LANDesk\Log\tmcsvc.log
• The Targeted Multicast Service on the client handles all elections
• When a device is elected for the first time TMCSVC installs the LANDesk PXE Service and LANDesk PXE MTFTP Service
  
  These services will remain installed, but inactive, if the PXE election changes
• TMCSVC is responsible for starting and stopping the services whenever elections take place

Note: Restarting the LANDesk Targeted Multicast Service on the PXE rep will cause the rep to go through the election process.

SelfElectController.log

• C:\ProgramData\LANDesk\Log\SelfElectController.log
• This log contains more information on elected devices

PXEsvc.log

• C:\ProgramData\LANDesk\Log\pxesvc.log
• Enumerates the PXE Service install process, Boot.wim and Mac NBI download process and communication with the core server

Note: Restarting the LANDesk PXE Service on the PXE rep will cause the rep to attempt to download the boot wim and NBI files.

Pxemtftp.log

• This is not used during the election process but enumerates the file transfer of the boot.wim and NBI files to clients as they perform a network boot.

Issue:

While building the HII database, the following error pops up:

"Processing drivers for HII failed.  Error "Index was outside the bounds of the array."

Cause:

Microsoft changed the format for INF files.

Solution:

Download and install 2016.3 SU3 (See note below) by referring to the following document: LANDESK Management and Security 2016.x and newer Sustaining Patch Information

• Description
• What to Expect from Conditionals
• Adding Conditionals to a Template
• Utilizing Conditionals in conjunction with Public Variables

Description

This document is intended to cover the newly added feature of Conditionals in LANDESK Provisioning. Conditionals are best used to consolidate templates, allowing flexibility for:

• Multiple Images
• Software Distribution
• Disk Configuration
• Hardware Types
• BIOS Architecture

What to Expect from Conditionals

• Conditionals in LANDESK provisioning use "If and Else" arguments to determine multiple outcomes for a template.
• Stacking of multiple "if" conditionals is allowed. LANDESK will address all "if" conditionals one at a time.
• "Else" conditionals will only apply to the "if" conditional directly preceding it.
• Conditionals can be used at any point in the provisioning template, in any section.
• Custom scripts can be used in conjunction with Conditionals.
  • A successful script (return 0) will result in an "if" conditional being executed.
  • A non-successful script (not return 0) will result in LANDESK skipping past the associated conditional, or moving on to a corresponding "else" conditional.

Adding Conditionals to a Template

In this case, a default Deploy Template will be customized using Conditionals. To create such a template, browse to Tools>Provisioning. In the Operating System Provisioning tool, clickNew Template>Deploy Template.

Fill out the required fields and clickCreate.Should look something like this:

Right Clickany of the actions, and selectAdd Condition> If or Else

Utilizing Conditionals in conjunction with Public Variables

In LANDESK 2016, a new action type was introduced called Compare Variable. This action is extremely useful when using conditionals in provisioning. The following is an example of where to use this new feature:

We have an Image for Laptops and an Image for Desktops. How do we utilize both images in one Template?

This scenario will use the same template created above. The first step in using conditionals is to find a characteristic that LANDESK can use to differentiate between devices. LANDESK Inventory yields a different value for Desktops and Laptops.

For this example, we have "Chassis Type" recorded as NoteBook and Mini Tower. These values can be used as conditional arguments using Public Variables.

To add "Chassis Type" to public variables, open the Operating System Provisioning tool and select theTools drop-down list from the toolbar. Then select Public Variables.

Select Add. Enter any Search Value that seems fitting - needs to be one word. The Type will be set to "Database value." The replacement value will be set to the entry in inventory; "Computer"."System"."Chassis Type"

SelectOK.

Open the properties of the base template created above and right click the OS installation section from the Action List. Select Add Condition> If.

Right click the newly created condition and select Add Action. Select Compare Variable in the "Type" drop-down list. Select the variable created above in the "Variable" drop-down list and enter Mini Tower in the blank space. Click Apply.

Right Click OS installation once more and select Add Action. Select Deploy Image from the drop-down list, name the action appropriately, and click OK. Fill out the action properties to deploy the desktop image.

Now do the same with the Notebook image, only this time use an Else conditional. It should look something like this:

Description

This document is intended to show the versions of WinPE used in each version of LANDESK Management Suite. The goal is to facilitate getting the correct drivers for the WinPE version being used.  Note, these drivers refer to drivers such as Storage or Network Card drivers in order for the Windows PE (Windows Pre-Execution) environment to be able to see the hard disk and access network resources.   This is not related to the drivers that will be on the target operating system if booting into Windows PE for imaging a final OS is an objective.

Ivanti Endpoint Manager 2018.1

• EPM 2018.1 uses WinPE 10.0.15063.x and requires Windows 10 drivers

Ivanti Endpoint Manager 2017.3

• EPM 2017.3 uses WinPE 10.0.15063.x and requires Windows 10 drivers

Ivanti Endpoint Manager 2017.1

• EPM 2017.1 uses WinPE 10.0.10240.x and requires Windows 10 drivers

LANDESK Management Suite 2016.3

• LDMS 2016 uses WinPE 10.0.10240.x and requires Windows 10 drivers

LANDESK Management Suite 2016

• LDMS 2016 uses WinPE 10.0.10240.x and requires Windows 10 drivers

LANDESK Management Suite 9.6 SP3

• LDMS 9.6 SP3 uses WinPE 5.0, requiring Windows 8.1 drivers, the same as LDMS 9.6 SP2

LANDESK Management Suite 9.6 SP2

• LDMS 9.6 SP2 uses WinPE 5.0, requiring Windows 8.1 drivers, the same as LDMS 9.5 SP3

Determining your WinPE version

If you upgrade your LDMS version or apply a service pack, your WinPE version will be updated as well.  The WinPE image in contained in the boot.wim and boot_x64.wim files on your core and on your PXE reps.  If you upgrade your LDMS version but do not redeploy your PXE reps they will have an older WinPE version.  If you are unsure which version is running within WinPE you can open a console and type "ver".  This will return the version in x.x.xx format.  Match this up to the WinPE version using this chart:

Note: WinPE 10 and Windows 10 share the same version number as part of Microsofts "One Windows" policy.   It is included in Windows ADK (Windows KITS 10)

To find out exactly what PE version you are on, from within a Command Prompt in Windows PE you can look at the following registry key: HKLM\Software\Microsoft\Windows NT\CurrentVersion\WinPE

The following Microsoft document describes what NDIS driver versions are required for each OS:

NDIS Versions in Network Drivers (Windows Drivers)

Issue

The following error occurs when booting into Windows PE:

WinPE boot error "resolving core server name (%mycoreserver%)........"

Cause

• This normally occurs when the ALL.REG file within the BOOT.WIM does not contain the Core Server name or it needs to be changed to FQDN.
• If CORENAME.TXT and ALL.REG get modified manually and a later patch, service pack, or upgrade updates the boot.wim or boot_x64.wim, the CORENAME.TXT and ALL.REG will need to be updated again.

Resolution

The following steps will be taken on the core server:

• Mount the .WIM files that are used to create the Windows PE boot environment
• Modify the CORENAME.TXT and ALL.REG files that are used to specify the core server name for Windows PE
• Commit the changes made to the .WIM files so that the boot.wim and boot_x64 .WIM files contain the changes made
• Update the PXE Representatives with the newly changed .WIM files

These steps follow:

1. Create a new directory you will eventually mount your 32-bit .WIM file to.   Example: C:\bootwim
2. Create a new directory you will eventually mount your 64-bit. WIM file to.   Example: C:\boot_x64wim)
3. From a command prompt change to the \Program Files (x86)\LANDESK\ManagementSuite\LANDESK\vboot directory.
4. Type the following command to mount the Boot.wim file:
   
   
   This will mount the 32-bit boot.wim file that contains the 32-bit Windows PE environment used with computers booting to a Legacy 32-bit bios.  This means it will open upthe .wim image file and allow access to it through a directory.

   dism /mount-wim /wimfile:boot.wim /index:1 /mountdir:c:\bootwim

5. Type the following command to mount the boot_x64.wim file:
   
   
   This will mount  the 64-bit boot_x64.wim file that contains the 64-bit Windows PE environment used with computers booting to a UEFI bios.  

   dism /mount-wim /wimfile:boot_x64.wim /index:1 /mountdir:c:\boot_x64wim

6. Change to the Temp subdirectory under C:\bootwim\ you created in Step 1.
7. Save your changes to the CORENAME.TXT file.
   

   CORENAME.TXT will simply contain one line with the name of the core server.   This can be changed to FQDN or IP address to suit the needs of your environment.

8. Change to the WINDOWS\SYSTEM32  subdirectory under c:\bootwim and edit the file ALL.REG in Notepad or another text editor.
9. Modify the line that says "CoreServer"="[Corename]" and change the core name to FQDN or IP address as suits your needs.
10. Save your changes to the ALL.reg file.
11. Copy the cert from the server (ex:6d7g84c9.0) from the server directory (C:\Program Files (x86)\LANDESK\Shared files\cbaroot\certs) to your offline boot.wim diretory (%offlinefolder%\cba8\cbaroot\certs\) be sure to delete the old cert. Note: This step ensures you don't receive mapped drive failures within Provisioning.
12. Repeat steps 6-9 for the boot_x64.wim
    
    Now it is necessary to commit the changes made in the C:\bootwim and C:\boot_x64wim directories to save them into the .WIM files.  This is done by using the DISM (Deployment Image Servicing and Management) tool with the switch "/commit-wim" to save the changes to the images we mounted in steps 4 and 5. IMPORTANT: It is absolutely necessary to close all Explorer windows related to the bootwim mount directory before running the unmount commands. Failure to do so will cause your commit to fail due to files still being in use.
    
    
13. Type the following command to unmount the boot.wim and commit (save) the changes:
    

    dism /unmount-wim /mountdir:c:\bootwim /commit
    This will commit (or save) the changes to the boot.wim made in modifying the CORENAME.TXT and ALL.REG.

14. Type the following command to unmount the boot_x64.wim and commit (save) the changes:
    

    dism /unmount-wim /mountdir:c:\boot_x64wim /commit
    This will commit (or save) the changes to the boot_x64.wim made in modifying the CORENAME.TXT and ALL.REG

15. At this point, it is necessary to re-deploy the PXE representatives, as the .WIM files reside on the PXE Representatives.  When the targeted devices do a network boot they are directed to their PXE representative for their subnet and download the associated .WIM file that will then be their Windows PE environment.  The following steps detail this.
16. In the LANDESK Management Suite console, go to the Distribution tool group and then go to the OS Deployment tool.
17. From the OS Deployment tool expand the "All Other Scripts" section.
18. Right-click "PXE Representative Deployment" and select "Schedule".
19. The "Scheduled Tasks" tool should open and the newly created task should be highlighted.
20. Add the PXE representatives to the task and start the task.
    
    Note: If you already have a PXE Representative Deployment task created, you can just re-use that one to re-push the PXE representative.
    
    

    If the BOOT.WIM and BOOT_X64.WIM files were updated by a patch, service pack or upgrade, these steps will need to be done again.

    
    
    
    

HII Driver Management

Hardware-Independent Imaging is a vital part of a successful imaging process. Additional features have been added to provide control and flexibility to the drivers being deployed to devices. The ability to disable drivers, assign drivers to specific hardware, and assign setup drivers has been added. It is not required to assign drivers, auto detection and assignment of drivers will still occur for devices that do not have a specifically assigned driver. The HII driver library should be rebuilt after applying Service Pack 1 to update the HII driver client database (drivers.db3).

The HII driver management has been moved from an icon on the Operating system deployment toolbar and is now a a tool in the Distribution Toolbox

Disable Drivers

After building the HII library you may notice that some drivers automatically have new entries under disabled. The drivers were disabled for the generic matches included in the inf file that would have matched hardware the driver was not designed for. Reviewing these entries will show device IDs beginning with *PNP, indicating the driver could match a number of plug-and-play devices. If the driver is needed for a device in the environment, the entry can simply be removed from the disabled list.

When adding a driver to the disabled list, the driver library folder structure will be shown. Locate and select the inf file for the driver to be disabled. After selecting the driver the list of available OS and architecture will auto populate with the versions found inside the inf you selected. Set the desired OS and architecture to list the available device IDs for the selected driver. Check the disabled box for the device ID to disable and click update to disable the driver. Select any other OS and architecture combinations and disable as needed. When complete click update and close.

Assign Drivers

Assigning drivers will be matched on the make, model, OS and architecture of a device. The inventory scan now includes hardware IDs for use in HII driver management. When a driver is being assigned the hardware listing will only be shown if a devices has returned an inventory scan from an Service Pack 1 agent that matches make, model, OS and architecture.

In this example Windows 7 is selected, however on the core server there are no devices on Windows 7 for that make and model so the device tree is blank.

A device running Windows 8 for that make and model does exist, so when selected the device tree is shown.

Assign Driver .inf file

After selecting the desired option in each of the drop-downs, locate and select the device that will be assigned a driver from the device tree. The option populate by selected device ID can be used to auto fill the search box.

Searches can be made more generic by searching for just the vendor id and device id. Other Device IDs that would apply can be viewed on the device if no driver is found.

Check the appropriate driver to assign it to the selected device. Once assigned the text for the device will turn green to indicate an assigned driver. To remove the assignment, select the device and click the red x next to the assigned driver.

Assign Driver Package

Devices requiring a setup package can also be assigned. Selecting the radio button driver package and select the appropriate software distribution package for that device. In the provisioning template add an HII action in the system configuration section to install the setup packages.

Managing Assigned and Disabled Drivers

Assigned and/or disabled items are visible in the console. Those entries can be edited and removed by selecting the item and the selecting edit or remove.

Issue

CTOS action is failing in the provisioning template.

The image is sysprepped.
The following error is in the C:\Windows\Temp\ConfigureTargetHandler.log file:

ConfigTargetOSHandler.exe:Could not stat dir :\ldprovisioning error 2

Cause

Inject Script action is not injecting UNATTEND.XML in the Target File Name field which caused CTOS to not find any unattend.xml files.

Solution

Change the Target File Name field of the Inject Script action to inject UNATTEND.XML for the file name.

If not using an Inject Unattend script action, add one to the template and ensure it injects the file as Unattend.xml.

Problem:

OS Deployment template actions are failing.  To determine the cause of the failures it's helpful to take a look at the log files, but WinPE is loaded onto a RAM drive and the logs disappear when the device reboots.  If you log a support case, LANDesk will ask you for these logs.

Solution:

When you start a provisioning template, the computer boots into WinPE and will stay in WinPE until you get to the Configure Target OS action.  After CTOS, the computer reboots and all logs and files generated in WinPE are lost.  We need to pause the process prior to the CTOS action.  Edit your template and insert a wait action just prior to CTOS.  Specify a wait time in seconds.  Usually 600 seconds (5 minutes) is sufficient.  In LDMS 9.6+, you can continue from the wait action early if you desire.  In LDMS 9.5 you will need to wait out the entire timer, so choose your duration accordingly.

Run your template again, and view the computer you are provisioning.  If it's a remote computer you can use LANDesk Remote Control to view the WinPE environment.  This document shows you how:

Use LANDesk remote control to view a computer in WinPE provisioning

Next we will open a console window to locate and copy the logs to a remote computer:

1. Click the green icon on the bottom left and select New Console
2. Type cd\
3. Type cd ldprovision
4. Type dir *.log to view the log files in this location.  This is the main log location for provisioning within WinPE
5. If you would like to view these logs within WinPE, type "notepad nameoflog.log"
6. We need to map a network drive to copy the files to a shared folder on a remote computer.  Do so using the NET USE command:   

   Use the Net Use command to map or disconnect a drive

7. Copy the files to the drive letter you just mapped.  We will assume you mapped the E drive to your remote computer.  The command is:
   

   xcopy *.log E:

8. You can now access these logs from the remote computer which you mapped as the E: drive.  If you are working with LANDesk support, email these logs to your support representative or attach them to your case.

Troubleshooting OS Provisioning using the log files

Each OS Provisioning template action has a log file.  In addition, the overall template process has a log, called "ldprovision.log".  This should be your first stop.  Open the log file and scroll through.  You are looking for a section of the log similar to this:

2015-04-17 14:35:38(1404-1408) ldProvision_x64:********************************** Begin processing actions **********************************

This indicates the beginning of the template actions.  You will see the start of each action called out in the log similar to this:
   

2015-04-17 14:35:38(1404-1408) ldProvision_x64:*********  Begin an action - Map_toPreferred

You will also see that each action has it's own action handler.  You will see the ldprovision.exe action handler calling additional handlers, similar to this:

     2015-04-17 14:35:39(1404-1408) ldProvision_x64:Launching action handler [MaptoPreferredHandler_x64.exe] with parameters ["]

     2015-04-17 14:35:39(1404-1408) ldProvision_x64:handler launched.

At the end of each action you will see an indication of success or failure, and then the next action starts.  Keep in mind that some actions show failed but do not affect the success of the entire template.  For example the vboot action, or in some cases HII may show failed but the template can continue and ultimately succeed.  Locate the failed action that you are troubleshooting.  Each action handler has it's own log file, so next pull up the log for the specific action handler that failed.  If the name of the handler is "myactionhandler.exe" the log file will be "myactionhandler.log".   If you have difficulty identifying the failed action, press CTR+F to open the Find box, and search for "failed".

The log file specific to the action which failed will give you greater detail into the cause of the failure.  You will also see a failure error code.  Sometimes these codes can be very generic, other times they are quite specific.  Search the LANDesk community for your failure reason and error codes and you should find discussions and documents that help you resolve the failure.  If you are not able to determine the cause of the failure, log a support case with LANDesk and provide the log files to your support rep.

Purpose

This article outlines how to verify if a driver should be matched to a device. This goes beyond just running HII Preview.

What is considered a 'Match' to HII?

The following items must have an exact match for a driver to naturally be selected as a match by HII:

• OS
• Architecture
• Hardware ID

Note: The term 'natural' in this document is used to imply no Driver Assignment.

Items Needed

• HIIPreview.log- from Client
• drivers.db3- From Core
• Name and path info of *.inf file to be compared - From HII Library
  • Example: ..\Dell Optiplex\Win8.1\x64\Network\ewgnss.inf

Get Info From HIIPreview

The HIIPreview.log will list the computers OS, Architecture, and all Devices that were reported by the computer, and all Hardware ID's each device responded with.

You will need the OS and Architecture listed:

Example:

Running preview for OS 6.3 Workstation AMD64: Windows 8.1 64-bit

You will also need the Device's hardware id's that you are investigating:

Example:

Hardware device discovered.  Device number 5:

Device name: PCI Express standard Root Port

    Primary device ID:    PCI\VEN_15AD&DEV_07A0&SUBSYS_07A015AD&REV_01

    Additional device ID:    PCI\VEN_15AD&DEV_07A0&SUBSYS_07A015AD

    Additional device ID:    PCI\VEN_15AD&DEV_07A0&CC_060400

    Additional device ID:    PCI\VEN_15AD&DEV_07A0&CC_0604

    Additional device ID:    PCI\VEN_15AD&DEV_07A0&REV_01

    Additional device ID:    PCI\VEN_15AD&DEV_07A0

    Additional device ID:    PCI\VEN_15AD&CC_060400

    Additional device ID:    PCI\VEN_15AD&CC_0604

    Additional device ID:    PCI\VEN_15AD

    Additional device ID:    PCI\CC_060400&DT_4

    Additional device ID:    PCI\CC_060400

    Additional device ID:    PCI\CC_0604&DT_4

    Additional device ID:    PCI\CC_0604

Get Details to Query

Since the OS, Architecture, and Hardware ID must have an exact match for natural driver matching to occur, we need to obtain information to build our query.

Note: Tool used in examples is sqlitebrowser (https://github.com/sqlitebrowser/sqlitebrowser)

Get OS_IDN

In the HIIPreview.log, there is a line about the OS version:

Running preview for OS 6.3 Workstation AMD64: Windows 8.1 64-bit

Looking up that OS in the OS table of the drivers.db3 we see the OS_idn = 7

SELECT *
FROM OS

Note: The architecture listed in the OS table is not important. Even though it shows Win8_1x86, this OS still applies to our example machine that is Windows 8.1 x64. Architecture is handled by its own table.

Get Arch_idn

In the HIIPreview.log, there is a line about the OS version:

Running preview for OS 6.3 Workstation AMD64: Windows 8.1 64-bit

There are 3 possible Architectures:

• 1 = Both
• 2 = x86
• 3 = x64

Since our example shows AMD64, Arch_idn = 3.

If an entry in the drivers.db3 is listed as Arch_idn = 1 (both) it is applicable for both x86 and x64 OS's. Because of this, we'll Include Arch_idn = 1 as in our query as well.

For our example - Arch_idn = 3 OR Arch_idn = 1

Get InfFiles_IDN

• Run the following query using the drivers file name to find the InfFiles_IDN

SELECT *
FROM inffiles
WHERE FileName LIKE '%driver_name%';

• Locate the InfFiles_IDN listed for the driver - this will be used in the next query
  • There may be multiple instances of the drivers name, so use the File Path to validate which one you're dealing with.

In our example, we're dealing with this file: ..\Dell Optiplex\Win8.1\x64\Network\ewgnss.inf

For our example - InfFiles_IDN = 2.

Query for Matching Hardware IDs

Verify you have the following to build your query to search for matching Hardware IDs.

• InfFiles_idn
• OS_idn
• Arch_idn
• Hardware IDs from HIIPreview.log

Select *
From Devices
Where InfFiles_idn = 'Your infFiles_idn'
AND OS_idn = 'Your OS_idn'
AND (Arch_idn = 'Your Arch_idn' OR Arch_idn = '1')
AND Device = 'Hardware id from HIIPreview'

Example:

Select *
From Devices
Where InfFiles_idn = '2'
AND OS_idn = '7'
AND (Arch_idn = '3' OR Arch_idn = '1')
AND Device = 'PCI\VEN_15AD&DEV_07A0&SUBSYS_07A015AD&REV_01'

If no results are found, try the next Hardware ID from the HII Preview.

If a match is found with the query, it should be considered a natural match for HII.

If no matches are found for any of the Hardware IDs, this is an indicator that HII would not currently naturally select this driver to pair to the device during HII.

Driver Assignments will take priority to Natural Selection in this instance, but if no driver assignments are present, HII would not match the selected driver (InfFiles_idn) to the Device (selected from HIIPreview.log)

Purpose

This article will walk through resolving the issue of BSOD after provisioning when a NVMe SSD is installed on the target device.

Problem

Getting error "Windows failed to start" after reboot from provisioning.

Cause

NVMe hard drive not supported in Windows 7

- This has been found on Dell E7470's and other models using NVM Express drives.

- This has been found on Dell E7040's and other models using NVM Express drives.

Solution

Install patch from Microsoft on image before capturing image, when deploying image, you will no longer receive error.

MS Patch (https://support.microsoft.com/en-us/help/2990941/update-to-add-native-driver-support-in-nvm-express-in-windows-7-and-win…)

NVM Express in Windows 7 and Windows Server 2008 R2

Note:If Windows is not fully updated you may still see the blue screen. We always recommend keeping your images as updated as possible but if not you will need at least the following update to correct this issue.

- https://support.microsoft.com/en-us/help/2685811/kernel-mode-driver-framework-version-1-11-update-for-windows-vista--wi