• 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

• Description
• Common errors and description
  • Error: "Access Denied"
  • Error: "CommonCore.inf: (0xFFFFFFFF) OSD.Upgrade.exe,60000"
  • Error: "DirectoryNotFoundException"
  • Error: "Non-fatal error: FilterUnload failed, hr=0x801f0013"
  • Error: "System.ComponentModel.Win32Exception"
  • Error: "System.IO.IOException: Element not found"
  • Error: "System.UnauthorizedAccessException"
  • Error: "WAIK is not installed"
  • Error: "CommonCore.inf: (0xFFFFFFFF) OSD.Upgrade.exe,90000"
  • Issue: Upgrade fails at HII step
• Preparing to Re-Run OSD.Upgrade.exe

Description

OSD.Upgrade.exe is run during the installation of an Ivanti EPM Service Pack or any Ivanti patch that updates the WinPE image (boot.wim). It is responsible for configuring the image to function on a specific Core Server and migrating WinPE drivers from the boot.wim.bak into the new boot.wim. If OSD.Upgrade.exe fails, one or more of these steps may not be completed. This document will walk through re-running the OSD.Upgrade.exe installation step on the core server.

During the Service Pack or patch installation, there may be a failure with the OSD.Upgrade.exe process. The install error may be similar to CommonCore.inf: (0xFFFFFFFF) OSD.Upgrade.exe,60000.  Review the osd.upgrade.exe log file found in C:\Program Files (x86)\LANDESK\ManagementSuite\log to get more specific information about the error. If desired the osd.upgrade.exe.log file can be renamed prior to running osd.upgrade.exe again to make current errors easier to find.

A common cause of this issue can be that one of the .WIM files is already mounted from a prior process or through manual intervention by an administrator.

Common errors and description

• Error: "Access Denied"
  

  • Errors referring to access denied indicates that a folder path in the boot.wim is too long. Often this path will be for a driver that was injected into the WinPE image. There are two option for correcting this error. The first option is to just start with a clean boot.wim and add the necessary drivers after completing the OSD.Upgrade.exe process. In LDMS 9 Service Pack 3 the WinPE boot environment requires Windows 7 32-bit drivers. Updating those drivers is a manual process so starting with a clean boot.wim may be a good option. The second option would be to mount the backup of the boot.wim (boot.wim.bak) and rename the directories in the InstalledDrivers directory to use shorter names. After completing one of these options follow the steps outlined below to re-run OSD.Upgrade.exe.
    
    

• Error: "CommonCore.inf: (0xFFFFFFFF) OSD.Upgrade.exe,60000"
  

  • This is a general error indication. Review the log for additional errors.
  • Check to make sure the boot.wim is not mounted on the Core server.
    • The way to check this is running "dism /get-MountedWiminfo" from command prompt. This will show if wim's are mounted and where.
    • Check the OSD.Upgrade.exe.log file for any missing files. Then give it those missing files in the path that it is looking for them.
      • example: "09/06/2016 10:22:53 INFO  9680:1     RollingLog : File C:\Program Files\LANDesk\ManagementSuite\\ldlogon\provisioning\windows\Microsoft.VC90.CRT.manifest does not exist"

• Error: "DirectoryNotFoundException"
  

  • Errors referring to a .0 or an mpkg package indicate that a .0 file has been extracted to a sub-folder of the ldlogon folder. DO NOT delete any .0 files from the root of ldlogon. Navigate to the directory specified in the log (i.e. C:\Program Files (x86)\LANDESK\ManagementSuite\ldlogon\mac) and delete the .0 file. To prevent additional errors when re-running OSD.Upgrade.exe delete any additional .0 files that are found in sub-folders of the ldlogon folder leaving only the .0 files in the root of ldlogon. Follow the steps below to re-run OSD.Upgrade.exe.
  • Errors referring an ALL.REG file indicate that the wim file was still mounted when osd.upgrade.exe tried to execute. This is most likely due to errors in the previous attempt at running OSD.Upgrade.exe. Review the log and correct and additional errors found before following the steps below to re-run OSD.Upgrade.exe.
    
    

• Error: "Non-fatal error: FilterUnload failed, hr=0x801f0013"
  

  • This is normal and does not indicate a problem. Continue reviewing the log file for additional errors.
    
    

• Error: "System.ComponentModel.Win32Exception"

  • You are running the process as a restricted user. Either log in as an administrative user or right click OSD.Upgrade.exe and select run as administrator.
    • Make sure that you are either logged directly into the core server or using Remote Desktop with a /admin switch as a full administrator.
      
      

• Error: "System.IO.IOException: Element not found"
  

  • This error indicates that there is still a wim file mounted. Review the log for additional errors prior to this error. Follow steps below to re-run the OSD.Upgrade.exe process.
    
    

• Error: "System.UnauthorizedAccessException"
  

  • This error indicates either that there is still a wim file mounted, or that the bootmedia.wim.bak already exists. Bootmedia.wim.bak can be deleted as long as bootmedia.wim exists. Review the log for additional errors and then follow the step below to re-run OSD.Upgrade.exe.
    
    

• Error: "WAIK is not installed"
  

  • This is normal and does not indicate a problem. WAIK should have been uninstalled prior to upgrade. If WAIK is installed, uninstall it. Continue reviewing the log file for additional errors.
    
    

