Issue

Unable to modify the capture image template.

Cause

Prov_Action_Type table in the LANDESK database is missing some of the rows.

Resolution

1. Close the LANDESK Console.
2. Important! Backup the Core Server and the LANDESK database before doing the rest of the steps.
3. Check the properties of the following files in the \Program Files\LANDESK\ManagementSuite folder on the Core Server to make sure they do not have an UNBLOCK button by the Read-Only checkbox:
   
     prov_Loaddb.exe
     prov_InstallPlugin.exe
   
   
4. If there is an UNBLOCK button, click it to unblock the file.
5. If you use Remote Desktop to connect to the Core Server, add the /admin switch after the Core Server name to connect to the Core Server.
6. Open a command prompt window on the Core Server as administrator by right-clicking CMD.EXE on the Core Server and selecting the "Run as administrator" option.
7. In the command prompt window, change directory to the C:\Program Files\LANDesk\ManagementSuite folder and run the following commands:
   
   prov_Loaddb.exe -f "C:\Program Files\LANDesk\ManagementSuite\ENUActionsAndSections.xml"
   prov_InstallPlugin.exe -a

This article describes the new features and changes in the OS Provisioning tool in LANDESK Management Suite 9.6.

The focus on changes for OS Provisioning in LDMS 9.6 has been geared towards simplifying the process.

The older "OSD" product has been removed from the product and has been fully replaced by the Provisioning product.

LANDESK Provisioning takes the previous OSD concepts and extends them even further  LANDESK Provisioning offers true end-to-end Provisioning of a device from a "Bare Metal" metal state (No Operating System installed) to completely imaged, software installed, domain joined, LANDESK Agent installed, etc.

OSD is gone?  What happens now?

There is no upgrade process for existing OSD Scripts.    It will be necessary to create provisioning templates to perform the previous imaging tasks that OSD did.  Remember, Provisioning is not just for deploying images.  It can be used to distribute software, patch systems, execute scripts, etc.

The beauty of Provisioning is that you can chain an endless array of actions together.

New!   Simplified template creation process

LDMS 9.5 and subsequent service packs simplified the Provisioning templates and consolidated previously complex actions.

LDMS 9.6 furthers this by include simple template creation "wizards" to build a template foundation.

Creating a capture job has been simplified down to 5 steps within a single dialog:

1. Select “Capture Template” under “New Template”
2. Select “Capture template”
3. Select “Capture Image”
4. Name the template and give it a description.
5. Enter image file storage location.

Similarly, LDMS 9.6 has simplified creating a Deploy Image template into a single dialog:

New!  "Smart Partitioning" actions

There are two new partitioning actions that are referred to as "Smart Partitioning" actions.

Auto Assign Partitions

• Assigns standard drive letters to OS and Boot partitions
• This action discovers the OS partition and possible separate boot partitions and automatically assigns them standard driver letters.

• Action results: 
  
  Windows 7 and higher with separate boot partition including all UEFI:

OS Partition will be mounted as C:

Boot partition will be mounted as S:

         Windows XP and Windows 7 and higher with a separate boot partition:

OS/Boot partition will be mounted as C:

Create default partitions

• Assigns the default partitions for either UEFI or BIOS based computers.
• This action creates standard partitions as recommended for Microsoft operating systems (Windows 7 and newer)
• This prepares the disk for use with ImageX or other file based imaging tools.  The action will detect UEFI and BIOS based computers and configure the partitions.  Sector based imaging tools such as ImageW do not need this action.
• OS partition will be mounted as C:
• Boot Partition will be mounted as S:

LANDESK Provisioning takes advantage of the new "self-organizing" multicast.  This and other improvements to the software distribution model provide drastically improved imaging and software deployment speeds.

New!  "Installed Mapped Software" action

LANDESK Management Suite 9.6 offers a new "smart migration" feature that allows you to use your Software License Monitoring data to install or reinstall software as part of an imaging and system migration solution.  IProducts can be linked to packages, and in turn called as a group through a single "Install Mapped Software" action.

