Applies to LANDESK Managment Suite 9 SP3 and later

The Hardware-Independent Imaging (HII) Driver Repository is a location available via UNC and HTTP that serves as the "master" storage location for all drivers that are used in HII throughout the environment. It can be located on any machine. It does not have to be a LANDESK managed device. The HII Driver Database is also stored in the HII Driver Repository. Everything in the HII Driver Repository can be replicated to Preferred Servers throughout the environment as needed.

Important Note: The information in this document applies to LANDESK Management Suite 9 SP3 and later. HII in earlier versions of LDMS 9 functioned differently and the driver repository cannot be changed from \\coreserver\ldmain\landesk\files\drivers. For more information about using HII in LDMS 9 SP2 and earlier see Hardware Independent Imaging (HII)

Drivers

The drivers that are stored in the HII Driver Repository must be actual, complete drivers and supporting files. A driver file is a .inf file that contains information used to match the driver to the device. It also contains installation instructions and references to any supporting files that may be needed to make the device function.

Many manufacturers provide drivers as a .exe file. These executable files are usually merely a self-extracting wrapper that contains the .inf and supporting files. When the .exe is run, the .inf and supporting files are extracted and then Windows uses the actual driver file(s) to install the device.

LANDESK HII will not function with drivers in the .exe format as there is no way to determine from the .exe what devices the driver applies to. These types of drivers must be extracted to get to the critical driver files. Most manufacturers provide instructions for extracting the driver files from the .exe. Once this is done, the resultant files can be placed in the HII Driver Repository and they will be added to the HII Driver Database and available for deployment.

There are additional sources for drivers that are not recommended. These include large driver packs and driver harvesting utilities. While appealing due to the ease of getting large numbers of drivers quickly, they often result in corrupt, incomplete or bad drivers. When this happens drivers may not install completely or correctly and drivers may be installed that are not applicable to a device.

It is recommended that all drivers be obtained from the manufacturer or vendor of the device. Some large vendors provide websites that allow the download of many drivers, already extracted from a simple web interface.

Shares

The HII Driver Repository can be on any machine in any location. It must be available via UNC and HTTP. It is the only storage server in HII that requires both HTTP and UNC be available. If desired or needed, Preferred Servers where the HII Driver Repository is replicated can have a single share available (HTTP or UNC). It is recommended that the "master" HII Driver Repository be located near the LANDESK Core Server. By default the HII Driver Repository will be configured to the former HII driver store location at \\coreserver\ldmain\landesk\files\drivers and http://coreserver/landesk/files/drivers.

For information about creating a UNC share to be used by LANDESK see How to Configure a Preferred Package Server

For information on creating an HTTP share see How to set up a HTTP share for a Preferred Package Share

Tip: If for some reason you cannot create an HTTP share on the server where you are putting the HII Driver Repository, you can use the LANDESK Core server (or another web server) to provide the HTTP share. Simply create a new virtual directory in IIS and instead of providing a path to a location on the IIS server, point it to a UNC network location. You may need to provide additional credentials to allow IIS to access the files on the remote server. If you do this, make sure that the UNC share is close to the IIS server with a fast connection and remember that this could add to the IIS load on that server.

HII Driver Repository Manager

The HII Driver Repository Manager is accessible via the LANDESK Management Console. To open it select Tools > Distribution > OS Deployment then click the "Manage driver library for hardware-independent imaging" button.

Root UNC where driver files are stored: This is the UNC path to the root of the HII Driver Repository. Drivers can be stored directly in this folder or in any number of sub-folders as desired. The HII Driver Database will be be written to this directory so the path must be available for writing.

Root web URL for accessing the driver files: This is the HTTP path that clients can use to get the driver files and the HII Driver Database.

Note: These paths do not have to match or even be on the same server. However, they must point to the same location on disk.

Repository file count: This is the number of driver files (.inf) that were found and added to the driver library. Drivers require additional files (.sys, .cab etc.) and those files must be stored with the .inf files or the drivers will not function, however they are not counted or included in this total.

Drivers processed: This is the total number of unique devices, OS versions and architecture combinations that can be handled by the current HII Driver Database.

Last update: This is the last time the HII Driver Database was created/updated. It will not updated automatically so if drivers are added the HII Driver Database must be updated.