• Error: "CommonCore.inf: (0xFFFFFFFF) OSD.Upgrade.exe,90000"
  

  • Download Streams from Microsoft (https://technet.microsoft.com/en-us/sysinternals/bb897440.aspx). Go into properties of Streams an unblock the application. Run Streams against the folder the Ivanti EPM installer was xtraced to and run Streams against the folder LANDESK is being installed to (ie, \Program Files\LANDESK). Make sure the Ivanit EPM installer is being run locally (not networked drive), you are upgrading the machine locally (not RDP) and run the installer as Administrator.
    

• Issue: Upgrade fails at HII step
  

  • Log will displayRollingLog : HII: Setting driver repository path to "\\LDCoreName\ldmain\landesk\files\drivers" 08/05/2015 12:03:10 INFO 8732:1 RollingLog : HII: Initial driver file count to process:
  • In the \\LDCoreName\ldmain\landesk\files\drivers directory will be a db3 and db3 bak file. Rename the file to db3.old and db3 bak.old. Quit out of the installer and re-open and start install again
    .

Preparing to Re-Run OSD.Upgrade.exe

After reviewing your errors and completing the steps above perform the following steps:

1. Start an administrator command prompt (right click the command prompt and select run as administrator).
2. From the command prompt navigate to C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot.
3. Run the following command:
   
   DISM.EXE /Get-MountedWimInfo
   
   • The command should list all images that are currently mounted. There are instances however where a mounted image will not be listed. Check for the existence of the folder original_boot_wim and/or new_boot_wim in the C:\Users\logged in user \AppData\Local\Temp\imgtmp\ directory.
     
     
4. For each image listed and all folders found in the imgtmp directory listed in step 1, run the following commands:
   
   
   • DISM.EXE /Unmount-Wim /mountdir:"c:\path to dir(s) found in previous step" /discard  Where mountdir is the mount path listed from the dism.exe /Get-MountedWimInfo command or the folders specified in step 3.
   • DISM.EXE /Cleanup-Wim
   • Ensure that each unmount command completes successfully
   • Any errors that DISM may encounter will be logged in the %windir%\Logs\DISM directory.  (For further information see Understanding Failures and Log Files)
5. In Windows Explorer open the C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot directory.
   
6. Rename the existing boot.wim to boot.wim.bad.
7. Copy the backup boot.wim (the one from prior to upgrading) from C:\Program Files (x86)\LANDesk\ManagementSuite\backup\PatchName\ to the C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot directory.
   • If access denied errors occurred with drivers and a clean boot.wim file is desired, use the file listed in step 9 below.
8. Rename the restored boot.wim file in the vboot directory to boot.wim.bak.
9. Copy the boot.wim file from the installation package \image directory to the \vboot directory. You should now have a boot.wim and boot.wim.bak (either your backup or an additional copy from the patch) file in the vboot directory.
10. Run the OSD.Upgrade.exe from C:\Program Files (x86)\LANDesk\ManagementSuite\. This should take a few minutes to complete. If it exits quickly it is likely that there are additional errors.
11. Review the OSD.Upgrade.exe log found in C:\Program Files (x86)\LANDesk\ManagementSuite\logs to see if any additional errors were encountered. If additional errors were encountered, you must resolve each one and after resolving re-run OSD.Upgrade.exe.
12. If this still does not resolve the issue check "HKLM\SOFTWARE\Microsoft\WIMMount\Mounted Images" and remove any values in the key.

After OSD.Upgrade.exe has completed successfully you need to redeploy your PXE reps. Instructions for PXE deployment can be found at How to deploy PXE Representatives(step-by-step screenshots)

When a client machine boots into WinPE open a console to confirm the upgrade. The version shown in the console should be 6.1.7601 or higher.

OSD.Upgrade.exe.log

Issue

The WinPE wallpaper can be changed to allow for branding or customization.

Resolution

The WinPE wallpaper can be modified using the following steps:

1. From the Ivanti Endpoint Manager Console to Tools > OS Provisioning
2. From the Preboot drop-down select the icon Change WinPE Wallpaper
   
   
3. Browse to the bitmap file that will be used as the wallpaper.
4. Check the boxes (32-bit and/or 64-bit) to specify the image file(s) that the wallpaper will be changed in.
5. Click Ok

• Description
  • Core Logs
  • Client Logs
  • Steps to disable removal of the client provisioning folder
  • Understanding Action Handler Flow (Client)
  • Action Handler Logs
    • Related Video: How to Troubleshoot Provisioning Template Actions

Description

This document is intended to explain provisioning action handlers so that failures seen in individual actions within a provisioning template can quickly be found and corrected.

Core Logs

Logs on the core will help with why a task is not starting, but do not provide a lot of detail about why a certain action failed.

The following are the core logs:

• %LDMS_HOME%\log\prov_schedule.exe.log
• %LDMS_HOME%\log\provisioning\provisioning.log

Client Logs

Device logs can be found in the following locations on the client:

• x:\ldprovision
• systemdrive:\windows\temp

Steps to disable removal of the client provisioning folder

1. Right-click desired provisioning template and go to "Properties".

2. In the left-hand pane, select "Options" and uncheck the box next to "Remove Client Provisioning folder".

Understanding Action Handler Flow (Client)

Each action that is run in a provisioning template is done by an action handler. An action handler may launch multiple other action handlers as part of its task. These other tasks could be considered to be child actions. The deploy image action in 9.5 and higher is an example of this. The Deploy Image action hander may automatically download the appropriate tool for imaging using a Download Action handler. The Deploy Image action then maps a drive to the network location where the image file is using the Map to Preferred Server action handler. Finally it will complete its own job of deploying the image using itself. The launch of each of the additional action handler used by deploy image will be logged in the DeployImageHandler.log along with the result code from the additional handler.

This sample DeployImageHandler.log shows the launch of two additional action handlers (DownloadHandler.exe and maptopreferredhandler.exe) as well as the exit codes for those handlers.

ExecuteCmd DownloadHandler.exe /source="http://mycore/ldlogon/provisioning/windows/imagew.exe" /dest="x:\ldprovision\imagew.exe"

created process, file handle 60 with non-readonly parameter

Process Exit Code: 0

Verifying file was successfully downloaded.

The file (x:\ldprovision\imagew.exe) was successfully downloaded

Getting free drive letter

Free drive letter: f

ExecuteCmd maptopreferredhandler.exe /path="\\mycore\images\win7.tbi" /driveletter=f /pathisfile

created process, file handle 68 with non-readonly parameter

Process Exit Code: 0

 

If a failure occurred in either of the additional actions (DownloadHandler and maptopreferredhandler) launched by deployimage the errors would be shown in the DeployImageHandler.log with a corresponding exit code. Zero indicates the task succeeded. If a failure occurred the DeployImageHandler.log may not contain enough detail to determine the root cause of the failure. Instead the log from the additional action handler (DownloadHandler.log or maptopreferredhandler.log) should be reviewed. The additional action handler may even launch its own child handlers before returning so those logs may also need to be reviewed.

If the failure seen in the DeployImageHandler.log was an error mapping the drive to the image, the MaptoPreferredHandler.log would provide additional details about the failure. Sometimes the error will be spelled out. Other times only an error code will be shown. The error codes shown will often correspond to the windows error codes listed at http://msdn.microsoft.com/en-us/library/windows/desktop/ms681381(v=vs.85).aspx. This allows a simple lookup to get additional information about the failure. Viewing the primary action handler log and following the failure through to the action handler log where the failure actually occurred will save time and frustration while troubleshooting provisioning templates.

Action Handler Logs

Related Video: How to Troubleshoot Provisioning Template Actions

Issue

• Booting a machine in UEFI mode in a network segment with an active PXE representative doesn't make the machine load WinPE.
• The PXE menu doesn't appear.
• The machine reports the error PXE-E21: Remote boot canceled

Solution

1. This can be caused by having duplicate MAC addresses listed in the inventory.   These can be found by creating a custom Column Set for the All Devices view and sorted by MAC Address.
2. UEFI is still not compliant with the PXE menu specifications, therefore booting a machine in UEFI mode via PXE for provisioning works only when the device is associated to a provisioning task on the core.

The error PXE-E21 appears when the device is not associated with a provisioning task on the core.

Ivanti submitted an enhancement request to the UEFI Forum regarding this issue. Once they add the support needed, Ivanti will be able to support the PXE menu for the devices booting in UEFI mode as well.

At the moment, the only way to have the PXE menu functionality on a device booting in UEFI mode is setting it up to boot in Legacy BIOS mode.

Issue

After enabling FIPS on the core server, Provisioning templates stop working.

If you select a Provisioning template to execute, it will attempt to run but will fail with error 80001803H

Cause

This issue occurs after enabling FIPS 140-2 on a core server. When FIPS 140-2 is enabled, a new SHA1 cert is generated on the core and replaces the old MD5 core cert.

The WINPE image does not get updated automatically with the new cert and thus communication from a client being imaged is refused by the core server.

Resolution

On the core server, do the following steps:

1. Navigate to \Program Files (x86)\LANDESK\ManagementSuite
2. Run "OSD.UPGRADE.EXE"

This will update BOOT.WIM, BOOTMEDIA.WIM, and BOOT_X64.WIM and inject the newer SHA-1 certificates into the Boot Images.

Question:

I am attempting to use an Unattend.xml as part of my Ivanti EPM Provisioning job.

What support does Ivanti offer for troubleshooting or customizing my unattend.xml?

Answer:

Ivanti provides a sample unattend.xml either on the Ivanti community or bundled with the product as a service to our customers to give them a starting point.

Customizing the UNATTEND.XML to cover the customer environment will be necessary in most cases.

Troubleshooting or customizing the UNATTEND.XML file is not covered within the scope of LANDESK Support.

It is recommended to use Microsoft Windows System Image Manager to create an UNATTEND.XML file.

For more information on the Microsoft Windows System Image Manager, refer to the following Microsoft Technet Article:

http://technet.microsoft.com/en-us/library/cc766347(v=ws.10).aspx

Microsoft documentation or contacting Microsoft support is advised for assistance with the UNATTEND.XML

See the following Microsoft article:

http://technet.microsoft.com/en-us/library/cc748874(v=ws.10).aspx

This video demonstrates how to capture a profile using a provisioning template.

Click HERE to play in a separate browser window (You can maximize the video if you use that link)

Error message:

The error message is located in the agent install log (C:\ProgramData\LANDesk\Log\wscfg32.log). The last message in the log will look like so:

Tue, 12 Sep 2017 09:32:59 INI:  EXEC49=C:\Program Files (x86)\LANDesk\LDClient\SCSDiscovery.exe, /Output Silent SystemDiscovery /NoFile, NOWINDOW + INSTALLONLY

Tue, 12 Sep 2017 09:32:59 Starting process: C:\Program Files (x86)\LANDesk\LDClient\SCSDiscovery.exe /Output Silent SystemDiscovery /NoFile

The agent install will be hung from that point on.

Cause:

SCSDiscovery.exe Is used to determine if the device is vPro capable. The device may not be ready to run that EXE and it may not have access to the DLL's it needs to determine vPro functionality. This is usually because the OS is booting up for the first time and goes through additional configuration on the initial boot.

Solution / Workaround:

Add a 200 second wait (This time can be adjusted as needed) as the first action is System Configuration. This will allow the OS to go through it's initial configuration/OS setup. In general, it's a good idea to put a wait at the beginning of System Configuration to allow the OS enough time to boot properly.

Issue:

When stamping your NBI with the Ivanti Startup Disk Stamper you are unable to click create and get a message that "the NBI OS version is different than the agent OS version.", as seen below.

Cause:

The cause of this message is that the NBI Source (the installer placed in the applications folder to create the NBI) and the Agent Source (OS of the machine that is used to create and stamp the NBI) does not match.

As you can see the main version of the OS is the same, however the update version is mismatched which is what is causing the message and the create button to be grayed out.

Solution:

The best way to ensure the versions match is to download your installer first. Then use that to install the OS on the machine you plan to create the NBI on, make sure you do not update the OS then create your NBI and stamp it. Most users end up with issues because the first thing they do is update the OS and in this case is causing the issue.

• Introduction
• Changes in Internet Information Services (IIS)
• Configuring the NetBoot Install Files Repository
• Space Requirements on the Elected Representative

Introduction

LANDESK 2016.3 introduced Self-Electing Subnet Services. This changes the way NetBoot Services are configured. Self-Electing Subnet Services will need to be enabled alongside PXE Services in the Client Connectivity Agent Settings for managed devices:

For more information on the full configuration, please visit How To: Configure PXE services in LDMS 2016.3.

Changes in Internet Information Services (IIS)

NetBoot Installers includes files that have zero-value extensions. IIS is not configured by default to account for these file types, so the IIS MIME Types need to be updated.

Open Internet Information Services (IIS) Manager on the Core Server and browse to the Default Web Site. From there, select MIME Types:

In the MIME Types Action Window, select Add... Configure the new "." MIME Type as follows:

Click OK. It is not necessary to run an IISReset.

Configuring the NetBoot Install Files Repository

By default, the NetBoot Image location on the core will be http://corename/landesk/vboot/Netboot.

This location can be configured in the Operating System Provisioning tool in the LANDESK Management Console.

Go to Tools > Provisioning > OS Provisioning. Select Preboot and click ManageNetBoot Image Mappings:

Click OK once the desired Configurations have been made.

At this point, the Self-Elected PXE Representatives will need to check in with the Core Server to Acknowledge the updated Repository Settings. This can be done in two ways:

• Manually restarting the LANDESK PXE Service on the Elected Representative.
• Waiting for the Elected Representative to check in via the Polling Frequency (Configured in the Self-Electing Subnet Services Tool).

When this is done, the pxesvc.log located on the Representative under C:\ProgramData\LANDesk\Log will log something similar to the following:

Thu, 16 Feb 2017 12:32:35 Redirecting and resolving paths for Default.
Thu, 16 Feb 2017 12:32:35 Original path: http://ldcore20163/ldlogon/mac/NBIs/Stamped.nbi/, redirected path: http://ldcore20163.ADAY.local/ldlogon/mac/NBIs/Stamped.nbi/
Thu, 16 Feb 2017 12:32:35 Redirected path: http://ldcore20163/ldlogon/mac/NBIs/Stamped.nbi/, resolved path: http://ldcore20163/ldlogon/mac/NBIs/Stamped.nbi/
Thu, 16 Feb 2017 12:32:35 Redirecting and resolving paths for VMware7,1.
Thu, 16 Feb 2017 12:32:35 Original path: http://ldcore20163/ldlogon/mac/NBIs/Stamped.nbi/, redirected path: http://ldcore20163/ldlogon/mac/NBIs/Stamped.nbi/
Thu, 16 Feb 2017 12:32:35 Redirected path: http://ldcore20163/ldlogon/mac/NBIs/Stamped.nbi/, resolved path: http://ldcore20163/ldlogon/mac/NBIs/Stamped.nbi/
Thu, 16 Feb 2017 12:32:35 ******* Leaving GetNetbootFiles *******

Space Requirements on the Elected Representative

The Space Requirements on the Elected Representatives is very little. Elected PXE Representatives will redirect the NetBooted Macs to the Core/Preferred Server in order to pull down the full NBI.

A typical size for a LANDESK Stamped NBI will be around 550MB. The NBI files copied down the PXE Representatives will be around 20-30MB in size. On the Representative, they are located under C:\Program Files (x86)\LANDesk\PXE\System\images\mac.

Overview

This document contains the steps necessary to deploy a Windows 10 image in provisioning using ImageX. Although it mentions Windows 10, the same steps will work for Windows 7, 8 and 8.1.

Capture Windows 10 Image

For help with capturing the image, refer to the following Community article:

How to Capture a Windows 10 image with IMAGEX

Import the UNATTEND.XML file

1. Copy the Winx64Unattend.xml file to a directory on the Core Server. The file is in the ProvImageX.zip file attached to the following Community article:

How to Deploy a Windows 10 Image with ImageX

2. In the Operating system provisioning tool in the LANDESK Console on the Core Server, click on Provisioning templates in the left pane.

3. Click Tools at the top of the window then click Install Scripts.

4. In the Install scripts window, click the Browse button and browse to the folder where the Winx64Unattend.xml file was copied and select it.

5. In the Script name box, enter a name for this unattend file to uniquely identify it.

6. In the Description box, enter a description if desired.

7. Select Windows for the Target operating system.

8. Click the Import button to import the unattend file into the database. The Script name will appear in the Install scripts list if it is successful.

Import the Provisioning Template

1. Copy the provisioning template DeployWin10ImageX.xtp to a folder on the Core Server. The template is in the ProvImageX.zip file attached to the following Community article:

How to Deploy a Windows 10 Image with ImageX

2. In the Operating system provisioning tool in the LANDESK Console on the Core Server, click on Provisioning templates in the left pane.

3. Click the Import templates icon along the top of the Operating sytem provisioning tool.

4. Click the Browse button in the Import templates window and browse to the location where the template was copied in step 1 and select it.

5. Click the Import button.

6. Click OK.

7. Click the Close button in the Import templates window. The imported template will show up in the Operating system provisioning tool under Provisioning templates | My templates | All my templates with a name starting with DeployWin10ImageX and includes a Date/Time stamp. The template name can be changed after it is imported.

Modify the Imported Provisioning Template

1. In the Operating system provisioning tool, double-click the provisioning template that was imported in the Provisioning templates | My templates| All my templates folder.

2. Expand the OS-installation section of the template and click on the Deploy Image action.

3. Make sure that ImageX is selected for the image type.

4. Enter the UNC path including the filename to the Windows 10 image to be deployed. The file will have a .WIM extension.

5. Click the Validate button which updates the Command-line then click Apply.

6. Click on the Inject unattend file action under the Post-OS installation section of the template.

7. Select the unattend.xml file that was imported earlier from the Script name drop-down list.

8. Click the Apply button.

9. If the OS being deployed already has the drivers for the computer to be imaged or you are not planning on using LANDESK Hardware independent imaging, the Hardware independent imaging action can be deleted from the template in the Post-OS installation and System configuration sections.

10. Click on the Install LANDESK Agent action in the System configuration section of the template.

11. Select the desired LANDESK Agent from the Configuration name drop-down list.

12. Click the Apply button.

13. Add additional actions to the template if desired. Do this by right-clicking the section of the template and select the Add Action option. There is an action to join the domain and an action to run software distribution packages as well as many others. After adding any actions, be sure to click the Apply button.

14. Click OK to save the changes to the template.

Enter the Variables

1. In the Operating system provisioning tool, click on Provisioning templates in the left pane.

2. Click Tools and click Public Variables.

The public variables shown in the screenshot above are there by default. The Replace value for the variables corename and coreIP can be changed if needed but do not change the Search value (variable name) for them or it will break provisioning. The Search values are case-sensitive.

3. Click the Add button.

4. Enter AdminPass in the Search value box. This variable is used in the unattend.xml file.

5. Select Sensitive data from the Type drop-down list.

6. In the Replacement value and Confirm replacement value boxes, enter the password which will be assigned to the local Administrator account on the computer when the image is deployed.

7. Click OK.

AdminPass now shows up in the Public variables window.

8. Click Add.

9. Enter WinProdKey in the Search value box. This variable is used in the unattend.xml file.

10. Select String from the Type drop-down list.

11. Enter the Windows 10 product key in the Replacement value box.

12. Click OK.

13. Click Add.

14. Enter Company in the Search value box. This variable is used in the unattend.xml file.

15. Select String from the Type drop-down list.

16. Enter your Company name in the Replacement value box.

17. Click OK.

18. Click OK to close the Public variables window.

Add Drivers for Hardware Independent Imaging (HII)

This step can be skipped if the HII actions were deleted from the template.

For help with HII, click F1 in the LANDESK Console and search for HII.

Add Devices to be Imaged

This section can be skipped if the devices are already in the LANDESK Console under All Devices.

1. In the LANDESK Console, expand Configuration.

2. Right-click Bare Metal Devices and select Add Devices.

3. In the Add bare metal device window, select MAC address for the Identifier type from the drop-down list.

4. Click the Add button.

5. In the Bare Metal Device window, enter a name for the device in the Name box. The name entered will be the computers name after it is imaged.

6. Make sure the Identifier type has MAC address selected then enter the MAC address of the of the computer in the Identifier box.

7. Click the Add button.

8. The MAC address will show up in Server identifiers. Click OK.

9. The computer added will show up in the Add a bare metal device window. Click OK.

10. The computer added will show up in the LANDESK Console in the Configuration | Bare Metal Devices folder after the LANDESK Inventory Server service processes it.

Add the Image Server as a Preferred Server

Setup a preferred server for the computer where the image share is located if it has not already been done. Following Community article has information on setting up preferred servers:

How to configure the Preferred Server (Target) for Content Replication

Schedule the Template and start the Task

1. Drag the computer(s) from the Bare Metal Devices folder or from All Devices and drop them on the template that was imported earlier.

2. Click Save.

3. Make sure all devices targeted for the task are off.

4. Right-click the task and select Start now | All.

5. Wait a minute to give the task time to initialize.

Network Boot the Devices and Wait for the Task to Complete

1. Network boot (PXE boot) the computer(s) in the provisioning task. When the computer(s) are PXE booted, they will automatically load WINPE and run the template. For help with network booting the computer(s), refer to the computers documentation.

2. Wait for the provisioning task to complete. The computer(s) will reboot at least 2 times during the provisioning process. Following are screenshots of various stages of the provisioning process:

Downloading WINPE from the PXE Representative. The IP address shown is the IP address of the PXE Representative.

WINPE is loading.

WINPE has successfully loaded and has started to run the provisioning template.

ImageX is currently running to deploy the image.

The image has been deployed and the computer has rebooted to load the OS. It has started going through the sysprep process to load the OS for the first time.

The OS rebooted and is continuing to load for the first time processing the unattend.xml file.

Sysprep has completed and is now running the actions in the System Configuration section of the template. When the template is done, the computer will shutdown.

Alternate Method to Start a Provisioning Template on a Computer

For this method, skip the following sections of this document:

Add Devices to be Imaged

Schedule the Template and Start the Task

Network Boot the Devices and Wait for the Task to Complete

1. If the computers all do a BIOS boot then you can skip to step 3. If the devices do a UEFI boot, Click Preboot | PXE Boot Options in the Operating system provisioning tool.

2. Make sure there is a check in the Always PXE Boot UEFI Devices and click Save.

3. Network boot (PXE boot) the computer and click F8 when it shows on the screen. Refer to the computers manual if you need help PXE booting it.

4. Select WinPE Provisioning and hit Enter on the keyboard.

5. WINPE is downloading from the PXE Representative. The IP address shown is the IP address of the PXE Representative.

6. WINPE has downloaded and is now starting on the computer.

7. Enter the Domain, Username and Password for an account that has rights to provisioning in the LANDESK Console. Use the same account that you login with to the LANDESK Console.

8. Click OK.

9. Click on the Provisioning template under All my templates and click OK.

10. The template is now running. Wait for it to finish. The computer will shutdown when the template is done. Refer to the screenshots in the previous section to see various stages of the provisioning process.

Error message:

"The selected software distribution package is invalid. Specify a valid software distribution package." Error occurs when you try to save a provisioning template.

The troubleshooting steps below can also be used to troubleshoot issues with Packages not saving in a template even after they have been mapped.

Solution / Workaround:

     1) Look through the template and find a install software action that is missing a "Selected Package":

     2) Select the correct package for that action. Once the template saves, edit the template again and verify that the selected package was maintained after saving.

     3) In rare instances, you will run into a bad package that will not save in the template. If you do:

• Attempt to export the package, and then import the same file back into the console. This will re-enter the distribution package into the database and fix issues that can be caused when updating to newer versions of the software.
  • How to Import/Export Software Distribution Packages
• If exporting and Importing does not fix the issue, the package is most likely not repairable. Recreate the package and map the new package to the template.

• 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

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.

Overview:

This document provides the steps necessary to capture a Windows 10 image using IMAGEW.EXE v2 for use in a provisioning template. The screenshots and steps in this document show Windows 10 but the same steps will work for Windows 7, 8 or 8.1.

Create a provisioning template to capture the image

1. Open the Operating System Provisioning tool in the LANDESK Console by clicking Tools | Provisioning | OS Provisioning.

2. In the Operating system provisioning tool, click on the All my templates folder.

3. Click New Template and select the Capture Template option.

4. Enter a name for the template.

5. Enter a description for the template which is optional.

6. Select LANDESK ImageW V2 for the Image Type.

7. Enter the UNC path including the filename to the location where the image file will be saved. The filename extension will be .tbi.

8. If the image share does not exist, create it before trying to capture the image. You will also need to setup a preferred server for the computer where the image share is located if it has not already been done. Following Community article has information on setting up preferred servers:

How to configure the Preferred Server (Target) for Content Replication

Note: You must have Write Credentials specified in the preferred server section, the account used must have modify rights to the image share in order to capture the image.

