Provisioning for LANDESK Management Suite

• This is a list of highly recommended documents for increasing overall knowledge of this component.
• The articles listed below are applicable to LANDESK Management Suite 9.5 and 9.0.
• If you want to review additional content regarding this component, please use the Provisioning Discussion Tab or Provisioning Documents Tab

Initial Install and Configuration

• Getting Started With LANDESK Provisioning in LDMS 9.5
• Create and use a "provisioning agent" for end to end provisioning
• Use a "single agent install" to create and use a "provisioning agent" for end to end provisioning

Additional Information

• About changes to Provisioning Action Handlers in 9.5 SP1
• About Provisioning Action Handlers - Changes in LDMS 9.5
• About LANDesk Hardware Independent Imaging (HII)
• About the LANDESK HII Driver Repository
• About the LANDESK HII Driver Database

"How To" Documents

General

• How to detect and Install Patches within Provisioning
• How to migrate from XP to Windows 7 in LDMS 9.0 using Provisioning
• How to use ImageX with LANDESK Management Suite
• How to Import/Inject Scripts in Provisioning
• How to: Build a Profile Migration Command Line with sample script

HII (Hardware Independant Imaging)

• How to add drivers to WinPE for LANDESK Management Suite 9.5
• How to manage drivers using the HII tool
• How to use HIICLIENT in preview mode
• How to use DISM to manually inject drivers into the Boot.wim

PXE

• How to configure DHCP to work with LANDESK PXE boot
• How to: Redeploy PXE Representatives
• How to troubleshoot the LANDESK PXE Process

Troubleshooting this Component

General Troubleshooting

• How to troubleshoot OSD: The log files

PXE Issues

• How to troubleshoot the LANDESK PXE Process
• How to troubleshoot PXE boot (OSD and Provisioning)

Template Issues

• How to troubleshoot Provisioning Template Action Handlers
• How to troubleshoot the Configure Target OS action in Provisioning template

Windows PE Issues

• How to Troubleshoot WinPE hanging after selecting an OSD script from the Boot Menu.
  

NOTE:This article is not a comprehensive list of documents and issues. You can continue to search the rest of the community or the portion specific to Provisioning if this page has not helped.

I want to show you how I fixed all of our HII Problems in 9.5 SP1 and dramatically speeded up the provisioning process with a few simple steps.
We working with this method for weeks now without any problems...so I wanted to share it to the community.

Benefits:

No DELL USB 3.0 Driver Problems, No more Blue Screens after StandBy Mode, No mixing of drivers because of generic Hardware IDs, massivly speeded up Provisioning Process

Steps:

1. Create a Driver Share like this
   
   You get this Drivers from here: Dell Driver CAB files for Enterprise Client OS Deployment
2. Become familiar with the oldschool Copydrivers.exe-Tool and populate the .ini like this.
   
   
3. Edit your Provisioning Template
   Map a Network Drive to preferred Server
   
   
   Run the Copydrivers.exe with /c
   
   
   Run the Microsoft DISM-Command
   x:\windows\system32\dism.exe
   /image:c:\ /add-driver /driver:"c:\Drivers" /recurse /forceunsigned
   
4. DELETE HII from the Template (its not needed in the POST-OS Section anymore)
   

Now your Windows Installation has all drivers that are needed right for this computer model.

Kind regards,
Marco Feuerstein

Germany

Hi.

I am experiencing a random and intermittent issue with provisoning, where some machines will get stuck on the System Configuration stage of the Image Template.

It ssems that it does not relate to machine model or type.

We tested 8 laptops and tested 2 different images and found the following:

x220 - Image A (Successful) TYPE 4291-2XG

X230 - Image A (Successful) TYPE 2325-62G

x240 - Image A (Successful)

x240 - Image A (Successful)

x220 - Image B (Failed) tasks fails at mapping a network drive. TYPE 4291-2XG

x220 - Image B (Successful) TYPE 4291-2XG

x230 - Image B (Failed) tasks fails at mapping a network drive. TYPE 2325-20G

x230 - Image B (Successful) TYPE 2325-20G

It has happened before where this action actually locks the scheduler account that we have in place.

This does not appear to be an issue with x240s, nor does this appear to relate to machine type.

Any advice on what could be causing this issue ?

Hi all,

Got our first Dell M6800 laptop in this week, am getting Win7 x64 drivers prepped for OSP with HII....downloaded the latest Dell enterprise driver pack for this model, imported into the driver library, assigned the needed drivers.

For whatever reason, when attempting OSP, HII just will not download two specific driver files...one's not terribly important, the Dell touchpad driver (specifically the file DellTPAD.exe) and the Centrino Untimate N drivers, which are much more important (netwsw00.sys specifically).    I just cannot determine why these two specific files aren't able to be downloaded....I have tried UNC as well as HTTP, I can manually download both files either way, but HII doesn't seem to be able to.

HIIclient.log doesn't seem to indicate any problems other than the failed DISM command at the end, return code 2.   The files are listed in the list of files to be downloaded

Setupapi.offline.log shows the following errors for each file...

!!!  flq: Error installing file (0x00000002)

!!!  flq: Error 2: The system cannot find the file specified.

!    flq:      SourceFile   - 'c:\Windows\LDDriverStore\M6800-win7-A05-DPCCC\M6800\win7\x64\input\323GH_A00-00\win7x64\production\Windows7-x64\DellTPad.exe'

