Applies to LANDesk Management Suite 9.0 SP3 and newer

Issue

• Cannot right-click a provisioning template to schedule it.
• Schedule option is greyed out.
• Cannot schedule OSD scripts.
• Cannot create OSD scripts.
• Cannot select Windows when creating Provisioning Boot Media.
• Cannot select Windows PE for the Boot environment when creating a new provisioning template.

Cause

Installed a new Core Server using the existing Core Server database and the WAIK licensing information was not transferred properly.

Note:  The issue can also be caused by moving the existing LANDesk database to a new database server.

Resolution

1. Run the following SQL statement against the LANDesk database:
   
   update keyvalue set intvalue=0 where applicationname='WAIKLicenseAgreement'
   
   
2. Reopen the LANDesk Console and accept the license agreement.

Issue:

Trying to fine tune our Profile Captures.  I have two issues.

1. I am unable to filter out specific file types from the capture.
   Even though I set specific filters for various file types such as *.wmv, *.avi, *.mp3, etc., these are still being captured.
2. Need list of variables available for use in Profile Migration.

Resolution:

There is no tool in provisioning to do any filtering of files or folders that are in the desktop folder. If desktop is selected for the profile capture it will capture any and all files and folders in the desktop folder, regardless of any filters set.

You can filter all other folders in the profile, just not the desktop.

As a workaround a script has been built that searches for user added files and folders in the desktop folder, (everything except shortcuts).

The script moves all of these to the local "My Documents" folder for that profile, then places shortcuts in the desktop folder to the moved items.

From there, you can filter out what you do not want to include in the profile capture, such as pictures, music, other multimedia files, etc.

For additional information and tips on setting up the profile capture, see the following document;

How to: Build a Profile Migration Command Line with sample script

Environment:

LANDESK Management Suite 9.6, and may apply to earlier versions.

Error message:

IP address 127.0.0.1

Waiting for IP address..................

Timed out before acquiring an IP address.

The operation failed as no adapter is in the state permissible for this operation.

Failed to get localhost IP address or resolve core server name. Please check your network and try again.

Cause:

This issue can be caused by some versions of the corresponding DELL NIC driver.

Solution:

Per the information from DELL's support website, an updated driver (version 19.5.0.0, A11) has specifically "fixed issue that system can not get IP under some WinPE environment".

To fix the issue, the driver needs to be injected into the network boot image and the PXE rep needs to be redeployed.

Applies to DELL models:

Latitude 3340

Latitude E5250/5250

Latitude E5440

Latitude E5450/5450

Latitude E5540

Latitude E5550/5550

Latitude E6440

Latitude E6540

Latitude E7240

Latitude E7250/7250

Latitude E7440

Latitude E7450

Precision T1700

Precision M2800

Precision M4800

Precision M6800

Dell Precision Tower 5810

Dell Precision Tower 7810

Dell Precision Tower 7910

OptiPlex 9020

OptiPlex 9020M

OptiPlex 7020

OptiPlex XE2

Applies to OS:

Windows 7, 32-bit; Windows 7, 64-bit; Windows 8, 32-bit; Windows 8, 64-bit; Windows 8.1, 32-bit; Windows 8.1, 64-bit

Purpose

This document will outline how to import/export unattend files from the LDMS Core.

Import Unattend File

• Click Tools | Distribution | OS Provisioning

• Click the Install Scripts icon

• In the Install Scripts window click Browse, then select the unattend.xml to be imported.
• Provide a Script Name which is how the script will appear with LDMS
• Click Import

The script will now be available for selection in the Provisioning Inject Unattend file action.

Export Unattend File

• Click Tools | Distribution | OS Provisioning

• Click the Install Scripts icon

• In the Install Scripts window, in the Install Scripts section, select the Script to be exported.
• Click Export

• Select the location to export to, and name the file with the *.xml extension.

The exported *.xml is now available for editing. Once it has been modified with desired changes, it can be Imported again for use.

Related Articles

Building an Answer File

Walkthrough: Build a Simple Answer File

Purpose

This article outlines how to add a Provisioning only user. This will provide rights to Provision devices, while restricting access to other features of the program.

Steps

• Add the user to the LANDesk Management Suite Group on the LDMS Core

• Add the user into User Management in the LDMS Core

• Assign the Provisioning role to the user

• Reset IIS