In addition any standard LANDESK query can be created as a "product" within the Software Licensing Monitoring tool.    An example of the use of this would be if you wanted to install software on laptops only, you could create a LANDESK query that would return results for only laptops.

"Smart migration" can also be used to upgrade or change software:

Examples:

Upgrade example: Map Office® 2010 to Office® 2013

Change software example: Map iTunes® to VLC Media Player

New!  "Device Name Prompter" action

This action changes the %ldhostname% variable to what is typed in.  This is to be run before an inject script action.  When the "Device Name Prompter" action runs it will pop up a windows asking the operator to enter the desired computer nam.e

Improved!   PXE Boot option configuration

• PXE Boot options have been moved from the "Configure Services" menu.  They are now located in the OS Provisioning tool under the "Preboot" dropdown.
• Changes made to the PXE boot options take effect immediately, no need to redeploy a PXE representative.  The client makes a web service call to download the F8 PXE Boot menu options.

New!   Disconnected Provisioning

This new option allows you to deploy templates from a thumb drive.

To create, put in the USB device,  right click the template, and choose  “Create disconnected template”.    (USB thumb drive will be formatted) .  The template will deploy the image, do CTOS,  install the agent (Self-contained.exe) and attempt any other action that does not require a core connection.

With connection to the core, Distribute Software, Patch System and other core-dependent actions will succeed.

New!   "Launch Template" action

This new action is used in migration scenarios for migration from one computer to another computer.  This action utilizes machine to machine mapping.  The actions from the launched template are not included into the sections of the current template, it is run entirely just after the first template.

Improved!   Change  Changes to the "Wait" action

• You can now cancel a provisioning “Wait” action.  Previously you had to wait until the timeout, or until the file existed that the Wait action was set to wait for.
• Wait actions are often used in troubleshooting to give someone a chance to into the command prompt in Windows PE to manipulate or view the file system or registry.

Improved!   Various Enhancements

• Better resizing of Template UI
• Ability to copy and paste from template  to template.
• Multiple templates can be open simultaneously
• Defaults to Windows PE for Boot Environment and Windows for Target OS rather than "
• Auto-naming of actions
• Action name and description shows on Client UI.
• History auto-refreshes.
• Wait UI can be cancelled.

This article applies to LANDESK Management Suite 9.6 Service Pack 1

Issue

After upgrading LDMS 9.6 Core Server to Service Pack 1, Provisioning tasks fail due to MaptoPreferredHandler.exe crashing an error.

MaptoPreferredHandler.exe - Application Error
The instruction at 0x0000003a referenced memory at 0x0000003a. The memory could not be written.

Associated Errors in Provisioning Logs:

• DeployImageHandler.log:

DeployImageHandler.exe:ExecuteCmd maptopreferredhandler.exe /path="\\PreferredServer\OperatingSystems\Windows7x86.tbi" /driveletter=e /pathisfile
DeployImageHandler.exe:created process, file handle 74 with non-readonly parameter
DeployImageHandler.exe:Process Exit Code: -1073741819

Associated errors in Provisioning History located within the LDMS Console View:

• Type: Deploy Image
  • Internal Status: -2147477501

Cause

Certain Provisioning files are updated on the LDMS Core when 9.6 SP1 is applied. These files are incompatible with the current WINPE configuration.

Solution / Workaround

Redeploy the PXE representative to update the WinPE files so they are compatible with LDMS 9.6 SP1.s

Has anybody had any sucess provisioning a Lenovo Thinkpad Tablet2 device? We're running 9.5 SP2, and I cannot get it to boot from a Provisioning Boot medium writen to a USB stick. The tablet is 32bit UEFI, it seems the slightest hint of anything 64bit on the boot medium causes it to fail.

Is there anyway of forcing 32bit only when creating the \ldmain\landesk\vboot\bootmedia.wim file?

Can someone please tell me if this is a bug or is it by design?