!    flq:      TargetFile   - 'c:\Windows\System32\DriverStore\FileRepository\apfiltr.inf_amd64_neutral_8c7ba743a1167e82\DellTPad.exe'

!!!  sto: Failed to copy file 'c:\Windows\LDDriverStore\M6800-win7-A05-DPCCC\M6800\win7\x64\input\323GH_A00-00\win7x64\production\Windows7-x64\DellTPad.exe' to 'c:\Windows\System32\DriverStore\FileRepository\apfiltr.inf_amd64_neutral_8c7ba743a1167e82\DellTPad.exe'. Error = 0x00000002

!!!  flq: SPFQNOTIFY_COPYERROR: returned SPFQOPERATION_ABORT.

!!!  flq: Error 995: The I/O operation has been aborted because of either a thread exit or an application request.

!!!  flq: FileQueueCommit aborting!

!!!  flq: Error 995: The I/O operation has been aborted because of either a thread exit or an application request.

!!!  sto: Failed to copy driver package to 'c:\Windows\System32\DriverStore\FileRepository\apfiltr.inf_amd64_neutral_8c7ba743a1167e82'. Error = 0x00000002

!!!  sto: Failed to import driver package into Driver Store. Error = 0x00000002

Checking that source location, the file is in fact not there....I assume that means it was never downloaded from the driver store.   So....what else should I look at to find out why?   I am really stumped.

Thanks!

We used to have this in our PXE server and unsure what happened but long story short:

We want to know how to add tools like clonezilla, memtest, etc to our PXE server F8 menu so that we can boot them without the CD. Every solution I have seen seems to relate to PXELinux.

Thanks

Applies to LANDesk Management Suite 9.0

This article discusses many topics related to provisioning.  It is recommended to read and understand all the Provisioning Basics and Provisioning Tips and Tricks in the Provisioning Launch Page located here:

LDMS Provisioning Launch Page

XP to 7 Migration Scenario

With the emergence of Windows 7 and the end of support announcements by Microsoft migrating from Windows XP to Windows 7 is becoming more and more of an issue in many environments.  Many times people want to know what the LANDESK provisioning process can do to help them accomplish that.  The answer is: Pretty much all of it.

The problem is that there is so much you can do with it that it can become difficult to design and implement the migration path that you would like.  This document attempts to combat much of that problem.  It has the migration process broken out into logical steps, and each step will have information and/or 1 or more sample templates that show some of the more common options that can be used to create an end to end migration process.  Each template provided here should be completely self contained and modular, meaning where there is more than one way to accomplish a task you should be able to choose which option you would like to use and plug it in with any of the options from the previous and following steps.

If anyone has any steps or samples that they would like to provide please mention that in the comments, or e-mail them to mach6@landesk.com with a clear explanation of what they are/what they do.  I believe this article can be a great opportunity to leverage the knowledge and expertise of the Community so we don't all need to recreate the same process.

XP to 7 Migration Steps Overview

I have divided up the XP to 7 migration process into approximately 7 steps.  These steps are:

1. Capture user profiles from the existing machine
2. Get into Windows PE to continue
3. Deploy Windows 7 (with HII)
4. Post Imaging Customizations (such as join the domain, etc.)
5. Install Software
6. Detect and install patches
7. Deploy the previously captured image

Some of these steps can be moved around, but this basic outline should provide an idea of what challenges need to be overcome, as well as provide an organized method of solving individual problems that work together to form a complete solution, rather than a single overwhelming task.

XP to 7 Solutions and Information

Choose an adventure for each step.  If you choose adventure 1a that does not mean you need to stick with 2a, 3a, etc.  Each step should allow you to mix and match to custom build the process that will work best for you in your environment.  Some steps (in particular 4) can have multiple adventures chosen, depending on your needs.

1 - Capture Profile

     Adventure 1a. Using LANDesk Profile Migration

          Information:

               Best Known Methods for Profile Migration in LANDesk 9.0

          Sample Template:

               Profile Migration Templates for Provisioning in LANDesk 9.0

     Adventure 1b. Using Microsoft USMT

          Sample Template:

               Provisioning - Steps to use User State Migration Tool (USMT) to capture a profile

               NOTE: This document was originally written for LDMS 8.7 and may not be current.  I have some USMT sample templates that will be tested and released in the near future.

2 - Get into WinPE

     Adventure 2a. PXE Boot

          Information:

               This option requires a PXE Representative to be deployed on each subnet and for every computer that will be migrated to have PXE Boot be the default boot option.

     Adventure 2b. VBoot

          Sample Template

               LDMS 9.0 Provisioning - Vboot Sample Template

               Note: As of 9.0 SP2 this sample template will no longer be needed, as the reboot action will have a Vboot reboot option.  Please read the attached document for important warnings about using Vboot.

3 - Deploy Windows 7 (with HII)

     Adventure 3a. Image Deploy

          Information:

               Best Known Method for Deploying Windows 7 - Revision 3 updated 3/19/2010

          Sample Template:

               Advanced Windows Image Deployment Provisioning Templates - Windows XP, Vista, 7

     Adventure 3b. Scripted Install

          Sample templates will be coming soon.  A fairly simple Scripted Install with HII process has been made possible as of 9.0 SP1.  An article will be created in the coming days to show the process.  That article will be linked here.

