Applies to LANDESK Management Suite 9

In LANDESK Management Suite 9, LANDESK introduced new Hardware Independent Imaging (HII) tools. These tools can be used in conjunction with OSD or Provisioning to apply drivers for particular hardware devices when deploying a generic Windows image.

Hardware Independent Imaging Components

HII Driver Repository

This is where the actual driver files are stored. This can be ANY machine with a UNC and HTTP share available to client machines. It is recommended that the HII Driver Repository be located with a high-speed, low-latency connection to the Core Server. The drivers can be organized in any manner and should include the inf files and all supporting files. The location of the HII Driver Repository is configured in the LANDESK Management Console.

The "master" HII Driver Repository can be replicated to Preferred Servers as needed. The Preferred Servers do not have to have both UNC and HTTP shares available as long as clients are configured to use the available share.

For more information on the HII Driver Repository see HII Driver Repository

HII Driver Database

Once drivers are placed in the HII Driver Repository, and the HII Driver Repository Manager configured to point to the drivers, the HII Driver Repository Manager will generate the HII Driver Library Database. A progress bar will indicate the progress of the database creation and when the database is complete. The HII Driver Database is not updated automatically so it should be updated anytime new drivers are added to the HII Driver Repository

The driver library is created at the root of the HII Driver Repository and is named drivers.db3. This file is distributed to clients and used to determine the correct drivers and the associated files necessary for any given hardware device and the corresponding driver.

For more information on the HII Driver Library Database see HII Driver Database

HIIClient

HIIClient is the client side application that is run in order to get drivers installed on target devices. HIIClient will use HTTP by default, but can be configured to use UNC. No other configuration is necessary.

When HIIClient runs it will automatically detect the Windows® version (Windows XP®, Windows 7®) that is installed, the architecture that is installed (x86, x64) and all the individual devices connected to the client (Hard drive controller, video card, sound card, chipset etc.). HIIClient will then use the HII Driver Database to find the best matching drivers available in the HII Driver Repository. The best drivers are determined by a number of factors and should match the drivers that Windows would choose. Only the best matching and most recent driver for each device is downloaded.

The drivers are downloaded from Preferred Servers (if configured) and then installed on the device. The installation method for the drivers varies depending on the Windows version being deployed. For more information about HII Client see HIIClient

Preferred Servers

With LDMS 9 SP3, HII has been improved to allow the use of Preferred Servers via HTTP or UNC and download speed has been improved. All Preferred Server configuration requirements are the same as for LANDESK features that use Preferred Servers.

Because HII runs in WindowsPE, some special considerations are worth noting. Windows PE will assign a random hostname to the device when it boots. Also WindowsPE will not have any domain access or credentials natively. This means that it is very important that any Preferred Server that will be used by HII have the client Read-only credentials configured. For more information on Preferred Server configuration see:

LANDESK Content Replication - Preferred Server (Target) Configuration

How to Configure a Preferred Package Server

How to set up a HTTP share for a Preferred Package Share

Important Information

The HII tools use information contained in driver files and information obtained from devices in order to match up the right drivers and devices without requiring the user to manually configure or match up anything. In order to do this, LANDESK pulls information from drivers files in accordance with standards published by Microsoft. Occationally device manaufacturers will take shortcuts or have an error in a driver file. When this happens it can cause LANDESK to match the wrong drivers to a machine and can result in problems. In every case if the Windows were pointed to the driver, it would also incorrectly identify the driver as applicable and install the driver.

To reduce the potential impact of such errors, it is recommended that drivers be obtained from official sources whenever possible and any errors should be reported to the device manufacturer or vendor. Large packages of drivers (aka driver packs) have been found to often contain many errant and corrupt drivers that can cause problems. Additionally driver harvesting utilities often do not gather all the necessary information or files for a driver and can produce problematic drivers as well.

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

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

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

Applies to LANDESK Management Suite 9 SP3 and newer

Description

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

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

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