We can see the SCN file get created under the \\coreserver\ldlogon directory but the bare metal server never gets committed to the database. The same process works fine adding it from the core server.

Description

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

Core Logs

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

The following are the core logs:

• ManagementSuite\logs\prov_schedule.exe.log
• ManagementSuite\logs\provisioning\provisioning.log

Client Logs

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

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

Note: When troubleshooting LANDESK Provisioning, it is helpful to turn off removal of the client provisioning folder.

Steps to disable removal of the client provisioning folder

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

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

Understanding Action Handler Flow (Client)

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

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

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

created process, file handle 60 with non-readonly parameter

Process Exit Code: 0

Verifying file was successfully downloaded.

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

Getting free drive letter

Free drive letter: f

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

created process, file handle 68 with non-readonly parameter

Process Exit Code: 0

 

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

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

Action Handler Logs

Related Video: How to Troubleshoot Provisioning Template Actions

Hi,

We are also having issues as described in this thread - Lenovo Tablet2 provisioning.  I have found that as we are using the Lenovo USB Network adaptor and a Powered USB Hub, the MAC Address of 5 tablets are now the same (these were not built with LANDESK) unfortunately this means that now I am trying to build and capture with LANDESK it is not working.

I cant delete the devices as they are valid Devices, but the MAC Address is duplicated.

Does anyone have any ideas?

Adam

LANDave

MarXtar

Issue

• Computer reboots and runs through the sysprep process but does not run any of the actions in the System Configuration section.
• End of the CONFIGTARGETOSHANDLER.LOG file shows it found a SETUP folder in a directory other than WINDOWS.

The following shows in the CONFIGTARGETOSHANDLER.LOG file:

2014-02-11 23:57:54(956-1072) ConfigTargetOSHandler.exe:Found dir d:\CompareRite\setup

Cause

There can be no SETUP folders at the second level except for in the Windows folder (C:\WINDOWS\Setup).

Solution

1. Add an action in the template right before the CTOS action that renames the SETUP folder to something else.
2. Add an action in the System Configuration section, that renames the folder back to SETUP.

NOTE: UEFI is only supported in Provisioning and not OSD. The industry UEFI standard does not support a menu so you will need to use a scheduled provisioning task instead.

Provisioning UEFI PXE Boot devices:

Follow these steps to boot the device:

1. Add the client(s) to the Inventory using the Bare Metal Server option:
   

   A. Expand the Configuration section in the Network view of the LDMS console

   B. Right-click "Bare Metal Server"

   C. Click "Add Devices"

   D. Select a desired identifier type (typically MAC address) and then click "Add"

   E. Enter a name for the computer, and the identifier (such as MAC Address)
       (Note: You can add multiple computers by entering multiple names an identifiers)

   F. Click OK when finished.

2. Schedule your Provisioning Template (Right click desired template and select "Schedule Template")
3. Add the client computer(s) to the task, but leave the physical device turned off.
4. Start the task. It will go to active, and then after a few seconds will go back to a Pending status.
5. Power on the device(s), and tell it to Network Boot (Usually F12 or Delete).
6. At this point the PXE Rep should see there is already a task waiting for that machine, and send it straight into WinPE, and automatically begin the Provisioning task.

In order to import a large list of new devices, the CSVIMPORT utility should be used.   Often hardware vendors are able to provide a list of MAC Addresses and/or other identifiers that can be used to import machine information into the LANDESK Database in order to facilitate provisioning of UEFI Bare Metal (With no operating system installed) devices.

CSVIMPORT allows the usagse of a .CSV file in order to import Mac Address, Computer name and/or other identifying information.

For more information about CSVIMPORT, see the following article:

How to use CSVIMPORT.EXE to import devices

Applies to LANDESK Management Suite 9.0 SP4 and later

Issue

The following error occurs when booting into Windows PE:

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

Cause

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

Resolution

The following steps will be taken on the core server:

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

These steps follow:

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

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

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

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

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

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