The user should now have access to access Provisioning Templates through WinPE.

Error Logging In

If the user is not setup correctly, it may fail during login with this message:

The user name or password specified is not correct. Provide new credentials.

If login fails too many times, it will fail with error:

error:[800001509H]The user name or password specified is not correct. Provide new credentials.

If a user is unable to log into the WinPE menu, their login failure will be logged in the IIS log:

C:\inetpub\logs\LogFiles\W3SVC1\u_ex150813.log

2015-08-13 16:54:19 10.14.130.58 POST /LANDesk/ManagementSuite/Core/Provisioning.Secure/ProvisioningSecure.asmx - 443 evdomain\BadCredentials

10.14.130.56 - - 401 1 64 625

If the steps above are all set, and the issue persists, the IIS error code can be reviewed for additional information.

Reviewed 7/30/2015

Problem

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

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

Solution

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

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

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

More Information

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

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

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

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

Reviewed 9.30.2015

How To:  Deploy Power Management Policies in an OS Provisioning Template

Disclaimer:  This procedure is not native to LDMS OS Provisioning and is considered a custom solution.  As such it is not supported by LANDesk and may have unintended consequences.  Use this solution at your own risk.

Issue:

OS Provisioning templates do not contain Power Management actions.  Also, Power Management is not part of the agent configuration.  As such, Power Management Policies need to be pushed out to devices separately after the device is provisioned and the agent is installed.  This adds an additional manual step to the process when preparing a new device for deployment or imaging devices in your environment.

Solution:

Power Management policies can be applied via command line. 

The ldlogon share on your core server contains a PWM folder.  This folder contains the XML file and the .ini file used by each of your power management policies. Each file has a version number - match this to the ID of your Power Management policies in the console:

For example:

LDCORE_v323_ProcTriggerSvcCfg.xml

LDCORE_v323.ini

To apply this version 323 policy, both the .xml and the .ini files should be copied to the LDClient directory on the target device, but renamed as follows:

• LDCORE_v323_ProcTriggerSvcCfg.xml
• Rename to: ProcTriggerSvcCfg.xml
• LDCORE_v323.ini
• Rename to: PWMScript.ini

Once copied, run  "PWMCfg.exe /init" from the ldclient folder on the target device.  This should apply the policy as defined in those files.

Step by Step:

There is more than one way to accomplish this within LDMS.  Below are two common methods.

Using Copy File and Execute File template actions:

1. Edit or create a Provisioning template.  Ensure that the System Configuration group contains a Deploy Agent action since the LDMS agent is required before applying Power Management policies.
2. Add a Map/Unmap drive to preferred server action to System Configuration and map a drive to your core's ldlogon share:
   
3. Add a Copy File action to copy and rename the Power policy .xml file:
   
4. Add a second copy file action to copy and rename the Power Policy .ini file:
   
5. Finally, add an Execute File action to run PWMCfg.exe /init
   

A sample provisioning template .xtp has been attached to this article.  It can be imported to your core.  Please note, it was created in LDMS version 9.6 SP2 and may not work with older versions.  It will also need to be configured with the specific details and file names for your environment, and is provided as an example.  It will not be supported and should be used at your own risk.  

Using a software distribution package:

1. Create a script which copies the above .xml and .ini files and renames them.  The source and destination locations, and file names, remain the same as above.  After copying and renaming the files, the script should execute PWMCfg.exe /init
2. Create a software distribution package and link it to the script you just created.  For more info on creating a software package see this article:
   LANDESK Software Distribution Landing Page
   
3. Add a Distribute Software action to your Provisioning Template, and select your script distribution package:
   
   

Description:

In LDMS 9.6 a new feature was added called Machine Mapping. This feature is found under Toolbox -> Distribution -> Machine Mapping.

This feature was created to make it easier to provision new systems more dynamically with less work by the administrator.

It was specifically built to utilize three template actions, Install Mapped Software, Launch Template, and Deploy Profile.

This document will give you an understanding of how Machine Mapping is used and how to set it up.

Note: The RBA rights necessary to see the Machine Mapping tool in the Console are Software Distribution, OS Provisioning, and SLM.

Configuration:

Open the Toolbox to Distribution and click on Machine Mapping.

This is a simple process.   You have a Source, Destination, and Days Valid.

To add a device to the Source or Destination simply drag it from the device list above to the desired area.

