We use a diskpart script to configure the hard drives in Dell Latitudes (7280 or 7480) for imaging them to Windows 10. This has worked flawlessly on most, if not all, of our Dell laptops.

This is the script:

select disk=0

clean

convert gpt

create partition efi size=500

format fs=fat32 quick label=System

assign letter=S

create partition msr size=128

create partition primary

format fs=ntfs quick label=Windows

assign letter=C

Now all of a sudden, I see this error :

Virtual Disk Service Error

The specified drive letter is not free to be assigned.

It appears the issue may be happening on just one of the Dell 7480 laptop. Other machines I just imaged

Has anybody seen this error when provisioning a Dell laptop to Windows 10?

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

I am running 2016 SP3.

New computer out of the box. Set it up and captured image.

During deployment it deploys image then fails next step Auto Assign Partitions, then Fails Inject unattend, then Ctos.

Never had one fail this before.

Ran Provisioning again but put a wait state after image deploy and after Auto Assign partitions. After deploy image I went in to a command prompt and attempted to do a C:

I got a message about bitlocker. I did not turn on bitlocker before capturing image.

Since the image was layed down on the hard drive I booted to the hard drive (Windows 10 Pro ver 1709) Went into control panel - bitlocker and it says awaiting to turn bitlocker on with a caution sign. Below it says Bitlocker off. In Computer Management C drive says bitlocker.

Any thoughts on how this is happening?

• 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

I am running 2016 SP3.

New computer out of the box. Set it up and captured image.

During deployment it deploys image then fails next step Auto Assign Partitions, then Fails Inject unattend, then Ctos.

Never had one fail this before.

Ran Provisioning again but put a wait state after image deploy and after Auto Assign partitions. After deploy image I went in to a command prompt and attempted to do a C:

I got a message about bitlocker. I did not turn on bitlocker before capturing image.

Since the image was layed down on the hard drive I booted to the hard drive (Windows 10 Pro ver 1709) Went into control panel - bitlocker and it says awaiting to turn bitlocker on with a caution sign. Below it says Bitlocker off. In Computer Management C drive says bitlocker.

Any thoughts on how this is happening?

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.

Hi everybody,

I got a very strange error aftger updating to 2018.1

My proovisioning template stuck after rebooting (see printscreen).

Has somebody any idea what i could be?

Befor (on 2017.1) it works fine.

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.

I started with the provisioning and unattend templates  with the Deploying Windows 7 best known methods article.   I had to do some tweaks to get it to actually deploy the image to my machine but now it deploys and labels the drives properly.  Now  however I am getting an error during the inject script section of the template. in the status it gives me the error [80001501H] The web service responded with an invalid call"  

If I look at the inject script action in the provision history, I have the internal value result code of : -2147478271

If I look in the ldprovision log file from the client I get the following....

2013-06-18 21:32:57(1064-1024) ldProvision:*********  Begin an action - Inject_script

2013-06-18 21:32:58(1064-1024) ldProvision:Do EnvironmentCheck

2013-06-18 21:32:58(1064-1024) ldProvision:Is WinPE Action=1, Is WinPe Environment=1

2013-06-18 21:32:58(1064-1024) ldProvision:Session Data: <variables/>