8. Change to the WINDOWS\SYSTEM32  subdirectory under c:\bootwim and edit the file ALL.REG in Notepad or other text editor.
9. Modify the line that says "CoreServer"="[Corename]" and change the core name to FQDN or IP address as suits your needs.
10. Save your changes to the ALL.reg file.
11. Repeat steps 6-9 for the boot_x64.wim
    
    Now it is necessary to commit the changes made in the C:\bootwim and C:\boot_x64wim directories to save them into the .WIM files.  This is done by using the DISM (Deployment Image Servicing and Management) tool with the switch "/commit-wim" to save the changes to the images we mounted in steps 4 and 5. IMPORTANT: It is absolutely necessary to close all Explorer windows related to the bootwim mount directory before running the unmount commands. Failure to do so will cause your commit to fail due to files still being in use.
    
    
12. Type the following command to unmount the boot.wim and commit (save) the changes:
    

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

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

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

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

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

    
    
    
    
    

Problem

Deploying an Image or Capturing an Image fails during OS Provisioning.

Downloading prerequisites...
Connect to core:96-CORE3
Loading template...                                              
Action #1
Capture image
FAILED
error:[80001803H]The action failed.
Execute result:
return:-1
output:

Provisioning History Shows:

Internal Status: -2147477501

Cause

The Preferred Server listed in the template fails to resolve or authenticate. This is can be caused by a few things:

• The Preferred Server is not defined in the LDMS core.
  • If this is the case, the maptopreferredhandler.log on the client will show:

maptopreferredhandler.exe:******Mapping to: \\PreferredServer\share
maptopreferredhandler.exe:Drive letter = e
maptopreferredhandler.exe:Mode - Require Direct, no preferred server.
maptopreferredhandler.exe:Could not get credentials for preferred server.
maptopreferredhandler.exe:End of Map Drive.  Path used: - \\PreferredServer\share\.

• The Preferred Server credentials could not successfully authenticate.
  • This is often caused when the password for the Preferred Server is incorrect.
  • It may also occur if the Client cannot resolve the Preferred Server
  • The maptopreferredhandler.log on the client will show:

maptopreferredhandler.exe:******Mapping to: \\PreferredServer\share
maptopreferredhandler.exe:Drive letter = e
maptopreferredhandler.exe:Mode - Attempt preferred server.
maptopreferredhandler.exe:Could not map or unmap drive. Error code: 86

Solution / Workaround

Check the each cause to identify which one may be causing the current issue.

• Verify the Preferred Server that is used in the template is defined in the LDMS Core under Tools | Distribution | Content replication / Preferred Servers.

Note: Preferred Servers are mapped to as literal strings. This means that if a Preferred Server is added by FQDN, Maptopreferredhandler.exe (used in provisioning) will only recognize that it has credentials for that Preferred Server if it is listed in the template by FQDN. If you enter it by Short Name / Netbios, it requires that a Preferred Server be added to match. Because of this, there may be multiple Preferred Servers in the LDMS Core that point at the same machine.

• Verify the client can resolve the Preferred Server
  • From the MaptoPreferredHandler.log identify the Drive Letter and Share that is being mapped to. Use this information to manually map the share.
  • To test the credentials open a new Console window on the Client in WinPE and enter the following command:

  • Net Use e: \\PreferredServer\Share

• If it resolves the share, the window will prompt for credentials.

• If it fails to resolve the share it will give an error with information about the cause.

System error 53 has occurred.
The network path was not found.

• If the client cannot resolve the Preferred Server, it will be unable to map the drive necessary for provisioning.
  • Try using alternative names such as FQDN, Netbios, or IP in the template. If none work, correct the underlying issue preventing the machine from resolving the Preferred server.
• Verify the Credentials defined for the Preferred Server are current and have permission.
  • From the MaptoPreferredHandler.log identify the Drive Letter and Share that is being mapped to.
  • Use this information to manually map the share.
  • To test the credentials open a new Console window on the Client in WinPE.
  • Enter the following command:

  • Net Use e: \\PreferredServer\Share