9. Click Create.

10. The template created will show up in the Operating system provisioning tool under All my templates.

Install a PXE Representative

If PXE representatives have not already been installed, install a PXE representative on the same subnet as the Windows 10 computer. Instructions for installing PXE representatives is available in the following Community article:

How to configure Self Electing PXE services in LDMS 2016.3 or higher

Note: PXE representatives cannot have multiple NICs/LANs and they cannot have WIFI.

Prepare the Windows 10 Computer for Capturing the Image

1. Install Windows 10 on a computer or get a computer that already has Windows 10 installed. Make sure the LANDESK Agent is not already installed on the computer or it will need to be removed before capturing the image.

Note: Install the OS on the smallest partition possible so it can be deployed to as many different hard drives in the environment. ImageW captures all partitioned space and will only deploy to hard drives big enough to hold the captured partitions. It will expand the last partition to fill the drive if there is free space left over.

2. After the OS is installed, configure the OS with any Company requirements.

3. Install all OS patches currently available because this will save time in the long run so that the computers do not have to be patched later.

4. Install all applications that are common for all users in the company that this image will be deployed for their use.

Run SYSPREP.EXE to Prepare the OS for Capturing

SYSPREP.EXE is located in the Windows\System32\Sysprep folder on the Windows 10 computer.