Save: Clicking Save will commit the changes to the path(s) and build the HII Driver Database. A progress bar and message will indicate when it is complete.

Note: When the HII Driver Database is build, the processing is performed by the machine that is running the LANDESK Management Console. If a remote console is being used and has a poor connection to the HII Driver Repository, the creation of the HII Driver Database may take significantly longer than expected.

Cancel: Clicking cancel will simply close the dialog without updating the HII Driver Database or committing any changes to the path(s).

Preferred Server and Credentials

The HII Driver Repository Manager must be able to read and write to the configured UNC path. Additionally when client machines are being imaged they are not members of any domain and therefore possess no credentials that can be used to access a UNC path.

To help resolve this the HII Driver Repository Manager will make sure that the server configured in the UNC path is configured as a Preferred Server. For information on configuring a Preferred Server see LANDESK Content Replication - Preferred Server (Target) Configuration.

If you do not want this server to be used as a Preferred Server, configure an invalid IP address range (such as 1.1.1.1 to 1.1.1.2) and it will not be distributed to clients. However make sure to configure credentials. Clients can use these credentials to access the HII Driver Database and driver files for download. This allows the clients to authenticate from WinPE even though they are not yet members of the domain and eliminates the need for the creation of NULL or unprotected shares.

If only HTTP will be used by the clients, the HII Driver Repository must still be configured as a Preferred Server in order for the HII Driver Library to be created successfully. However the clients will not use the read credentials as they will access the files via HTTP.

For more information about HII see Hardware Independent Imaging (HII)

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.

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.

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.

Note: These tools were radically updated and improved in LDMS 9 SP3. It is highly recommended to update to SP3 for the best HII functionality, along with other improvements available in SP3. OSD, Provisioning and imaging generally has been improved dramatically. If you would like to use HII in LDMS 9 SP2, please see:

LDMS Version 9 HII Quick Start Guide

The specified document was not found.

Hardware Independent Imaging Components

The information below applies to LDMS 9 SP3. See above for SP2 and earlier.

Hardware-Independent Imaging in LANDESK 9 SP3 consists of a few parts and utilizes other LANDESK functions to provide a complete solution. For information about other aspects involved in using OSD and/or Provisioning to deploy operating systems including image preparation see:

The specified document was not found.

LANDESK OS Deployment Landing Page

LANDESK Provisioning Landing Page

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.0 and 9.5

OSD Logs

LANDESK OSD creates logs for every job that is run. Any failures are noted in the log and can be used to troubleshoot and resolve the problem.

Finding the Logs

The logs will be located on the core server. Locally they are in \Program Files\LANDESK\ManagementSuite\log\. Remotely they can be found at \\CORE\ldmain\log\. The logs will be named CJ-OSD-ScriptName-0-MMDDYYYY-HHMMSS.log.

Reading the Logs

OSD jobs are processed by the Custom Job Processor, so the logs will follow the format of other Custom Job logs. Please see the following example of a deployment job.

Note: Because of the web format, the lines may wrap. In the actual log, each step/command is on one line and will only wrap if word wrap is enabled.

Each line in the log indicates a new command run on a client. The line will only appear in the log once the command is complete, either successful or failed. This means that the machine is currently running the line AFTER the last line in the log.

If the job was run on a single device, or from the PXE boot menu, it will only have one device listed. If it was run on multiple devices as part of a larger job, each line will list the computer and the command so the full script for each computer is scattered throughout the log.

Log

"Machine","CbaStatus","ExitCode","Duration","Begin","End","Command"
"001E4F53C173","OK",0,0:00:00,2/8/2010 12:30:49 PM,2/8/2010 12:30:49 PM,"WINPE, TIMEOUT=1800"
"001E4F53C173","ERR_Fail",-2147481753,0:00:23,2/8/2010 12:30:49 PM,2/8/2010 12:31:12 PM,"diskpart /s X:\LDClient\rmvol.txt"
; "Job Complete","0 Done","1 Failed","0 Off","0 Unknown"

Key

• Computer Name - This is the name that the core has for the client. If the client is not in the database, or cannot be identified, this will be the MAC address