Note: (use the information from maptopreferredhandler.log we gathered in your command i.e. Net Use e: \\96-Core\Images)

• Enter the same credentials that are defined for the Preferred Server within the LDMS Core when prompted
• The command window will indicate if successful.

• If it lists a failure, this is what is happening when Maptopreferredhandler.log tries to map to the share.

System error 86 has occurred.

• If manually mapping the drive fails, identify working credentials and update the Preferred Server in the LDMS Core accordingly.

Environment:

LDMS 9.6

Review Date:

9/15/2014

Error Message:

DrvLoad: Unable to load X:\InstalledDrivers\...\e1d6432.inf (Error 0x80070002)

Problem:

When WinPE is attempting to load a driver, it fails.

Cause:

When going through an OSD or Provisioning task , WinPE uses drvload.exe to access drivers. If drvload.exe is unable to load a driver successfully for use, different actions can fail, including making network connections which are required for performing OSD and Provisioning tasks.

Solution / Workaround:

• Load the drivers' .inf file onto a thumb drive and attach to the machine that is booting into WinPE.
• Identify the thumb drives assigned drive letter
  • Open a New Console

• Type diskpart then press Enter.

• Type list volume then press Enter. This will dislay assigned drive letter.

• Identify the drive letter for the thumb drive.
• Type exit and press Enter.

• Next try mounting the driver from the thumb drive using the command: X:\Windows\System32\drvload.exe [usbDriveLetter]:\[path_to_driver]\[driver_name].inf

Example: The driver in this example is located on the root of C:\

X:\Windows\System32\drvload.exe C:\e1c6432.inf

• If the driver is compatible, the console will display: DrvLoad: Successfully loaded [usbDriveLetter]:\[path_to_driver]\[driver_name].inf

Example:

DrvLoad: Successfully loaded C:\e1c6432.inf

• If the driver is not compatible, the console will display an error.

Note: The error may vary.

Example:

DrvLoad: Unable to load c:\BadDriver.inf (Error 0xe0000100)

• If manually attempting to use drvload.exe to load a driver fails, this must be corrected before OSD or Provisioning tasks can work.

Possible Causes of a Failure

• The test may have selected the wrong file.
• Dependent files may be missing that are needed as a reference by the *.inf file.
  • .dll, .cab, .sys files may be dependencies for the driver. Try adding them if available.
• The driver file added may be corrupted. Try re-downloading and testing.
• The driver selected may be incorrect. Try a different driver.
  • Windows Blue drivers have been seen to work in some circumstances where Windows 8.1 x86 drivers did not.

Hi All,

I have tried find solutions to this issue of mine, but have not been successful till now. I have just recently setup multiple PXE representatives in my respective subnets (1 for each subnet). However, after setting up Windows on those machines and getting the latest Windows Update on all these PXE representatives, I managed to successfully deployed the PXE agents and services to these machines.

But it seems that all the PXE representatives are giving this error message in Event Viewer and I was wondering if anyone has seen this error message before? All PXE Services start up fine and are in automatic mode, but I just keep getting this error message.

"The description for Event ID ( 2 ) in Source ( PxeServices ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: LoadParsingDlls:  Failed to load Dll Library for ConfigServer."

Any advice is appreciated, thank you.

Cheers,

Jonathan

I'm running 9.6 SP1 and when I try to capture a profile I'm getting a 1163 return code. I've looked around and can't seem to find anything that explains return code 1163 as related to 9.6 SP1. Any guidance would be appreciated.

Applies to LANDESK Management Suite 9.0 and newer.

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: In LANDESK Management Suite 9.5, the 64-bit version of WinPE is included to add support for UEFI devices.

Resolution

LANDESK Management Suite 9.6, 9.6 + SP1

• LDMS 9.6 uses WinPE 5.0, the same as LDMS 9.5.
  

LANDESK Management Suite 9.5 SP2 with BASE 0214 patch