For use in LANDESK, the computer can be sysprepped in Audit mode without the Generalize box checked or it can be sysprepped in OOBE mode with the Generalize box checked.

Select the options for sysprep then click OK to run it. When sysprep is complete, the computer will shutdown.

Note: Do not let the computer boot into the OS until after the image is captured or you will have to run sysprep again.

Add a Bare Metal Server Entry

1. In the LANDESK Console, expand Configuration.

2. Right-click Bare Metal Devices and select Add Devices.

3. In the Add bare metal device window, select MAC address for the Identifier type from the drop-down list.

4. Click the Add button.

5. In the Bare Metal Device window, enter a name for the device in the Name box. Name it whatever you like because the name does not matter for the capture.

6. Make sure the Identifier type has MAC address selected then enter the MAC address of the Windows 10 computer in the Identifier box.

7. Click the Add button.

8. The MAC address will show up in Server identifiers. Click OK.

9. The computer added will show up in the Add a bare metal device window. Click OK.

10. The computer added will show up in the LANDESK Console in the Configuration | Bare Metal Devices folder after the LANDESK Inventory Server service processes it.

Create a Scheduled Task for the Capture Template

1. Drag and drop the Bare Metal device on the Capture Template that was created previously.

2. Click Save.

3. Right-click the task created in the Scheduled tasks tool and select Start now | All.