4 - Post Imaging Customizations

     Adventure 4a. Install LANDESK Agent

          Information:

               Create and use a "provisioning agent" for end to end provisioning

     Adventure 4b. Join Domain

          Information:

               Use Join Domain Action

     Adventure 4c. Any other custom type actions

          Information:

               This can be any other action that would need to be done to "customize" the environment.  Usually this would be done through a batch file or script, but can also be a series of individual actions.  Some examples and best practices will be coming soon, including how to run different customizations depending on the manufacturer/model of the computer.

5 - Install Software

     Adventure 5

          Information:

               Use the distribute software action.

          Sample Template:

               Deploying Multiple Software Distribution packages at one time, and in a specific order

6 - Detect and Install Patches (use provisioning agent with provisioning Scan and Repair Settings)

     Adventure 6

          Information:

               Detect and Install Patches within Provisioning

               How to use Custom Groups to quickly bring a Computer up to date.

7 - Restore profile (must use same method as capture)

     Adventure 7 a. Using LANDesk Profile Migration

          Information:

               Best Known Methods for Profile Migration in LANDesk 9.0

          Sample Template:

               Profile Migration Templates for Provisioning in LANDesk 9.0

     Adventure 7b. Using Microsoft USMT

          Sample Template:

               Provisioning - Steps to use User State Migration Tool (USMT) to capture a profile

               NOTE: This document was originally written for LDMS 8.7 and may not be current.  I have some USMT sample templates that will be tested and released in the near future.

Conclusion

The documents and sample templates provided should allow for each step of the migration process to be tested independently, and then put together in fully functional master template.  If anything is missing, incorrect, or doesn't work please add a comment or e-mail me at mach6@landesk.com.

It always happens again, that a client stays active in the provisioning task, but when I look trough the Provisioning history all actions are done.

