Quantcast
Channel: Ivanti User Community : Document List - OS Deployment and Provisioning
Viewing all 639 articles
Browse latest View live

Troubleshooting LANDesk Provisioning

$
0
0

Troubleshooting LANDesk Provisioning

Troubleshooting - Core Side

View histories for failures or error messages

View provisioning.log located in
CoreServer\ldlogon\provisioning folder for template execution messages

View PXE Rep deployment and prov_schedule log files in the
CoreServer\ldmain\log folder

 

Troubleshooting – Target Machine

 

WinPE

 

 

 

View the launch.log in X:\ldprovision folder for provisioning loading status

View ldProvision.log in X:\ldprovision folder for error messages and XML content

View Output.txt in c:\ldprovision folder for application error messages only if app hangs

 

LinuxPE

 

 

 

Use Alt + F2 to toggle to command prompt

View /var/log/messages for errors loading LinuxPE

View /var/log/taskmaster.log for errors load provisioning

View /var/log/provisioning.log for template errors and XML content

Windows Target device

View ldProvision.log in WinDir\Temp folder for error messages and XML content

View run##.tmp in WinDir\Temp folder for template execution messages

Linux Target device

View ldProvision.log in /tmp folder

 

Troubleshooting – PE Manual Execution

Load new console in PE and change to ldprovision folder X:\ldprovision – PXE, Z:\ldprovision – Boot Media

Launch provisioning by executing ldprovision.exe

ldProvision command-line options:

-c corename or IP -d debug

-f task XML file name -h help

-m mode 1-3 (1=default) -t download directory

-s run as daemon (Linux only)

-v version (NOTE: This is lower case v)

-V # (1-255) Verbose logging (NOTE: This is capital V)

Example: ldprovision –c mycore –t x:\ldclient -V 255     

 

Troubleshooting – OS Manual Execution

 

Windows OS

Using target that has ld agent installed, map drive to or copy contents of
CoreServer\ldlogon\provisioning\windows from core to local folder

Execute ldprovision as shown in PE manual execution, note log files are placed in windir\temp

 

Linux OS

Using target that has ld agent installed, mount point to or copy contents of
CoreServer\ldlogon\provisioning\linux from core to local /tmp folder

Execute ldprovision as shown in PE manual execution, note log files are placed in var/log---


Troubleshooting PXE boot (OSD and Provisioning)

$
0
0

PXE Boot

PXE booting is the most common method used to get machines into a pre-boot environment in order to capture and deploy images, or run provisioning templates. PXE or Preboot Execution Environment has been around for quite a while and allows a machine to boot using a NIC to load a boot image or boot instructions from another computer on the network. For more information about PXE please see:

 

LANDesk PXE boot

LANDesk uses a DHCP Proxy, or PXE Representative to implement PXE booting. The PXE software is installed on any machine on a subnet where it listens to DHCP requests. If a request is heard that includes a PXE boot request, the PXE Representative sends the requisite information to allow the client to use the PXE representative as a boot server. An image (WinPE, DosPE or LinuxPE) is then transmitted to the client via TFTP from the PXE representative. That image is loaded into RAM and the machine loads the preboot environment. For more indepth information on the LANDesk PXE process see Understanding the PXE Process.

 

PXE Errors

PXE errors will present immediately upon attempting to boot the machine from PXE. The error will usually displayed will be in the format of PXE-EXX followed by a description. For a complete list of PXE errors and descriptions as well as some solutions, please see:

PXE Boot errors and descriptions.

 

The most commonly seen PXE errors are:

PXE-E52 ProxyDHCP offers were received. No DHCP offers were received

PXE-E53: No boot filename received

PXE-E55 ProxyDHCP: No reply to request on port 4011

PXE-E74 error when PXE booting and no F8 menu appears. - PXE-E74 bad or missing pxe menue and or prompt information

 

TFTP Errors

After the PXE process has identified the boot server and started processing, the client will download an image file via TFTP. This can sometimes cause errors as well. Please review the following articles about TFTP errors:

PXE Boot fails with TFTP timeout error

 

Other PXE boot issues