4. Expand the task and click on All devices under the task.

5. Give the task a minute to completely initialize and verify the task Status shows Waiting.

Network Boot the Windows 10 Computer to Capture the Image

1. Network boot the computer. Refer to the computers documentation, if you need help with how to network boot the computer.

2. WINPE is downloading from the PXE representative. The IP address shown is the IP address of the PXE representative that the client is communicating with which is useful to know for troubleshooting.

3. WINPE has finished downloading and is now initializing to run the template.

4. The provisioning template is running.

5. ImageW is now running and capturing the image.

6. When ImageW finishes, it will report a success or failure. Hopefully, it will report a success as shown in the screenshot above. The template progress window will only remain open for short time before closing. Check the status in the scheduled task to make sure it was successfully.

Overview:

This document provides the steps necessary to capture a Windows 10 image using IMAGEx.EXE for use in a provisioning template. The screenshots and steps in this document show Windows 10 but the same steps will work for Windows 7, 8 or 8.1.

• Overview:
• Create a provisioning template to capture the image
• Install a PXE Representative
• Prepare the Windows 10 Computer for Capturing the Image
• Run SYSPREP.EXE to Prepare the OS for Capturing
• Add a Bare Metal Server Entry
• Create a Scheduled Task for the Capture Template
• Network Boot the Windows 10 Computer to Capture the Image