• Status - This is the status of the command. OK is good. ERR_Fail or ERR_Timeout are bad.
• Exit Code - This is the actual exit code returned by the command. It can be used to track down and resolve the problem.
• Duration - This is how long the command took to run. This can be useful in determining if the command behaved as expected.
• Begin and End - These are the date and time stamps when the action started and ended. They are rarely useful.
• Command - This is the actual command that was run.
• Job Status - This is the final status of the job with machine counts for each condition

Troubleshooting

There are a few different values and clues in the log that can be used to identify the problem. The most common are the exit code, status, and the duration.

Status

The status will usually be either OK, ERR_Fail or occasionally ERR_Timeout. These are pretty self explanatory. If the custom job processor ever gets a ERR_Fail or ERR_Timeout, it will stop processing the script and the job will be marked as failed. The final line in the log (before the job status line) will be the line that failed. Usually you can search for more information about the command or the exit code to find possible resolutions.

Sometimes the job completes successfully and every status is OK but in reality the job didn't work correctly or as expected. In this case, each line has to be evaluated and ideally compared to a known good log. Because of the variety of utilities that can be used in and OSD script and the widely varying exit codes, LANDESK does not always interpret the exit code correctly as a failure. In these cases, use the exit code of the line that you think failed to look for solutions. Examples of where this can happen include diskpart and imagew (depending on the failure reason).

Exit Code

The exit code is the actual return value that the command returned. For example, if diskpart is run and the command line arguments were wrong, diskpart returns a 2. The OSD log with therefore contain a 2 as the exit code.

Normally an exit code of 0 indicates success and anything else is a failure. However some vendors stray from this pattern. If a command has a non-zero exit code, the best place to look for an explanation of that code is from the vendor. In the case of diskpart, a list of exit codes (0-5) can be found here, about 1/3 down the page.

A Description of the Diskpart Command-Line Utility

Note: LANDESK OSD uses diskpart several times for operations on the disk. 0 is success, but not all "failures" are real failures. For example, one command goes through all drive letter mapping from A to Z and removes the mount point so that drives can be mapped correctly. However no one has 26 drives so at some point, diskpart will try to remove a drive letter mapping that doesn't exist. In this case, diskpart returns a non-zero value, but there is no "actual" failure. Other utilities may behave in a similar fashion. Information from the vendor and understanding of the command will help identify these cases.

Duration

The duration listed in the log is the amount of time from start to finish that the command took. This is most useful for the drvmap (mapping drives) and actual image utility commands (imagex, ghost, etc).

Most actions in the OSD script don't take much longer than a few seconds to complete. The obvious exception is the command that is actually restoring (or capturing the disk or files). If the duration seems wrong, it probably is, and that command should be looked at carefully. Some examples would be:

• drvmap - This is the utility that maps the needed drives. It should only take a few seconds. It will timeout at about 2 minutes. If it times out, the most likely cause is incorrect credentials or the client cannot contact the target with the path specified. For example, hostname only might not work. The client may need the FQDN of the target.
• Imaging utility (imagew, imagex, ghost etc) - Sometimes the imaging tool runs in a minute or less. Unless the target computer is connected to a fiber-optic network with the world's fastest disks, something is probably not right. This can be a problem accessing the image file, the image file is invalid or corrupt, the client can't get to the disk (drivers), the disk isn't big enough, and a variety of other possibilities. Use the exit code to figure out exactly what is happening. Note: In these cases, usually the OSD job will continue and possibly complete "successfully". In reality, the machine didn't end up how it should have, so the only way to verify the image deployed correctly is the check the machine.

Applies to LANDESK Management Suite and LANDESK Management Suite 9.0 and 9.5

Description

Recently many companies have decided to transition hard drives to an Advanced Format. This generally means that they are using a sector size of 4k instead of 512 bytes. The primary goal is to improve disk performance.

Problem

In order to use and work with the Advanced Format drives, an Operating System and anything that interacts with a disk at a low level must be "Advanced Format Aware." The following Microsoft OSes are known to be "Advanced Format Aware"

• Microsoft Windows Vista® SP1
• Microsoft Windows 7®
• Microsoft Windows Server 2008®
• Microsoft Windows PE 2.1 (built from Vista SP1 code)
• Microsoft Windows PE 3.x (built from Windows 7 code)

