I have a template that installs and launches a program (distributes a Windows Action that launches an exe) and when I run the template, everything runs fine but I would like the ldprovisioning UI to exit after launching the program but while the program is still running.

Description

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

Ivanti Endpoint Manager 2018.1

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

Ivanti Endpoint Manager 2017.3

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

Ivanti Endpoint Manager 2017.1

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

LANDESK Management Suite 2016.3

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

LANDESK Management Suite 2016

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

LANDESK Management Suite 9.6 SP3

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

LANDESK Management Suite 9.6 SP2

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

Determining your WinPE version

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

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

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

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

NDIS Versions in Network Drivers (Windows Drivers)

Issue

The following error occurs when booting into Windows PE:

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

Cause

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

Resolution

The following steps will be taken on the core server:

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

These steps follow:

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

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

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

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

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

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

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

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

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

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

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

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

    
    
    
    

HII Driver Management

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

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

Disable Drivers

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

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

Assign Drivers

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

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

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

Assign Driver .inf file

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

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

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

Assign Driver Package

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

Managing Assigned and Disabled Drivers

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

Issue

CTOS action is failing in the provisioning template.

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

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

Cause

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

Solution

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

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

Problem:

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

Solution:

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

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

Use LANDesk remote control to view a computer in WinPE provisioning

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

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

   Use the Net Use command to map or disconnect a drive

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

   xcopy *.log E:

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

Troubleshooting OS Provisioning using the log files

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

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

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

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

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

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

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

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

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

Purpose

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

What is considered a 'Match' to HII?

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

• OS
• Architecture
• Hardware ID

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

Items Needed

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

Get Info From HIIPreview

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

You will need the OS and Architecture listed:

Example:

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

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

Example:

Hardware device discovered.  Device number 5:

Device name: PCI Express standard Root Port

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

    Additional device ID:    PCI\VEN_15AD&DEV_07A0&SUBSYS_07A015AD

    Additional device ID:    PCI\VEN_15AD&DEV_07A0&CC_060400

    Additional device ID:    PCI\VEN_15AD&DEV_07A0&CC_0604

    Additional device ID:    PCI\VEN_15AD&DEV_07A0&REV_01

    Additional device ID:    PCI\VEN_15AD&DEV_07A0

    Additional device ID:    PCI\VEN_15AD&CC_060400

    Additional device ID:    PCI\VEN_15AD&CC_0604

    Additional device ID:    PCI\VEN_15AD

    Additional device ID:    PCI\CC_060400&DT_4

    Additional device ID:    PCI\CC_060400

    Additional device ID:    PCI\CC_0604&DT_4

    Additional device ID:    PCI\CC_0604

Get Details to Query

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

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

Get OS_IDN

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

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

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

SELECT *
FROM OS

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

Get Arch_idn

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

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

There are 3 possible Architectures:

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

Since our example shows AMD64, Arch_idn = 3.

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

For our example - Arch_idn = 3 OR Arch_idn = 1

Get InfFiles_IDN

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

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

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

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

For our example - InfFiles_IDN = 2.

Query for Matching Hardware IDs

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

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

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

Example:

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

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

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

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

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

Purpose

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

Problem

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

Cause

NVMe hard drive not supported in Windows 7

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

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

Solution

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

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

NVM Express in Windows 7 and Windows Server 2008 R2

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

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

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.

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. 

I am having a very hard time getting an image to deploy to a surface pro 3

The deploy image handler gives me this error each time.

2018-02-02 22:39:57(3044-2140) DeployImageHandler_x64.exe:Replacing path string \\knt001ap21\ldimaging\images, with e:

2018-02-02 22:39:57(3044-2140) DeployImageHandler_x64.exe:New Args:  /r /o /x /d:0 /rb:0 /f:e:\KentW10Ent64Surface.tbi

2018-02-02 22:39:57(3044-2140) DeployImageHandler_x64.exe:Going to execute imagew.exe  /r /o /x /d:0 /rb:0 /f:e:\KentW10Ent64Surface.tbi