I checked the ldprovision.log and it seems, the client lost connection after a reboot (it's not at the end from the template). After several tries of calling the webservice, the log ended. BUT ca. five minutes after the last entry in the log, I can see he has done the further actions. The executefilehandler.log shows me that he executed the last action.

In the picture you can see all action are checked successful and I saw, he ran the last actions. So why ended the provisioning logs and why is this client still active. Had anyone else to do with such a behavior?

Purpose:

How to query for machines that are PXE representatives.

A typical scenario for building such a query is to find out of there is more than one PXE representative on a subnet.   The default "PXE Representatives" group in the console does not return IP address as a column.

Steps:

1. Create a New Query.
2. Name the New Query.
3. Under Machine Components navigate to Computer > OS > Drivers and Services > Service > Name.
4. Select the equals(=) operator.
5. Under Display Scanned Values, select LANDesk(R) PXE Service.
6. Select Insert.
7. Under Select Columns: navigate to  Computer > Network > TCPIP > Bound Adapter > IP Address.
8. Click the Include (>>) button.
   
9. Select Save.

Issue

The following error occurs when attempting PXE boot:

PXE-E74 bad or missing PXE menu and or prompt information

• No F8 boot menu appears.
• The proxy IP indicates the correct address.
• Re-deploying the PXE representative does not resolve the problem.
• Installing PXE rep on another machine does not resolve the issue.

Cause

• The PXE rep installation software is corrupt.
• Port 69 Traffic is blocked to the PXE Representative
• The PXE Agent embedded in the firmware of the NIC is handling DHCP option 43 incorrectly
• Multiple PXE representatives on one subnet.
• The BIOS and NIC firmware have a limited capacity for PXE Boot Menu options. This has been seen on a number of computers including:
  • Lenovo machines with BIOS 3.11 or later

Resolution

Disable some PXE Boot Menu options

• It has been found that some updated versions of BIOS from some manufacturers do not properly handle large PXE boot menus
• To reduce the PXE boot options see: 'How to hide LinuxPE, WinPE, or DOS PE PXE Boot Options from the F8 Menu?'
• It is recommended to remove the LinuxPE and DosPE options, as they are normally not used

Obtain a new PXE Representative installation package from LANDESK Support.

• Copy the osdrep.msi file into the C:\Program Files\LANDESK\ManagementSuite\landesk\files folder.

• Run the PXE Rep deployment script on the target machine.

Enable traffic on port 69 to the PXE Representative

• This would be configured in the client firewall, or possibly a switch on the network

DHCP Options 43 and 60 should not be used when using LANDESK to PXE boot

• Options 43 and 60 should not be configured on the DHCP server when using LANDESK PXE boot as they will conflict with the information and data sent to the client from the PXE representative. See below for steps to resolve this.

DHCP Server

1. Open DHCP on DHCP Server
2. Go to -> Scope -> Scope Options
3. Right click and choose Scope Options and choose Configure Options
4. Uncheck either option 060 and option 043 (they are not be needed)

DHCP Configuration when using LANDESK PXE Boot

When neither option 60 nor option 43 is set, PXE clients will wait until a PXE server contacts them. The LANDESK PXE representative will listen to DHCP discovery packets sent by PXE clients and answer at the same time as the DHCP server does. The LANDESK PXE and LANDESK PXE MTFTP services on the PXE representatives handle the requests made by clients attempting to PXE Boot.

In order to support PXE clients on a network, the DHCP server is usually configured in one of the following three modes:

• Option 60 not set, Option 43 not set
• Option 60 set to 'PXEClient', Option 43 not set
• Option 60 set to 'PXEClient', Option 43 set

When neither option 60 nor option 43 is set, PXE clients will have no clue where the PXE server is, and they will therefore wait until a PXE server contacts them. In this mode, the PXE server must listen to DHCP discovery packets sent by PXE clients and answer at the same time as the DHCP server does.

When option 60 is set to 'PXEClient', it means that the DHCP server knows where the PXE server is. If option 43 is not set, the PXE server is on the same computer as the DHCP server (same IP address). If option 43 is set, PXE clients must decode option 43 to know how to reach the PXE server.

In most situations, option 43 does not need to be setup, because the PXE server will either listen to DHCP discovery packets (DHCPProxy), or be on the same computer as the DHCP server. However, if the PXE server is on a separate subnet (it cannot listen to DHCP discovery packets), or if there are several PXE servers on the same subnet, option 43 is the only viable solution in order to instruct PXE clients on what to do.

Multiple PXE Representatives on a subnet

Multiple PXE representatives on a subnet can cause problems with the PXE boot process.  In addition other non-LANDESK PXE boot solutions can also cause issues and will not co-exist with the LANDESK PXE solution.

The following query can be created to find the IP address of all PXE Representatives (or the query can be modified to return other criteria if so desired)

How to: Create a LANDESK Query to find all PXE Representatives

For more information on PXE boot errors please see:

PXE Boot errors and descriptions.

For more information on troubleshooting PXE boot please see:

Troubleshooting PXE boot (OSD)

Issue:

After adding a device using the "Add Bare Metal Server" wizard, no new device shows up in the device list.

To add Bare Metal device entries to the console, the following steps should be taken:

1. From the console's Network view drill down to Configuration - Bare Metal Server
2. Right-click and choose Add devices
3. Click Add
4. Give the machine a name
5. Enter Identifier like the MAC address
6. Click Add
7. Click OK twice

Cause:

Typically this is caused by the Inventory Server Service on the core server not running.

Possible workaround if the Inventory Service is running:

You can run barescan.exe from the managementsuite directory.

barescan.exe -v core=<CoreServerName> name=test mac=123456789aac

 

Replace <CoreServerName> with the name of the Core Server to create the Bare Metal device on.
This will create an inventory scan file that resembles the following:

 

Device ID =Agentless

Scan Type =BAREMETAL

Type =Bare Metal Provision

Last Hardware Scan Date =1397079334

Display Name =test

Device Name =test

Network - NIC Address =123456789AAB

Network - TCPIP - Host Name =test

OS - Name =Bare Metal

LANDesk Management - Inventory - Scanner - Type =Bare Metal Provision

LANDesk Management - Inventory - Scanner - File Name =barescan.exe

Network - TCPIP - Bound Adapter - (Number:0) - Physical Address =123456789AAB

 

Barescan.exe then places this in the LDSCAN folder on the core server and it gets processed by the Inventory scanner

Resolution:

The first thing to check when this happens is to look at the Inventory Server Service to make sure that it is running.  Any entry in the console for Bare Metal devices will need the Inventory Service running in order to insert the device into the database.

If the Inventory Service is in a state of "Starting", then there is a problem and the core may need to be rebooted to resolve.  If this does not resolve the problem with the Inventory Service starting, there may be an issue with the database or with connectivity to the database.

To resolve this issue the following steps should be taken:

Add non-LDMS administrator account to the LDSCAN folder with the following Security Permissions:

• Modify
• Read & Execute
• List Folder Contents
• Read
• Write

Determine what is causing the Inventory Service to not start. 

Once the Inventory Service will start the Bare Metal devices should show up in the database.

One of the most common uses of Provisioning is to extend the capacities and functions of imaging or new device deployments to include the installation of the OS as well as configuration settings and software installations. In order to bridge the gap between WinPE and the new OS, LANDESK uses a process called Configure Target OS (abbreviated as CTOS). This is a separate action that needs to be added to the template for a template that installs an image, and is included as part of the Scripted Install action. This article covers the function and troubleshooting of the Configure Target OS action

Configure Target OS overview

The Configure Target OS (CTOS) action is available only in the Post-OS installation section of the provisioning template. It needs to be the final action in the template before the System Configuration section, no actions can come after the CTOS action. The CTOS prepares the device to resume provisioning after the client boots into the target OS, then restarts the device, leaving WinPE and allowing the computer to boot normally. In order for the CTOS action to work, the image that was deployed to the client MUST be sysprepped.

The Configure Target OS takes advantage of a few Microsoft technologies in order to resume when the device completes booting into the target OS (Windows XP, 2003, 2008, 7, 8, 8.1, 2012). Files are injected to the root of the OS drive (C:\ldprovision) and commands are added to the appropriate files such that they are run during the mini-setup just prior to booting into the target OS.

Windows XP/2003

1. All needed files are copied to C:\sysprep\i386\ldprovision directory on the client device. The C:\sysprep\i386 directory must exist and be accessible
   
   Note: Sysprep is responsible for creating the i386 folder.  If the folder is not getting created, you can get around the issue by creating a new action in the script, putting the action in front of the CTOS action, that creates this folder.  If this folder does not exist it will cause the failure of any additional action after CTOS runs and reboots the client.
   
   
2. The cmdlines.txt file in the OEM folder on the client device is created or modified. A line is added to call ldprovisioning.cmd. Windows will run cmdlines.txt at the end of the mini-setup, calling ldprovisioning.cmd.

Windows 7, 8, 8.1, 2008, 2012

1. All needed files are copied to C:\ldprovisioning directory on the client device.
2. The unattend.xml is modified and commands are added to call ldprovisioning.cmd from the C:\ldprovisioning directory.

LDProvision.cmd

When run, ldprovisioning.cmd installs the basic LANDESK CBA agent in C:\Program Files\LANDESK\LDClient and configures it as a service to start on OS boot. It also modifies the actions.ini file in C:\Program Files\LANDESK\Shared Files\cbaroot to contain a line pointing to C:\ldprovision\ldprovision.exe with the needed command line options. The actions.ini file is used by the LANDESK CBA agent as instructions when starting, so the commands contained therein are run when the service starts.

Troubleshooting Configure Target OS

Troubleshooting the CTOS action can be especially difficult. Because of the nature of the operation and how it works, LANDesk must give up control to the Windows installation processes for a time, and then resume afterwards. This can sometime make it difficult to determine where the problem is occurring. The problem can be in WinPE trying to copy and modify files, it can be somewhere in the mini-setup of the OS, and it can be after the OS has completed all setup tasks and has fully booted.

The first step to troubleshoot the CTOS action is to determine where in the process the failure is occurring. The CTOS action will not always get marked as failed. Often provisioning just fails to continue through the rest of the template.

WinPE

This is where it is most likely to see an actual failure of the template. Usually this means something could not be copied correctly or modified. The device will stay in WinPE after the template fails so troubleshooting can be done in the exact condition the device is in when it fails.

1. Open a new console in WinPE.
2. Check to make sure that the C: drive is accessible.
3. Change to the C: drive and look around. Does it look like the image was put down correctly?

If you deployed:

     Windows XP/2003

1. Change to C:\sysprep directory. Verify that the I386 directory exists. Look to see if the ldprovision folder was created and populated

   1. Note: Sysprep is responsible for creating the i386 folder.  If the folder is not getting created, you can get around the issue by creating a new action in the script, putting the action in front of the CTOS action, that creates this folder.  If this folder does not exist it will cause the failure of any additional action after CTOS runs and reboots the client.  This also prevents the $OEM$ directory from being created in the i386 folder.
      

2. Check the cmdlines.txt in C:\sysprep\$OEM$\ and make sure it contains a line for ldprovisioning.cmd
3. Verify that ldprovisioning.cmd is in C:\sysprep\$OEM$\

     Windows 7, 8, 2008, 2012

1. Change to C:\ldprovisioning directory. Verify the ldprovisioning.cmd is in the folder and the folder is populated. It should contain over 20 files.
2. Verify that the unattend.xml exists in C:\Windows\Panther
3. Verify that the commands calling ldprovisioning.cmd exist in the unattend.xml for the platform (x86, amd64, ia64) you have deployed.

     Windows 8.1

1. Change to C:\ldprovisioning directory. Verify the ldprovisioning.cmd is in the folder and the folder is populated. It should contain over 20 files.
2. Verify that the unattend.xml exists in C:\Windows\Panther
3. Verify that the content of the file %windir%\Windows\Setup\scripts\SetupComplete.cmd contains the following line; %systemdrive%\ldprovisioning\ldprovisioning.cmd

Sometimes all of these will be correct and ready to go, but the device will remain in WinPE. Usually there is not a failure of the task. It is possible that the reboot command didn't run correctly but everything else did. To verify this, simply restart the client and observe the results.

Between WinPE and Windows

After the client reboots out of WinPE it will boot off the hard drive into the target OS. Because the image was sysprepped, it will go through a mini-setup process. If no sysprep file was provided, it will prompt for a number of items such as the computer name, user names, time zone, product key, etc before completing the booting process into the target OS.  LANDesk has no control over this process and is not running at all. Near the end of the mini-setup process Windows executes the commands that LANDesk added during the CTOS action. For Windows XP and 2003 the mini setup executes the commands in the cmdlines.txt at then end of the sysprep steps. For Windows Vista, 2008 and 7 the commands are exeucted during the Specialize pass in the unattend.

Windows XP/2003

The important file here is the cmdlines.txt This file should contain the call to ldprovisioning.cmd. It is here that LANDesk is again introduced into the process. When cmdlines.txt is executed it runs ldprovisioning.cmd from the same directory, which prepares the device to resume provisioning after the whole mini-setup process is complete.

Windows 7, 8, 2008, 2012

Sections are added to the unattend.xml in the Specialize section. This is a special section of the unattend.xml that can also be used for things like setting the home page for Internet Explorer, etc. In this section, the RunSynchronousCommand action is added calling ldprovisioning.cmd from C:\ldprovisioning\. The section of the unattend will look roughy like the following:

<settings pass="specialize" xmlns="" wasPassProcessed="true">
    <component name="Microsoft-Windows-Deployment" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <RunSynchronous>
            <RunSynchronousCommand action="add">
                <Description>LANDesk Provisioning Install</Description>
                <Order>1</Order>
                <Path>cmd /c %systemdrive%\ldprovisioning\ldprovisioning.cmd</Path>
            </RunSynchronousCommand>
        </RunSynchronous>
    </component>
</settings>

Windows 8.1

As mentioned in Add a Custom Script to Windows Setup a command line is injected within the SetupComplete.cmd (%systemdrive%\ldprovisioning\ldprovisioning.cmd) which will then be run after the reboot following the mini-setup phase. Hence, the system will follow the provisioning process when rebooting.

In Windows

Once the device completes the mini-setup section, it will boot into the final OS. As the device boots up, it runs the LANDesk Management Agent service that was installed by ldprovisioning.cmd. As part of the startup process, the LANDesk Management Agent will run the commands in the actions.ini file. The actions.ini file was also modified by ldprovisioning.cmd to contain the following command

C:\ldprovisioning\ldprovision.exe -c <CORE>

Troubleshooting Tip: If you would like to get extra logging for problems you are seeing later in the template, open this file BEFORE the device completes the boot after the mini-setup and change it to the following:

C:\ldprovisioning\ldprovision.exe -c <CORE> -V 255 -L C:\<LOG FILE>

       Note: the -V is a capital V and is case sensitive

Once ldprovision.exe starts, it queries the core server for the next action in the template, and provisioning will continue with the actions in the System Configuration section.

───────────────────────────────────────

See also CTOS action fails after reboot.

Hello,

In a provisionning template, we can choose the action "Reboot/Shutdown" and then use "Boot to Managed WinPE(Virtual Boot)" to simulate a PXE boot.

The big problem is that the boot.wim image is copied from the core server, and not from preferred server. (so 127MB WAN trafic for a computer in another country)

So my request : what is the exact command lines executed when action is Reboot : "Boot to Managed WinPE(Virtual Boot)"

I want to make a script or template to download boot.wim file from preferred server, and not from core server.

Thanks

(i can't understand why LANDesk doesn't have thought about to be able to provisionning exclusively from preferred servers (LAN traffic) to avoid WAN traffic...)

Currently in 9.5 we have a home grown way to  vboot from the sites preferred server so we don't have to keep pushing the 200+ meg wim file across the wan link to the target devices at remote site.  Some of tour remote sites in other countries have a very small pipe(<1 meg) and there is just no way we can push this 200 megs over and over again for re imaging

So in 9.5 we did the following as a work around.  Basically we are using template actions to do this exact work that is found in the OSD script but we copy the files that are needed from the local preferred server.

Example of the section in the osd script below. 

REMEXEC0=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="http://%CUSTJOBHOSTIP%/landesk/vboot/bootfile.exe"

REMEXEC1=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="http://%CUSTJOBHOSTIP%/landesk/vboot/tlibr16.dll"

REMEXEC2=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="http://%CUSTJOBHOSTIP%/landesk/vboot/tlibr32.dll"

REMEXEC3=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="http://%CUSTJOBHOSTIP%/landesk/vboot/lddefrag.exe"

REMEXEC4=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="http://%CUSTJOBHOSTIP%/landesk/vboot/cicfgmgr.vxd"

REMEXEC5=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="http://%CUSTJOBHOSTIP%/landesk/vboot/cindis.vxd"

REMEXEC6=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="http://%CUSTJOBHOSTIP%/landesk/vboot/copyfile.exe"

REMEXEC7=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="http://%CUSTJOBHOSTIP%/landesk/vboot/tokreplw.exe"

REMEXEC8=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="http://%CUSTJOBHOSTIP%/landesk/vboot/boot.img"

REMEXEC9=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="http://%CUSTJOBHOSTIP%/landesk/vboot/ChangeBCD.exe"

REMEXEC10=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="http://%CUSTJOBHOSTIP%/landesk/vboot/BCD"

REMEXEC11=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="http://%CUSTJOBHOSTIP%/landesk/files/bcdedit.exe"

REMEXEC12=<qt/>%LDMS_CLIENT_DIR%\ChangeBCD<qt/> <qt/>%LDMS_CLIENT_DIR%\bcdedit.exe<qt/> <qt/>%LDMS_CLIENT_DIR%\BCD<qt/>

REMEXEC13=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /dest="C:\boot.wim" /p="http://%CUSTJOBHOSTIP%/landesk/vboot/boot.wim"

REMEXEC14=<qt/>%LDMS_CLIENT_DIR%\copyfile.exe<qt/> <qt/>%LDMS_CLIENT_DIR%\boot.img<qt/> <qt/>%LDMS_CLIENT_DIR%\BCD<qt/> \boot\BCD

REMEXEC15=<qt/>%LDMS_CLIENT_DIR%\lddefrag.exe<qt/> <qt/>%LDMS_CLIENT_DIR%\boot.img<qt/>, STATUS

REMEXEC16=<qt/>%LDMS_CLIENT_DIR%\bootfile.exe<qt/> %LDMS_CLIENT_DIR%\boot.img /keep /bootunsafe, ASYNC

We want to do the same for 9.6 but the vboot files are very different. Seems like they are only 3.   Since there is no OSD scripts in 9.6 that we can take a peak at to see how this is done, does any one know how to achieve this in 9.6?  I personally cant believe that VBOOT from pref server inst an option. Landesk needs to realize that although most places in the US have very high speed fat pipes they are just as many places around the globe that does not.  This is where Pref. Servers play a crucial role in having a replica of the data that is stored locally and is reliable unlike a peer.   Hopefully landesk will add this feature in later releases and expand on the roles of preferred servers.  But for now any advice on how to get this done would be great!

Issue

Provision.log on the core server is filled with these linesfor Unable to find template for computer IDN 11108.

The log is similar to this one:

ERROR ProvisioningService 3/29/2011 7:29:38 AM : Unable to find template for computer IDN 11108
VERBOSE ProvisioningService 3/29/2011 7:29:49 AM : GetTaskXML, SIDS:
VERBOSE ProvisioningService 3/29/2011 7:29:49 AM : MACAddress: BC305BCFDFB4
VERBOSE ProvisioningService 3/29/2011 7:29:49 AM : SerialNumber: J68B8P1
VERBOSE TemplateFinder 3/29/2011 7:29:49 AM : >>GetTemplateForServer,computerIDN 11108
DEBUGGING TemplateFinder 3/29/2011 7:29:49 AM : >>GetProvisioningTaskForComputer.computerIdn 11108
INFO TemplateFinder 3/29/2011 7:29:49 AM : No task found. Check task with Done status.
ERROR TemplateFinder 3/29/2011 7:29:49 AM : couldn't find task for computer 11108

Resolution

In some rare circumstances the provisioning process ''forgets'' to remove that line from the actions.ini file and so the client calls the web service method GetTemplateForServer on the core server to ask to the core "what I should do?"

The provisioning for this machine is already terminated (or canceled) and so the core replies ''I do not know" and writes it in the log.

The solution is the following:

Stop the LANDESK services on the device and start them again.

Access the client identified with the Computer ID that is ''spamming'' the log

1. Launch CMD.EXE as administrator.
2. Issue the commands:
   

   CD "C:\Program Files (x86)\LANDesk\Shared Files\cbaroot\"
   NOTEPAD actions.ini

   
   a. Launch CMD.EXE as administrator
   b. Issue the following commands:
   

   CD "C:\ProgramFiles (x86)\LANDesk\Shared Files\cbaroot\"
   NOTEPAD actions.ini

3. Remove the line where the provisioning is referenced.
   It should be something similar to this one:
   

   "landesk.provisioning=C:\ldprovisioning\LaunchLdprovisionAsUser.exeC:\ldprovisioning\ldProvision.exe-c PEBLNDSK01 -t C:\ldprovisioning-w 15 -r 20"

4. Save the file.
5. Open the file again with Notepad to be sure that the modification has been saved.
6. Reboot the machine

Description:

This document only applies if you already set up Product to Package Mapping in 9.5 and after upgrading to 9.6 you only get a blank screen when opening it the Product

If you just installed 9.6 and have not yet set up Software License Monitoring please go here: How to configure Product to Package Mapping and install Mapped Software

Cause:

When the database upgrades it runs coredbutil.exe /xml=provisioning.xml /buildcomponents. If you look at the coredbutil.exe.log in ManagementSuite\Log on the Core you'll find this error.

ERROR 4320:1    DataServices : System.Data.OleDb.OleDbException (0x80040E14): ALTER TABLE only allows columns to be added that can contain nulls, or have a DEFAULT definition specified, or the column being added is an identity or timestamp column, or alternatively if none of the previous conditions are satisfied the table must be empty to allow addition of this column. Column 'Disabled' cannot be added to non-empty table 'PROV_ProductMapping' because it does not satisfy these conditions.

If this is the case we have to clear the data already in that table.

Resolution:

Before running this you must make a backup of the database and the Core.

Warning: This will remove any previous Product to Package Mapping assignments you have made.  Please make sure you have recorded these so you can restore them. 

To resolve this issue open SQL Server Management Studio and select you database and run this command:

Delete from Prov_ProductMapping

Then run this to make sure to table has been cleared:

Select * from Prov_ProductMapping.

The table should be clear.

Now on the Core open up a command prompt navigate to the ManagementSuite folder. Once there run:

Coredbutil.exe /xml=provisioning.xml /buildcomponents

This should take only a few minutes at most.

Once you see coredbutil.exe disappear from task manager you should be able to open Product to Package Mapping and see all of the software you set up in Software License Monitoring.

We are getting new HP computers. I have a new Windows 7 X64 image. After I run sysprep OOBE with generalize. I shut down the computer. I then capture the image. The capture procedure works fine. When I try to use the new image... The computer looks like it is going to boot. I get past the windows screen and I see the logo but then it reboots after it displays a message "autochk program not found skipping autocheck" If I run safemode it will reboot after loading the drivers.

If I boot the original syspreped drive that has only had the image taken on it (NOT Deployed) I get the same result.

If I do the same process but before I capture the image I do a disk to disk acronis copy. The new drive will boot fine using acronis.

I think that something may be getting messed up with the MBR when I capture a image but I don't understand how.

--------------------------------------------------------------------------

[11/06/2014 11:24:28 am] /b /uy /d:0 /rb:0 /max:2GB /f:i:\WINDOW~1\LD40A8F0621F5D

[11/06/2014 11:24:28 am] Image for Windows 2.79 (GUI)

[11/06/2014 11:24:28 am] Starting ...

imagew.exe /b /uy /d:w0 /f:"i:\WINDOW~1\LD40A8F0621F5D" /max:2GiB

[11/06/2014 11:24:29 am] Backup: Drive 0 Microsoft reserv Partition (01) 128 MiB GPT Entry

[11/06/2014 11:24:29 am] To: i:\WINDOW~1\LD40A8F0621F5D.TBI

[11/06/2014 11:24:32 am] INFO: Total Sectors:262144  Total Allocated:262144

[11/06/2014 11:24:32 am] INFO: 262144 Sector(s) backed up

[11/06/2014 11:24:32 am] Backup: Drive 0 (C:)  Partition (02) 100 MiB EFI System

[11/06/2014 11:24:32 am] To: i:\WINDOW~1\LD40A8F0621F5D.TBI

[11/06/2014 11:24:32 am] INFO: Total Sectors:204800  Total Allocated:38018

[11/06/2014 11:24:32 am] INFO: 38018 Sector(s) backed up

[11/06/2014 11:24:32 am] Backup: Drive 0  Partition (03) 953540 MiB HPFS/NTFS

[11/06/2014 11:24:32 am] To: i:\WINDOW~1\LD40A8F0621F5D.TBI

[11/06/2014 11:36:10 am] INFO: Total Sectors:1952849920  Total Allocated:75333200

[11/06/2014 11:36:10 am] INFO: 49706584 Sector(s) backed up

[11/06/2014 11:36:15 am] Operation Completed with Error Code 0

[11/06/2014 11:36:15 am] Stop

--------------------------------------------------------------------------

[11/06/2014  2:31:56 pm] /r /o /d:0 /f:i:\WINDOW~1\LD40A8~1.TBI /rb:0

[11/06/2014  2:31:56 pm] Image for Windows 2.79 (GUI)

[11/06/2014  2:31:56 pm] Starting ...

imagew.exe /r /d:w0 /f:"i:\WINDOW~1\LD40A8~1" /o

[11/06/2014  2:31:56 pm] Restoring: Microsoft reserv Partition (01) 128 MiB GPT Entry

[11/06/2014  2:31:56 pm] To: Drive 0 ------- Partition (80) 953868 MiB Free Space

[11/06/2014  2:31:56 pm] From: i:\WINDOW~1\LD40A8~1.TBI

[11/06/2014  2:32:01 pm] Restoring:  Partition (02) 100 MiB EFI System

[11/06/2014  2:32:01 pm] To: Drive 0 ------- Partition (81) 953640 MiB Free Space

[11/06/2014  2:32:01 pm] From: i:\WINDOW~1\LD40A8~1.TBI

[11/06/2014  2:32:01 pm] Restoring:  Partition (03) 953540 MiB HPFS/NTFS

[11/06/2014  2:32:01 pm] To: Drive 0 ------- Partition (81) 953540 MiB Free Space

[11/06/2014  2:32:01 pm] From: i:\WINDOW~1\LD40A8~1.TBI

[11/06/2014  2:44:02 pm] Operation Completed with Error Code 0

[11/06/2014  2:44:02 pm] Stop

This article applies to LANDESK Management Suite 9.6.  This article will also work for previous versions, however some steps may vary.

Issue:

Preferred server fails with error in WinPE

Cause:

The Preferred Server name is not resolvable without the FQDN in some environments.

Resolution:

Add a DNS suffix search list to the clients registry in the WinPE image with the following steps;

(More detail behind this process can be found in this Microsoft KB.)

1. In your Management Console, go to your Operating System provisioning window and click on the "Manage Drivers in WinPE Image" icon, then select the image you want to edit (32, 64, or other), and hit next.
2. Once the "Driver list" is open, browse to %temp% and locate the following file:

      %temp%\imgtmp\Apply\Windows\System32\ALL.reg

3. Edit the file with Notepad or another acceptable editor.
4. Add the following below what is already there:

[HKEY_Local_Machine\System\CurrentControlSet\Services\TCPIP\Parameters]

"SearchList" = "YourDomain.com,Internal.YourDomain.com,SomeOtherPlace.com"

[HKEY_Local_Machine\System\CurrentControlSet\Services\TCPIP\Parameters]

"SearchList" = "YourDomain.com,Internal.YourDomain.com,SomeOtherPlace.com"

NOTE: You need to substitute in your FQDN names instead of the "YourDomain.com", "Internal.YourDomain.com" etc.

    5. Save the file and close the Windows Explorer so that nothing relating to that folder is open

    6. Add a driver of some kind to the Manage Windows Driver window and name it "Bogus Driver"

    7. Save that by clicking Finish

    8. Once all of that is saved you need to go back in and open the "Manage the Windows Drivers in the PE" window again so that you can REMOVE that bogus driver.

• NOTE ** The reason you add the bogus driver is that unless you add something your changes will not be saved to the WIM file.

    9. Close the window and finish once you have removed the bogus driver.

    10. Redeploy the PXE server(s) as described in this document.

You now have the ability to ping the Preferred Sever name without FQDN and you can find things in all of your DNS search domains.

**Alternative method to editing the boot.wim can be found here.

I want to show you how I fixed all of our HII Problems in 9.5 SP1 and dramatically speeded up the provisioning process with a few simple steps.
We working with this method for weeks now without any problems...so I wanted to share it to the community.

Benefits:

No DELL USB 3.0 Driver Problems, No more Blue Screens after StandBy Mode, No mixing of drivers because of generic Hardware IDs, massivly speeded up Provisioning Process

Steps:

1. Create a Driver Share like this
   
   You get this Drivers from here: Dell Driver CAB files for Enterprise Client OS Deployment
2. Become familiar with the oldschool Copydrivers.exe-Tool and populate the .ini like this.
   
   
3. Edit your Provisioning Template
   Map a Network Drive to preferred Server
   
   
   Run the Copydrivers.exe with /c
   
   
   Run the Microsoft DISM-Command
   x:\windows\system32\dism.exe
   /image:c:\ /add-driver /driver:"c:\Drivers" /recurse /forceunsigned
   
4. DELETE HII from the Template (its not needed in the POST-OS Section anymore)
   

Now your Windows Installation has all drivers that are needed right for this computer model.

Kind regards,
Marco Feuerstein

Germany

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.

A visual representation of this process is attached as a flowchart below:

Step 1 - 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.