Days Valid is how long that mapping will function. This is useful if you need are provisioning many systems and need a specific time frame.

Uses:

To present how this can be used to benefit your environment I will give a few case studies.

Case Study #1

You need to provision new systems for different departments, accounting, sales, and marketing. Each of these departments requires different software. You could create three different templates with the different software but it is much more efficient to use Install Mapped Software and Machine Mapping.

To do this you just need to designate one template machine from each department. In the screenshot above you can see that Win8xTA is being used as the template machine for 3 other systems.

With this set every time a system is being provisioned and gets to this template action it will look at the Machine Mapping and then install the software that has been mapped, In other words if the template system was an Accounting system and it had Dynamics installed, the Install Mapped Software action would install Dynamics on the system being provisioned. If the system you are provisioning is mapped to the template system in Marketing and that has Photoshop installed, Photoshop will be installed on the new system when the action executes.

(Important: This will only work if you have set up Product to Package Mapping. How to configure Product to Package Mapping and install Mapped Software)

Case Study #2

You are migrating users to new systems and need to get their profiles and software moved over with minimal work.

To do this, first create the Machine Mapping for the old machine as the Source and the new machine as the Destination.
Example in the first screen shot WIN8-1X64 mapped to WIN81X64-3

Then create two provisioning templates.

First create template with Install Mapped Software and Deploy Profile actions in System Configuration.

(Be sure to set Deploy Profile to Useautomatic naming.)

Second create another template that is configured with Capture Profile and Launch Template actions.

(Be sure to set Capture Profile to Use automatic naming.)

Select the first template created in the Launch Template action.

Finally, schedule the second template to the source system. It will capture the profile from the old machine and then launch the first template on the destination, which will then install the software from the old system and restore the profile.

(Note: There is a slight delay between the Launch Template action and the new template starting.)

(Important: Also if there is no Machine Mapping for the system and you have a Launch Template action, it will schedule the new template to itself.)

Finally enjoy the time saved from not having to move, name, or copy files,or manually installing specific software.

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.

Purpose

This article covers how to enable PXE logging. This can be helpful when troubleshooting PXE representatives.

Steps

• Modify the following registry key on the PXE Representative:
  • x86 - HKLM\SOFTWARE\Intel\PXE\
  • x64 - HKLM\SOFTWARE\Wow6432Node\Intel\PXE
• Change the following values [0 = off, 1 = on]
  • PxeMtftp_DebugOutToFile_On
    • Creates PXEMTFTP.LOG
  • PxeServices_DebugOutToFile_On
    • Creates PXESVC.LOG
• Restart LANDesk(R) PXE MTFTP Service
• Restart LANDesk(R) PXE Service
• The log files can be found in C:\Program Files (x86)\LANDESK\PXE\System

By applying a template with action to map a drive it fails and shows in the maptopreferredhandler.log that the credential for the preferred sever are not correct.

"Could not get credentials for preferred server."

Resulution

Copy all of the *.0 files out of C:\Program Files\LANDesk\Shared Files\Keys\ into the Boot.wim\cba8\cbaroot\certs\ and Boot_x64.wim\cba8\cbaroot\certs\

The following documente will help to mount the boot.wim to add the .0 files

How to: Mount the boot.wim using ImageX and Change the Core Name in the boot.wim

Error: "resolving core server name (%mycoreserver%)" when booting into WinPE

First, open up your command XML. The best way you want to view it is in the console's Profile Migration editor. To get to it, follow these steps;

1. If you open up your Management Console, and go to Tools>Distribution>OS Deployment
2. I am going to show you how to edit the XML in the provisioning template as OSD is gone in 9.6. But the same XML can be used in either location.
3. Go into you're "my templates" section and create a new template (or edit an existing one). Create a "Capture Profile" action.
4. Once you have added the action, you can browse to add a new Command XML, or edit to edit one.
5. Hit "Edit" and select the template you want and hit "Edit" again. You can place the attached SampleProfileXML in the "...\ldlogon\uma\commandxml" folder and use it, or use one you are already working with.

Now that you are in the editor, here are some of my tips to remember when building a Profile Migration Script (Command XML);

Tips