2018-02-02 22:39:57(3044-2140) DeployImageHandler_x64.exe:ExecuteCmd imagew.exe  /r /o /x /d:0 /rb:0 /f:e:\KentW10Ent64Surface.tbi

2018-02-02 22:39:57(3044-2140) DeployImageHandler_x64.exe:Could not create process, error: 2

2018-02-02 22:39:57(3044-2140) DeployImageHandler_x64.exe:Tearing down Environment.

2018-02-02 22:39:57(3044-2140) DeployImageHandler_x64.exe:ExecuteCmd maptopreferredhandler_x64.exe /unmap /driveletter=e:

2018-02-02 22:39:57(3044-2140) DeployImageHandler_x64.exe:created process, file handle bc with non-readonly parameter

2018-02-02 22:39:57(3044-2140) DeployImageHandler_x64.exe:Process Exit Code: 0

2018-02-02 22:39:57(3044-2140) DeployImageHandler_x64.exe:execute failed with 2

the image is there.  I can see it when I manually check.  HELP!!

I got some new HP Pro-books with 2 drives (SSD+HDD). For some reason system detects the HDD (Data) is as disk 0 and SSD (system) as disk 1.

I need to provision those devices, but can't figure out how to make landesk provisioning install OS on SSD (disk 1)

It always select the HDD marked as disk 0 as a system disk and install OS there.

Of course I could remove the HDD from the notebook, but it's not the way I want to solve it.

Thank you for help.

The registry value resides in WOW6432Node on a Win10 box. My script checks for a property of a key there for a the value to hit 0, when it hits zero a file is made. I have a wait for file task that looks for that other file to continue the provisioning task. This script runs fine when outside of Ivanti but slotting into my task sequence as a Windows Action causes Ivanti to totally skip my value check, create the file and keep moving. Is there something Im missing here?

Hi All,

Not familiar with LANDesk know enough.  Trying to install a new PXE rep since our old PXE rep vm no longer working.  I'm unable to setup a new one.  I search and found a few articles but I'm unable to find the correct how to docs.  I couldn't find the "PXE Representative Deployment Script" in the console.  Any help would appreciate.  Thank you.

Hello professionals!

I have a problem with the PXEBoot.

If I start the installation and let PXE boot via F12, everything works fine.

But if I set the Bios Settings->Legasy Desable and Boot Order->Netboot (abridged description for HP 400 G4) from Windows (the settings will be taken over), then the computer will boot in PXE, but will not find any PXE or the boot file. I'm still looking. Other devices work wonderfully.

Did you have such a problem?

With kind regards.

Hallo Profis!

Ich habe ein Problem beim PXEBoot.

Wenn ich die Installation anstoße und PXE per F12 booten lasse, funktioniert alles wunderbar.

Wenn ich aber die Bios Einstellungen->Legasy Desable und Boot Order->Netboot setze (verkürzte Beschreibung für HP 400 G4) aus dem Windows heraus (die Einstellungen werden übernommen), dann bootet der Rechner zwar in PXE, aber findet kein PXE oder die Bootdatei nicht. Da bin ich noch am Suchen. Andere Geräte funktionieren wunderbar.

Hattet ihr so ein Problem?

Mit freundlichen Grüßen.

Issue

When attempting to PXE boot, the following error appears:

• PXE Boot fails.
• No F8 option is recieved by clients.
• Unable to PXE Boot machines.
• Unable to network boot machines.
  
  

Cause

• No PXE representatives are deployed.
• Deployed PXE Representative is turned off.
• PXE representative is not in the same broadcast domain as target machine.
• Firewall on PXE representative is blocking requests from target machine.
• PXE services are not running.
• Windows Deployment Services (WDS) are installed on the PXE representative.
• Another service on the server is using port 67
  
  

Resolution