Create a Provisioning Template to Capture the Image

1. Open the Operating System Provisioning tool in the LANDESK Console by clicking Tools | Provisioning | OS Provisioning.

2. In the Operating system provisioning tool, click on the All my templates folder.

3. Click New Template and select the Capture Template option.

/servlet/JiveServlet/downloadImage/102-47198-8-145266/3_Capture.png

4. Enter a name for the template.

5. Enter a description for the template which is optional.

6. Select ImageX for the Image Type.

7. Enter the UNC path including the filename to the location where the image file will be saved. The filename extension will be .WIM.

8. If the image share does not exist, create it before trying to capture the image. You will also need to setup a preferred server for the computer where the image share is located if it has not already been done. Following Community article has information on setting up preferred servers:

How to configure the Preferred Server (Target) for Content Replication

Note: The Read Credentials account used for the preferred server must have modify rights to the image share in order to capture the image.

9. Click Create.

10. The template created will show up in the Operating system provisioning tool under All my templates.

Install a PXE Representative

If PXE representatives have not already been installed, install a PXE representative on the same subnet as the Windows 10 computer. Instructions for installing PXE representatives is available in the following Community article:

How To: Configure PXE services in LDMS 2016.3

Note: PXE representatives cannot have multiple NICs/LANs and they cannot have WIFI.

Prepare the Windows 10 Computer for Capturing the Image

1. Install Windows 10 on a computer or get a computer that already has Windows 10 installed. Make sure the LANDESK Agent is not already installed on the computer or it will need to be removed before capturing the image.

Note: Install the OS on the smallest partition possible so it can be deployed to as many different hard drives in the environment. ImageW captures all partitioned space and will only deploy to hard drives big enough to hold the captured partitions. It will expand the last partition to fill the drive if there is free space left over.

2. After the OS is installed, configure the OS with any Company requirements.

3. Install all OS patches currently available because this will save time in the long run so that the computers do not have to be patched later.

4. Install all applications that are common for all users in the company that this image will be deployed for their use.

Run SYSPREP.EXE to Prepare the OS for Capturing

SYSPREP.EXE is located in the Windows\System32\Sysprep folder on the Windows 10 computer.

For use in LANDESK, the computer can be sysprepped in Audit mode without the Generalize box checked or it can be sysprepped in OOBE mode with the Generalize box checked.

