Software distribution

This chapter explains how to use LANDesk Management Suite to distribute software and files to devices throughout your network.

Read this chapter to learn about:

Software distribution overview

Software distribution lets you deploy software and file packages to devices running the following operating systems:

Devices receiving the software distribution packages must have the following LANDesk agents installed:

Software distribution features include:

If you don't have an existing package that you want to deploy, you can use Management Suite package-building technology to create a standalone executable program for the required software installation. Once you have a package, store it on a Web or network server called a "delivery server." Through the console, you can schedule distribution using the Scheduled tasks window. The core server communicates the package's location (URL or UNC path to the device), and the device then copies only the files or the portions of the files it needs from the delivery server.

For example, if you're reinstalling a software program because some of its files were corrupted or missing, the system copies only the damaged or missing files, not the entire program. This technology also works well over WAN links. You can store the package on multiple servers, and then schedule devices to use the server appropriate to their needs (that is, location proximity, bandwidth availability, and so on).

Software distribution will also resume interrupted package downloads. For example, if a mobile device was in the process of downloading a large package and that device disconnects from the network, once the device reconnects the download resumes right where it left off.

In Management Suite, software distribution consists of these main steps:

  1. Create or obtain a software package. The software package can be one or more MSI files, an executable, a batch file, a Macintosh package, a Linux RPM package, a Windows script host package, an application virtualization package, or a package created with the legacy Management Suite package builder. Put the package on your delivery server.
  2. Create a distribution package (Tools > Distribution > Distribution Packages). The distribution package contains the files and settings necessary to install a specific software package, such as the package name, any dependencies or prerequisites, command-line parameters, additional files needed to install the package, and so on. These settings are stored in the database and create a distribution package. Once you create a distribution package, the information is stored in the database and can easily be used in multiple tasks.
  3. Create a delivery method (Tools > Distribution > Delivery Methods). The delivery method defines how a package will be sent to devices. These options aren't associated with a specific distribution package. Options include Targeted Multicast and push and/or policy distributions. Don't create a delivery method every time you want to distribute a package. Delivery methods allow you to define best practices for deploying software. Ideally, create a template delivery method to reuse for distributions that use the same delivery method.
  4. Schedule the distribution job in the Scheduled tasks window (Tools > Distribution > Scheduled Tasks). Specify the distribution package, the delivery method, the devices that need to receive the distribution package, and when the task should run.
  5. When the scheduled time occurs, the scheduler service will start the scheduled task handler which deploys the package using the options selected in the delivery method. These may include the following:
  1. The software distribution agent obtains the package from its local cache, a peer on the network, or the delivery server and processes it on the device by installing or removing the packaged files.
  2. After the package is processed, the software distribution agent sends the result to the core server, where it's recorded in the core database.

Separating distribution tasks into two parts, distribution packages and delivery methods, simplifies the distribution process. Now you can create delivery method templates that are independent of a particular package. For example, you could create a default Targeted Multicast delivery method template, and whenever you have a package you want to multicast, you can deliver the package using that template without having to reconfigure the distribution package or the delivery method.

If you have different people in your organization that create packages and distribute packages, these changes help simplify job roles and task divisions. Package creators can now work independently from package deliverers.

Understanding package types

Software distribution supports these package types:


These are packages in the Windows Installer format. You must use a third-party tool to create MSI packages. These packages consist of a primary .msi file and can include supporting files and transforms. Transforms customize how MSI packages are installed. If your MSI package consists of multiple files, make sure you add all of them in the Distribution package dialog.


In order for an executable package to be used by software distribution, it must meet the following criteria:

As long as the executable meets these two criteria, any executable can be used for installing the package. You can include additional files for executable packages.

Batch file

Batch file packages are based on a Windows/DOS batch file. You can include additional files for these distribution packages. The successful completion status of the batch file package is based on the value of the errorlevel system environment variable when the batch file has finished running.

NOTE: Using batch files in tasks on Windows 95/98 devices
In Windows 95/98, when launches a batch file that contains a Windows executable, the batch file will launch the executable and continue executing commands in the batch file without waiting. The core will receive a result when the batch file ends, not necessarily when the Windows executable ends. In this case, the core won't know if the Windows executable ran correctly and it will report a successful completion if the rest of the DOS commands ran successfully.

If the batch file launches a DOS executable, the batch file will then wait for the executable to finish before continuing on. For DOS executables, the core will receive a result when all processes have ended.


Any Macintosh file can be downloaded, though Management Suite won't download directories. Install packages (.pkg) can contain directories. They must be compressed. If the file downloaded has an extension of .sit, .zip, .tar, .gz, .sea, or .hqx, Management Suite will decompress the file before returning. (Users should make sure that Stuffit Expander has its "check for new versions" option disabled; otherwise a dialog may interrupt script execution.)

Linux RPM

These are packages in Linux RPM format. These packages must be stored on a Web share for Linux RPM distribution to work.

LANDesk Application Virtualization:

LANDesk Application Virtualization uses Thinstall technology to virtualize an application, storing it in a single self-contained executable file with the application and the DLL/device driver dependencies. When run, virtualized applications run in an isolated environment without making changes to the Windows installation they are run on.

Virtualized applications run on locked-down devices without requiring additional privileges.

Virtualized applications generally consist of one or more executable files. Software distribution can be used to deploy virtualized application executable files to managed devices. Any of the software distribution delivery methods are used with virtualized application packages, including the Run command from the source. When deploying a run from source virtualized application package, managed devices use an application shortcut icon to run the virtualized application executable file over the network.

Windows Script Host Package (.wsf):

Windows Script Host Packages (WSH) are Microsoft Software’s new alternative to batch files that are often used to automate similar tasks such as mapping drives, copying files, or modifying registry keys. The WSH files are most commonly used with Jscript (.js) and VBScript (.vbs). One major advantage of the Windows Script Host package over the .bat package is that they allow the user to combine multiple languages into a single file by using the language independent file extension (.wsf). These packages can often be created in Notepad, an HTML editor, Microsoft Visual C++, or Visual InterDev.

SWD package

These are packages built with the legacy LANDesk Enhanced Package Builder (installed separately). Although the Enhanced Package Builder is no longer shipped with Management Suite, LANDesk Software continues to support the distribution of files created with it. They are executable files that have properties that uniquely identify them as software distribution (SWD) packages.

Understanding the available delivery methods

Software distribution provides these delivery methods:

NOTE: LANDesk has included default delivery method configurations for each of these delivery method types. These default methods have default settings that should work well in most environments. If you want to modify one of these defaults, you may want to use copy and paste to create a duplicate delivery method that you can then rename, preserving the defaults for future reference.

Software distribution core server components

The following components of software distribution run or reside on the core server:

Setting up the delivery server

The delivery server is the server that stores the software distribution packages. It can be either a Web server or a Windows file server. We recommend that for best results, the packages be URL-based. In general, properly configuring a URL is less work than configuring a UNC path.

HTTP package shares need to have the Internet Guest Account added with at least read privileges, since the packages will be accessed via anonymous HTTP.

UNC package shares need to have the Domain Computers group added with at least read privileges.

To configure a Web server for software distribution

These steps explain how to create a virtual directory on a Web server and enable it for browsing. In general, virtual directories need to allow reading and directory browsing, and anonymous access to the virtual directory must be enabled. Execute must not be set or the share won't work correctly. You also may want to disable write permissions so devices can't change the directory's contents.

  1. Create a directory on the Web server where you want to store your software distribution packages. The usual location for such a directory on an IIS Web server is a subdirectory in the c:\inetpub\wwwroot directory.
  2. Copy the packages to this directory.
  3. From the Control Panel, double-click Administrative Tools and then Internet Services Manager.
  4. In the right panel, double-click the icon with the device's name and then click Default Web Site.
  5. In an empty area in the right panel, right-click and select New, then click Virtual Directory.
  6. From the wizard, click Next and then enter an alias for your directory. Click Next.
  7. Either enter the path or browse to a path and click Next.
  8. In the Access Permissions dialog, enable Run script and Browse. This enables you to browse packages when creating a distribution package. Click Next and Finish.
  9. From the shortcut menu for the virtual directory you just created, click Properties.
  10. On the Documents tab, clear the Enable default content page option and click OK. Default pages can interfere with the share's ability to provide a directory that can be browsed.
  11. On the Directory Security tab, click the Edit button in the Authentication and access control box. Make sure Integrated Windows authentication is checked. Also make sure Digest authentication for Windows domain servers is cleared.
  12. To enable Port 80 on the Web server, in the left panel, right-click Default Web Site.
  13. Click Properties. In the Web Site Identification dialog, the TCP Port box should display 80. If it doesn't, click Advanced to add the port.
  14. Ensure that the Web site is available by opening a browser and entering the URL for your Web server and virtual directory. For example, if the name of your Web server is Test and the name of the virtual directory is Packages, enter the following URL:


    A list of the packages you have copied to this directory should appear.

The size and number of packages you put in this directory is limited only by available disk space. Subdirectories can be created to logically group packages. Each subdirectory that's created must have the access permissions set, as described in the "To configure a Web server for software distribution" task above.

Once you copy the packages to a package share on a Web server, they're staged and ready to be copied to the target devices. When scheduled, the URL or UNC path of the package is passed to SDClient.exe (the device agent) as a command-line parameter. SDClient.exe manages the file transfer, starts the installation, and reports the status. Although the HTTP protocol is used for the file transfer, the status report is returned through the standard LANDesk agent.

The Web server communicates with the device to ensure that the package copies correctly. If the package transmission is interrupted during the download, the Web server can use the HTTP protocol to restart the download at the point where it stopped. The Web server doesn't check, however, to ensure that the package was installed correctly. That traffic is TCP-based, and it returns the status to the core server using the standard LANDesk agent.

Configuring a file server for software distribution

Devices that don't have a browser must receive distribution packages from a UNC path on a Windows network server. This can be the same folder as the one you set up on your Web server. If you're using preferred servers, you can configure authentication credentials for your UNC package share there, without having to configure a null-session share.

If you aren't using preferred servers or preferred server credentials, you'll need to make your package share null-session, which allows users to access the share without having to provide alternate credentials. Use the SysShrs.exe utility to create a null-session share folder.

To configure a network server for software distribution
  1. To set up a shared folder on your network server, right-click the folder you want to share and then click Sharing.
  2. Click Share this folder and click Permissions.
  3. Add the Everyone and the Guest groups, but grant them only read permissions. In a domain environment, also add the Domain Computers group and grant only read permissions. Apply the changes.
  4. Configure preferred package server credentials as described in Configuring preferred package servers.
  5. Copy the software distribution packages to this folder on the network server.

The size and number of packages you store on the network server is limited only by the available disk space.

Configuring IIS Web servers for software distribution

When hosting packages on a Microsoft IIS Web server, there is some additional configuration you need to do:

IIS 6 handles virtual directories differently than IIS 5 (IIS 5 was the Windows 2000 Web server). On an IIS 6 server, if you select a directory and from its shortcut menu make it a Web share, the directory registers itself in IIS 6 as a Web application rather than a virtual directory. The problem is that as a Web application, when trying to select an executable file, the Web server attempts to run the file as a Web application rather than download the file to the user.

The solution is to go into IIS, change the shared directory from a Web application to a virtual directory, and turn off execute permissions.

When hosting files on an IIS 6 server, files without a registered MIME file type will result in an HTTP error 404, File Not Found. This will resulting in the multicast and/or installation of the file failing unless you register MIME file types.

To register MIME file types
  1. Launch Internet Information Services (IIS) Manager.
  2. Expand the local computer in the tree.
  3. Click Web Sites > Default Web Site.
  4. From the package Web share's shortcut menu, click Properties.
  5. Click the HTTP Headers tab.
  6. Click MIME Types.
  7. Click New.
  8. In the Extension box, enter an asterisk (.*).
  9. In the MIME Type box, type application/octet-stream.
  10. Click OK twice and apply the changes.

Distributing a package

A distribution package consists of the package file you want to distribute, any additional files needed by the package, and settings that describe the package components and behavior. You must create the package before you can create the distribution package definition for it.

These instructions explain how to create a software distribution package. For the package to execute correctly, the software distribution package must exist on either a network or Web server and the devices must have the software distribution agent installed.

There are three main steps required to distribute a package to devices.

Step 1: Create a distribution package for the package you want to distribute.

Step 2: Choose the delivery method.

Step 3: Schedule the package and delivery method for distribution.

To create a distribution package
  1. Create the package you want to distribute.
  2. Click Tools > Distribution > Distribution Packages.
  3. From the shortcut menu of the package group you want, click New distribution package > the package type you want to create.
  4. In the Distribution package dialog box, enter the package information and change the options you want. Note that you must enter the package name, description, and primary file. For more information on each page, click Help.
  5. Click OK when you're done. Your script appears under the tree item for the package type and owner you selected.

NOTE: LANDesk has included default delivery method configurations for each delivery method type. These default methods have default settings that should work well in most environments. If you want to modify one of these defaults, you may want to use copy and paste to create a duplicate delivery method that you can then rename, preserving the defaults for future reference.

To create a delivery method (only necessary if a default delivery method isn't ideal in your environment)
  1. If you've already configured a delivery method that you want to use, or you are using one of the default delivery methods, skip to the next procedure, "To schedule a distribution task."
  2. Click Tools > Distribution > Delivery Methods.
  3. Right-click the delivery method you want to use, and click New delivery method.
  4. In the Delivery Method dialog box, enter the delivery information and change the options you want. For more information on each page, click Help.
  5. Click OK when you're done. Your script appears under the tree item for the delivery method and owner you selected.
To schedule a distribution task
  1. Click Tools > Distribution > Scheduled tasks.
  2. Click the Create software distribution task toolbar button.
  3. On the Distribution package page, select the distribution package you created.
  4. On the Delivery Method page, select the delivery method you want to use.
  5. Click Save to save your changes.
  6. From the network view, drag targets onto the task in the Scheduled tasks window. Targets can include individual devices, computer groups, LDAP objects (user, machine, and group), LDAP queries, and inventory queries.
  7. From the task's shortcut menu, click Properties.
  8. The Target devices page shows the devices that will receive this task.
  9. On the Schedule task page, enter the task name and the task schedule.
  10. Return to the Overview page and confirm the task is configured how you want it to be.
  11. Click Save when you're done.

View the task progress in the Scheduled tasks window.

Working with distribution owners and rights

In environments where there are many Management Suite users, it can get confusing knowing which distribution packages, delivery methods, and scheduled tasks each user is responsible for. To help with this problem, Management Suite makes the user that created the distribution package, delivery method, or scheduled task the default owner of that item. Only the owner and RBA Administrators/Software distribution configuration users can see these private items.

Private items appear under the My delivery methods, My packages, or My tasks trees. Administrative users can see items for all users under the All distribution packages, All delivery methods, and All tasks trees.

When users create a distribution item, the Description page has an Owner option. Users can select Public if they want all console users to see that item. Administrators can select a specific user in addition to Public.

For more information on using role-based administration with software distribution, see Software distribution.

Using multiple distribution packages in a task

Push, policy, and policy-supprted push software distribution tasks can include a preliminary package and a final package. When using multiple packages, the packages are installed in order one at a time. The previous package must return a successful task status on all targeted devices before the next package begins installing.

Preliminary and final packages are useful in cases where you want to run commands before and/or after the main package. For example, you could create a batch file package that executes commands to configure the targeted device for the main package. After the main package finishes installing, you could specify a final batch file package that does any post-configuration. Any package type can be a preliminary or final package, but the delivery method must be push. The policy-supported push delivery method doesn't support preliminary and final packages.

You can specify preliminary and final packages when you schedule a distribution task. The Scheduled task - properties dialog's Distribution package page has the Preliminary package and Final package options. Before you can click one of these options, you must go to the Delivery method page and select a push delivery method. To do this, click Push for the Delivery type and click the Delivery method that you want to use.

To use multiple distribution packages in a task
  1. Create the packages you want to use in the task.
  2. Click Tools > Distribution > Scheduled tasks. Click the Create software distribution task toolbar button.
  3. On the Delivery method tab, click Push as the Delivery type and click the Delivery method that you want to use.
  4. On the Distribution package tab, click the Package type and Distribution package that you want to use.
  5. Click Preliminary package, Main package, or Final package, depending on when you want that package installed, and click Set.
  6. Repeat steps 4 and 5 for any other packages you want installed for this task. You can only have one package in each stage and you must always have a Main package.
  7. Finish configuring the task and schedule it.

About file downloading

Software distribution has several methods for getting the file down to the device for installation. These include:

When a file needs to be downloaded, the device software distribution agent, SDClient, first checks the cache to determine if the file is located in the cache. The cache is defined as either C:\Program Files\LANDesk\LDClient\sdmcache or the path stored in the "Cache Directory" under the multicast registry key:

The structure of files in the cache will be identical to the structure of the files on the Web or network server. This allows multiple packages to have files with the same name and not cause problems.

If the file isn't in the cache, SDClient will typically attempt to download the file from a peer in the network. You can configure the delivery method to require a peer download.

If the file can't be obtained from a peer, SDClient will download the files directly from the UNC or URL source. You can configure the delivery method so that if the file is to be obtained from the source, only one device in the multicast domain will download the file from the source location. Under most circumstances when downloading from a UNC share, this requires the UNC share to be a NULL session share. If the file to be downloaded is URL-based, SDClient will download the file from the Web site.

In either case, SDClient will put the file in the multicast cache. After it is put in the multicast cache, SDClient processes the downloaded file.

When a file is downloaded into the cache it will remain in the cache for several days, but it is eventually deleted from the cache. The amount of time that the file will remain in the cache is controlled by the delivery method used when deploying the package.

Updating package hashes

Because many package files are obtained from peers in the network, the files are verified prior to installation. The integrity of the files are verified by comparing the MD5 hash of the file to the MD5 hash generated at the core server.

When a distribution package is first scheduled, Management Suite downloads the files and calculates the hash values associated with the primary file and any additional files used by the distribution package. If the hash stored with the package doesn't match the hash value SDClient computed on the target device, the download isn't considered valid.

If you make any changes to the package outside of Management Suite, such as updating the package contents, you need to reset the hash, or any scheduled tasks using the updated package will fail.

To reset a package hash
  1. Click Tools > Distribution > Distribution packages.
  2. From the shortcut menu for the package whose hash you want to update, click Reset file hashes. This can take a few minutes on large packages.

Running packages from the source server

Software distribution normally downloads package files to the local device's cache and then installs the package from the cache. This may not work well if a package or application expects installation files to be in a specific folder structure, such as with the Microsoft Office installer, or if the application installation doesn't use all source files for every installation.

For cases like these, you can instead have the local software distribution agent run the file directly from the source, whether that's a preferred server or the source specified in the package. When you enable run from source, software distribution won't download package files to the local cache, nor will it run the package from a peer.

When using run from source with packages stored on Web shares, the primary file must be an MSI file or SWD package. With UNC shares, the primary file can be any file type.

To create a delivery method that uses run from source
  1. Click Tools > Delivery methods > Network usage.
  2. Click Use run from source to deploy files.
  3. Finish configuring the delivery method.

Using software distribution with packages on a distributed file system (DFS)

Distributed file systems (DFS) use several servers to provide files that are available from a single file share. Software distribution's default method of bandwidth detection in a DFS scenario ends up using the root server to calculate bandwidth, which may not be the actual server that provides the file. Software distribution now provides an optional way of calculating bandwidth. With this new method, bandwidth detection retrieves a small portion of the actual file being distributed. This way, software distribution calculates bandwidth from the server providing the file.

This alternate bandwidth detection method isn't enabled by default. You can enable this option from the file in the core server's ldlogon folder. Once you update this file, the changes become part of new or updated agent configurations. You must redeploy your agent configuration to devices for the change to take effect.

Look for this section in and make the necessary changes.

; The following registry values control detecting bandwidth by file download
; change the UseDownloadForBandwidth value to 1 to enable use of file download for bandwidth detection
; the DownloadSize value should be entered as a Hex value between 400 and FFFF(1024 bytes to 65535 bytes).
REG1=HKEY_LOCAL_MACHINE, SOFTWARE\LANDesk\ManagementSuite\WinClient\SoftwareDistribution\UseDownloadForBandwidth, 0, , REG_DWORD
REG2=HKEY_LOCAL_MACHINE, SOFTWARE\LANDesk\ManagementSuite\WinClient\SoftwareDistribution\DownloadSize, 2000, , REG_DWORD

Configuring preferred package servers

You can specify the preferred server that devices will check for software distribution packages. This can be important in low-speed WAN environments where you don't want devices downloading packages from off-site servers. When you specify preferred servers, you can also specify the credentials managed devices should use to authenticate with each preferred server. You can also specify the IP address ranges that preferred server will be available to.

When using preferred servers with a distribution job, only the server portion of the UNC or URL file/package path is replaced; the rest of the path must be the same as what was specified in the distribution task. If the file isn't on the preferred server, it will be downloaded from the location specified in the distribution package. The only distribution method that doesn't support preferred servers is Multicast (cache only).

The core server also uses preferred servers. The core server uses distribution package hashes to verify distribution packages in scheduled tasks. The core server will first try to generate these hashes from a preferred server. Using a local preferred server makes the hashing process much quicker. If the package isn't available on one of the preferred servers, the core server falls back to generating the package hash from the path specified in the distribution package. You generally won't want the core server pulling a large package over the WAN link for hashing, so hashing files on a server that's local to the core will be much faster and use less low-speed bandwidth.

Managed devices store the preferred server list locally in the preferredserver.dat file. To create this file, a device communicates with the core server and then makes a filtered list of preferred servers (based on IP address range limits, if any). The device then does a bandwidth check to each preferred server and saves the top three servers in the preferredserver.dat file. Note that the bandwidth check doesn't produce guaranteed reliable results. For example, a server that's close by may have a high load at the time the agent checks, so it may get bumped off even if normally it's the best candidate.

The distribution agent updates the preferredserver.dat file every 24 hours or when the IP address changes. Not every device has to go through this process. Devices share their preferred server lists with peers. This is the process managed devices go through to maintain a current preferred server list:

  1. If preferredserver.dat is in the local file cache, the distribution agent uses it.
  2. If preferredserver.dat is on a peer, the agent retrieves the file from that peer.
  3. If preferredserver.dat isn't available locally or on a peer, the device contacts the core server, creates a filtered preferred server list, and saves that locally as preferredserver.dat.
  4. If preferredserver.dat is empty or if none of the preferred servers respond, the agent checks for a preferred server list in the local registry.

If none of these steps results in an available preferred server, the local agent uses the distribution path specified in the distribution job.

To configure preferred package servers
  1. Click Configure > Preferred server.
  2. Click Add to add a new server, or click an existing entry and click Edit.
  3. Enter the server information. If you want to use IP address ranges that you want this server to be available to, enter them and click Add.
  4. Click Test credentials to make sure the credentials you provided work.
  5. Click OK.

Storing preferred package servers in the registry

The easiest way to manage preferred servers is with the Server credentials dialog (Configure > Preferred server). If you want to configure a fallback list of preferred servers that will be used if there are no servers in the preferredserver.dat file, you can create the following registry key on managed devices, and set the value to the preferred package server name. You can specify multiple package servers by separating them with semicolons.

Here's a sample registry entry:

Customizing the number of servers stored in preferredserver.dat

By default, the preferredserver.dat file contains three servers whose test results gave the highest bandwidth at the time of the bandwidth check, in order. You can change the number of servers stored in preferredserver.dat by updating this line in the file in the core server's ldlogon folder. Valid numbers range from 0 to 7. Once you update this file, the changes become part of new or updated agent configurations. You must redeploy your agent configuration to devices for the change to take effect.

; Settings for the lddwnld/ldredirect files, the DynamicPreferredServers is the
; maximum number of preferred servers that will be stored. Set this to 0 to disable
; the dynamic preferred server functionality.
REG51=HKEY_LOCAL_MACHINE, SOFTWARE\LANDesk\ManagementSuite\WinClient\SoftwareDistribution\DynamicPreferredServers, 3, , REG_DWORD

Customizing preferred server prioritization

In order to prevent delays when the most preferred servers do not have a package, the redirection logic will start to prefer servers that have been actually providing files to the device. You can change the preferred server prioritization in preferredserver.dat by updating these lines in the file in the core server's ldlogon folder:

; In order to prevent delays when the most preferred servers do not have a package
; the redirection logic will start to prefer servers that have been actually
; providing files to the client. The following registry options control when a
; server is moved up the list. The ServerHistoryUseCount value indicates the number
; of times a server must be used before it will be moved to the start of the list,
; the ServerHistoryCacheTime value indicates how long it should be remembered (in seconds).
REG52=HKEY_LOCAL_MACHINE, SOFTWARE\LANDesk\ManagementSuite\WinClient\SoftwareDistribution\ServerHistoryUseCount, 3, , REG_DWORD
REG53=HKEY_LOCAL_MACHINE, SOFTWARE\LANDesk\ManagementSuite\WinClient\SoftwareDistribution\ServerHistoryCacheTime, 3600, , REG_DWORD

Understanding UNC authentication

When you add preferred servers (Configure > Preferred server), you also provide credentials that devices should use when accessing the preferred server. For security reasons, make sure these credentials provide read-only access. Devices obtain these credentials from the core and use them to authenticate with that preferred server. When using preferred servers added to the Server Credentials dialog, you no longer have to configure your package shares to be null-session shares, as was necessary with previous versions. As long as the credentials you provide for the preferred server work with the package share (Click Test credentials in the User name and password dialog), managed devices should be able to access the share.

About byte-level checkpoint restart and dynamic bandwidth throttling

Management Suite 8 and later versions support distribution byte-level checkpoint restart and dynamic bandwidth throttling. Checkpoint restart works with distribution jobs that SWD first copies to the device cache folder (by default, C:\Program Files\LANDesk\LDClient\SDMCACHE). When a bandwidth controlling option is selected, the files get copied to the device cache first, and checkpoint restart allows interrupted distributions to resume at the point where they left off.

Dynamic bandwidth throttling specifies that the network traffic a device creates has priority over distribution traffic. This option also forces a full download of the file into the device's cache, which also enables byte-level checkpoint restart, where downloads resume where they left off if interrupted. If you select this option and leave the Minimum available bandwidth percentage at 0, once the device initiates network traffic, the distribution cuts back to about one packet per second until the traffic stops. Increasing the minimum available bandwidth preserves approximately the amount of device bandwidth you specify for distribution if the distribution needs network bandwidth and there is contention for bandwidth on the device.

If you're reinstalling or repairing an SWD package or an MSI package, you may not want to use the dynamic bandwidth throttling option, because these package types normally only download the files they need. Using dynamic bandwidth throttling in this case would force a full download of the package when a repair might normally only require a small portion of the package.

Dynamic bandwidth throttling isn't available on Windows 95, Macintosh, or DOS devices. Windows 98 and Windows NT devices can use dynamic bandwidth throttling if they have Internet Explorer version 4 or later installed.

You can configure collective bandwidth throttling so that only one device from the multicast domain will download from the remote source. You can also configure the amount of bandwidth used when downloading from the source. This feature is available on all versions of Windows systems. Collective bandwidth throttling isn't available on Macintosh or DOS systems.

Using Targeted Multicast with software distribution

LANDesk Targeted Multicast technology makes it possible to distribute large packages to many users across the network with a minimum of network traffic. Targeted Multicast features require no additional hardware or software infrastructure, and require no router configurations to allow multicast packets. You get the extraordinary benefits of multicast technology with none of its traditional headaches.

Targeted Multicast is designed to work with your existing software distribution packages. When you use Targeted Multicast, you can easily distribute software, even in WAN environments with multiple hops and low connection speeds (56k). Targeted Multicast uses HTTP for delivery from a Web site to a subnet representative. Management Suite's inventory scanner provides all the subnet information to the Targeted Multicast service.

Targeted Multicast provides unique benefits that standard methods of "multicast" don't provide. Inventory-based targeting of devices enables you to send a package to a selected group of computers that fit specific criteria via a multicast. Targeted Multicast is also simplified because there's no need to configure routers to handle deliveries.

When compared to conventional software distribution methods, Targeted Multicast significantly reduces the time and bandwidth needed to deliver software packages. Instead of sending a package across the wire for each device, only one transfer is made for each subnet. Bandwidth savings increase as the number of devices on each subnet increases.

You can activate Targeted Multicast from the delivery method properties by checking the Use Multicast to deploy files option on the Network usage page of the Delivery methods properties. Multicast is available in policy supported push, push, and multicast (cache only) delivery methods. Underneath the Network usage page you will find several pages that allow the multicast to be configured.

When you start a distribution using Targeted Multicast, you'll see the Multicast software distribution window. This window contains detailed information about how the distribution is proceeding. For more information about what each field means, click the Help button on the Multicast software distribution window.

Both Windows and Macintosh OS 10.2 devices support Targeted Multicast. Additionally, you can multicast OS deployment images.

Using peer download

Peer download is a Targeted Multicast option that forces targeted devices to install a package from the devices' local cache or from a peer on the same subnet. This option conserves network bandwidth, but for the package installation to be successful, the package must be in the local cache or a peer's cache.

If you don't select the Peer Download option, the Targeted Multicast device agent will still attempt to conserve bandwidth by checking the following locations for package files in this order:

  1. Local cache
  2. Peer on the same subnet
  3. Package server

Copying files to the local multicast cache folder

You have the option of copying one or more files to the local multicast cache folder using multicast. This option copies a file to the targeted devices' local cache. It doesn't install the file or do anything else with it. This option is useful for getting files to multicast domain representatives or a device in each multicast domain. You can do an initial deployment to domain representatives and then redo the deployment with the peer download option to ensure devices only download the package from a peer on their subnet.

Configuring Targeted Multicast

Before using Targeted Multicast, you need to make sure the Targeted Multicast components are in place on the subnet you're distributing to. Targeted Multicast requires Management Suite 8 agents and a multicast domain representative.

To manually specify which computers will be multicast domain representatives
  1. In the network view, click Configuration > Multicast Domain Representatives.
  2. Add domain representatives by dragging the computers you want to be representatives from the network view into this category.

Targeted Multicast will use the first computer that responds per subnet in the Multicast domain representatives group.

Only Windows computers can be multicast domain representatives. If you are using multicast to distribute packages to Macintosh computers, make sure there is at least one Windows computer in the multicast domain that can act as a domain representative for the Macintosh computers. If you only have a few Windows computers in a predominantly Macintosh environment, it's best to manually specify Windows domain representatives in the Multicast Domain Representatives group.

You can throttle multicasts by changing the bandwidth sliders in the Bandwidth usage page under the Network usage page on the Policy-supported Push, Push, and Multicast delivery method windows.

You can also customize Targeted Multicast options in the Configure Management Suite Services dialog box. To configure the Targeted Multicast service, click Configure > Services > Multicast tab. Click Help on that tab for more information.

Running an application under the context of the currently logged-on user

LANDesk Management Suite performs most application installations and other tasks using full system privileges. Some application installations and other tasks need to be performed as the system's current user. Since the release of LANDesk Management Suite 8.7 SP2, the startasuser.exe application, makes it possible to run an application under the context of the currently logged-on user.

startasuser.exe will launch the supplied command line in the context of the user currently logged onto the system. startasuser.exe supports the following command line format:

startasuser.exe [///silent] [///timeout=x] [///?] command line...

If no user is logged onto the system when startasuser.exe launches, the application returns the standard Windows ERROR_NOT_LOGGED_ON (1245) error.

All of the command-line options for the startasuser.exe application are preceded with three forward slashes (///); this is done to prevent confusion with command line options of the launched application.

The command line options are outlined in more detail below.


This option results in the created process being started as hidden. This should prevent any windows of the application displaying.


This option controls the timeout (in seconds) for the launched application. If the launched application has not completed before the specified timeout has occurred, the startasuser.exe application will exit with the standard Windows error WAIT_TIMEOUT (258).


This option causes command line usage to be displayed to stdout. Because startasuser.exe is a Windows application, the help will not display in the command prompt by default. Use the following command line to display help from within a command prompt:

startasuser.exe ///? > more

command line…

After any startasuser.exe options, specify the full command line for the application to be run.

The following two examples show how to use the startasuser.exe application to launch an executable or install an MSI.

To run an executable (in this case, regedit) as the currently logged-on user
  1. Create a batch file with the following command line:
    startasuser.exe ///timeout=300 regedit.exe
  2. Save the batch file on a file server set up for use with software distribution.
  3. In the LANDesk Management Suite console, click Tools > Distribution > Distribution packages.
  4. From the My distribution packages group shortcut menu, click New distribution package > New batch file package.
  5. Add the batch file saved in step 2 as the main distribution package.
  6. Save the distribution package.

This package can now be used in a software distribution task and will result in the regedit application being launched in the context of the user currently logged on.

To install an MSI package as the currently logged-on user:
  1. Create a batch file with the following command line:
    startasuser.exe msiexec.exe /I <name>.msi
    startasuser.exe msiexec.exe /I <name>.msi
  2. When creating the batch file, replace <name> with the name of the MSI package to be launched. Add additional MSI command-line options if needed.
  3. Save the batch file on a file server set up for use with software distribution.
  4. On the same file server, preferably at the same location, add the MSI package and any additional files.
  5. In the LANDesk Management Suite console, click Tools > Distribution > Distribution packages.
  6. Right-click the My distribution packages group, and then click New distribution package > New batch file package.
  7. Add the batch file saved in step 2 as the main distribution package.
  8. Save the distribution package.

This package can now be used in a software distribution task and will install the MSI package using the currently logged on user.

Using MSI distribution packages

Management Suite supports MSI installation with full status reporting and MSI package recognition. The MSI distribution package type is the Management Suite preferred method of software distribution. Understanding the MSI parameters will help you set up MSI packages and delivery methods.

Using MSI command-line parameters with software distribution

When installing an MSI distribution package, Management Suite leverages the MSI API calls. MSI installations use two different types of command-line parameters:

Option parameters

Option parameters are the switches that are used by the Microsoft installation tool, Msiexec.exe. For example, the /q switch is a common switch for Msiexec that silences an unattended installation.

In the Distribution package-properties dialog box, you can enter MSI option parameters in the Install/Uninstall options page's Command line field. Click the checkmark button next to the field to validate the command line. More information on Msiexec options can be found at:

Property reference parameters

Property references, also known as public properties, are specific to the MSI file. The parameters are passed to the MSI installation APIs directly. They can be used in the Command line field of an MSI distribution package’s Install/Uninstall options.

The syntax of property references is PROPERTY=VALUE. A common property reference is the Transforms property. This is the property that calls up a .mst (transform) file. More information on property reference parameters can be found at:

The information on an application’s public properties can be obtained from the software installation documentation, the application's official Web site, or by contacting the software vendor directly.

Running an MSI silently

In Management Suite, running an MSI silently is automatically handled under the Install/Uninstall options for a delivery method. To run an MSI silently, go to the Install/Uninstall options page for the desired delivery method and click Quiet mode, no user interaction.

Automating an MSI installation

For many MSI’s, silencing the MSI also automates the installation. In such cases, all you need to do to automate an MSI installation is select Quiet mode, no user interaction in the delivery method.

Sometimes a property reference is required for the installation to complete. In such cases the MSI installer will prompt for a value. During an automated installation, no such prompt will occur. The MSI installation will fail with the standard MSI error 1603, Fatal error during install. Required public properties should be assigned a value in the distribution package’s Command line field.

Using a transform file with an MSI installation

Answer files for MSI’s are called transform files and end with a .mst extension. Not all MSI installations need a transform file; however, a transform file can be used if there are too many property references that need their values changed or assigned. If supported by the application, an answer file may be created to pass in all property reference parameters.

If a transform file is required but not provided during the installation, error 1603, Fatal error during install, will be the result. Often the software vendor will have the information needed or a tool to create a transform file for their specific MSI. For example, to deploy the volume license version of Microsoft Office 2003, a transform file should be used. Microsoft has a tool called the Custom Installation Wizard that installs as part of the Office 2003 Resource Kit. The Office 2003 Resource Kit can be downloaded from the following web site:

If the vendor doesn't have the needed information or such a tool, Microsoft provides a tool called Orca that can create a transform file. For additional assistance, refer to the Orca help file.

Handling reboots with an MSI installation

Management Suite handles MSI reboots using the Reboot page in the delivery method properties. LANDesk will automatically pass both the REBOOT=REALLYSUPPRESS and the /NORESTART parameters when Never reboot is selected in the delivery method.

The Always reboot option passes the /FORCESTART parameter.

Reboot only if needed allows the MSI to handle the reboot. If feedback is enabled, the user can be prompted to reboot. It is important to know that MSI's support custom actions. If a custom action initiates a reboot, Management Suite can't prevent this.

MSI checklist

If a deployment involves an MSI, follow this checklist.

Assigning return codes

The Assign return codes dialog box is used to send status back to the core server based on whether or not a distribution task was successful. In the past, Management Suite only read 0 as a success and anything else would be treated as a failure. This would pose issues for administrators as the application may have installed without error, however, because the return code was sent back as a number other than 0, Management Suite would indicate failure.

Vendors maintain lists created by product developers of all possible return codes and the specific outcome that the codes indicate. Now Management Suite has added the ability for administrators to look up return code lists and build templates that can be associated with individual or multiple packages. Each return code can be designated by the administrator to indicate success or failure and send back a custom message indicating specific results of the installation. Management Suite now ships with a Windows installer process for Office 2003 and Office XP templates. For more information on the return codes included in this template go to:

In addition to using this feature with third-party vendor applications, return code templates can also be created for proprietary applications written by internal developers. Management Suite provides a default template as well as the ability to create new custom templates, copy the default or custom templates, or make modifications to any templates through the Return code template manager. When templates are created, a specific template can be associated with a specific package on the Assign return codes dialog box through the Package return code mappings window. Modifications to templates can also be made from this location.

Users have the option to add all possible return codes indicating success or failure or only add additional return codes that indicate success. In the instance that only success codes are added, any return codes not referenced in the template are automatically mapped as failures.

There are two default templates included with Management Suite:

One of these templates is automatically assigned to the distribution package based on its type. You can change the template mapping in a distribution package's properties.

To use the Return code template manager
  1. Click Tools > Distribution > Distribution packages.
  2. On the Distribution packages toolbar, click the Return code template manager button.
  3. In the Return code template manager dialog, click Add, Modify, Delete, Import, or Export.
  4. Click Save.
To add a new return code mapping template
  1. Click Tools > Distribution > Distribution packages.
  2. On the Distribution packages toolbar, click the Return code template manager button.
  3. In the Return code template manager dialog, click Add.
  4. Enter a Template name and Template description.
  5. Select a Template filter type.
  6. Click OK.
  7. In the Package return code mappings dialog box, if you want to change the default message for success or failure, select a State and enter a corresponding Message for that state.
  8. Add a new mapping by clicking Add.
  9. At the bottom of the dialog box, enter the numeric return code or return code range.
  10. Enter a Message and select a State.
  11. Repeat steps 8-10 as necessary.
  12. Click OK. Your new template appears in the list.
To apply the return code mapping to a distribution package
  1. Click Tools > Distribution > Distribution packages.
  2. Double-click the package you want to modify.
  3. In the package properties tree, click Assign return codes.
  4. Click the return code template you want to apply.
  5. Click Assign.
  6. Click Save.

Exporting and importing return code templates

Return code templates are stored in the core database, but you can export templates to an XML file and import them at other servers. If a distribution package is being synchronized through core synchronization, its assigned return code template is part of the synchronization data.

To export a return code template
  1. Click Tools > Distribution > Distribution packages.
  2. On the Distribution packages toolbar, click the Return code template manager button.
  3. Click the template you want to export.
  4. Click Export.
  5. Browse for a path and enter a File name.
  6. Click Save.
To import a return code template
  1. Click Tools > Distribution > Distribution packages.
  2. On the Distribution packages toolbar, click the Return code template manager button.
  3. Click Import.
  4. Browse for the XML file containing an exported template.
  5. Click Open.

Using the software deployment portal

The Software Deployment Portal window is accessible through Desktop Manager on managed devices. The portal lists all software distribution package tasks that have been distributed using a policy based delivery method.

When you launch the portal, it prompts you to wait while it synchronizes with the policy server to refresh the application list. During this time the policy sync is running and downloading any new policies. The required policies aren't displayed on the Software Deployment Portal window and start installing automatically (unless deferred by the end-user). The other tasks are displayed in the Software Deployment Portal window.

The managed device includes a policy invoker service that examines policies that are downloaded. The policy tasks are stored in a small database when retrieved. The invoker service monitors this database and updates that status of policies as they move from one state to another. It also reads the status of policies to determine if an installation needs to take place. The invoker doesn't install packages. It calls the software distribution agent (sdclient.exe), which does the install.

In addition to the policy update that happens when a user opens the Software Deployment Portal, these agent configuration options also affect policy update intervals. An update occurs:

You can change these policy update settings on the agent configuration dialog's Software distribution > Policy Options page.

Distributing software to Linux devices

Once you've deployed the Linux agents, you can distribute software to your Linux devices. The initial Linux agent deployment uses an SSH connection. Once the agents are installed, the core server uses the standard LANDesk agent to communicate with the Linux server and transfer files. To distribute software to a Linux device, you must have Administrator rights.

You can only distribute RPMs to Linux devices. The Linux agents will automatically install each RPM you distribute. The RPM itself isn't stored on the server after installation. You can install and uninstall the RPM you specify using software distribution. You can only use push delivery methods with Linux software distribution. For Linux software distribution, the settings in the push delivery method are ignored, so it doesn't matter which push delivery method you select or what the settings in it are.

The distribution follows this process:

  1. The core server connects to the Linux device through the Standard LANDesk agent
  2. The device downloads the package
  3. The device runs a shell script that uses RPM commands to install the RPM package
  4. The device sends status back to the core server.

You can store Linux RPMs on HTTP shares. Linux software distribution doesn't support UNC file shares. For HTTP shares, make sure you've enabled directory browsing for that share. If you use an HTTP share on a Windows device other than the core, you need to configure IIS with the correct MIME type for RPM files. Otherwise, the default MIME type IIS uses will cause the RPM to fail to download the file.

To configure the RPM MIME type on Windows devices
  1. From Windows Control Panel, open Internet Services Manager.
  2. Navigate to the folder that hosts your distribution files. From that folder's shortcut menu, click Properties.
  3. On the HTTP Headers tab, click the File Types button.
  4. Click New Type.
  5. For the Associated Extension, type rpm. Note that rpm is lowercase.
  6. For the Content type, type text/plain.
  7. Click OK to exit the dialog boxes.

Once you've hosted the files on your package share, create a new Linux distribution package in the Distribution packages window, associate it with the delivery method you want, and schedule the delivery.

Understanding Linux software dependencies 

When you click Save in a Linux package's Distribution package-properties dialog box, software distribution parses the primary RPM and any dependent RPMs you selected for dependencies those RPMs require. These dependencies then appear in the Missing libraries dialog box. Checking a dependency in this dialog box tells software distribution to not prompt you about it again. You can check dependencies you know are installed on managed devices. This dialog box is for your information only. If a dependency is missing on a target device and you didn't specifically include that dependency as a dependent package, the RPM probably won't install successfully.

Troubleshooting distribution failures

Software distribution lets you distribute packages to a large number of devices at once. If there is a problem with the package, or the software being deployed conflicts with already existing software, you could cause problems for thousands of devices at once. When planning a deployment using software distribution, take care to not overwhelm the help desk.

Before deploying a new package, test it with some test systems. Ideally, these test systems should include all of the operating systems and applications that are used in your environment. Once the package is deployed, confirm that all of the systems and applications are still working as expected.

Once the package has been validated against test systems, do a limited deployment. Target a small number of devices in your environment. When deciding how many devices to target, the rule of thumb is not to target more devices than your help desk can handle. Once the package has been deployed to these devices, let the software sit for a couple of days to see if users encounter any problems.

After the initial deployment, you can begin rolling out the software to other devices in the enterprise. The speed at which these rollouts occur should be based on the variety of devices the enterprise has and the load your help desk can handle.

Here are some other problems you might encounter:

Scheduled task can't find package

If the scheduled task indicates that the package can't be located, make sure that the package can be viewed from the device.

If the package is URL-based, you can check to make sure it is accessible by using a Web browser. Remember, if your DNS is set up to resolve the package, you'll need to verify that the package has been distributed to all of the Web servers.

If the package can be viewed from the device but still does not download properly, the problem may be that the URL or UNC based package share doesn't allow anonymous access. Check the permissions on the UNC or URL share and make sure it allows anonymous access. For UNC locations, make sure it has properly been configured as a null session share.

Bandwidth detection doesn't work

One of the most common problems that can occur is having PDS set up for bandwidth detection. In device setup, one of the common base agent options is to choose between PDS and ICMP for device bandwidth detection. When a device is configured to use PDS for bandwidth detection, it will only detect between RAS and non-RAS connections. So, if you configure a distribution to only work with high speed connection and the package installs on a computer with a WAN connection, check and make sure it is configured to use ICMP and not PDS.