• WinPE 5.0 requires Windows 8.1 driver (32 bit).
• For additional information on managing drivers in LANDESK Management Suite 9.5 please see How to Add Drivers to WinPE for LANDESK 9.5.

LANDESK Management Suite 9.5 SP1 with BASE 1017 patch

• The WinPE version is updated to 5.0.
• For additional information on managing drivers in LANDESK Management Suite 9.5 please see How to Add Drivers to WinPE for LANDESK 9.5.

LANDESK Management Suite 9.5 (with HP ElitePad Integration Update and/or the BASE 0228A patch) - 9.5 SP1

• The WinPE version is updated to 4.0.
• WinPE 4.0 requires Windows 8 drivers (NDIS 6.3).
• WinPE 4.0 does include a generic NDIS driver so a specific NIC driver may not be required.
• For additional information on managing drivers in LANDESK Management Suite 9.5 please see How to Add Drivers to WinPE for LANDESK 9.5.
• Client devices must have processor support for PAE/NX/SSE2 in order to boot into WinPE 4.0.

LANDESK Management Suite 9.0 SP3 - LANDESK Management Suite 9.5 without Service Pack

• The WinPE version is updated to 3.1.
• WinPE 3.1 requires Windows 7 drivers (NDIS 6.2).
• For additional information on managing drivers in LANDESK Management Suite 9.5 please see How to Add Drivers to WinPE for LANDESK 9.5
• For additional information on managing drivers in LANDESK Management Suite 9.0 please see How to add drivers to WinPE for LANDESK 9

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

NDIS Versions in Network Drivers (Windows Drivers)

Hey everyone,

I'm not sure if anyone else is seeing this, but I figured it was worth mentioning.  We've been configuring & testing Provisioning for the last couple months and it's gone well for the most part.  We were having some major PXE issues, but those were resolved by SP1.  The only other major issue we've had is with deploying packages via the Distribute Software action.  I haven't figured out why, but packages will randomly fail on random machines.  For instance...

Let's say I deploy a Provisioning task to 15 machines.  All 15 machines re-image fine, install the LANDesk agent fine, but a few of them fail to install let's say 1 of the 5 packages I want deployed to them.  What's even stranger is that it isn't the same package that fails each time.

I've been digging around on the forums for a week now looking for solutions.  One idea was that the security scanner was getting in the way.  I tried the solution of using an agent that doesn't run a security scan and then install the normal agent after I'm done with packages.  No go.  So I'm not sure what's up.

At this point, I've completely given up on the Distribute Software action and resorted to downloading the install files in WinPE by utilizing PrefMap.exe and then install them via the Execute File action.

Any ideas?

Thanks.

Running LD 9.5 SP3

After upgrading from 9.5 SP2 to SP3 the Pxe Representative Deployment script that came with my original Landesk install would show success but never installed anything, it just uninstalled whatever files that were there.

I called Landesk Support and was told this was known to happen for some people and not for others. It was suggested to copy Osdrep.msi to the Pxe Server and run it.

Well that installs all the files except BCD which is needed to boot to Pxe. By the way the script calls for BCD.dat to be copyed and looking at a old pxe server install the file in the Boot fold is BCD not BCD.dat.  Also looking on the core in ldmain\landesk\vboot folder there is a BCD.dat which is older then the BCD file in there.

I have over 26 Pxe Reps and don't want to remote in to each one and run osdrep and then copy the BCD file everytime I have to redeploy one.

Anyone else had this problem?

PS I have looked at permissions on the folders that contain the Pxe files on the core server and there have been no changes.

Hello All,

We are looking to upgrade from 9.5 SP2 to 9.6. Has anyone upgraded to production yet,  and were there any issues with provisioning ?  I am looking for feedback on

1. Import/Export Templates from 9.5 to 9.6
2. PXE Rep installation and content replication
3. Provision template testing - any gotchas
4. HII Driver DB and driver isolation
5. Performance when imaging with the new 9.6 with multicasting technology
6. Any issues you encountered that would help us with the migration.

Thanks

-Daniel J Mercuri II

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.