Other earlier versions of Windows, including Windows XP® and Windows Server 2003® are not "Advanced Format Aware." This means that if they are installed on an Advanced Format drive, they must follow some special steps to ensure that the alignment is correct and to prevent performance degredation. This does not mean that Windows XP cannot be installed on an Advanced Format drive, just that the disk must be set up properly to avoid a performance hit when using Windows XP.

How it can happen

One way a machine can get to a problem state is to use Windows Vista (or newer) or Windows PE 2.1 (or newer) to partition a disk, and then install Windows XP manually, as a scripted install, or using an ImageX image. Because WinPE 2.1 is "Advanced Format Aware" by default, the disk is not aligned such that Windows XP can run correctly.

Resolution

There are a few ways to resolve or avoid this issue. Because Windows XP cannot be updated to handle Advanced Format drives, problems will only be on machines that use Windows XP. Newer OSes should be updated as needed to support the Advanced Format drives and they will function correctly.

Updates

See the following article from Microsoft about updates for Advanced Format drives:

An update that improves the compatibility of Windows 7 and Windows Server 2008 R2 with Advanced Format Disks is available

ImageW

ImageW v2 works with Advanced Format drives. Because ImageW is a sector-based imaging tool, the alignment and partitions are contained in the image file. If an image was captured from a machine where the disk alignment was correct, any images deployed will have the correct alignment as well. This applies regardless of if the image was captured from, or deployed to, an Advanced Format drive or not.

Important Note: LANDESK strongly recommends that only ImageW 2.x be used for all ImageW tasks. ImageW 1.x should NOT be used. Any remaining .img files (ImageW 1.x) should be migrated to ImageW if possible by deploying with ImageW 1.x and re-capturing with ImageW 2.x.

ImageX and Ghost

ImageX® and Ghost® are both file-based imaging tools. This means they capture files only, not disk information. During deployment, they restore files to and existing volume. These tools need to have the disk partitions already created in order deploy the image correctly. That means they depend on the alignment being correct before the image is applied. For more information about file-based vs. sector-based imaging and ImageX, see Using ImageX with LANDESK.

There are a few options to resolve or avoid issues with Windows XP and Advanced Format drives. They are outlined in this article from Microsoft:

You cannot install Windows XP successfully after you use Windows Vista or Windows PE 2.0 to create partitions on a hard disk

Basically, the options are:

• Disable "automatic disk translation" feature in BIOS. It can be changed from "Auto" to "Large"
• Set several registry keys in WinPE 2.1 before partitioning the disk

The best option when deploying OSes with LANDESK is to set the registry keys before partitioning the disk.

OSD

When using the OSD tool, the registry keys will need to be added before any diskpart commands. The first diskpart command is usually the first command run in WinPE. It looks something like:

REMEXEC18=diskpart /s X:\LDClient\rmvol.txt

Commands will need to be manually added to the script before this command to set the proper registry keys. This can be done in the Advanced Edit of the script. Please see Advanced edit of OSD scripts for information on editing OSD scripts.

Provisioning

In LANDESK Provisioning, the action that runs diskpart is the Partition action. There are several possible actions and steps that can be run as a Partition action in order to perform all the steps necessary to prepare the disk. The Partition action will automatically add the registry keys needed before running any diskpart commands.

In order for the Partition action to set the registry keys correctly, the Provisioning Template MUST have the correct Target OS set. It will only apply when the Target OS is set to an OS that is not "Advanced Format Aware" (e.g. Windows XP Pro) It will NOT add the necessary registry keys if the Target OS is just set to Windows.

Important Note: These registry keys should ONLY be set when deploying Windows XP from WinPE 2 or greater. They should not be set when deploying an "Advanced Format Aware" operating system.

More Information

For more information about Advanced Format drives please see the following external articles. This list is by no means exhaustive.

Understanding the Impact of Large Sector Media for IT Pros

Information about Microsoft support policy for large sector drives in Windows

Windows PE is stripped of most of Windows components so we will need to use some external applications to get this information.

• DriverView - This tool will show you all drivers that are currently loaded in WinPE

http://www.nirsoft.net/utils/driverview.html