Common Errors and Resolution

• Error: "Access Denied"
  • Errors referring to access denied indicates that a folder path in the boot.wim is too long. Often this path will be for a driver that was injected into the WinPE image. There are two option for correcting this error. The first option is to just start with a clean boot.wim and add the necessary drivers after completing the OSD.Upgrade.exe process. In LDMS 9 Service Pack 3 the WinPE boot environment requires Windows 7 32-bit drivers. Updating those drivers is a manual process so starting with a clean boot.wim may be a good option. The second option would be to mount the backup of the boot.wim (boot.wim.bak) and rename the directories in the InstalledDrivers directory to use shorter names. After completing one of these options follow the steps outlined below to re-run OSD.Upgrade.exe.
• Error: "CommonCore.inf: (0xFFFFFFFF) OSD.Upgrade.exe,60000"
  • This is a general error indication. Review the log for additional errors.
• Error: "DirectoryNotFoundException"
  • Errors referring to a .0 or an mpkg package indicate that a .0 file has been extracted to a sub-folder of the ldlogon folder. DO NOT delete any .0 files from the root of ldlogon. Navigate to the directory specified in the log (i.e. C:\Program Files (x86)\LANDESK\ManagementSuite\ldlogon\mac) and delete the .0 file. To prevent additional errors when re-running OSD.Upgrade.exe delete any additional .0 files that are found in sub-folders of the ldlogon folder leaving only the .0 files in the root of ldlogon. Follow the steps below to re-run OSD.Upgrade.exe.
  • Errors referring an ALL.REG file indicate that the wim file was still mounted when osd.upgrade.exe tried to execute. This is most likely due to errors in the previous attempt at running OSD.Upgrade.exe. Review the log and correct and additional errors found before following the steps below to re-run OSD.Upgrade.exe
• Error Non-fatal error: FilterUnload failed, hr=0x801f0013
  • This is normal and does not indicate a problem. Continue reviewing the log file for additional errors.
• Error: System.ComponentModel.Win32Exception
  • You are running the process as a restricted user. Either log in as an administrative user or right click OSD.Upgrade.exe and select run as administrator.
• Error System.IO.IOException: Element not found.
  • This error indicates that there is still a wim file mounted. Review the log for additional errors prior to this error. Follow steps below to re-run the OSD.Upgrade.exe process.
• Error System.UnauthorizedAccessException
  • This error indicates either that there is still a wim file mounted, or that the bootmedia.wim.bak already exists. Bootmedia.wim.bak can be deleted as long as bootmedia.wim exists. Review the log for additional errors and then follow the step below to re-run OSD.Upgrade.exe.
• Error WAIK is not installed
  • This is normal and does not indicate a problem. Waik should have been uninstalled prior to upgrade. If Waik is installed, uninstall it. Continue reviewing the log file for additional errors.

Preparing to Re-Run OSD.Upgrade.exe

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

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

After OSD.Upgrade.exe has completed successfully you need to redeploy your PXE reps. Instructions for PXE deployment can be found at The specified document was not found.

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

This article applies to LANDESK Management Suite 9.5

Issue:

When running a scheduled task to deploy the PXE Representative it fails.

Workaround:

The PXE Representative can be manually installed by following these steps:

1. Push the "PXE Representative Removal" script to the PXE representative and then reboot the PXE representative once removal is complete.
2. Copy OSDREP.MSI from the core under Managementsuite\landesk\files to the PXE Representative.
3. Manually run OSDREP.MSI on the PXE Representative.
4. Verify that the LANDesk(R) PXE MTFTP Service and LANDesk(R) PXE Service are both installed and started. 
5. On the PXE representative, verify that within Program Files (x86)\LANDesk\PXE\System\images\ there are four folders:

   Boot, EFI, IA32 EFI, and x86pc

6. If missing files, the OSDREP.MSI may be corrupt. Obtain a clean copy of the OSDREP.MSI from an LDMS installer or Service Pack installation package.