There are a number of other miscellaneous issues seen during PXE boot. Please review any article that applies.

How Tos
PXE Deployment Issues
Other Errors

LANDesk OS Deployment and Provisioning Landing Page

$
0
0

LPOSD.png

 

OS Deployment and Provisioning for LANDesk Management Suite

 

Changes with 9.5

Changes with 9.0 SP3

 

Initial Install and Configuration



Additional Options and Information



Sample Provisioning Templates



Troubleshooting this Component

 

Notice: Any E-Learning content is available by default to Members who have a minimum support agreement at Professional level.

 

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 LANDesk OSD and Provisioning if this page hasn't helped.

Imaging machines with LANDesk Agent installed

$
0
0

Problem

 

Creating an image of a machine with a LANDesk Management Agent installed can cause the machines, which 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 on install of the client.

 

Resolution

 

Important:

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 the Sysprep or unattend.txt file. LANDesk integrates with  Sysprep by adding commands to the GUIRunOnce section to install the LANDesk Agent once the image has been restored to a workstation.  Besides causing duplicate devices, the LANDesk agent is often updated and adding it to the image will quickly cause your image to be outdated and within a short time, you will have to be reinstalling the agent after laying down the image anyway.

 

 

If the agent must be included in the image, then 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 8.1 - 8.8

  1. Search for and Delete all instances of LDISCAN.CFG Note: This is a hidden file
  2. Delete HKLM\Software\Intel\LANDesk\CommonAPI\UniqueID
  3. Delete HKLM\Software\LANDesk\CommonAPI\UniqueID

 

LANDeskMangement Suite 9.0 and later

 

  1. Install the LANDesk agent, then STOP all LANDesk related services
  2. Delete the following: For 32bit clients -  HKLM\Software\Intel\LANDesk\CommonAPI\UniqueID and for 64bit clients - HKLM\Software\Wow6432Node\Intel\LANDesk\CommonAPI\UniqueID
  3. Delete the following: For 32bit clients -  HKLM\Software\LANDesk\CommonAPI\UniqueID and for 64bit clients - HKLM\Software\Wow6432Node\LANDesk\CommonAPI\UniqueID
  4. On XP delete C:\Documents and Settings\All Users\Application Data\LANDesk (delete the entire directory and subdirectories)
  5. On Windows 7 delete C:\ProgramData\LANDesk (delete the entire directory and subdirectories)
  6. Run from command line (as administrator) "clientdbutil.exe /create" from the \ldclient directory
  7. Verify that a new database was created in the same path as you deleted above

 

 

 

See Community discussion for additional tips and information:

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

WinPE Version Information by LANDesk Management Suite Version

$
0
0

Applies to LANDesk Management Suite 8.8 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 w HP ElitePad Integration Update

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

 

LANDesk Management Suite 9.0 SP3 - LANDesk Management Suite 9.5

 

LANDesk Management Suite 9.0 - LANDesk Management Suite 9.0 SP2

  • The WinPE version is updated to 2.0.
  • WinPE 2.0 requires Windows Vista drivers (NDIS 6.1).
  • For additional information on managing drivers in LANDesk Management Suite 9.0 please see How to add drivers to WinPE for LANDesk 9

 

LANDesk Management Suite 8.8

Updating the WinPE image on PXE representatives

$
0
0

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.

DHCP Configuration when using LANDesk PXE Boot

$
0
0

Description

When PXE booting using LANDesk PXE boot, a DHCP server is necessary to provide an IP Address. However, there are 4 scope options in DHCP that are related to PXE. This article summarizes them and their settings.

DHCP Scope Options

 

There are 4 DHCP Scope options related to PXE that can work in 2 sets of 2: 43 and 60 and 66 and 67

 

When a PXE client boots, it sends out a DHCP request. This DHCP request contains option 60 to identify it as coming from a PXE client and not an OS.

 