1. I found it best to INCLUDE all and then EXCLUDE the specific Users, Files, and Folders you do not want captured. When you look at the Command XML, you’ll notice on the User Profiles, and on Files and Folders I INCLUDE each of the top directories I want, and then EXCLUDE the lower directories I do not want captured.
2. When doing either an INCLUDE or EXCLUDE, make sure to check the “Scan Sub Folders” option if it applies.
3. There are some good variables that are specific to UMA\SMA, you have to look in the Documentation to find them.
   1. http://download.lenovo.com/ibmdl/pub/pc/pccbbs/thinkvantage_en/sma60dg_en.pdf
4. I found it best to have the users logged off at time of capture and deployment, but I have seen successful captures with the user logged on as well.
5. The “My Documents” section, when you are building your script, appears to be useless, I just ignore it all together. All of you're "My Documents" can be included in the selection of "User Profiles" and in the "Files and Folders"  as shown above in rule # 1. The %Personal Directory% variable takes care of it unless the user has been added to the exclude list.
6. When in doubt, check the documentation listed in Rule # 3, it actually has a lot of information.

Attached is the sample XML script as listed above. If you open it up in the Profile Migration editor, you can see how I apply each of the above mentioned rules.

Issue

On rare occasions, the "Manage Drivers in Windows PE Image" tool shows a blank list of drivers after selecting the desired boot.wim file.

This issue generally stems from the boot.wim file being improperly unmounted the last time it was used.

Resolution

The first step to resolve this issue would be to verify the existence of the boot.wim file on the core. It'll be found at "C:\Program Files\LANDESK\ManagementSuite\landesk\vboot."

If the boot.wim is present, we'll need to run some DISM commands to verify if there are currently any WIM image files mounted on the core.

Open an administrator command prompt and rundism /get-MountedWimInfo. If there are currently any mounted files, you should see something like this.

    NOTE: There may be more than one mounted WIM file on the core. The one we're concerned with is going to be under the vboot directory, but all stray mounted WIM files should be dealt with.

From what we can see in the screenshot, we know that there is currently a WIM image file mounted. Its currently mounted to "C:\Mount" with an original file location being "C:\Program Files\LANDESK\ManagementSuite\landesk\vboot\boot.wim."

Note the Status. In this example, the status is listed as OK. This is usually best-case scenario; meaning the WIM file can be easily unmounted. Anything other than OK (Such as Needs Remount or Status Un-available) will likely result in needing to repair or revert the damage.

Its recommended to first try to unmount the WIM file gracefully so we don't lose any work done to the currently mounted WIM file. This is done by running the command "dism /unmount-Wim /MountDir:"Mount Dir" /commit."

If unmounting the WIM fails, or the Status is listed as something other than OK, there are a couple of things we can try. The first being Remounting the WIM file. This can be done by runningdism /remount-Wim /MountDir:"MountDir."

After successfully remounting the WIM, attempt to unmount it once more using the steps above. If remounting fails, the only option left is to run DISM Cleanup.

Run dism /cleanup-Wim. This will tell DISM to search for and "Clean up" any stale or corrupted image files on your core.

    NOTE: This will erase any previous work done to the Boot.WIM from the last time it was mounted. Any drivers or files added will have to be re-added after running this command.

Run dism /get-MountedWimInfoonce more to ensure there are no longer any mounted WIM files on the core.

The "Manage Drivers in Windows PE image" tool should now be showing the full list of drivers.

Requires Access To:

LDMS console, HII Driver library and boot.wim image files.

Background Information:

The USB3.0 stack is a special case.  It contains a USB controller, a USB3.0 Root Hub, and, for Intel devices, an eXtensible host controller.  The USB3.0 controller is connected to and available on the PCI bus, which is visible to the WinPE OS.  HIIClient can see it and choose a driver for it.  However, the Root Hub and eXtensible host controller devices are not on the PCI bus; they are on a separate USB3.0 bus.

The USB3.0 bus is not visible to WinPE by default because WinPE does not have a USB3.0 controller driver by default.  That means when HIIClient.exe asks WinPE what devices are connected, WinPE will not return information about the USB3 hub or eXtensible host controller. Because there is no USB3.0 controller driver, the bus (and any devices connected to it) cannot be seen. WinPE will return only information about the USB3.0 controller, even if driver assignments are made for the remaining USB3.0 devices.

Resolution:

The solution is to inject the USB3.0 controller drivers into your boot.wim image.  This makes the drivers available in WinPE.  Essentially, the USB3.0 controller device will be installed in WinPE, so when HIIClient runs it can detect the full USB3.0 bus that is controlled by the USB3.0 controller, and select the appropriate drivers for all the USB3.0 devices from the HII driver library.  Sometimes it is sufficient to inject just the USB3.0 controller driver, and other times drivers for all USB3.0 stack devices should be injected.

This document describes how to inject drivers into the boot.wim image:

How to add drivers to WinPE for LANDESK OS Provisioning

This document describes which WinPE version used for each version of LANDesk Management Suite, so you can assign the drivers compatible with your WinPE version and architecture:

About Windows PE versions used in LANDESK Management Suite

One known issue is that Intel does not currently offer 32-bit USB3.0 drivers for Windows 8 or Windows 8.1.  If your WinPE version requires 8.0 or 8.1 drivers, you may be able to use the Windows 7 x86 driver provided by Intel.  You can test driver compatibility with your WinPE version; this document provides instructions:

How to test drivers compatibility within WinPE

Once you've tested the driver and you know it installs successfully and enables the USB3.0 stack, you can inject that driver into the boot.wim.

• Description
  • Identifying the Issue
    • No logging generated on the core
    • Missing LANDESK Management Agent service
    • Verifying the Inventory Record
    • Verifying the PXE.amsx Web Service functionality
    • Verifying the LANDESK Management Agent Service functionality
    • Machine shows "OFF"
      • Causes
      • Resolutions
    • In the event that the certificate files are not valid inside of the boot images

Description

This issue is characterized by selecting an OSD script from within the PXE Boot Menu inside WinPE, the Boot Menu window disappearing, and then no further pop ups or display windows occurring.

There are several causes for this behavior, and therefore, several possible solutions. This troubleshooting guide is centered around the issue of the OSD script failing to be initiated on the core server, or the OSD logs indicating that the machine is "OFF". If the OSD script indicates that it is launching at least one EXEC line against the target, then this troubleshooting guide can be skipped.

Possible Causes:

• Duplicate devices names in the database. 
  (Suggestion is to create a query based on target mac address and delete all instances that already exist in inventory)
• Miniscans being turned off for Inventory.
  (Under Configure Services > Inventory -> Advanced Settings the value for Ignore Mini Scans should be set to 0).
  

  If "Ignore Mini Scans" is set to 1", NO miniscans from the OSD client will be processed!   This must be set to 0.

• Core Server missing files in the \Program Files (x86)\LANDesk\Shared Files folder.
• Missing LANDesk Management Agent.
• No Inventory Record for target client (MAC address or full inventory record should exist)
• Certificate in boot image does not match certificate on core or certificate is damaged or missing.

Below is a visual representation of this a flowchart that diagrams this process:

           (Click for full size)

Identifying the Issue

To determine the troubleshooting path, it must first be determined how far the process is progressing. The fastest way to accomplish this is to determine if a CustJob log is being created. Follow the steps below to determine this:

1. On the core server, go to the log directory. This is located at the following path <Install Drive>:\Program Files (x86)\LANDESK\ManagementSuite\logs or can also be accessed via UNC share at <coreservername>\ldlog.

2. Once in the log directory, it is recommended to sort by Date Modified, with most recent at the top.

3. The log file will be named CJ-OSD-<scriptname>-<timestamp>.log

4. If there is a log file, open it with a text editor, such as Notepad or Word.

5. If the log file is similar to the one listed below, and indicates that the machine is OFF, then CBA is unable to contact the specified machine or CustJob has targeted an incorrect machine record.

"Machine","CbaStatus","ExitCode","Duration","Begin","End","Command"

"(OFF) XPSP2B","OFF","N/A","0:00:00","11/6/2008 12:19:28 PM","11/6/2008 12:19:28 PM","N/A"
; "Job Complete","0 Done","0 Failed","1 Off","0 Unknown"

 

If there is no log, then the process did not complete to the point of initiating CustJob to launch the OSD script. See below for actions.

First, verify that the following service are installed and running on the core server:

LANDESK Inventory Server

LANDESK Management Agent

If these services are running, it may be beneficial to restart these services. If the LANDESK Management Agent service is missing, go to the "No logging generated on the core" section below. Once restarted, reboot the machine into WinPE and select the script from the menu.  If the same behavior occurs, follow the indicated directions:

If there was no log file generated in the log directory on the core, go to the "No logging generated on the core" section below.

If there was a log and it indicated that the machine was OFF, go to the "Machine shows OFF" section below.

No logging generated on the core

The process to request a script to run on the client machine involves a series of processes to request, resolve and schedule the task from the client to the core server. The below steps will attempt to identify and resolve the issue related to these processes.

Missing LANDESK Management Agent service

If the core does not have a LANDESK Management Agent service, you can install this service by following the steps listed below:

1. On the core, pull up the Start > Run window

2. In the field, type or paste the following command and then hit enter:

"C:\Program Files (x86)\LANDESK\Shared Files\residentagent.exe" /register

Once the service is installed, start the service and then try the OSD process again.

If there is not a C:\Program Files (x86)\LANDESK\Shared Files folder on the core server, please contact LANDESK Technical Support for further assistance.

If the LANDESK Management Agent service is installed and running and a service restart did not resolve the issue, please follow these additional troubleshooting steps:

Verifying the Inventory Record

OSD needs an inventory of the device being imaged in order to create the task and begin logging.  New machines that have not been inventoried before will be listed by its MAC address in the Device Name column in the console.

If there is no inventory record for that device, restart the inventory service and reboot the client and try imaging again.  If still no inventory record appears for the device please contact LANDESK Technical Support for further assistance.

Verifying the PXE.amsx Web Service functionality

• Open the CoreWebServices.dll.log located in the log directory on the core server. The log should contain lines that are similar to those listed below:

RunScript: started with client mac address 000C29461DD1, script GUID bc6a8a9c-3edc-4845-83fb-5e1cceb60b71
RunScript: completed successfully with client mac address 000C29461DD1, script GUID bc6a8a9c-3edc-4845-83fb-5e1cceb60b71

Note: Each script has an associated GUID.  The GUID is contained in the Script (Located in the ManagementSuite\Scripts directory).   This must match in the PXEMENU table in the database in order for the script to be associated properly.

Line in Script: GUID=71e307da-bb27-46ab-ac8d-ef9641f3139f

Entry in Database:

• Can the LANDESK PXE.asmx web page be accessed? (Note: This must be run locally on the Core Server

• Open a web browser on the core and type/paste the following address:

http://localhost/LANDESK/ManagementSuite/Core/core.webservices/PXE.asmx

This should display the web page shown below:

• Will the GetObjIDFromMacAddress function resolve a Mac address to a Computer_Idn from the PXE.asmx web page?
  (Note: This must be run locally from the Core Server)

1. Click on the GetObjIDFromMACAddress link in the web site.

2. On the MAC Address field, enter in the mac with no spaces or dashes.

3. Click on the "Invoke" button to process.

4. The following return should be displayed:

NOTE: The number encased by > < is the object ID and corresponds to the machine's ID assigned by Inventory.

If this process fails, then there is most likely a missing record. Ensure that the Inventory contains the MAC address associated with a machine record.

Will the RunScript function start the job by manually putting in the MAC Address and ScriptGUID?
(Note: This must be run locally from the Core Server)

1. Click on the RunScript link in the website.

2. On the indicated fields, input the MAC Address and the script GUID.

3. Hit the Invoke button.

A CustJob window should launch on the core and start processing the script. You can also look to see if this process generates a log file in the log directory. If this process succeeds, then it indicates that IIS may be hung or not correctly processing SOAP requests.
Try running an "IISreset" command from Start > Run. You may also need to re-register ASP.NET on the core with the following command:

"C:\Windows\Microsoft.NET\Framwork\v4.0.30319\aspnet_regiis.exe -i"

• Enable OSD Web Tracing by doing the following:

1. Edit the web.config file in C:\Program Files (x86)\LANDESK\LANDESK\ManagementSuite\LANDESK\ManagementSuite\Core\Core.WebServices so that the line "<trace enabled="false"" reads "<trace enabled="true"" and restart the World Wide Web Publishing Service service.  (iisreset -restart also works)

2. The following URL may be used to pull up the Web Trace to track what requests are made to the OSD Web service on the core: (Note: This must be run on the LANDESK Core Server)

http://localhost/LANDESK/ManagementSuite/Core/core.webservices/trace.axd

• An http caching appliance will respond to the http requests made by the client. Due to the caching appliance responding, the client will not receive the subsequent lines of the script. Configure the caching appliance to not cache the http traffic from the Core Server.

Verifying the LANDESK Management Agent Service functionality

• Run script calls a local execute on the Core Server. The LANDESK Management Agent service must be running on the Core Server.

• To test the Management Agent service, run the following command line:

"C:\Program Files (x86)\LANDESK\Managementsuite\custjoblaunch.exe"

/objid=<object id of machine> /script="<script name without directory path>" /bootonly

For Example:

"C:\Program Files (x86)\LANDESK\Managementsuite\custjoblaunch.exe" 83 "DeployGhostImage.ini" /bootonly

If this does not launch the script, remove and re-install the LANDESK Management Agent service with the following commands:

Remove:

"C:\Program Files (x86)\LANDESK\Shared Files\residentagent.exe" /unregister

Install:

"C:\Program Files (x86)\LANDESK\Shared Files\residentagent.exe" /register

If these steps do not resolve the issue, please contact LANDESK Technical Support for further assistance.

Machine shows "OFF"

NOTE: When troubleshooting Inventory related issues, please ensure that you are logged in to the core console with a user that does not have any restricted scopes applied and that is allowed to view the Default All Machines scope.

Causes

1. Another machine in the database has the IP address assigned to the machine in WinPE.  Custjob.exe is targeting that device.

2. The inventory scan had not yet processed the ip address from the miniscan. This could be because the inventory service is stopped or hung.

3. Duplicate devices (two machines with the same MAC Address) in the database.

4. Core cannot contact the Agent on UDP port 9595 or port 38293. (Firewall, or other filtering device is blocking this port.)

5. Under Configure | Services | Custom Jobs, the Discovery setting may be set to TCP only.  WinPE only responds to UDP.

6. DNS can be in a state where the client can resolve the Core Server but the Core Server cannot resolve the agent workstation.

7. NIC driver may not be entirely functioning properly.

8. Name resolution problems may prevent the core from targeting the machine by DNS name.

Resolutions

1. Start or restart the Inventory Service.

2. Search for the IP address that WinPE has.  If another device has this IP address, delete that inventory record.

3. That device may show up twice in the database.  Delete all devices with that MAC Address.  See
   community article 1569 for assistance with this.

4. Open UDP ports 9595 39293 between the Core Server and the Agent workstation.

5. Go to Configure | Services | Custom Jobs and set the Discovery to try both UDP and TCP.

6. Go to Configure | Services | Custom Jobs and check the box to Disable DNS/WINS Lookup.

7. Make sure the Core Server can ping the Agent workstation by name and IP.

8. Update the NIC driver In the WinPE image.

9. Make sure the Core Server and PXE reps are running the same version of software.

10. Verify that the client miniscans are being received by the core server. Enable the Store Scans option in Configure | Service | Inventory | Advanced. Set the value to 1 and restart the Inventory service. Browse to the ldmain\ldscan\Storage directory and verify that .IMS files are being received when the client boots into WinPE.

11. Verify that the core is processing mini scans. Check Configure | Services | Inventory | Advanced | Ignore mini scans. This value needs to be set to 0.

In the event that the certificate files are not valid inside of the boot images

1. Navigate to \Program Files (x86)\LANDesk\ManagementSuite

2. Run "osd.upgrade.exe"

3. This will inject the proper core certificates into the boot images.

Description

When using LANDESK PXE it may be desired to remove some of the options listed on the PXE menus. There are also cases where too many options cause problems for some network cards. Whether removing them for convenience or to resolve and issue with the menu not showing up there are a number of ways to accomplish this. Three options are shown here:

• Manually Changing the PXE Representative    
• Customizing the PXE Deployment Script
• Deploying the PXE Rep with Modifications in a Transform File

Manually Changing the PXE Representative

The first option is to manually change the options onthe PXE Representative. On the PXE Representative, set the registry keys to 1 for the items that are to be disabled.

• HKLM\SOFTWARE\INTEL\PXE\ProxyDHCP\DisablePredefinedWinPE
• HKLM\SOFTWARE\INTEL\PXE\ProxyDHCP\DisablePredefinedDosPE
• HKLM\SOFTWARE\INTEL\PXE\ProxyDHCP\DisablePredefinedLinuxPE
• HKLM\SOFTWARE\INTEL\PXE\ProxyDHCP\DisablePredefinedProvisioningLinuxPE
• HKLM\SOFTWARE\INTEL\PXE\ProxyDHCP\ /v DisablePredefinedProvisioningWinPE

Note that on a 64-bit OS you will need to go to the 32 bit subsystem of the registry, which is found by adding Wow6432Node after Software as shown below.

• HKLM\SOFTWARE\Wow6432Node\INTEL\PXE\ProxyDHCP\DisablePredefinedWinPE
• HKLM\SOFTWARE\Wow6432Node\INTEL\PXE\ProxyDHCP\DisablePredefinedDosPE
• HKLM\SOFTWARE\Wow6432Node\INTEL\PXE\ProxyDHCP\DisablePredefinedLinuxPE
• HKLM\SOFTWARE\Wow6432Node\INTEL\PXE\ProxyDHCP\DisablePredefinedProvisioningLinuxPE
• HKLM\SOFTWARE\Wow6432Node\INTEL\PXE\ProxyDHCP\ /v DisablePredefinedProvisioningWinPE

Customizing the PXE Deployment Script

The second option is to use a custom PXE deployment script that calls a batch file to update the menu options. There is a custom script and associated batch file attached to this community article called UpdatePxeMenu.zip. The new script includes two additional lines that will download and execute the batch file. The batch file is commented and has details on how to disable each menu option within it. The DosPE option is set to disabled within the batch file. This new script allows the deployment of PXE reps with the configured options without having to modify the msi transform file as outlined below.

1. Download the UpdatePxeMenu.zip file
2. Extract the files
3. Place Pxe Representative Deployment w Menu Disable.ini in the \ManagementSuite\scripts directory. This will add an entry to the OS Deployment > OSD Scripts > All Other Scripts directory that can be used for PXE Representative deployment
4. Place UpdatePxeMenu.bat in the \ManagementSuite\landesk\files directory. This is the directory where the PXE Representative deployment script will access the file
5. Run the new script to deploy your PXE Representatives

Deploying the PXE Rep with Modifications in a Transform File

The third option available in 8.7 Service Pack 1 and later this can be done during the PXE Representative deployment by using a TRANSFORM file with OSDRep.msi. It is also necessary to create a new PXE Representative Deployment Script that uses the Transform File.

To create an MST do the following:

1. Install ORCA
2. Note: The Orca.msi can be found after installing the Windows Installer feature of the  Microsoft Platform SDK.
3. Open OSDRep.msi with Orca (OSDRep.msi can be found on the Core server at <drive>:\Program Files\LANDESK\ManagementSuite\LANDESK\files)
4. In Orca, click on Tranforms | New Transforms.
5. Click to highlight the Registry option on the left pane.
6. On the right pane, click the Name heading to sort by name.
7. Locate the following values.
   • DisablePredefinedWinPE
   • DisablePredefinedDosPE
   • DisablePredefinedLinuxPE
8. To disable the desired values, change the value from 0 to 1.
9. In Orca, click on Transforms | Generate Transform.
10. Save the Transform as name it OSDRepF8Options.mst. Save it in the same directory as OSDRep.msi.

Modify the PXE Representative Script

The PXE Representative Deployment Script must now be copied and the copy must be modified.

1. Make a copy of the "PXE Representative Deployment Script.ini" and name it "PXE Representative Deployment with MST to Disable F8 Options.ini".
2. Make the following changes:
   • Add a new line that downloads the OSDRepF8Options.mst.
   • Modify the installation line to add the TRANSFORMS property to the MSI switches. An example of the new line and the edited line are given below:

REMEXEC20=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="http://%CUSTJOBHOSTIP%/landesk/files/OSDRepF8Options.mst"
REMEXEC21=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /p="http://%CUSTJOBHOSTIP%/landesk/files/osdrep.msi" /msi /N /An /Ac /cmds=TRANSFORMS="""%LDMS_CLIENT_DIR%\sdmcache\OSDRepF8Options.mst"""

More information on PXE boot errors:

PXE Boot errors and descriptions.

How to trouble shoot LANDESK PXE:

Troubleshooting PXE boot (OSD)

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)

Issue

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

Cause

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

Resolution

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

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

LANDesk Management Suite 9.0 and later

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

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

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

          Delete the following Registry Keys for 64 bit clients:

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

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

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

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

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

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

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

See Community discussion for additional tips and information:

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

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 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)