Environment

LANDESK Management Suite 9.5

Problem/Issue/Symptoms

- Booting a UEFI machine via PXE fails, reporting the following error message: winload.efi file is missing or contain errors

- The PXE boot tries to load WinPE 32 WIM image from the Representative (BIOS mode) rather than the 64 bit one (UEFI mode)

Cause

- The PXE Representative has not been updated with the latest Service Pack or component patch installed on the Core Server

- The PXE Representative installation file is not updated on the core

Solution

Verify that your Core server is running at least the version 9.5 of the Management Suite.
To verify the version and the patch level of your Core follow this article: How to identify the patch level on the LDMS core server?
Redeploy the PXE Representative to make sure he runs the same version as the core: Update or remove PXE representative

If this the problem persists, make sure the following file on the is the same as the one from a fresh Core installation at the same version.
If needed, replace the file with the one taken form the fresh installation and redeploy the PXE Representative:

%LDMS_HOME%\landesk\files\osdrep.msi

Applies to LANDesk Management Suite 9 SP3 and greater

HIIClient is the client-side portion of hardware-independent imaging (HII) in LANDESK Management Suite. HIIClient.exe is run on target machines, identifies the correct drivers for the device, then downloads and installs the drivers. It is stored on the LANDESK Core server and downloaded as needed by client machines in Windows PE during a deployment job.

HIIClient Options

There is only one option for HIIClient, which is what download method to use. HTTP or UNC. By default, running HIIClient with no switches will use HTTP to download the HII Driver Database and the necessary drivers. To have HIIClient use UNC instead, add /UNCPath to the command. This option can also be configured in the OSD script or Provisioning action by checking the box. This will cause HIIClient to get the database and drivers from a UNC share.

The exact shares that are used are the ones configured in the HII Driver Repository Manager. Preferred Servers can be used, but the shares and paths must match. For example, if the HII Driver Repository is configured as \\fileserver\share\drivers, then the Preferred Server must have the replicated files at \\preferredserver\share\drivers. HIIClient will not "fall back" to another method if the configured method (UNC or HTTP) is not available.

HIIClient Process

Download HII Driver Library

Once HIIClient.exe is downloaded and run on the client machine a web call is made to the Core server to find out the location of the HII Driver Repository and the HII Driver Database. With that information, the HII Driver Database is downloaded locally to the client. The database can be downloaded from a Preferred Server as long as it is available and current on the Preferred Server. The download process will communicate with the original HII Repository source only to verify that the file on the Preferred Server matches the original. if the file on the preferred server doesn't match the original, the download process will download from the original HII Repository source only, if there are a lot of client connections, the source server can't afford the network workload, so we need to disable the matching mechanism. Here is the steps for disabling matching mechanism:

Add the registry value in WinPE:

REMEXEC53=reg add HKLM\Software\LANDesk /f /v hii_db3_noverify /t REG_DWORD /d 1

Now the download process will download the HII Repository from preferred server directly, not the source server.

Detect Everything

HIIClient will then detect everything that is needed to find the right drivers. The OS must be installed on the device, but doesn't have to be running or ever run. HIIClient should be run right after the image is deployed. HIIClient will identify which version of Windows is installed (XP-2008) and where it is installed. It will also determine which architecture has been installed, x86 (32-bit) or x64 (64-bit). This determination is based on what OS has been installed, not what any of the hardware is capable of. This means that if Windows 7 x86 has been installed on an x64 processor, HIIClient will correctly determine that Windows 7 x86 drivers should be used.

Once the basic OS information has been determined, HIIClient will obtain a list of all hardware devices connected to the client. This information will include the Hardware Device ID and all Compatible IDs. These IDs are used to match the hardware to specific device drivers.

Match Drivers

When HIIClient has downloaded the HII Driver Database and gathered all the necessary information about the client and all connected devices, HIIClient uses this information to match devices to drivers. In order for a driver to match, it must have information about the right hardware or compatible ID.