Select the options for sysprep then click OK to run it. When sysprep is complete, the computer will shutdown.

Note: Do not let the computer boot into the OS until after the image is captured or you will have to run sysprep again.

Add a Bare Metal Server Entry

1. In the LANDESK Console, expand Configuration.

2. Right-click Bare Metal Devices and select Add Devices.

3. In the Add bare metal device window, select MAC address for the Identifier type from the drop-down list.

4. Click the Add button.

5. In the Bare Metal Device window, enter a name for the device in the Name box. Name it whatever you like because the name does not matter for the capture.

6. Make sure the Identifier type has MAC address selected then enter the MAC address of the Windows 10 computer in the Identifier box.

7. Click the Add button.

8. The MAC address will show up in Server identifiers. Click OK.

9. The computer added will show up in the Add a bare metal device window. Click OK.

10. The computer added will show up in the LANDESK Console in the Configuration | Bare Metal Devices folder after the LANDESK Inventory Server service processes it.

Create a Scheduled Task for the Capture Template

1. Drag and drop the Bare Metal device on the Capture Template that was created previously.

2. Click Save.

3. Right-click the task created in the Scheduled tasks tool and select Start now | All.

4. Expand the task and click on All devices under the task.

5. Give the task a minute to completely initialize and verify the task Status shows Waiting.

Network Boot the Windows 10 Computer to Capture the Image

1. Network boot the computer. Refer to the computers documentation, if you need help with how to network boot the computer.

2. WINPE is downloading from the PXE representative. The IP address shown is the IP address of the PXE representative that the client is communicating with which is useful to know for troubleshooting.

3. WINPE has finished downloading and is now initializing to run the template.

4. The provisioning template is running.

5. ImageX is now running and capturing the image.

6. When ImageW finishes, it will report a success or failure. Hopefully, it will report a success as shown in the screenshot above. The template progress window will only remain open for short time before closing. Check the status in the scheduled task to make sure it was successfully.

• • Background:
  • Step by Step:
  • Reference:

Background:

The Example in this document is how to troubleshoot PXE representative not working issue.

Step by Step:

1. After deploying the agent with PXE component following this document:

How to configure Self Electing PXE services in LDMS 2016.3 or higher 

There is no Elected PXE device in the console. You can check this in Self-electing subnet services - PXE - Current State.

2. Go to the affected agent with PXE component. Open Services and find LANDesk(R) PXE Service and LANDesk(R) MTFTP Service are not running.

3. Go to the log folder: C:\ProgramData\LANDesk\Log, check log PXEsvc.log, Pxemtftp.log, SelfElectController.log and Tmcsvc.log.

The example here is in PXEsvc.log, boot.wim and boot_x64.wim download failed and caused this issue. Afte the download issue is resolved. PXE representative is working as expected.

Fri, 29 Dec 2017 13:46:50 ******* Entering GetWimFiles: Attempting to get latest boot images for Windows. *******
Fri, 29 Dec 2017 13:46:50 LDClient path (for lddwnld.dll) is C:\Program Files (x86)\LANDesk\LDClient\.
Fri, 29 Dec 2017 13:46:50 Downloader/Multicast using config file located here: C:\ProgramData\LANDesk\TMCDownload\downloadermulticastconf.xml
Fri, 29 Dec 2017 13:46:50 About to call DownloadFiles (2 files) with these settings:
Fri, 29 Dec 2017 13:46:50 m_allowedBandwidthWAN: 100
Fri, 29 Dec 2017 13:46:50 m_allowedBandwidthLAN: 100
Fri, 29 Dec 2017 13:46:50 m_discardPeriodSeconds: 604800
Fri, 29 Dec 2017 13:46:50 m_preserveDirectoryStructure: 0
Fri, 29 Dec 2017 13:46:50 m_bUseWanBWForPush: 0
Fri, 29 Dec 2017 13:46:50 m_bSynchronize: 0
Fri, 29 Dec 2017 13:46:50 Allowed download methods(m_downloadControl):
Fri, 29 Dec 2017 13:46:50 Peer
Fri, 29 Dec 2017 13:46:50 Source
Fri, 29 Dec 2017 13:46:50 m_preferredServerControl: AttemptPreferredServer
Fri, 29 Dec 2017 13:46:51 Download failed file not found at source(1): http://YONGCORE173CN.bjsupportdomain.com/landesk/vboot/boot.wim
Fri, 29 Dec 2017 13:46:51 Failed to download http://YONGCORE173CN.bjsupportdomain.com/landesk/vboot/boot.wim with errorCode 11
Fri, 29 Dec 2017 13:46:51 Download failed file not found at source(1): http://YONGCORE173CN.bjsupportdomain.com/landesk/vboot/boot_x64.wim
Fri, 29 Dec 2017 13:46:51 Failed to download http://YONGCORE173CN.bjsupportdomain.com/landesk/vboot/boot_x64.wim with errorCode 11
Fri, 29 Dec 2017 13:46:51 Lddwnld did not download all files successfully.

Reference:

How to Troubleshoot Self-Electing PXE Services

How to configure Self Electing PXE services in LDMS 2016.3 or higher

Issue with Self-Electing PXE Services in LDMS 2016.3

This is a video tutorial on how to use Machine Mapping. This will cover the three provisioning action templates for which Machine Mapping was created.