• DevManView - This will work as an alternative to Windows device  manager, it will allow you to see all your devices like the NIC and what driver it is using.

http://www.nirsoft.net/utils/device_manager_view.html

To access these tools from WinPE you will need to copy them locally using one of the following methods, also you will need to have basic knowledge of how to work with the Windows command line tool,

1. Use the File Transfer option of Remote Control to copy the files to the X:\ drive of the device.
2. Place the files in a network share and connect to it from WinPE

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/net_use.mspx?mfr=true

   3.  If the problem is related to the NIC and there is no network connection then you will need to include the files directly in to the image.

This document will provide instructions on how to modify the WinPE image.

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

NOTE: Make sure to unzip the files before copying them to WinPE.

Applies to LANDesk Management Suite 9.0

LANDesk Management Suite 9.5 adds the ability to point to driver setup packages

One of the problems that I have seen with LANDESK 9 HII is the inability to load Setup.exe drivers during the HII process.  To many this is a big deal because a lot of drivers these days require applications to run them, One example is the HP Quicklaunch buttons for laptops. Which have drivers embedded in the executable and the application is required to use the driver like On Screen Display messages.  I personally like to have those installed on my models.

Here is a workaround that I have found that is quite successful in getting this job done with a little AutoIT scripting.  Wmi_model.exe will detect your System Model and deploy another script based off of that system.

• Modify the wmi_model.au3 to address your specific model types and build the wmi_model.exe with autoIT.
• Create a batch file to deploy your setup.exe driver files

• Place your driver setup files in your image (im my example i have them in c:\drivers\setup)

     (Optional:  You don't have to place these files in your image if you want to conserve image space, you can copy them over during the HII imaging      process if you want.  How you get the files to that location is up to your preference as long as they are there when sysprep runs)

• Sort them by application: ie:  c:\drivers\setup\quicklaunch, c:\drivers\setup\3ddriveguard, etc
• Place the wmi_model.exe in c:\drivers\setup
• Place your system .bat files in c:\drivers\setup  (ie: c:\drivers\setup\rp5700.bat)

• Modify your Sysprep file and add the following line to your sysprep.inf (XP) or modify unattend.xml (Win7) with WSIM (Windows System Image Manager)

Now you can deploy your image the following process will take place:

• Image is Deployed
• LANDESK takes care of the hal, msd and pnp drivers
• sysprep will take place then launch wmi_model.exe at first log on
• wmi_model.exe which will detect its System Model thru a WMI call and based on its System Model will point to your batch file that will apply your setup.exe driver applications.

About Wmi_model.exe

Determines WMI_Model, then deploys appropriate Drivers

Change History:
v1.2 - April 27, 2011 - Added Wildcard LIKE support for model names

You will need ScITE editor to modify and build the application
Download: http://www.autoitscript.com/autoit3/downloads.shtml

Source Code:

; AutoIt Version: 3.0
; Language:       English
; Platform:       Win9x/NT
;
; Script Function:
;   Determines WMI_Model, Then Deploys Appropriate Drivers
;   Change History:
;   v1.2 - April 27, 2011 - Added Wildcard LIKE support for model names

#AutoIt3Wrapper_Au3Check_Parameters=-q -d -w1 -w2 -w3 -w4 -w5 -w6
Local $sPC = ".", $sScript, $model

Local $oWMIService = ObjGet("WinMgmts:\\" & $sPC & "\root\CIMV2")
If IsObj($oWMIService) Then    Local $colItems = $oWMIService.ExecQuery('SELECT * FROM Win32_ComputerSystem', 'WQL', 0x30)    If IsObj($colItems) Then        For $oItem In $colItems            $model = $oItem.Model            Switch $model                Case StringInstr ( $model, "System Model" ) <> 0                    MsgBox(64,"Image Configuration", "The PC Model is:  " & " " & $model,3)                    RunWait("C:\drivers\setup\name.bat")                Case StringInstr ( $model, "System Model" ) <> 0                    MsgBox(64,"Image Configuration", "The PC Model is:  " & " " & $model,3)                    RunWait("C:\drivers\setup\name.bat")                Case StringInstr ( $model, "System Model" ) <> 0                    MsgBox(64,"Image Configuration", "The PC Model is:  " & " " & $model,3)                    RunWait("C:\drivers\setup\name.bat")                Case StringInstr ( $model, "System Model" ) <> 0                    MsgBox(64,"Image Configuration", "The PC Model is:  " & " " & $model,3)                    RunWait("C:\drivers\setup\name.bat")                Case Else                    MsgBox(16, "", "The PC Model is: " & $model & @CRLF & " There is no configuration for this model",5)                    Exit            EndSwitch        Next    EndIf
EndIf

Attached is the source code and I will explain what you need to do to modify.

• Modify the line Case StringInstr ( $model, "System Model" ) <> 0 with your System Model.  This new modified script will allow more of a WildCard type expressions to matched.  Before you had to have exact match, but I had issues with System Models having multiple System Names like HP Compaq 6000 Pro Small Form Factor and HP Compaq 6000 Pro SFF.  Now you only have to put in HP Compaq 6000 Pro  and it will detect both models.

       Example:Case StringInstr ( $model, "HP Compaq 6000 Pro" ) <> 0

• Modify RunWait("C:\drivers\setup\name.bat") with the .bat, .vbs,.exe, etc. that you will be calling that holds all the setup.exe launch commands.     

       Example:RunWait("C:\drivers\setup\6445b.bat")

• Add more Case items per model you want to use. I supplied 4 examples, but you can just add/remove as many as you want.
• Optional - If you don't want the MSG box to pop up and want it completely silent, remove the  MsgBox lines
  

Example of a Batch Script to run:

6445b.bat

 

::6445b.bat

::Install applications for HP 6445b

@ECHO OFF

 

:Install QuickLaunch Buttons

Start /wait C:\Drivers\setup\quicklaunch\Disk1\setup.exe -s

 

:Install 3D Drive Guard

Start /wait msiexec /i C:\Drivers\setup\3ddriveguard\HPMDPAI32.msi /qn /norestart

 

Exit

Issue

PXE Boot fails with a "TFTP TIMEOUT" error. This can also present as the following errors:

• PXE T04
• PXE-E36
• PXE-E32
• PXE Error M0F

Cause

VPN software has changed the MTU setting in the registry on the PXE Representative causing TFTP to fail.

Resolution

On the PXE Representative, do the following:

1. Open Regedit
2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces
3. Search for "MTU" and select "Match whole string only".
4. There will be an MTU value for each network interface
5. Verify that the value is set to 1500
6. The PXE Representative may need to be rebooted

More information on PXE boot errors:

PXE Boot errors and descriptions.

How to troubleshoot LANDESK PXE boot:

Troubleshooting PXE boot (OSD)

Issue

The template to deploy the OS completes successfully but there is no Operating System installed on the client.

The DeployImageHandler.exe.log file shows no errors:

2013-10-21 22:53:34(1172-1160) DeployImageHandler.exe:ExecuteCmd maptopreferredhandler.exe /path="\\server\ldmain\Win7DemoImage.WIM" /driveletter=e /pathisfile

2013-10-21 22:53:34(1172-1160) DeployImageHandler.exe:created process, file handle 70 with non-readonly parameter

2013-10-21 22:53:37(1172-1160) DeployImageHandler.exe:Process Exit Code: 0

2013-10-21 22:53:37(1172-1160) DeployImageHandler.exe:Replacing path string \\landesk.univ-montp2.fr\ldmain, with e:

2013-10-21 22:53:37(1172-1160) DeployImageHandler.exe:New Args: /apply e:\Win7DemoImage.WIM 1 C:

2013-10-21 22:53:37(1172-1160) DeployImageHandler.exe:Going to execute imagex.exe /apply e:\Win7DemoImage.WIM 1 C:

2013-10-21 22:53:37(1172-1160) DeployImageHandler.exe:ExecuteCmd imagex.exe /apply e:\Win7DemoImage.WIM 1 C:

2013-10-21 22:53:37(1172-1160) DeployImageHandler.exe:created process, file handle 60 with non-readonly parameter

2013-10-21 22:53:38(1172-1160) DeployImageHandler.exe:Process Exit Code: 0

2013-10-21 22:53:38(1172-1160) DeployImageHandler.exe:Tearing down Environment.

2013-10-21 22:53:38(1172-1160) DeployImageHandler.exe:ExecuteCmd maptopreferredhandler.exe /unmap /driveletter=e:

2013-10-21 22:53:38(1172-1160) DeployImageHandler.exe:created process, file handle 70 with non-readonly parameter

2013-10-21 22:53:38(1172-1160) DeployImageHandler.exe:Process Exit Code: 0

However, it seems that the image is deployed in seconds, which is not possible.

Cause

The .WIM file may contain another image such as "system reserved" (image was provided by a PC manufacturer)

Resolution

Edit the .WIM file to confirm the ID of the image that contains the OS and modify the command-line accordingly. In that case Image ID is #2.

!!!! BE CAREFUL TO NOT CLICK ON VALIDATE AFTER SETTING THE COMMAND-LINE OR IT WILL REVERT TO ID #1 !!!!

Issue

In a provisioning template that includes a Capture Profile action, the selections in the File name unique identifiers checkboxes are not saved.

Resolution

Install Service Pack 2 for LDMS 9.5 and install the latest component patches available

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

Provisioning OSD PXE Boot devices with UEFI

Follow these steps to boot the device:

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

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

   B. Right-click "Bare Metal Server"

   C. Click "Add Devices"

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

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

   F. Click OK when finished.

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

Issue:

Provisioning template fails almost immediately when started.

Removing the Distribute Software action(s) from the template resolves the issue.

Cause:

A Push Delivery Method was selected which is not allowed with provisioning templates.

Solution:

Select a Policy or Policy-Supported Push delivery method when running or creating provisioning template tasks.

Applies to LDMS 9.0 and LDMS 9.5

Issue

Devices get to the Configure Target OS (CTOS) action, they reboot into Windows, but provisioning fails to continue.

Provisioning.log would show the following:

/Provisioning/windows/ProvisionGUI.exe)