A normal (microsoft) DHCP server reply with a DHCP provided IP address but, when neither option 60 nor option 43 is set in the DHCP Scope options, the PXE clients will still have no clue where the PXE server is and will therefor wait until a PXE server contacts them. In this way, the PXE server must listen to DHCP discovery packets containing option 60 sent by PXE clients and answer at the same time as the DHCP server does. This is the default method and also the reason why you might need to add IP Helper addresses of the IP of your PXE Representative to your VLAN configuration in the same way you would for a DHCP server when the clients and your DHCP/PXE are in seperate VLANS.

 

However, a DHCP Server that also has the PXE representative installed will send out only 1 reply, so we need option 60 set in DHCP. When option 60 is set to 'PXEClient', it means that the DHCP server knows where the PXE server is. If option 43 is not set, it means the PXE server is on the same computer as the DHCP server (same IP address). If option 43 is set, PXE clients must decode option 43 to know how to reach the PXE server.

 

Option 60 is not normally available in DHCP, but can be created and set automatically by running the following commands:

netsh dhcp server add optiondef 60 PXEClient String 0 comment=PXE support

netsh dhcp serverset optionvalue 60 STRING PXEClient

 

After the client receives the PXE answer it needs to go to the next step, which is to download a boot environment. This is where DHCP options 66 and 67 come in. Option 66 tells the PXE booted client what the Bootserver is and option 67 the Bootfile that needs to be loaded. These 2 options don't work with LANDesk PXE representatives and should always be left unconfigured! The LANDesk PXE makes use of an extra layer in the bootprocess, the LANDesk PXE menu, which includes options for Local Boot, WinPE menu, WinPE Provisioning etc. Configuring the DHCP option 66 and 67 means a PXE Boot will equal a boot to a bootenvironment like WinPE, no flexibility.

 

Summarizing:

Set Option 60 if the PXE representative is installed on a DHCP Server, let option 43 unconfigured

Set Option 60 in combination with option 43 if the PXE representative is not on the DHCP server, but also not in the broadcast range of the client

Options 66 and 67 should NOT be set.

LANDesk Provisioning Landing Page

$
0
0

SSM landing.png

Provisioning for LANDesk Management Suite

  • This is a list of highly recommended documents for increasing overall knowledge of this component.
  • The article's listed below are applicable to LANDesk Management Suite 9.5 and 9.0. They may also apply to 8.8.
  • If you want to review additional content regarding this component, please use the Provisioning Discussion Tab or Provisioning Documents Tab

 

Changes with 9.5

Changes with 9.0 SP3

 

Initial Install and Configuration

Additional Options and Information

Troubleshooting this Component

Sample Provisioning Templates

 

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 hasn't helped.


Changes to Provisioning Action Handlers in 9.5

$
0
0

Applies to LANDesk Management Suite 9.5 and newer.

 

Description

In LANDesk Management Suite 9.5 provisioning action handlers have been added or updated to enable users to accomplish the same provisioning tasks in fewer steps. The addition of preferred server actions allows for a single template to be used for multiple sites, reducing the management requirements of existing templates. Preferred server actions leverage the credentials provided in the preferred server configuration.

 

With the increased use of preferred servers for credentials, it is recommended that you configure the core in the preferred server configuration. An IP range (i.e. 1 .1.1.1-1.1.1.2) can be configured for the core so that clients will not use the core as their preferred server but will be able to get credentials for the core.

 

New or Improved Actions

Capture/Deploy Image (improved)

Capture Profile (new)

Deploy Profile (new)

Download from Preferred Server (new)

Map/Unmap Drive to Preferred Server (new)

 

Capture Profile

Capture profile enables a single provisioning action to capture user profiles using the LANDesk SMA tool. Greatly reducing the number of provisioning actions required to capture profiles. Configuration of the SMA xml is required to define items that will be captured during the SMA process. Capture profile does not make use of preferred servers, the capture fill will be written to the specified path.

 

Capture Profile Action

CaptureProfile.JPG

 

Capture Profile Xml Selection

CaptureXml.JPG

 

Capture Profile Xml Configuration

CaptureXmlDetails.JPG

 

Deploy Profile

Deploy profile enables a single provisioning action to deploy user profiles using the LANDesk SMA tool. Greatly reducing the number of provisioning actions required to deploy profiles.

 