2013-06-18 21:32:58(1064-1024) ldProvision:Create process (x:\cba8\httpclient.exe) with args (  -f "X:\ldprovision\InjectScriptHandler.exe" http://myserver/LdLogon/Provisioning/windows/InjectScriptHandler.exe)

2013-06-18 21:32:58(1064-1024) ldProvision:Process exit code:0

2013-06-18 21:32:58(1064-1024) ldProvision:The file (X:\ldprovision\InjectScriptHandler.exe) was successfully downloaded

2013-06-18 21:32:58(1064-1024) ldProvision:Download handler ok.

2013-06-18 21:32:58(1064-1024) ldProvision:Launching action handler [InjectScriptHandler.exe] with parameters ["]

2013-06-18 21:32:58(1064-1024) ldProvision:handler launched.

2013-06-18 21:32:58(1064-1024) ldProvision:Reporting action status: 5 to core

2013-06-18 21:32:58(1064-1024) ldProvision:Call web service GetStatusString()

2013-06-18 21:32:58(1064-1024) ldProvision:Start TryallWebService Attempt:0.

2013-06-18 21:32:58(1064-1024) ldProvision:End TryallWebService Attempt:0. ExitCode:0

2013-06-18 21:32:58(1064-1024) ldProvision:StatusString = The Web service responded with an invalid call.

2013-06-18 21:32:58(1064-1024) ldProvision:Call web service SetActionStatus()

2013-06-18 21:32:58(1064-1024) ldProvision:Start TryallWebService Attempt:0.

2013-06-18 21:33:02(1064-1024) ldProvision:End TryallWebService Attempt:0. ExitCode:0

2013-06-18 21:33:02(1064-1024) ldProvision:End of action - Inject_script

2013-06-18 21:33:02(1064-1024) ldProvision:Last action failed

2013-06-18 21:33:02(1064-1024) ldProvision:**********************************  End processing actions  **********************************

The injectscripthandler.exe log is below..

2013-06-13 18:07:28(1072-1044) InjectScriptHandler.exe:CreateHeaderFile - X:\ldprovision\setupinstall.header.txt

2013-06-13 18:07:28(1072-1044) InjectScriptHandler.exe:CreateBodyFile - X:\ldprovision\setupinstall.body.txt

2013-06-13 18:07:28(1072-1044) InjectScriptHandler.exe:Args = -V -H"X:\ldprovision\setupinstall.header.txt" -o"X:\ldprovision\setupinstall.body.txt" -f"X:\ldprovision\setupinstall.result.xml" http:/myserver/landesk/managementsuite/core/ProvisioningWebService/WebService.asmx

2013-06-13 18:07:28(1072-1044) InjectScriptHandler.exe:going to call x:\cba8\httpclient.exe -V -H"X:\ldprovision\setupinstall.header.txt" -o"X:\ldprovision\setupinstall.body.txt" -f"X:\ldprovision\setupinstall.result.xml" http://myserver/landesk/managementsuite/core/ProvisioningWebService/WebService.asmx

2013-06-13 18:07:28(1072-1044) InjectScriptHandler.exe:start Try httpclient No=0.

2013-06-13 18:07:28(1072-1044) InjectScriptHandler.exe:end Try httpclient No=0.exitCode=0

2013-06-13 18:07:28(1072-1044) InjectScriptHandler.exe:Exit Code of InstallCallHTTPClient = 0

2013-06-13 18:07:28(1072-1044) InjectScriptHandler.exe:FindElement returned 0, value is false

2013-06-13 18:07:28(1072-1044) InjectScriptHandler.exe:invalid result

2013-06-13 18:07:28(1072-1044) InjectScriptHandler.exe:FindElement returned 0

2013-06-13 18:07:28(1072-1044) InjectScriptHandler.exe:An internal error has occurred with the management product.

I can navigate to the path where webservice.asmx is located and seems to be fine there at least from a different computer in a web browser, and I have the drive mapped where the unattend file is located.

Any advise on where to check would be greatly appreciated..  I can't tell if it is something in IIS, or if there is somewhere else I have a file missing...  Any help would be appreciated.

Thanks

Chris

I am having problems PXE booting ESX VMs on 2017.3.  This morning I had VMs that would not provision, they could not get an IP address for the template.  I spent the morning working with various drivers and finally got that to work.  Then I went to reload a couple more VMs that happened to be on VM version 8.  Knowing that I have had previous lockup problems with Windows 10 on VM version 8, I opted to upgrade the hardware to currently available 11.  Now when I try to PXE that newly upgraded system, I cannot load the boot.sdi file.  It ends up crashing with the message that "A required device isn't connected or can't be accessed."  I went through all the postings about changing the TFTP block size, but unless it takes time for that change to replicate, those options didn't help.  At the moment, I am stuck in a pickle: Either stay on hardware version 8 which locks up machines randomly, or have machines that can't PXE.  Assistance is greatly appreciated.  Thanks.

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.

I have been searching for a way to turn on network discovery for all profiles during provisioning but I have yet to find a way,  information I can find is either old or has spotty results.  I have tried various methods in unattend.xml they are not working, and usually making things worse by keeping the agent from running after CTOS.  Does anyone know if there is a way to turn on file and print sharing during provisioning so that the OSD doesn't pop up asking for network visibility?  We have found that if someone isn't there to answer that, then file and print sharing remains off and provisioning fails. 

A teammate and myself have been trying to understand the difference between copying, cloning and making private copies of templates and template groups. We have multiple people collaborating on a 100+ Public action template group and need clear definitions of each. 

Our desired workflow : user A needs to make a change to Public development template group 1 (aka dev master) so they acquire a current copy of dev master for private use, make their changes in their own userspace, test and when done, update dev master (sounds very git-like :hint: :hint:)

So far I can only find vague definitions of each - I would **love** to have these cleared.

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

All right, so I am a member of 2 groups, Provisioning Development and my team. We keep our dev / testing templates in the Provisioning Development group, and the public templates that our techs use to deploy in Public. I have recently converted all public templates to locked templates.

Directory structure as such:

• Provisioning templates
  • My templates
  • Provisioning Development templates
    • Included Templates
    • Standalones
    • Windows 10
      • Win10x64 Enterprise CBB – SSC- Dev
      • Win10x64 Enterprise CBB – Standard- Dev
      • Win10x64 Enterprise LTSB – Production- Dev
    • Windows 7
    • Windows 8.1
    • All team templates
  • Public
    • Windows 10
      • Win10x64 Enterprise CBB – SSC
      • Win10x64 Enterprise CBB – Standard
      • Win10x64 Enterprise LTSB – Production
    • Windows 7
    • Windows 8.1
    • All public templates

Notice the difference between the names is the dev templates contain “- Dev” in the title.

So when I have to update a template, I create a locked version of the Dev template, delete the Public version out of Public → All public templates, and move the locked template over to Public → Windows 10.

However, when I attempt to rename the locked template to remove the “- Dev” out of the title, I get the error message:

I can find no reference to the template that supposedly already exists. Any ideas? Bug perhaps?

We have a vendor who builds our devices for us and has a Ivanti replication server in the warehouse connecting over a VPN back to our head office and core server.

Our vendor is able to build new devices with no issues at all, if they build a device that has been seen by Ivanti before it will never be offered a PXE offer.

We have checked our inventory for the MAC address of these devices, and they do not ever appear in the Network view.

We have also check we have selected under PXE boot options, Always PXE boot UEFI devices.

I believe the issue is related to Ghosting in the database, but do not know how to investigate this. My guess would be that the MAC address is stored somewhere in the Ivanti database, and cannot be viewed in the console.

We are using Ivanti Management console 2017.1

Our devices are all UEFI with secure boot with UEFI network stack enabled.

We do not experience this issue here in head office.

• 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.

• 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: