OS deployment

The LANDesk OS deployment tool groups together several features that let you deploy images remotely to new or existing devices. These features streamline new device provisioning and redeploying existing devices, with options to migrate user profiles and to image with hardware-independent templates that can be applied to different device models. With these automated features you can deploy and re-image devices without user input or the need for a technician to work at each device.

You can schedule deployments and migrations to occur after hours, and by using the LANDesk targeted multicast technology to distribute images, you won't saturate network bandwidth by deploying the same image to multiple devices.

The following features are part of the OS deployment tool:

This chapter begins with the basics of deploying OS images:

OS deployment overview

The OS deployment (OSD) feature provides two methods of deploying OS images to devices on your network:

If you use Microsoft's Sysprep utility to create your images, OS deployment creates customized sysprep.inf files and injects them into each device's image on a per device basis, customizing Windows computer names, domain information, and so on from the core database.

OS deployment includes a built-in imaging tool you can use to create images. OS deployment also supports third-party imaging tools that you may already be using, such as Symantec Ghost, PowerQuest DeployCenter, and Microsoft XImage.

OS deployment can image, deploy, and migrate from these boot environments:

* The LANDesk PE Toolkit contains Microsoft Windows Pre-installation Environment software (“WinPE”), a third party product. In order to use the LANDesk PE Toolkit, you must have a valid license to use WinPE. If you purchased a license to use WinPE from LANDesk, your use of WinPE is subject to the applicable terms and conditions of LANDesk’s End User License Agreement for the licensing of LANDesk software.

Since some of these environments require licensed software, you'll need to provide copies of the licensed software for OS deployment to validate before you can use a particular environment.

WARNING: OS deployment (imaging) should be used with caution. Operating system deployment includes wiping all existing data from a device's hard disk and installing a new operating system. There is a substantial risk of losing critical data if the OS deployment is not performed exactly as described in this document, or if poorly implemented images are used. Before performing any OS deployment, we recommend that you back up all data in such a manner that any lost data may be restored.

OS deployment steps for Windows devices

When planning and implementing a Windows OS deployment operation, follow this sequence of steps:

  1. If you plan to use a DOS or Windows PE imaging environment and you haven't validated your licenses already, validate them by clicking the Validate licenses toolbar button in the Operating system deployment window. Insert the operating system CDs as prompted. You only need to do this once. The Linux boot environment doesn't require license validation.
  2. (Optional) Run the Microsoft Setup Manager and Sysprep utilities on the device whose image you want to capture.
  3. Create or reuse an image capture script in the Operating system deployment window.
  4. Schedule a task with the Scheduled tasks tool that runs the capture image script on the device whose image you want to capture. (Watch the Custom Job Status window updates for success or failure).
  5. Create or reuse an existing image deployment script in the Operating system deployment window.
  6. Schedule a task with the Scheduled tasks tool that runs the deploy image script on target devices where you want the image deployed.
  7. Targeted devices running Windows OSes and LANDesk agents will begin the image deployment job when scheduled (agent-based deployment).
  8. Targeted devices that are PXE-enabled will begin the image deployment job the next time they boot (PXE-based deployment).

Read the relevant sections below for detailed information about each of these steps.

OS deployment steps for Linux devices

The following is a list of constraints imposed on Linux installations.

  1. The root ('/') partition must be of filesystem type ext2, ext3, or xfs.
  2. The root partition cannot be contained in an LVM PV (Logical Volume Manager - Physical Volume), but must be a partition (physical, or extended) in the drive's MBR (Master Boot Record).
  3. The last partition is the only partition that can be expanded; therefore it, too, must be of filesystem type ext2, ext3, or xfs.
  4. You must specify which partition the root partition is on ( hda3 or sda2)

NOTE: Linux PE only supports IDE devices. Serial ATA and SCSI are not supported. If you want to image these devices you must use a third-party imaging tool

When planning and implementing a Linux OS deployment operation, follow this sequence of steps:

  1. Create or reuse a Linux configuration image capture script in the Operating system deployment window.
  2. Schedule a task with the Scheduled tasks tool that runs the capture image script on the device whose image you want to capture. (Watch the Custom Job Status window updates for success or failure).
  3. Create or reuse a Linux configuration image deployment script with the OS Deployment/Migration Tasks wizard.
  4. Schedule a task with the Scheduled tasks tool that runs the deploy image script on target devices where you want the image deployed.
  5. Targeted devices running Windows OSes and LANDesk agents will begin the image deployment job when scheduled (agent-based deployment).
  6. Targeted devices that are PXE-enabled will begin the image deployment job the next time they boot (PXE-based deployment).

OS image guidelines

You can create OS images with the LANDesk imaging tool or other imaging tools. When you run the OS Deployment/Migration Tasks wizard to create an imaging script, you are prompted to specify the image type and imaging tool. The wizard automatically generates command lines for the LANDesk imaging tool, Symantec Ghost 7.5, and PowerQuest DeployCenter 5.01.1.

NOTE: When you install the OS deployment and profile migration component, files for the LANDesk imaging tool are automatically installed on your core server. If you want to run the LANDesk imaging tool from a different location, you need to copy the following four files: imageall.exe, image.exe, restall.bat, and backall.bat. If you want to use Microsoft XImage, you must copy the files ximage.exe and xmlrw.dll into the \\<core>\ManagementSuite\OSD\imaging folder.

If you have a different imaging tool, you can supply the command line for it at the end of the wizard. If you specify a custom command line, the wizard will put your custom line in the right location in the script so that you don't have to edit the script manually.

Understanding the OS deployment imaging environments

When capturing or restoring an image, OS deployment boots the target device into an imaging environment. OS deployment supports these imaging environments:

Note that the imaging environment you choose is independent of the OS you are imaging. For example, you can use the Linux imaging environment to image Windows operating systems.

Validate the DOS and Windows PE boot environments by clicking the Validate licenses toolbar button in the Operating system deployment window. Insert the operating system CDs as prompted. You only need to do this once. The Linux boot environment doesn't require license validation. The validation dialog box also lets you change the default preboot environment for devices in the PXE holding queue. Devices in the holding queue will boot into the environment you select. Your choices are limited to boot environments you have validated.

Image filenames

You should give your images unique filenames. Deploying different images with the same filename simultaneously on the same subnet can cause problems. Depending on how an imaging utility names image files and the imaging environment you're using (DOS with multi-file Ghost images, for example), you may have only five unique characters in your filename once it is converted to a DOS 8.3 name format.

When capturing images, the LANDesk imaging tool for DOS, Windows, and Linux uses the last six characters of the computer name, followed by a two-digit image number for each file in the image. If you're capturing images from multiple devices at the same time and the last six characters of the computer name aren't unique, you'll experience errors during the capture process.

Symantec Ghost and PowerQuest DeployCenter generally use the first eight characters of the computer name for the image filename, which must also be unique for simultaneous image capture to work correctly.

When capturing images from multiple devices, you have two ways of ensuring that your images have unique names:

LANDesk agents and images

You should not include the LANDesk agents in your images. If you use a Sysprep image, OS deployment will install the LANDesk agents on the Windows-based OS after the image is restored.

If your Windows-based non-Sysprep images include LANDesk agents, you will need to delete the ldiscan.cfg file from the root of the hard drive before imaging. You will also need to delete these keys:

If you leave these in the image, all devices using the image will have the same core database entry. Alternatively, if you have non-Sysprep images that already have LANDesk agents on them, you can enable the Reject duplicate identities option on the Duplicate device ID dialog box (Configure > Services > Inventory > Device IDs).

Partitions and images

By default, when OS deployment restores an image on a target device, it deletes any existing partitions on that device.

The LANDesk imaging tool supports single-partition and multiple partition images (up to four partitions). In the Linux PE environment, when using the LANDesk imaging tool, you can only capture and deploy one partition at a time.

Non-Windows images

You can use OS deployment to deploy almost any image your imaging tool supports, not just Windows-based images. When deploying non-Windows or non-Sysprep images, make sure you do not select the Image is Sysprepped option in the new configuration dialog boxes.

Customizing images with Setup Manager and Sysprep

You can use Microsoft's Setup Manager and Sysprep utilities when deploying Windows 2000/2003, Windows XP, and Windows XP x64 Edition images. Sysprep customizes a Windows installation so that when the OS reboots, it looks for an answer file (sysprep.inf) and reconfigures itself for the new device. Setup Manager creates the sysprep.inf answer file that Sysprep uses.

Before creating OS deployment scripts, you should run Microsoft's Setup Manager (setupmgr.exe) and create a sysprep.inf answer file for the images you're deploying. You can then use this file as the basis for any OS deployment scripts you create by selecting the Use existing sysprep.inf file as a template option on the Specify Sysprep file information page of the wizard. Any OS deployment script settings you make in the wizard override the equivalent options in the template sysprep.inf file.

Using Sysprep on your Windows 2000/XP images allows OS deployment to query the core database for each device you're deploying and to migrate certain user settings, such as:

You can also set these options globally for images you deploy:

OS deployment uses information from the core database and from the image deployment script to create a custom sysprep.inf for each device you're imaging. OS deployment then injects that sysprep.inf into each device's image.

Creating a Sysprep image

To create an image that uses Sysprep
  1. On the device whose image you want to capture, make configuration or customization changes to prepare it for imaging.
  2. At the root of the device's hard drive, make a c:\sysprep folder.
  3. From a Windows 2000 or Windows XP installation CD, open \Support\Tools\DEPLOY.CAB and copy sysprep.exe and setupcl.exe to the sysprep folder you created.
  4. Open a DOS command prompt and change to the sysprep folder. Run Sysprep. If you don't use the reboot option, you'll need to shut down the device from the Start menu once a message appears requesting that you shut down.
  5. Boot to DOS and run your imaging tool manually.

For more information on Setup Manager and Sysprep

Refer to Microsoft's Web site for documentation about the Setup Manager and Sysprep utilities. Sysprep has many powerful features you can use that are beyond the scope of this document.

You may also find help for issues with using Sysprep on the LANDesk Support Community Web site; go to community.landesk.com.

Agent-based deployment

You can use the agent-based deployment method to deploy OS images to devices running Windows 98, Windows 2000, or Windows XP.

For information on the other method of image deployment, see PXE-based deployment.

Prerequisites

If you're not using PXE to deploy images, devices must meet the following criteria:

What happens during an agent-based deployment

  1. The core server connects to the device and runs any preconfiguration commands you specified in the image deployment script.
  2. OS deployment uses the software distribution agent to distribute a virtual boot partition file to the device and modifies the boot sector to boot from this file, then reboots the device.
  3. The device boots to DOS or Windows PE (depending on your choice), detects and loads a network driver, then retrieves and installs the image file from the image server.

    For non-Sysprep images, the device reboots after the imaging completes. OS deployment considers the job complete after this reboot.

    For Sysprep images, agent-based deployment continues in this manner:

  4. Before rebooting and loading the image, the DOS or Windows PE agent replaces sysprep.inf with a customized file for that device.
  5. The imaged device boots and customizes itself based on what is in the sysprep.inf file.
  6. For Windows images, any post-image commands you specified in the image deployment script are run from the RunOnce registry key.
  7. For Windows images, OS deployment runs wscfg32.exe using your default device agent configuration to reinstall the LANDesk agents.

Creating imaging scripts

LANDesk OS deployment provides OS deployment and profile migration tools that let you create and manage both imaging (image capture and image deploy) scripts and profile migration scripts.

With the OS deployment tool you can create scripts that perform the following tasks:

Once you have created a script, you can schedule it to run on devices by using the Scheduled tasks tool.

If you are deploying an image to PXE-enabled devices, you can add image deployment scripts to the PXE DOS boot menu. This menu is DOS-based and appears on the device during a PXE boot. For more information, see Using the PXE boot menu.

To run the OS Deployment/Migration Tasks wizard
  1. Click Tools > Distribution > OS deployment.
  2. In the Operating system deployment window, right-click All OSD Scripts and click the script type you want to create. (You can also click the toolbar button for the script type you want to create.)

    A wizard opens to guide you through the script creation.

  3. Configure the script as necessary. Once complete, the script appears in the All OSD Scripts group in the Operating system deployment window.

Administrators (users with the LANDesk Administrator right) can copy scripts to user subgroups in the User scripts group.

Additional notes on scripts

About Generic DOS tasks scripts

Modifying scripts

You can modify your scripts at any time, either by reopening the configuration dialog box and making changes, or by modifying the script directly in its .ini file and modifying any existing Sysprep settings in its associated .inf file.

NOTE: With DOS scripts, the only changes you should make are between the REMPINGx=DOS and REMEXECx=reboot.com lines. The other lines in the script manage the virtual boot partition files and boot process.

To modify a script via the dialog boxes
  1. Click Tools > Distribution > OS Deployment.
  2. Right-click the script and click Edit in the shortcut menu (or double-click the script).
  3. Advance through the wizard, making your changes.
To modify a script via an .ini file
  1. Click Tools > Distribution > OS Deployment.
  2. Right-click the script and click Advanced edit. The script's .ini file opens in Notepad. If this script has Sysprep settings associated with it, the sysprep.inf file also opens in Notepad.
  3. Make your changes
  4. Save the file(s).

NOTE: Where .ini and .inf files are saved
INI files are saved to the \\<core>\LDMain\Scripts directory. INF files are saved to the \\<core>\LDMain\LANDesk\Files directory.

Multicasting OS images

This section discusses deploying images using the LANDesk Targeted Multicast™ technology. Multicasting is slower than a single distribution. Multicasting throttles bandwidth and stages the image on the target device's hard drive. However, multicasting to four or more devices will usually save enough bandwidth to make this worth it.

Targeted Multicast supports only single-partition images, not multiple-partition images. Also, when using Targeted Multicast with OS deployment, images can span up to 10 files.

When multicasting images, the image file is cached on the device before being restored. Your hard drive must have enough space for the image file and the restored files.

Before using multicasting with OS deployment, make sure the multicasting components are in place on the subnet to which you are distributing/deploying image files. Multicast OS deployments may fail if you don't specify domain representatives for each multicast domain in the network view's Multicast Domain Representatives group. Multicasting requires LANDesk Management Suite 6.62 or higher agents on devices, and a LANDesk Management Suite 6.62 or higher multicast domain representative on the subnet.

If you try to multicast to a subnet that does not have a multicast domain representative, the deployment will start but it will not be able to finish, and you will have to create an OSD boot floppy. For more information, see Creating an imaging boot disk. If your routers forward UDP-directed broadcasts, and there will be Windows devices that can act as multicast domain representatives on the subnet you're deploying the image to, you should be able to use Targeted Multicast without designating multicast domain representatives. If your routers don't forward UDP-directed broadcasts, you must manually select your multicast domain representatives for each subnet, making sure the representatives you choose aren't among the devices you're deploying images to.

You can manually specify which devices will be multicast domain representatives by adding devices to the Configuration > Multicast domain representatives group in the network view.

Make sure you don't image any multicast domain representatives in a subnet, because the imaging will fail and leave the devices in an unusable state.

You can throttle multicasts by changing the Minimum number of milliseconds between packet transmissions option in the Configure advanced multicast options page of the OS Deployment/Migration Tasks wizard.

WARNING: If your multicasting environment isn't configured correctly and the Targeted Multicast fails, all target devices may be unbootable unless you follow the directions above.

Setting the maximum packet size for Targeted Multicast with OSD

If Targeted Multicast fails with distribution jobs, it may be because the maximum transmission unit (MTU) size on your network is fragmenting packets. Follow the steps below to adjust the MTU that multicast uses.

To set the maximum packet size to 512 bytes for a Targeted Multicast script
  1. Click Tools > Distribution > OS Deployment.
  2. Right-click the script and click Edit.
  3. In the Multicast section of the script, add the following line at the end of the section.

    MAX_PACKET_SIZE=512

    This string will set the maximum packet size for the Targeted Multicast to 512 bytes. Maximum packet size can be set between 256 and 1464 bytes. A setting above this range, or no setting at all, will force the default setting of 1464. A setting below this range will default to 256 bytes.

  4. Save and close the script.

WARNING: The MAX_PACKET_SIZE setting must be at least 28 bytes smaller than the maximum transmission unit (MTU) for the network the package is being distributed on. This is determined by adding the size of the IP header (20 bytes) and the UDP header (8 bytes) that are sent with each packet of data. Setting the maximum packet size higher than this limit will cause your distribution to fail.

Viewing image status reports

The device being imaged sends status updates to the core server. You can track status in the Custom Job window or with a report. As OS deployment sends imaging commands to devices, the commands appear in the Custom Job window. Devices being imaged send status updates for each script command that is sent. If image deployment fails for some reason, you can see the command that failed.

Common reasons why imaging fails include:

OS deployment creates a status report for each job, showing if it failed or succeeded on targeted devices.

To view a status report
  1. Click Tools > Reporting/Monitoring > Reports.
  2. Select the OS deployment success rate report.
  3. From the list of log files, select the file for the job you're interested in viewing.
  4. Click Run.

At the top of each report will be any jobs that failed on individual devices. Reports also show the details of each job, such as:

PXE-based deployment

OS deployment supports PXE booting and image deployment. PXE-based deployment provides another method (in addition to agent-based deployment) of automated remote imaging of devices on your network. With PXE support, you can boot both new and existing PXE-enabled devices and either execute an OS deployment script at the device from a custom PXE DOS boot menu, or scan devices into your core database and then schedule an image deployment job with the Scheduled tasks tool.

PXE-based deployment is a quick and easy way to image devices in a variety of situations, such as:

LANDesk offers several options for using PXE to deploy OS images. For more information, see Understanding the PXE boot options.

PXE protocol basics

PXE (Preboot Execution Environment) is an industry-standard networking protocol that enables devices to be booted and imaged from the network, by downloading and installing an executable image file from an image server, before the device boots from the local hard drive. On a PXE-enabled device, the PXE protocol is loaded from either the network adapter's flash memory or ROM, or from the system BIOS.

PXE uses the following communication standards: DHCP (Dynamic Host Configuration Protocol), TFTP (Trivial File Transfer Protocol), and MTFTP (Multicast Trivial File Transfer Protocol).

When a PXE-enabled device boots up, it sends out a DHCP discovery request. If a DHCP server implementing PXE is found, the server assigns an IP address to the device and sends information about available PXE boot servers. After completing the DHCP discovery process, the device contacts the PXE server and downloads an image file through TFTP. The imaging script is then executed, loading the OS image from the imaging server onto the device. The image file is referenced by an OS deployment script.

To learn more about PXE and its underlying technologies and functionality, read the PXE Specification v2.1 located at http://download.intel.com/design/archives/wfm/downloads/pxespec.pdf.

Using PXE representatives

PXE support software is installed on your core server as part of the normal OSD installation. However, to enable PXE support, you must first deploy a PXE representative on each subnet of your network where you want PXE support available. PXE representatives provide scalability on your network by deploying OS images to devices in their respective subnets.

Devices on each subnet use normal PXE query and file transfer methods to communicate with their resident PXE representative, which communicates with the core server using Web services (HTTP).

NOTE: Disable other PXE servers
If there is any other PXE server currently running on your network, you must first disable it in order to use LANDesk PXE support.

Deploying PXE representatives

You need to deploy one PXE representative on each subnet where you want to provide PXE boot support. You set up a PXE representative by running the PXE Representative Deployment script on the selected device. This predefined script is available in the Manage scripts tool (click Tools > Distribution > Manage scripts, then click the Public scripts folder).

You can have multiple PXE representatives on a subnet to help with load-balancing. When this is the case, the first PXE representative to respond to a device's request is the one that will be used to communicate with the core server.

NOTE: We recommend that you do not deploy a PXE representative on your core server.

There are no special hardware requirements for the device you select to be a PXE representative, but it must meet the following software requirements:

To deploy a PXE representative
  1. In the console, click Tools > Distribution > OS Deployment.
  2. In the Operating system deployment window, click the All other scripts tree item. Click the PXE representative deployment script, and then click the Schedule toolbar button.
  3. In the console's network view, select the target device on which you want to install PXE services.
  4. Drag and drop the selected device to the PXE Representative deployment task in the Scheduled tasks window.
  5. Right-click the PXE Representative deployment task, click Properties, and finish configuring the task.

NOTE: Updating PXE representatives
If you modify the PXE boot option settings (on the Configure > Services > OS deployment tab), you need to update all of your PXE representatives by re-running the PXE Representative Deployment script to propagate those changes to PXE representatives on each subnet. However, re-running the script is not necessary if you simply move PXE proxies from the Available proxies list to the Holding queue proxies list. For more information about the PXE holding queue, see Using the PXE holding queue.

To update or remove a PXE representative
  1. Click Tools > Distribution > Manage scripts.
  2. To update a PXE proxy, select Public scripts > PXE Representative Deployment. Right-click the script and select Schedule. (Or, to remove a PXE proxy, select the PXE Representative Removal script instead.)
  3. Drag and drop the target devices to the appropriate task in the Scheduled tasks window.
  4. Right-click the task, click Properties, and finish configuring the task.

Booting devices with PXE

When a PXE-enabled device boots, the following occurs:

  1. The PXE-enabled device sends out a query for PXE services running on a PXE representative on the network.
  2. If a PXE representative exists on the subnet, it responds and tells the device to continue to boot using PXE.
  3. A PXE boot session is initiated on the device and the PXE boot prompt displays. The default prompt message displays for four seconds and says "Press F8 to view menu." (You can modify these PXE boot prompt settings on the Configure > Services > OS deployment tab.)
  4. If the F8 key is pressed before the countdown expires, a preliminary PXE boot menu appears, allowing you to choose from the following boot options:
  1. If you don't press the F8 key before the countdown expires, the device will use the default boot option. The default boot option is determined by the following conditions:
  1. The scheduled OS deployment script runs on the device.

Understanding the PXE boot options

This section provides information on configuring the PXE boot prompt, and how to use the following PXE boot options:

Configuring the PXE boot prompt

You can control how the PXE boot prompt behaves when devices attempt to PXE boot.

When a PXE-enabled device boots up, a DHCP request attempts to initiate a PXE session by looking for a server (or proxy) running PXE services software (PXE and MTFTP) services. If the device discovers a PXE server, the PXE boot prompt displays on the device for a specified number of seconds. By pressing the F8 function key during this countdown, you access the PXE boot menu and can select an OS image to deploy on the device.

NOTE: If you have PXE representatives running on subnets of your network, and you want to implement PXE boot prompt changes to any of those proxies, you must run the PXE Representative Deployment script on the proxy.

To configure PXE boot prompt options
  1. Click Configure > Services, then click the OS deployment tab.
  2. Enter a value (in seconds) in the Timeout option. The default value is 4 seconds. The maximum number of seconds you can enter is 60 seconds.
  3. Type a message in the Message box. The default message is "Press F8 to view menu." The maximum number of characters you can type is 75 characters.
  4. Click Apply to save your changes, or click OK to save your changes and close the dialog box.
To implement PXE boot prompt changes to a PXE representative
  1. Click Tools > Distribution > Manage scripts.
  2. Select Public scripts > PXE representative deployment. Right-click the script and select Schedule.
  3. Drag and drop the PXE representative from the network view onto the task in the Scheduled tasks window.
  4. Right-click the PXE representative deployment script, click Properties, and finish configuring the task.

Using LANDesk managed boot

LANDesk managed boot is the default boot option when a PXE-enabled device boots and detects a failed image deployment script or failed DOS task script for it in the core database. You can also select this boot option manually at the device when the boot option menu appears.

Because it allows unattended deployment, LANDesk managed boot is useful for pre-targeting devices for imaging. For example, you could pre-target new devices for a particular OS image even before they arrive by importing a CSV file containing device MAC addresses into the core database. For more information, see Using CSVIMPORT.EXE to import inventory data.

To pre-target devices with the LANDesk managed boot option
  1. Before the PXE-enabled devices are connected to the network, add their identifications to the core database by importing a CSV file.
  2. Schedule an image deployment job for the devices.
  3. The imaging job fails because the devices are not yet connected to the network.
  4. Connect the devices to your network and boot them.
  5. The devices detect a failed imaging job and default to the LANDesk managed boot option.
  6. The previous failed image deployment job automatically launches and images the target devices.

Using the PXE boot menu

The PXE boot menu lets you interactively select an image deployment script for a device without having to schedule an image deployment job. This method might be useful when you have to re-image corrupted devices. Before using the PXE boot menu, you must first configure it by adding the OS deployment scripts you want to display in the menu.

You build the PXE boot menu system by creating directories and placing pre-configured OS deployment scripts in those directories. The script's description appears as a menu item in the PXE boot menu on the device.

To configure the PXE boot menu
  1. Click Tools > Distribution > PXE Boot Menu.
  2. To add a new directory or subdirectory to the menu system, click the New toolbar button (or right-click the parent directory and select New).

NOTE: Subdirectories can extend four levels from the top directory.

  1. Type a name for the directory. For example, the directory name could describe the OS platform or version number of the images contained in that directory. You can also change the name of the directory at any time by clicking the Rename toolbar button (or right-clicking the directory and selecting Rename).
  2. Click Tools > Distribution > Manage scripts, then drag and drop image deployment scripts to the appropriate directory in the PXE Boot Menu window.

NOTE: A maximum of 18 scripts can be placed in each directory.

  1. To save the PXE boot menu, click the Update toolbar button. (Note that you must click the Update button here in the console if you want changes to appear in the PXE boot menu on PXE devices when they boot.)

To access the PXE boot menu from a device
  1. Boot a PXE-enabled device.
  2. When the PXE boot prompt displays, press the F8 key before the countdown expires. Select PXE DOS menu. The menu system that you configured in the console's PXE Boot Menu window appears.
  3. To open a directory and view its subdirectories and images, type the number of the directory and press Enter. Navigate the menu system and find the image you want deployed on the device. You can press B to go back one level, or press X to exit the menu system.

NOTE: If you exit the menu system without making a selection, the device will wait for a scheduled imaging job from the core server.

  1. To select an OS image (referenced in an OS deployment script), type the number of the script and press Enter. The script runs and the image is loaded on the device.

Using the PXE holding queue

The PXE holding queue is another method for remotely deploying OS images to PXE-enabled devices. This method is especially useful in these situations:

By designating a subnet's PXE representative as a PXE holding queue, all the PXE-enabled devices on that subnet will be automatically added to the PXE holding queue in the console's network view when they PXE boot. You can also add a device to a PXE holding queue by scheduling the PXE - Add to Holding Queue script on the device, or by copying the device directly into the PXE holding queue group in the network view. Devices can then be scheduled for an image deployment job.

To configure a PXE holding queue
  1. Set up PXE representatives on your network.
  2. Click Configure > Services, then click the OS deployment tab.
  3. Select and move PXE representatives from the Available proxies list to the Holding queue proxies list.
    The Available proxies list shows all available PXE representatives on your network, identified by device name. This list is generated by running an inventory scan that detects PXE software (PXE and MTFTP) protocols running on the device. The inventory scan is run automatically whenever a PXE representative is initially set up.
  4. Click Reset. The Reset button forces all PXE-enabled devices on the same subnet as the selected PXE representative to re-enter the PXE holding queue in the console's network view. These devices can then be scheduled for an imaging job.

NOTE: The Reset button is enabled when you select a PXE representative in the Holding queue proxies list.

  1. Click OK to save your changes and close the dialog box.

The next time a device on that subnet boots, it will be added to the PXE holding queue object in the console's network view.

To deploy an image to a device in the PXE holding queue
  1. Click Tools > Distribution > Manage Scripts.
  2. Click an OS deployment script from the list, then click the Schedule toolbar button.
  3. In the console's network view, open the PXE holding queue folder, then select the target devices you want to deploy the image to.
  4. Drag and drop the selected devices to the Scheduled tasks window, and from the task's shortcut menu, click Properties and finish configuring the task.

Troubleshooting

Invalid OEM drivers in a Windows PE image will reset a device's boot environment and cause OSD tasks using that image to fail

If you add an invalid OEM driver to a Windows PE image and use that image for a task on a device, the device will boot into the Windows PE from that point onwards and the OSD task won't run. If this happens, do the following to fix the Windows PE image and restore the normal boot environment:

  1. On the OSD toolbar, click the Manage the drivers in the Windows PE image button.
  2. Remove the invalid OEM driver from the PXE-based Windows PE file (under \\pxeserver\..\PXE\System\images\peboot.img) and agent-based Windows PE file (under \\coreserver\ldmain\landesk\vboot\ldvpe1.img).
  3. PXE boot the device to the modified Windows PE image by selecting the "LANDesk Managed WinPE" option.
  4. Once the image boots, run this command: Diskinfo fix
  5. Restart the device. It will boot to the previous OS normally.
  6. Execute the OSD task that you scheduled.

Hardware-independent imaging

As you deploy images to your managed devices, it's challenging to maintain many different images based on different hardware configurations. New hardware requires new drivers, and existing hardware may have updated drivers you want to deploy. Rather than maintain dozens or hundreds of individual images for various hardware configurations, you can use hardware-independent imaging (HII) to deploy a base image to different devices and then automatically add the drivers that are required for each different type of hardware.

Hardware-independent imaging helps resolve common problems with imaging managed devices. For example, the hardware abstraction layer (HAL) .dll files need to be accurately chosen or the device may reboot to a black screen after imaging. Operating systems typically don't have the ability to recognize mass storage devices correctly, so it's important to have the right drivers when imaging. Also, manufacturers often have hardware-specific plug-and-play device drivers or they build driver dependencies into their applications, so it's possible to create new problems when imaging a device with the wrong drivers. With the hardware-independent imaging tool in LANDesk Management Suite you can avoid these types of problems and have greater control over the use of drivers in your managed devices.

An important consideration in using LANDesk hardware-independent imaging is that you can use it with images from any imaging tool. You can define the images with the tool you prefer, then create imaging scripts in Management Suite that incorporate the HII tool. If you already have images created with another tool, you'll be able to re-use them rather than create all new scripts.

A simplified description of the HII process is as follows. Details about the specific steps you'll need to follow and considerations for different types of images are described in the following sections.

  1. When you deploy an image created using HII, the imaging script boots the device to the Windows preboot environment. In the preboot environment, the HII tool will select the appropriate HAL .dll file and load it.
  2. The OS is installed on the device, but before the OS boots, the HII imaging script determines which drivers are required by the device and copies the driver files to the device's hard disk.
  3. The drivers are added to the device's registry, so that when the OS boots the Windows setup detects the new drivers, installs them, and configures the device with the drivers.
  4. Windows then restarts with the drivers running, and the Management Suite agent is installed.

NOTE: Because of changes to how administrator user account permissions are handled in Windows Vista and especially in Windows 7, you may find that master images you create that include these versions of Windows may not successfully deploy. We recommend that you visit the LANDesk Support Community website, community.landesk.com, for best-known method documents that describe master image scenarios and recommended procedures for creating and deploying images.

Tasks to set up hardware-independent imaging

To implement hardware-independent imaging with OS deployment scripts or provisioning templates, there are two general tasks you need to complete for the drivers you want to use in your images:

These two tasks are described in the following sections. In addition, there are notes for how to incorporate hardware-independent imaging into OS deployment scripts and provisioning templates.

Creating a driver library

As you plan and define the images you want to use for managed devices, you'll decide which drivers you want to use with specific device models. To use these drivers for hardware-independent imaging, you create a library of drivers that is saved on the LANDesk Management Suite core server. The drivers are then available for any deployment or provisioning script you want to run.

To create a library, you need to have the driver files in a folder, and the driver's .inf file must be included. You can include drivers from any device or share, because the files will be copied to the core server and stored in the library.

To add a driver to the driver library
  1. Click Tools > Distribution > OS Deployment.
  2. Click the Manage driver library button on the toolbar.
  3. Click Add.
  4. Select the Device type for which you will add a driver.
  5. Type the name of the device in the Device name box.
    This is also a list that lets you select a device name you have previously used.
  6. Click Next. Select the versions of Windows that the driver can be used with.
  7. Type any details about the driver that you need for your reference.
  8. Click Next. Click Browse and specify the location of the driver files.
    All driver files in the folder you selected are displayed.
  9. Verify that the correct files, including an .inf file, are displayed in the list, and click Next.
  10. If the driver files are valid, you will see a success message. Click Finish to close the dialog box.
    If you see an error icon, you'll need to find the correct driver files for the driver you have named.

  11. The driver you added is now displayed in the Hardware-independent driver library dialog box, under its corresponding device type. You can add other drivers by repeating the steps above.

  12. To add the drivers to the device library, click the Update button. Click Close when you have finished managing your drivers.

Associating devices with drivers in the library

When you have created a driver library for hardware-independent imaging, you can associate specific device models with the drivers you want to use in imaging those devices. By doing this you ensure that you can use one basic image for devices from different manufacturers, because as the HII tool runs it will find the correct drivers for each different device type.

The list of manufacturers and models that you use in this process must be accurate. These strings need to match the manufacturer and model strings in the device BIOS, which is where the HII tool looks to determine the correct model name.

To associate a device manufacturer and model with a driver in the library
  1. Click Tools > Distribution > OS Deployment.
  2. Click the Manage manufacturer and model button on the toolbar.
  3. In the Manufacturer column click the Add button.
  4. Select a manufacturer name from the list, or type a new name and press Enter.
  5. With the manufacturer selected, click the Add button in the Model column.
  6. Select a model name from the list, or type a new name and press Enter.
  7. With the model selected, click the Add button in the Device name column.
  8. In the Map model and device dialog box, select the device type in the left column and the device name, then click OK.
    The devices listed here are those you have added to the driver library.
  9. Repeat the steps above to make other associations between device models and the drivers you want to install on them. When you have finished, click Exit.

Using hardware-independent imaging with OS deployment scripts

You can incorporate hardware-independent imaging into an OS deployment script for Windows devices, if the script meets these requirements:

To incorporate hardware-independent imaging, you need to select the HII option in the script wizard so the HII tool runs after the operating system is installed. Also, you need to select one of the following options:

To include hardware-independent imaging in an OS deployment script
  1. Click Tools > Distribution > OS Deployment.
  2. Under OS images, select a script. Right-click the script and select Edit. Or, to create a new script, right-click All OSD Scripts and select New Windows PE configuration.
  3. Click Methods and credentials. Select the Images uses Sysprep and Use Hardware-independent imaging check boxes.
  4. Click Sysprep options > Hardware-independent imaging.
  5. To have the HII tool automatically select the manufacturer and model of the device to be imaged, click Auto detect.
    The tool will read the settings in the device BIOS to find strings that match the manufacturer and model strings you have defined when you associated device models with drivers.
  6. If you want to specify a manufacturer and model for the script, click Select manufacturer and model. Select a manufacturer and then a model from the lists.
    The device drivers associated with that model are listed for your reference.
  7. Define all other script options you want, and click Save to save the script.

Using hardware-independent imaging with provisioning templates

You can incorporate hardware-independent imaging into a provisioning template for Windows devices, if the template meets these requirements:

To incorporate hardware-independent imaging, you need to add an HII option in the Post-OS installation section of the template, so the HII tool runs after the operating system is installed.

There are two options for provisioning templates:

To include hardware-independent imaging in a provisioning template
  1. Click Tools > Distribution > OS Deployment.
  2. Under Provisioning templates, select a Windows-based template. Right-click the template and select Edit. Or, to create a new template, click the New provisioning template button on the toolbar.
  3. Click Action list, then click the Post-OS installation section.
  4. Click Add. Type a name and description for the action (such as HII), and then select Hardware-independent imaging from the Type list. Click OK.
  5. To have the HII tool automatically select the manufacturer and model of the device to be provisioned, click Auto detect.
    The tool will read the settings in the device BIOS to find strings that match the manufacturer and model strings you have defined when you associated device models with drivers.
  6. If you want to specify a manufacturer and model for the template, click Select manufacturer and model. Select a manufacturer and then a model from the lists.
    The device drivers associated with that model are listed for your reference.
  7. Click Apply to save the HII action with the template, then add any other actions to the template. Note that you should include a Reboot action in the Post-OS installation section after the HII action.
  8. Modify any other variables, included templates, or other settings for the template, and click OK when you have finished.