Deploy Profile Action

DeployProfile.JPG

 

Download from Preferred Server

Provides configuration options for the download location in any combination of peer, preferred server and/or source. Provides control of bandwidth usage during the download.

 

Download from Preferred Server Action

downloadpref.JPG

 

Map/Unmap drive to preferred server

Maps drives based on the preferred server configuration. Drives can then be used to run additional tools or installations. This action does require an agent to be installed. WinPE includes the necessary agent components for this action.

 

Map Drive to Preferred Server Action

map pref.JPG

Capture/Deploy Image

Capture image will automatically map and save the image to the path provided. It does not map to the preferred server but will use preferred server credentials to authenticate to the path provided. The capture file should be replicated to preferred servers for deployment. During deployment if a preferred server is used, the image file must be on the preferred server or the template will fail. The action will not fail over to the core for the image file.

 

The Deploy image action automatically maps a drive using the preferred server configuration if the image type is ImageW or ImageX. Actions to map to the image file and/or imaging tool are not longer required.  Templates imported from 9.0 will use and image type of other and will continue to use the mapped drives. If the template is changed from other to ImageW or ImageX, the map drive actions should be removed.

 

Capture Image

capture Image.JPG

 

Deploy Image

Deploy Image.JPG

When booting into WINPE nothing happens log shows ERR_Fail",-2147481753

$
0
0

Description


When booting into WINPE opening the PXE boot menu and selecting a script nothing happens. The custom job (cj-scriptname-date.log - located in \\core\ldlog) log shows ERR_Fail",-2147481753

 

Example of log:

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

"computername",   "OK" ,0,0:00:00,4/5/2011 10:43:45 AM,4/5/2011 10:43:45 AM,"WINPE, TIMEOUT=1800"
" computername ",  "ERR_Fail", -2147481753,0:00:22,4/5/2011 10:43:45 AM,4/5/2011 10:44:07 AM,"diskpart /s X:\LDClient\rmvol.txt" ;

 

"Job Complete" ,"0 Done"  ,"1 Failed","0 Off","0 Unknown"

 

Causes

 

Error code:-2147481753,  indicates the .0(core certificate) file is missing in WinPE image or an incorrect .0 file was injected

 

Resolution


Ensure the core server has a valid certificate. These are stored in the C:\program files\LANDesk\Shared Files\keys directory. Each valid certificate will have three files. There should be one .crt file, .key file, and a .0 file with the same date/time stamp for each valid certificate.  The .0 file will also be in the ldlogon directory on the core ( \\core\ldlogon).

 

For LDMS 8.8 SP3 or higher

The ldvpe1.img image should contain at least one .0 file that matches the .0 file on the core.

The .0 file resides in the cba8\cbaroot\certs directory in the ldvpe1.img.

 

To inject the .0 file into the ldvpe1.img

1. Use WinImage (or similar 3rd party tool) to open the ldvpe1.img file in the \ldmain\landesk\vboot folder.

2. Copy the .0 file from the Shared Files\Keys folder on the core into the cba8\cbaroot\certs folder in ldvpe1.img

3. Save the changes to the ldvpe1.img through WinImage. Close WinImage.

4. Ensure that all the .0 files also reside in the ldlogon directory.

5. Redeploy or update all PXE Representatives.

 

For LDMS 9.0 up to SP2


  1. Look in \\core\ldlogon see how many .0 files if only one then please reactivate your WINPE and skip to step 5.
  2. If multiple files exist, it needs to be determined which one is the correct .0 for your current core.
  3. Open the .0 files with a text editor and check for the correct corename (computer=  field).
  4. Once you have found the current .0 file, temporarily move the others .0 files to a different folder and then reactive WINPE.
  5. Once winpe is reactivated update or redeploy your PXE rep(s)
  6. Move additional .0 files back to Ldlogon if they are still needed.

 

For LDMS 9.0 SP3 and LDMS 9.5 and later

 

  1. Re run the OSD.Upgrade.exe process.

PXE-E53: No boot filename received

$
0
0
Description

When attempting to PXE boot, the following error appears:

 

PXE-E53: No boot filename received

 

Also,

PXE Boot fails.

No F8 option is recieved by clients.

Unable to PXE Boot machines.

Unable to network boot machines.

Cause

Possible causes:

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

Possible steps for resolution:

  • Ensure that a PXE rep is on and is deployed in the same broadcast domain as the target machine.
  • Ensure that no firewall is blocking requested packets from PXE booted machines.
  • Ensure PXE services are running.  The two services are "LANDesk(R)PXE Service" and "LANDesk(R) PXE MTFTP Service". If they are running, restart the services.
  • Redeploy the PXE Representative.
  • If PXE services repeatedly stop on PXE representatives, download and install the latest service pack on the core, then remove and redeploy PXE representatives.
  • Disable the Windows Deployment Services (WDS) on the PXE representative.

 

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

 

For more information on PXE boot errors please see:

PXE Boot errors and descriptions.

For more information on troubleshooting PXE boot please see:

Troubleshooting PXE boot (OSD)

Using the CSVImport utility

$
0
0

Automating the naming of computers during an OS Deployment task reduces the work load of the IT department, saving time and money. OSD has the ability to work with sysprep to name computers based off Device Name in the database. It uses the Mac Address of a computer to match a device to the computer name associated with that Mac Address in the Database.


Newly purchased computers do not exist in the LANDesk database as these computers have never been scanned. Such computers can be manually added to the database before deploying the image allowing the computers to be automatically named as part of an OS Deployment task.


To be able to add computers to the database before they are imaged, and possibly before the new computers are even unboxed, LANDesk provides a utility called csvImport.exe to manually add devices to the database. This utility is located in the C:\Program Files\LANDesk\ManagementSuite directory.

Changes to Provisioning Action Handlers in 9.5 SP1

$
0
0

Create Partition

To reduce the number of actions needed in a template additional options have been included with the create partition action handler. They include the ability to mount the newly created parittion, format the partition, and make the partition bootable. The ability to create GPT partitions has also been added.

 

CreatePartition.JPG

 

Hardware Independent Imaging (HII)

HII can now be run in both the Post-OS configuration (WinPE) section of provisioning as well as the System configuration section (Client OS). During the Post-OS configuration HII will only apply driver files. Driver setup packages are ignored. During the System configuration HII will apply assigned driver setup packages. Driver INF files are ignored as they should already have been applied in the Post-Os configuration.

 

HII.JPG

Patch System

The option to select the scan and repair settings that will be used has been added.

PatchSystem.jpg

 

Template Options

Template options have been added to allow provisioning to run silently, control how long the client GUI is visible after completing and to retain the provisioning folder when the template has completed.

ProvOptions.JPG

 

Windows Refresh

Support for Windows 8 refresh and reset have been added. Note that recovery media from your manufacturer may be required. Options for using the local WIM or specifying a WIM are available.

Reset: Deletes all personal files and settings. By default will quick delete files meaning files could be recovered using special software. Checking the option to fully clean the drive will erase data thoroughly making  recovering deleted files far less likely.

Refresh: Does not affect user data or settings.

Create and assing local WIM: Creates and image of the device in the current statue and assigns it as the local refresh/reset wim.

Assign specified image as local WIM: Assigns a new WIM as the local WIM on the device.

WindowsReset.jpg

Hardware Independent Imaging (HII) Preview

$
0
0

Applies to LANDesk Management Suite 9.5 SP1 and newer

 

Description

Hardware Independent Imaging allows drivers to be injected during the imaging process specific to the destination hardware. During hardware migration planning

driver decisions must be made. In order to assist with that migration planning a preview option has been added to HII, enabling IT to review driver assignments prior to upgrading to a new OS.

 

Requirements

  • The client where the preview is being run must have an agent installed
  • The client must be able to download the drivers.db3 file from the core server

 

Running HIIClient

  1. Copy HIIClient.exe to the client from the core. The file can be found in the %LDMS_HOME%\landesk\files directory.
  2. Run HIIClient with the appropriate preview options (See below).
  3. Review the logs for driver assignment and detection found in the directory where HIIClient was run.
    1. HIIClient.log
    2. HIIPreview.log

 

HIIClient options

hiiclient [/?] [/uncpath] [/taskid <taskid>] [/preview | /previewall] [/os <os> /arch <architecture>]

 

/? - Shows standard help and syntax information

/uncpath - Specifies if HII should use unc based paths to drivers

/taskid - Specifies the <taskid> to use to ask for SWD snippet when processing packaged drivers

/preview - Specifies if HII should run in preview only mode.

/previewall - Specifies if HII should run in preview only mode with debug information.

/os - Only valid with both /preview and /arch.

          Specifies which OS the preview should be run for.

          Valid options are: winxp, win7, win8, server2003, server2008r2, server2012

          If not specified the currently detected OS will be used.

/arch - Only valid with both /preview and /os.  Specifies which architecture the preview should be run for.

          Valid options are: x86, x64.

          If not specified the currently detected Architecture will be used for the preview.

How to Add Drivers to WinPE for LANDesk 9.5

$
0
0

How to Manage Drivers in WinPE for LANDesk 9.5

 

Applies to LANDesk Management Suite version 9.5, 9.5 SP1 and newer.

 

Description

In order to perform imaging in the LANDesk Management Suite the WinPE image used during the imaging process must contain drivers for devices such as the network adapter or hard drive controller.

In 9.5 additional drivers for Intel NICs, Intel hard drive controllers, and Intel USB3 have been included in the WinPE image for convenience.

The drivers for the WinPE image should match the version of the image file being used (32-bit for boot.wim and 64-bit for boot_x64.wim), not the OS being deployed.

 

For adding drivers in LANDesk Management Suite 9.0 please see How to add drivers to WinPE for LANDesk 9