As each match is found, it is ranked as to suitability. A driver will have a higher rank if it exactly matches the hardware ID than it would if the match is to a compatible ID, or if the match is more generic. For example, a driver that matches a specific network card would be ranked higher than another driver that matches the network card's compatible ID or matches part of the hardware ID. While both drivers might work, LANDesk uses this ranking to find the best driver available for the device.

The ranking system used by HIIClient is very similar to the system used by Windows and should produce the same results. This ranking system also means that newer, or updated drivers will be considered a better match than old drivers so the newer drivers will be used. It is not absolutely necessary to remove old drivers when an updated driver is added to the HII Driver Repository

After the drivers have been matched and ranked, only the best or highest ranked driver will be downloaded. HIIClient uses the database to determine exactly which files (drivers and supporting files) are needed. Only those files are downloaded. The downloaded drivers are placed on the system drive in \Windows\LDDriverStore.

Installing the Drivers

When the drivers are all downloaded, HIIClient will install the drivers. The steps taken to install the drivers will vary slightly based on which operating system is installed on the client

Windows XP

Windows XP does not have an "offline" method to install drivers, so HIIClient will only manually install the Mass Storage Driver (MSD) so that the machine will boot. For the rest of the drivers, HIIClient will add the appropriate information to the registry that will allow Windows to find the drivers during the normal process of installing drivers on first boot.

Windows 7, 8, 8.1, 2008, and 2012

For Windows Vista, 7 and 2008, HIIClient will use a tool called DISM to install the drivers. DISM (Deployment Image Servicing and Management) is a tool from Microsoft that allows the manipulation of "offline" images. In this case, the image has been deployed to the disk, but isn't running so it is considered offline. HIIClient will use DISM to install all of the downloaded drivers while still in WinPE.

Note: DISM will not work for Microsoft Windows Vista unless it has SP1. Any Windows Vista images that will be deployed should be updated to Windows Vista SP1 before deploying and using HII.

Logs

HIIClient will log information about the process in the HIIClient.log file. This log file can be found in WindowsPE and can be consulted if needed. It will be found in either X:\Windows\System32 or X:\LDProvisioning depending on how it was run. DISM also creates a log and it should be available at X:\Windows\Logs.

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

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

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