• Update BIOS on device
• Ensure that a PXE representative is on and is deployed in the same broadcast domain as the target machine.
• Ensure that no firewall is blocking requested packets from PXE booted machines.
• Ensure PXE services are running.  The two services are "LANDESK® PXE Service" and "LANDESK® PXE MTFTP Service".
  If they are running, restart the services.
• Redeploy the PXE Representative.
• If PXE services repeatedly stop on PXE representatives, download and install the latest service pack on the core, then remove and redeploy PXE representatives.
• Disable the Windows Deployment Services (WDS) on the PXE representative.
• Run the "netstat -abn" command to find the service which is using port 67 and disable/reconfigure this service.

Note: The PXE Representative may need to be rebooted if the services are running, the firewall is off, but it still does not respond.

• 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

Description

When PXE Booting you receive an error before booting into WinPE.

- TFTP Boot Issues

- PXE-032 Error

- NBD failing to load (freezes)

Cause

Starting in Windows 10 1709 build windows firewall has been updated to Windows Defender Firewall.

If you have your firewall enabled and you used to be able to PXE Boot it was because the PXE Services was set as an exception.

Solution

Windows 10 1709 requires that you specify the open ports for PXE into the Inbound Rules if you have your Windows Firewall enabled.

Ports used by LANDESK Management Suite - Full List

Open Windows Defender Firewall.

1. Test disabling it to see if this resolves your issue with PXE Booting. If it does then continue to add the Specific Ports into the Firewall Inbound Rules.

2. Windows Defender Firewall	Inbound / Outbound Rules

   
   
   
3. You can use the following document to reference Ports that LANDesk uses - Ports used by LANDESK Management Suite - Full List
   
   

4. General Tab	Advanced Settings	UDP Ports 67, 68, 69, 1758, 1759 and 4011

Hello,

I come to you with interesting OS provisioning failure. So let's start with presenting the configuration that I have:

LDMS version = 2016.3 SU02 on windows server 2012 R2 datacenter

Computer to install = DELL Precision 5510 with DELL TB16 (so the network cable is connected to the DELL TB16 and not directly to an RJ45 interface in the laptop)

Now time for describing the issue:

So we are testing the OS provisioning via LANDesk on a new DELL model which uses DELL TB16 (Thunderbolt 3 dock). The WinPE was successfully loaded and start to proceed the script "startnet.cmd" to load integrated drivers, check network connection and many other customized steps. Drivers were successfully loaded and WinPE get an IP address. One of these steps that I have mentioned is to create a folder under X:\ named "ldprovision" then use a CBA8 component called HTTPCLIENT.exe (under X:\CBA8\) to download ldprovision.exe from the core server to the folder "ldprovision" using HTTP

below is the command used:

httpclient -f ldprovision.exe http://%corename%/LdLogon/Provisioning/Windows/ldProvision.exe

Directly after this command the startnet.cmd will execute the executable file "ldProvision.exe" and here we get the error window (see picture in the attachment os_prov_error2.jpg)

After many hours of troubleshooting I found out that the root cause of this issue is that ldProvision.exe wasn't fully downloaded and when "startnet.cmd" reach the step where it launchs this executable file it fails because it is corrupted.

From WinPE I mapped a share to //%corename%/LdLogon/Provisioning/Windows/ and I tried to download this executable file by myself and guess what ... I had the same issue the download always fails to fully download "ldprovision.exe".

I checked the IIS log maybe I find some details and I found that everytime the HTTPClient try to download "ldprovision.exe" usgin HTTP Get method a new entry is added to the log file (see below):

2017-03-08 13:21:53 10.10.1.87 GET /LdLogon/Provisioning/Windows/ldProvision.exe - 80 - xxx.xxx.xxx.xxx - - 200 0 995 21374

so as you can see there is the windows error code 995 (sc-win32status) in the final HTTP Status (just after 200 0). The error description is : The I/O operation has been aborted because of either a thread exit or an application request. when I googled this error code most of web page refers to C# or ASP.net error related to closed sockets.

Does any one of you guys is using DELL TB16 or Thunderbolt 3 Dock and did he was able to provision it via LANDesk.

Thanks