For adding drivers in LANDesk Management Suite 8.8 please see How to add drivers to the WinPE Image (formerly KB #3469)

 

Additional information about the WinPE version and required driver versions for each version of LANDesk Management Suite can be found at WinPE Version Information by LANDesk Management Suite Version

 

Resolution

To manage drivers to the WinPE image for 9.5 use the following steps.

 

1. From the console go to Tools > Distribution > OS Deployment.

2. On the Operating System Deployment screen select “Manage the drivers in the WinPE Image.

winpe1a.jpg

 

3. Select the WinPE Image that you want to manage drivers in. The default selection (boot.wim) is the WinPE image used for 32-bit vBoot and PXE.

winpe2a.jpg

 

4. To manage drivers in the 64-bit WinPE image select "Others (For user specific image)" option. Browse and select the boot_x64.wim in the vboot directory where the default boot.wim is located.

winpe3a.jpg

 

5. The image file will be processed to open the WinPE image and gather the list of drivers currently in the WinPE image file.

winpe4a.jpg

 

6. Select add or remove to manage drivers.  Note: Drivers that we included by Microsoft in the WinPE image cannot be removed. If the driver list is blank it indicates that the image file is mounted by another process and must be unmounted before drivers can be added.

winpe5a.jpg

 

7. When adding a driver a driver name must be provided. Using a name that easily identifies the driver and hardware is recommended for ease of use as additional drivers are added and removed. Browse to the location of the INF for the driver. Note: The driver must match version of the OS in the WinPE image, not the OS being deployed. The driver for the boot.wim must be a Windows 7 32-bit driver. The driver for the boot_x64.wim must be a Windows 64-bit driver.

     a. Note: If you have applied the HP ElitePad Integration update the version of WinPE has been updated to 4.0. This requires Windows 8 drivers to be used in the WinPE. For additional information please see doc???

winpe6a.jpg

8. After the necessary drivers have been added, select Finish and the drivers will be injected to the image.

9. After the image has completed processing it is necessary to update existing PXE representatives. Instructions on updating PXE representatives can be found at Updating the WinPE image on PXE representatives


OSD.Upgrade.exe error during installation

$
0
0

Applies to LANDesk Management Suite 9 SP3 and newer

 

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.

 

Description

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 curent errors easier to find.

 

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: imagex /unmount
    • 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 command:
    • imagex /unmount "C:\mountpath". Where mountpath is the mount path listed from the imagex /unmount command or the folders specified in step 1.
    • 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.

Getting started with Provisioning for Windows 7 in LANDesk® Management Suite 9.5 and 9.5 SP1

$
0
0

Applies to LANDesk Managment Suite 9.5

Applies to LANDesk Managment Suite 9.5 SP1

Issue:

How do you setup provisioning to deploy a Windows 7 image with the LANDesk imaging tool (IMAGEW.EXE v2)?

What mode is required by provisioning for sysprep?

 

Solution:

Follow the instructions in the LD95Provisioning document attached to this article.

OSD Deploy script is failing to run with the error -1917386819.

$
0
0

Issue:

OSD script is failing with the error -1917386819 in the CJ log when running the imaging command.

Re-creating the OSD script did not resolve the issue.

Permissions are set correctly for the user specified in the OSD script.

 

Cause:

The image path had a space in the name.

 

Solution:

Removed the space in the image path then changed the OSD script to use the new path.

Provisioning template fails to load in WinPE

$
0
0

Applies to LANDesk Management Suite 9 SP3 and newer

 

Issue

When selecting a template to run on a WinPE device, or scheduling a template to a machine in WinPE, the template will not start and usually goes through the 40 retries. Looking in the LANDesk Management Console, the machine appears in the task and may show as "Failed" and/or "Off". Often this same template worked just fine in LANDesk Management Suite 9 SP2.

 

The Prov_Schedule.exe.log file on the Core Server often says "GetDeviceNameAndIP failed" or "Failed to preprod machine"

 

Cause

This issue is caused by attempting to run a Provisioning template that contains actions in the System Migration section on a machine in WinPE. Most commonly this is seen in a template that has a vBoot or Reboot action in the System Migration section to start the template. Normally this is so that machines that are still in Windows can get into WinPE.

 

Because the machine is in WinPE, the processes that normally start the template don't function and cause the template to fail, since the first action (Reboot) cannot be run.

 

Why did this work before?

Many times the exact same template worked perfectly in previous versions of LANDesk 9, and started having problems in SP3. Prior to SP3, there were significant issues on getting accurate and correct status information to the Core server in a timely manner. Many times, all of the machine in the task would have had a status of "Delayed". This status was incorrect and would often persist even after the task had started. However this particular problem allowed templates that contained System Migration actions to skip the entire section when started on a client already in WinPE. Basically another problem allowed functionality that shouldn't have existed. In SP3, the status and task information is much more correct and timely, meaning machines in WinPE can no longer take advantage of the error and skip the System Migration step.

 

This is the intended functionality. While many templates simply have a Reboot action to get the machine to WinPE, the System Migration section could contain other actions that could be vital. For example, it could be capturing a profile or backing up files prior to imaging the machine. Skipping those actions could be detrimental.

 

Solution

At present, the best solution is to remove the Reboot (or vBoot) action from the System Migration section of the provisioning template if you would like to start the template on machine in WinPE. That would apply to machines where the template is manually selected from the menu, or the template is scheduled and the machine booted to WinPE.

 

Another template that DOES contain the Reboot (or vBoot) action can be created and used to target clients that are still in Windows and should be rebooted to get into WinPE. The simplest way to do this is to right-click the current template and select Clone and modify it as needed. Alternatively, the WinPE template (the one without the Reboot action) could be included in another template. Then just add a Reboot action at the beginning. That way any changes to the overall process can be made in just the WinPE template and will automatically "sync" with the template containing the Reboot.

HII Driver Management

$
0
0

Applies to LANDesk Management Sutie 9.5 SP1 and newer

 

HII Driver Management

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

 

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

hiitoolbox.png

Disable drivers

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

 

hiidisabled.png

 

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

hiidisableinf.png

Assign Drivers

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

 

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

 

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

 

Assign Driver .inf file

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

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

 

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

Assign Driver Package

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

hiiassignpackage.png

 

Managing Assigned and Disabled Drivers

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

Viewing all 639 articles
Browse latest View live