Applies to LANDESK Management Suite 9.0[, 9.5

In LANDESK Management Suite 9, LANDESK introduced new Hardware Independent Imaging (HII) tools. These tools can be used in conjunction with OSD or Provisioning to apply drivers for particular hardware devices when deploying a generic Windows image.

Hardware Independent Imaging Components

HII Driver Repository

This is where the actual driver files are stored. This can be ANY machine with a UNC and HTTP share available to client machines. It is recommended that the HII Driver Repository be located with a high-speed, low-latency connection to the Core Server. The drivers can be organized in any manner and should include the inf files and all supporting files. The location of the HII Driver Repository is configured in the LANDESK Management Console.

The "master" HII Driver Repository can be replicated to Preferred Servers as needed. The Preferred Servers do not have to have both UNC and HTTP shares available as long as clients are configured to use the available share.

For more information on the HII Driver Repository see HII Driver Repository

HII Driver Database

Once drivers are placed in the HII Driver Repository, and the HII Driver Repository Manager configured to point to the drivers, the HII Driver Repository Manager will generate the HII Driver Library Database. A progress bar will indicate the progress of the database creation and when the database is complete. The HII Driver Database is not updated automatically so it should be updated anytime new drivers are added to the HII Driver Repository

The driver library is created at the root of the HII Driver Repository and is named drivers.db3. This file is distributed to clients and used to determine the correct drivers and the associated files necessary for any given hardware device and the corresponding driver.

For more information on the HII Driver Library Database see HII Driver Database

HIIClient

HIIClient is the client side application that is run in order to get drivers installed on target devices. HIIClient will use HTTP by default, but can be configured to use UNC. No other configuration is necessary.

When HIIClient runs it will automatically detect the Windows® version (Windows XP®, Windows 7®) that is installed, the architecture that is installed (x86, x64) and all the individual devices connected to the client (Hard drive controller, video card, sound card, chipset etc.). HIIClient will then use the HII Driver Database to find the best matching drivers available in the HII Driver Repository. The best drivers are determined by a number of factors and should match the drivers that Windows would choose. Only the best matching and most recent driver for each device is downloaded.

The drivers are downloaded from Preferred Servers (if configured) and then installed on the device. The installation method for the drivers varies depending on the Windows version being deployed. For more information about HII Client see HIIClient

Preferred Servers

With LDMS 9 SP3, HII has been improved to allow the use of Preferred Servers via HTTP or UNC and download speed has been improved. All Preferred Server configuration requirements are the same as for LANDESK features that use Preferred Servers.

Because HII runs in WindowsPE, some special considerations are worth noting. Windows PE will assign a random hostname to the device when it boots. Also WindowsPE will not have any domain access or credentials natively. This means that it is very important that any Preferred Server that will be used by HII have the client Read-only credentials configured. For more information on Preferred Server configuration see:

LANDESK Content Replication - Preferred Server (Target) Configuration

How to Configure a Preferred Package Server

How to set up a HTTP share for a Preferred Package Share

Important Information

The HII tools use information contained in driver files and information obtained from devices in order to match up the right drivers and devices without requiring the user to manually configure or match up anything. In order to do this, LANDESK pulls information from drivers files in accordance with standards published by Microsoft. Occationally device manaufacturers will take shortcuts or have an error in a driver file. When this happens it can cause LANDESK to match the wrong drivers to a machine and can result in problems. In every case if the Windows were pointed to the driver, it would also incorrectly identify the driver as applicable and install the driver.

To reduce the potential impact of such errors, it is recommended that drivers be obtained from official sources whenever possible and any errors should be reported to the device manufacturer or vendor. Large packages of drivers (aka driver packs) have been found to often contain many errant and corrupt drivers that can cause problems. Additionally driver harvesting utilities often do not gather all the necessary information or files for a driver and can produce problematic drivers as well.

Applies to LANDESK Management Suite 9 SP3 and newer

Description

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

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

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

Common Errors and Resolution

• Error: "Access Denied"
  • Errors referring to access denied indicates that a folder path in the boot.wim is too long. Often this path will be for a driver that was injected into the WinPE image. There are two option for correcting this error. The first option is to just start with a clean boot.wim and add the necessary drivers after completing the OSD.Upgrade.exe process. In LDMS 9 Service Pack 3 the WinPE boot environment requires Windows 7 32-bit drivers. Updating those drivers is a manual process so starting with a clean boot.wim may be a good option. The second option would be to mount the backup of the boot.wim (boot.wim.bak) and rename the directories in the InstalledDrivers directory to use shorter names. After completing one of these options follow the steps outlined below to re-run OSD.Upgrade.exe.
• Error: "CommonCore.inf: (0xFFFFFFFF) OSD.Upgrade.exe,60000"
  • This is a general error indication. Review the log for additional errors.
• Error: "DirectoryNotFoundException"
  • Errors referring to a .0 or an mpkg package indicate that a .0 file has been extracted to a sub-folder of the ldlogon folder. DO NOT delete any .0 files from the root of ldlogon. Navigate to the directory specified in the log (i.e. C:\Program Files (x86)\LANDESK\ManagementSuite\ldlogon\mac) and delete the .0 file. To prevent additional errors when re-running OSD.Upgrade.exe delete any additional .0 files that are found in sub-folders of the ldlogon folder leaving only the .0 files in the root of ldlogon. Follow the steps below to re-run OSD.Upgrade.exe.
  • Errors referring an ALL.REG file indicate that the wim file was still mounted when osd.upgrade.exe tried to execute. This is most likely due to errors in the previous attempt at running OSD.Upgrade.exe. Review the log and correct and additional errors found before following the steps below to re-run OSD.Upgrade.exe
• Error Non-fatal error: FilterUnload failed, hr=0x801f0013
  • This is normal and does not indicate a problem. Continue reviewing the log file for additional errors.
• Error: System.ComponentModel.Win32Exception
  • You are running the process as a restricted user. Either log in as an administrative user or right click OSD.Upgrade.exe and select run as administrator.
• Error System.IO.IOException: Element not found.
  • This error indicates that there is still a wim file mounted. Review the log for additional errors prior to this error. Follow steps below to re-run the OSD.Upgrade.exe process.
• Error System.UnauthorizedAccessException
  • This error indicates either that there is still a wim file mounted, or that the bootmedia.wim.bak already exists. Bootmedia.wim.bak can be deleted as long as bootmedia.wim exists. Review the log for additional errors and then follow the step below to re-run OSD.Upgrade.exe.
• Error WAIK is not installed
  • This is normal and does not indicate a problem. Waik should have been uninstalled prior to upgrade. If Waik is installed, uninstall it. Continue reviewing the log file for additional errors.

Preparing to Re-Run OSD.Upgrade.exe

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

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

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

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

This article applies to LANDESK Management Suite 9.5

Issue:

When running a scheduled task to deploy the PXE Representative it fails.

Workaround:

The PXE Representative can be manually installed by following these steps:

1. Push the "PXE Representative Removal" script to the PXE representative and then reboot the PXE representative once removal is complete.
2. Copy OSDREP.MSI from the core under Managementsuite\landesk\files to the PXE Representative.
3. Manually run OSDREP.MSI on the PXE Representative.
4. Verify that the LANDesk(R) PXE MTFTP Service and LANDesk(R) PXE Service are both installed and started. 
5. On the PXE representative, verify that within Program Files (x86)\LANDesk\PXE\System\images\ there are four folders:

   Boot, EFI, IA32 EFI, and x86pc

6. If missing files, the OSDREP.MSI may be corrupt. Obtain a clean copy of the OSDREP.MSI from an LDMS installer or Service Pack installation package.

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.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:

http://msdn.microsoft.com/en-us/library/windows/hardware/ff567893(v=vs.85).aspx

Updating WindowsPE Image

Any time that a driver is added to the WinPE image, or the WinPE image is modified in any way, those changes have to be transfered to all PXE representatives. Normally this is done by simply re-deploying the PXE representatives. However this can take up extra bandwidth and time. Attached are scripts that will simply copy the WinPE image from the core to the PXE representatives. There is a script for 8.8 and for 9. Simply download the script and save it to \\CORE\ldmain\scripts. Once there, it will appear with the All Other Scripts in the OSD tool with the PXE representative deployment scripts.

Note: This script WILL NOT install a PXE representative and should ONLY be run on clients that have already had the PXE representative deployed.

Issue

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

Cause

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

Resolution

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

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

LANDesk Mangement Suite 9.0 and later

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

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

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

          Delete the following Registry Keys for 64 bit clients:

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

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

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

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

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

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

     5. From the command line (as administrator) in the \LDCLIENT directory run the following

"clientdbutil.exe /create"

     6. Verify that a new database, (LDClientDB.db3) was created in the same path as you deleted above

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

See Community discussion for additional tips and information:

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

Applies to LANDESK Managment Suite 9.5 SP2

Issue:

How to capture a Windows 8.1 image with a provisioning template using IMAGEW.EXE v2.

How to capture a Windows 8 image with a provisioning template using IMAGEW.EXE v2.

How to capture a Windows 7 image with a provisioning template using IMAGEW.EXE v2.

Solution:

Follow the instructions in the LD95SP2Capture document attached to this article. The document only shows Windows 8.1 but the same steps will work for Windows 7 or Windows 8. The instructions work whether the computer is doing a BIOS boot or a UEFI boot.

Create image capture script

a. Open the LDMS console. Click Tools > Distribution >OS Deployment

b. Right click on All OSD/Profile Migration Scripts and select a new script based on the imaging environment you will use.

c. Select capture image. Give the script a name and a description.

d. Specify the credentials to be used

e. Specify the image information. If you will use LANDESK's imaging tools, choose LANDESK ImageW V2 for the Image type. Enter the UNC path where you will capture the image. For the path to the imaging application, use \\coreservername\ldmain\osd\imagew 2

Replace "coreservername" with the name of your core server. Replace "imagingtool" with imagew.exe (for Windows PE) or image.exe (for DOS).

f. Right click on the OSD script and click advance edit

g. Click Use editor button

h. Copy and paste this line, and modify OSD script as below:

i. If using the PXE Boot Menu, it is necessary to drag the script from the scripts folder to the PXE Boot Menu folder under the PXE Boot Menu section. This places the script in the bootmenu.cfg file.

NOTE: It is advised that you use the "Image Type" of "LANDesk ImageW V2".   This will require the path to be entered for the image application in the last line of the script to reflect the correct path.  For version 9, it is "\\Coreservername\ldmain\osd\imagew 2\imagew.exe"

To open this screen select Tools | Distribution | PXE Boot Menu. Once this screen is open, drag the script to the PXE Boot Menu folder. After the script is copied to the PXE Boot Menu, click the Update button which refreshes the bootmenu.cfg file stored on the core.

How to create Deploy OSD Script based partition Image, please refer to this article:

http://community.landesk.com/support/docs/DOC-30709

Applies to all versions of LANDESK Management Suite

Question:

How to manually install a PXE representative with a USB key?

You may want to create a PXE representative on a distant managed device on another site, for example. And unfortunately the connecion to reach this site is poor or unreliable.

Answer:

The steps to install the files and services necessary to run a PXE representative via USB key on this managed device:

1. Copy the following files from the Core to the PXE Rep as per below.
   
   IMPORTANT!
   PLEASE NOTE: Some files when copied across also need to be renamed. EXAMPLE from below pxeboot.0 is renamed to startrom.0
   
   C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\files\bootmenu.1, C:\Program Files (x86)\LANDesk\LDClient\bootmenu.1"
   C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\files\bstrap.0, C:\Program Files (x86)\LANDesk\LDClient\bstrap.0"
   C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\files\dosundi.1, C:\Program Files (x86)\LANDesk\LDClient\dosundi.1"
   C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot\bootmenu.0, C:\Program Files (x86)\LANDesk\LDClient\bootmenu.0"
   C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot\dosundi.0, C:\Program Files (x86)\LANDesk\LDClient\dosundi.0"
   C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot\bcd.dat, C:\Program Files (x86)\LANDesk\LDClient\bcd"
   C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot\bcd_x64.dat, C:\Program Files (x86)\LANDesk\LDClient\bcd_x64"
   C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot\bcd_ia32.dat, C:\Program Files (x86)\LANDesk\LDClient\bcd_ia32"
   C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot\boot.sdi, C:\Program Files (x86)\LANDesk\LDClient\boot.sdi"
   C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot\boot.wim, C:\Program Files (x86)\LANDesk\LDClient\boot.wim"
   C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot\boot_x64.wim, C:\Program Files (x86)\LANDesk\LDClient\boot_x64.wim"
   C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot\bootx64.efi, C:\Program Files (x86)\LANDesk\LDClient\bootx64.0"
   C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot\bootia32.efi, C:\Program Files (x86)\LANDesk\LDClient\bootia32.0"
   C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot\bootmgr.exe, C:\Program Files (x86)\LANDesk\LDClient\bootmgr.exe"
   C:\Program Files (x86)\LANDesk\ManagementSuite\landesk\vboot\pxeboot.0, C:\Program Files (x86)\LANDesk\LDClient\startrom.0”
   
   
2. Place the file osdrep.msi into a share drive on the managed device (i.e. the future PXE Representative computer)
   NOTE: FInd the osdrep.msi on the Core Server on the folder "C:\Program Files (x86)\LANDesk\ManagementSuite\ldmain\landesk\files"
   
   
3. Run the following command from your managed device on CMD

"C:\Program Files (x86)\LANDesk\LDClient\sdclient.exe" /p="\\<YOURPXEREPNAME>\<YOURSHARENAME>\osdrep.msi" /msi /N /An /Ac

EXAMPLE: C:\Program Files (x86)\LANDesk\LDClient\sdclient.exe /p="\\W2K12DC\c$\osdrep.msi" /msi /N /An /Ac

IMPORTANT   Give sufficient time for the install to finish, it can take up to 15 minutes depending on performance.

Description

LANDESK provides the ability to put one PXE Rep on each subnet so that settings on the network never have to be configured.

While not having to change any the configuration on any network device is a good feature, it may be beneficial and easier in certain environments to make network changes. For example, an environment that has 5 sites with 20 subnets each, would require 100 PXE Reps to avoid network configuration. However, with network configuration, they would only have to manage 5 PXE Representatives. Such a design would likely be preferred and LANDESK supports this design.

A PXE Representative can be used for multiple subnets similar to how any DHCP/Bootp server can be used for multiple subnets. This requires that a DHCP Relay agent exist that can forward DHCP/Bootp requests.

Diagram

The following diagram shows how subnets do not have a PXE Representative. Instead a DHCP Relay agent (often called an IP Helper with Cisco switches) exists on the network and must be configured to forward traffic to both the DHCP server and the PXE Representative, which can be on any other subnet.

Troubleshooting

Troubleshooting the PXE Representative is as simple as using Wireshark to verify that the PXE Rep received the DHCP/Bootp packets and responded.

Add the following filter to limit Wireshark traffic to bootp protocol on port 4011:

bootp || udp.port == 4011

Also, for TFPT, Wireshark can demonstrate the packet arriving and the response.

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\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.

    
    
    
    
    
    

Prerequisite:

Before you can deploy image based partitions, you need to prepare the image file based partitions, To capture image based partitions , please refer to this article:

http://community.landesk.com/support/docs/DOC-30713

How do I create a deployment script?

a. Open the LDMS console. Click Tools > Distribution >OS Deployment

b. Right click on All OSD/Profile Migration Scripts and select a new script based on the imaging environment you will use.

c. Select deploy image. Give the script a name and a description.

d. Specify the credentials to be used

e. Specify the image information. If you will use LANDESK's imaging tools, choose LANDESK ImageW V2 for the Image type. Enter the UNC path where you will capture the image. For the path to the imaging application, use \\coreservername\ldmain\osd\imagew 2

Replace "coreservername" with the name of your core server. Replace "imagingtool" with imagew.exe (for Windows PE) or image.exe (for DOS).

f. Click save button to save the deploy image script

g. Right click on the OSD script and click advance edit

g. Click Use editor button

h. Copy and paste this line, and modify OSD script as below:

i. If using the PXE Boot Menu, it is necessary to drag the script from the scripts folder to the PXE Boot Menu folder under the PXE Boot Menu section. This places the script in the bootmenu.cfg file.

NOTE: It is advised that you use the "Image Type" of "LANDesk ImageW V2".   This will require the path to be entered for the image application in the last line of the script to reflect the correct path.  For version 9.5, it is "\\Coreservername\ldmain\osd\imagew 2\imagew.exe"

To open this screen select Tools | Distribution | PXE Boot Menu. Once this screen is open, drag the script to the PXE Boot Menu folder. After the script is copied to the PXE Boot Menu, click the Update button which refreshes the bootmenu.cfg file stored on the core.

Applies to LANDesk Management Suite 9.0 SP3 and newer

Issue

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

Cause

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

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

Resolution

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