2013-11-12 14:15:12(1300-1876) ldProvision.exe:Process exit code:2

2013-11-12 14:15:12(1300-1876) ldProvision.exe:Create process (C:\Program Files (x86)\LANDesk\Shared Files\httpclient.exe) with args (  -f "C:\ldprovisioning\provcomm.dll" http://LDMS/LdLogon/Provisioning/windows/provcomm.dll)

2013-11-12 14:15:33(1300-1876) ldProvision.exe:Process exit code:2

2013-11-12 14:15:33(1300-1876) ldProvision.exe:download prerequisite files OK

2013-11-12 14:15:33(1300-1876) ldProvision.exe:Unable to load action configuration file; using default action configuration

2013-11-12 14:15:33(1300-1876) ldProvision.exe:Running in Daemon mode.

2013-11-12 14:15:33(1300-1876) ldProvision.exe:Provision Mode = PROVISION_MODE_CORE_SID

2013-11-12 14:15:48(1300-1876) ldProvision.exe:Start TryallWebService Attempt:0.

2013-11-12 14:16:09(1300-1876) ldProvision.exe:End TryallWebService Attempt:0. ExitCode:2

2013-11-12 14:16:21(1300-1876) ldProvision.exe:Start TryallWebService Attempt:1.

2013-11-12 14:16:43(1300-1876) ldProvision.exe:End TryallWebService Attempt:1. ExitCode:2

2013-11-12 14:16:56(1300-1876) ldProvision.exe:Start TryallWebService Attempt:2.

2013-11-12 14:17:17(1300-1876) ldProvision.exe:End TryallWebService Attempt:2. ExitCode:2

2013-11-12 14:17:31(1300-1876) ldProvision.exe:Failed to call web service. exitCode=2

2013-11-12 14:17:31(1300-1876) ldProvision.exe:Caught exception in main: code=80001500H, file=.\ProvisioningWebSvc.cpp, line=933

Cause

httpclient is not able to resolve the Core name

Resolution

Edit the boot.wim file and look for file corename.txt (it should be in the \temp folder).

Edit that file and replace the hostname by FQDN

Commit the change and try again.

See also Troubleshooting Configure Target OS action in Provisioning Template.

Issue

After enabling FIPS on the core server, LANDESK OSD scripts and Provisioning templates stop working.

After selecting and trying to launch an OSD script, nothing happens and the screen stays on the LANDESK imaging background.

If you select a Provisioning template to execute, it will attempt to run but will fail with error 80001803H

Cause

This issue occurs after enabling FIPS 140-2 on a core server. When FIPS 140-2 is enabled, a new SHA1 cert is generated on the core and replaces the old MD5 core cert.

The WINPE image does not get updated automatically with the new cert and thus communication from a client being imaged is refused by the core server.

Resolution

On the core server, do the following steps:

1. Navigate to \Program Files (x86)\LANDESK\ManagementSuite
2. Run "OSD.UPGRADE.EXE"

This will update BOOT.WIM, BOOTMEDIA.WIM, and BOOT_X64.WIM and inject the newer SHA-1 certificates into the Boot Images.

Applies to LANDesk Management Suite 9.0

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

The specified document was not found.

XP to 7 Migration Scenario

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

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

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

XP to 7 Migration Steps Overview

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

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

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

XP to 7 Solutions and Information

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

1 - Capture Profile

     Adventure 1a. Using LANDesk Profile Migration

          Information:

               The specified document was not found.

          Sample Template:

               Profile Migration Templates for Provisioning in LANDesk 9.0

     Adventure 1b. Using Microsoft USMT

          Sample Template:

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

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

2 - Get into WinPE

     Adventure 2a. PXE Boot

          Information:

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

     Adventure 2b. VBoot

          Sample Template

               The specified document was not found.

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

3 - Deploy Windows 7 (with HII)

     Adventure 3a. Image Deploy

          Information:

               The specified document was not found.

          Sample Template:

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

     Adventure 3b. Scripted Install

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

4 - Post Imaging Customizations

     Adventure 4a. Install LANDESK Agent

          Information:

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

     Adventure 4b. Join Domain

          Information:

               Use Join Domain Action

     Adventure 4c. Any other custom type actions

          Information:

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

5 - Install Software

     Adventure 5

          Information:

               Use the distribute software action.

          Sample Template:

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

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

     Adventure 6

          Information:

               Detect and Install Patches within Provisioning

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

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

     Adventure 7 a. Using LANDesk Profile Migration

          Information:

               The specified document was not found.

          Sample Template:

               Profile Migration Templates for Provisioning in LANDesk 9.0

     Adventure 7b. Using Microsoft USMT

          Sample Template:

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

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

Conclusion

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

Issue

• Booting a machine in UEFI mode in a network segment with an active PXE representative doesn't make the machine loading WinPE.
• The PXE menu doesn't appear.
• The machine reports the error PXE-E21: Remote boot cancelled
  
  

Solution

UEFI is still not compliant with the PXE menu specifications, therefore booting a machine in UEFI mode via PXE for provisioning works only when the device is associated to a provisioning task on the core.

The error PXE-E21 appears when the device is not associated to a provisioning task on the core.

LANDesk submitted an enhancement request to the UEFI Forum regarding this issue. Once they add the support needed, LANDesk will be able to support the PXE menu for the devices booting in UEFI mode as well.

At the moment, the only way to have the PXE menu functionality on a device booting in UEFI mode is setting it up to boot in Legacy BIOS mode.

Applies to LANDesk Management Suite 9.5 and 9.5 SP1

Issue:

Capture Profile action is failing with a 259 error.

Capture profile action is getting a timeout error.

Cause:

Capture Profile action has a 5 minute timeout.

Resolution:

Install Service Pack 2 which increases the timeout to 90 minutes.  In a future component patch this timeout value will be increased to 6 hours.

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

• The WinPE version is updated to 5.0.
• 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

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 Provisioning for Windows 7 in LANDESK Management Suite 9.0 SP2
• 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.

Landesk 9.5 SP2

I'm having a terrible time getting a video driver to install during CTOS. It comes up with a window saying GFXres.ar-SA.resourses can't be copied.

I deleted this file from my Driver Repository and Rebuilt the Database but I still get the same thing even though that file no longer exists in the Driver Repository. I al went into IIS manager and removed .resources from the filter. Did a IISreset but I still get the same outcome. HELP!

One last thing I went into the LDdriverstore on C drive and that file is not in there and Hiiclient log does not show that file listed in it.