Configuring device agents

Devices need the Management Suite agents on them to be fully manageable. Read this chapter to learn about:

The Agent configuration window lets you create new agent configurations for Windows, Linux, and Macintosh devices. The agent configurations you create can then be pushed to clients using the console's Scheduled tasks window.

NOTE: Deploying agents to Windows 95/98/NT devices
Management Suite no longer ships with agents that support Windows 95, Windows 98, or Windows NT devices. You can contact LANDesk Customer Care if you need the legacy agent that works with these devices.

NOTE: Creating device configurations for Windows devices not enabled for management
If you have Windows devices that are part of a Windows domain, you can push a configuration to those devices even if the standard LANDesk agent and the remote control agents aren't present. For more information, see the deployment documentation on the LANDesk community at

Working with agent configurations

Management Suite uses agent configurations that you create to deploy agents and agent preferences to managed devices. Once devices have the Management Suite agents on them, you can easily update agent configurations.

The Agent Configuration tool is used to create and update device and server agent configurations (such as what agents are installed on devices and what network protocols the agents use). Different configurations can be created for department or group specific needs. For example, configurations can be created for the devices in the accounting department or for devices using a particular operating system. For each type of configuration there can only be one default configuration. The default configuration can't be deleted, but it can be edited. It is a good idea not to have too many different configurations, as this makes support and troubleshooting more complex and time-consuming.

Prior to installing any agent software it is necessary to create an agent configuration (or use the default). This involves considerable planning and testing. It is best to deploy the correct configuration the first time, although the agent can be reconfigured and redeployed again if necessary.

An organization may need to have multiple agent configurations. For example, a laptop system might need a different configuration than a desktop system. In order to avoid deploying the wrong agent to the wrong system, it is important to adopt a sensible naming convention for each agent configuration.

The security and patch scanner agent is installed by default with the standard LANDesk agent. You can configure security scans to determine how and when the security scanner runs on managed devices and whether to show progress and interactive options to the end user. (The security scanner allows you to check for LANDesk software updates on devices and core servers even if you don't have a LANDesk Security Suite content subscription. With a Security Suite subscription you can take full advantage of the security scanner's capability to scan for and remediate known vulnerabilities, spyware, unauthorized applications, viruses, and other potential security risks.)

Before deploying agents, be sure to see the best known methods for agent deployment on the LANDesk user community Web site at

IMPORTANT: When creating agent configurations in mixed-language environments, make sure the agent configuration name uses only ASCII characters (English character set). An English core server is compatible with clients using all supported languages.

However, if the agent configuration name uses a non-ASCII characters, such as Japanese, Chinese, or Russian, the agent configuration must be created on a core/console of that same language and will only work on devices using the same language. For example, an agent configuration that includes Japanese characters must be created on a Japanese core, and must be deployed to a Japanese client.

Read the following sections for more information on:

Creating an agent configuration

Use the Agent configuration window to create and update device and server agent configurations (such as what agents are installed on devices and what network protocols the agents use).

You can create different configurations for groups' specific needs. For example, you could create configurations for the devices in your accounting department or for devices using a particular operating system.

To push a configuration to devices, you need to:

To create an agent configuration

  1. In the console, click Tools > Configuration > Agent configuration.
  2. In the Agent configuration tree, click the configurations category you want.
  3. Click the New Windows, New Windows Server, New Macintosh, or New Linux toolbar button.
  4. Enter a Configuration name.
  5. In the Agent configuration window's Start page, select the agents you want to deploy.
  6. Use the tree to navigate the dialogs relating to the options you selected. Customize the options you selected as necessary. Click Help for more information if you have questions about a page.
  7. Click Save.
  8. If you want the configuration to be the default (the configuration ldlogon\wscfg32.exe or ldlogon\IPSETUP.BAT will install), from the configuration's shortcut menu, click Default configuration.

Using the advance agent

The advance agent is the preferred method for deploying the agent in most environments. This agent has been created to leverage LANDesk bandwidth-friendly technology during the agent deployment. It can reduce the amount of network bandwidth used for Windows-based agent configuration. The Advance agent uses a two stage deployment method. The Advance agent is an MSI file that is deployed in advance of the full agent. The MSI installs and then initiates the download and install of the full agent package.

The advance agent works well for most devices, including laptops with intermittent or slow network connections. However, it doesn't support PDAs and other handheld devices.

The advance agent is a small 500 KB MSI package. When this package runs on a managed device, it downloads an associated full agent configuration package, which may be up to 15 MB in size, depending on the agents you select. In the Advance agent configuration dialog, you can configure what bandwidth-friendly distribution options the MSI will use for the full agent configuration download.

The advance agent works independently from the core server once it starts downloading the full agent configuration. If a device disconnects from the network before the agent configuration finishes downloading, the advance agent will automatically resume the download once the device is back on the network.

When you create an advance agent configuration, it takes a few seconds for the console to create the full agent configuration package. The console places the advance agent package (<configuration name>.msi) and the newly-created full agent configuration package (<configuration name>.exe) in the core server's LDLogon\AdvanceAgent folder. The file names are based on the agent configuration name.

Once you've created an agent configuration package, you need to run the MSI portion on devices by using one of the following methods:

Once you deploy the advance agent to devices, the advance agent starts downloading the associated agent configuration. The agent runs silently on the managed device, without showing any dialogs or status updates. The advance agent uses the bandwidth preferences you specified in the Advance agent configuration dialog, such as Peer Download and dynamic bandwidth throttling.

Once the MSI installs and successfully configures agents on a device, it removes the full agent configuration package. The MSI portion stays on the device, and if the same MSI runs again it won't reinstall the agents.

To create an advance agent configuration
  1. Create a Windows-based agent configuration (Tools > Configuration > Agent configuration).
  2. From that configuration's shortcut menu, click Advance agent.
  3. Select the options you want.
  4. If you select Peer download, you must make sure that the advance agent .msi file and the full agent configuration .exe package are in the software distribution cache of a device in the broadcast domain. If you select Peer download and don't do this before deploying the advance agent configuration, the deployment will fail because no cache or peer in the broadcast domain has the necessary files.
  5. If you'll be relocating the associated agent configuration package (the .exe file), change the path for the agent configuration package to match the new location.
  6. Click OK.
  7. If necessary, copy the associated .exe file from the LDLogon\AdvanceAgent folder to your distribution server. Make sure the path to the agent configuration executable matches the path you specified in the Advance agent configuration dialog. You should leave the MSI package on the core server in the default location. Otherwise, the package won't be visible for the advance agent push distribution task below.
To set up an advance agent push distribution
  1. In the Agent configuration window (Tools > Configuration > Agent configuration), click the Schedule a push of an advance agent configuration button.
  2. The Advance agent configurations dialog lists the agent configurations in the LDLogon\AdvanceAgent folder. Click the configuration you want to distribute and click OK.
  3. The Scheduled tasks window opens with the advance agent task you created selected. The task name is "Advance agent <your configuration name>".
  4. Add target devices to the task by dragging them from the network view and dropping them on the task in the Scheduled tasks window.
  5. From the task's shortcut menu, click Properties and schedule the task. You can see the MSI portion distribution progress in the Scheduled tasks window. There are no status updates on the full agent configuration once the MSI distribution completes.

Updating agent preferences on devices

If you want to update agent preferences on devices, such as requiring permission for remote control, you don't have to redeploy the entire agent configuration. You can make the changes you want in the Agent configuration window, and from that configuration's shortcut menu click Schedule update. This opens the Scheduled tasks window and creates an update task and package for the configuration you scheduled the update from. This package is only a few hundred kilobytes in size.

Updating preferences won't install or remove agents on a device. If the update contains preferences for agents that aren't on a device, the preferences that don't apply will be ignored.

IMPORTANT: Agent Watcher doesn't support preference changes through scheduled updates. If you want to change Agent Watcher preferences, right-click the device you want in the network view and click Update Agent Watcher settings.

To update agent preferences on devices
  1. Click Tools > Configuration > Agent configuration.
  2. Customize the configuration you want to use.
  3. When you're done, from the configuration's shortcut menu, click Schedule update to agent settings. This opens the Scheduled tasks window.
  4. Target the devices you want to update and schedule the task.

Creating standalone agent configuration packages

Normally the client configuration utility, wscfg32.exe, configures clients. If you want, you can have the Agent configuration window create a self-extracting single-file executable that installs an agent configuration on the device it's run on. This is helpful if you want to install agents from a CD or portable USB drive, or if you want to multicast an agent configuration.

To create a standalone agent configuration package
  1. Click Tools > Configuration > Agent configuration.
  2. Customize the configuration you want to use.
  3. When you're done, from the configuration's shortcut menu, click Create self-contained client installation package.
  4. Select the path where you want the package stored. Make sure the file name contains only ASCII characters (a-z, A-Z, 0-9).
  5. Wait for Management Suite to create the package. It may take a few minutes.

Agent security and trusted certificates

Management Suite 8 uses a certificate-based authentication model. Device agents authenticate to authorized core servers, preventing unauthorized cores from accessing clients. Each core server has a unique certificate and private key that Management Suite Setup creates when you first install the core or rollup core server.

These are the private key and certificate files:

An alternate method for getting the hash is to use the openssl application, which is stored in the \Program Files\LANDesk\Shared Files\Keys folder. It will display the hash associated with a certificate using the following command line:

openssl.exe x509 -in <keyname>.crt -hash -noout

All keys are stored on the core server in \Program Files\LANDesk\Shared Files\Keys. The <hash>.0 public key is also in the ldlogon folder and needs to be there by default. <keyname> is the certificate name you provided during Management Suite Setup. During Setup, it's helpful to provide a descriptive key name, such as the core server's name (or even its fully qualified name) as the key name (example: ldcore or This will make it easier to identify the certificate/private key files in a multi-core environment.

You should back up the contents of your core server's Keys folder in a safe, secure place. If for some reason you need to reinstall or replace your core server, you won't be able to manage that core server's devices until you add the original core's certificates to the new core, as described below.

Sharing keys among core servers

Devices will only communicate with core and rollup core servers for which they have a matching trusted certificate file. For example, let's say you have three core servers, managing 5,000 devices each. You also have a rollup core managing all 15,000 devices. Each core server will have its own certificate and private keys, and by default, the device agents you deploy from each core server will only talk to the core server from which the device software is deployed.

There are two main ways of sharing keys among core and rollup core servers:

  1. Distributing each core server trusted certificate (the <hash>.0 file) to devices and their respective core servers. This is the most secure way.
  2. Copying the private key and certificates to each core server. This doesn't require you to do anything to devices, but since you have to copy the private key, it exposes more risk.

In our example, if you want the rollup core and Web console to be able to manage devices from all three cores, you need to distribute the rollup core's trusted certificate (the <hash>.0) file to all devices, in addition to copying the same file to each core server's ldlogon folder. For more information, see the next section. Alternatively, you can copy the certificate/private key files from each of the three core servers to the rollup core. This way, each device can find the matching private key for its core server on the rollup core server. For more information, see Copying certificate/private key files among core servers.

If you want one core to be able to manage devices from another core, you can follow the same process, either distributing the trusted certificate to devices or copying the certificate/public key files among cores.

If you are copying certificates between standalone cores (not to a rollup core), there is an additional issue. A core won't be able to manage another core's devices unless it first has an inventory scan from those devices. One way of getting inventory scans to another core is to schedule an inventory scan job with a custom command line that forwards the scan to the new core. In a multiple core scenario, using a rollup core and the Web console is a simpler way to manage devices across cores. Rollup cores automatically get inventory scan data from all devices on the cores that get rolled up to it.

Distributing trusted certificates to devices

There are two ways you can deploy trusted certificates to devices:

  1. Deploy a device setup configuration that includes the core server trusted certificates you want.
  2. Use a software distribution job to directly copy the trusted certificate files you want to each device.

Each additional core server trusted certificate (<hash>.0) that you want devices to use must be copied to the core server's ldlogon folder. Once the trusted certificate is in this folder, you can select it within the device setup dialog's Common base agent page. Device setup copies keys to this folder on devices:

If you want to add a core server's certificate to a device, and you don't want to redeploy device agents through device setup, create a software distribution job that copies <hash>.0 to the folder specified above on the device. You can then use the Scheduled tasks window to deploy the certificate distribution script you created.

The following is an example of a custom script that can be used to copy a trusted certificate from the ldlogon folder of the core server to a device. To use this, replace "d960e680" with the hash value for the trusted certificate you want to deploy.

; Copy a trusted certificate from the ldlogon directory of the core server

; into the trusted certificate directory of the client


REMCOPY0=%DTMDIR%\ldlogon\d960e680.0, %TRUSTED_CERT_PATH%\d960e680.0

Copying certificate/private key files among core servers

An alternative to deploying certificates (<hash>.0) to devices is to copy certificate/private key sets among cores. Cores can contain multiple certificate/private key files. As long as a device can authenticate with one of the keys on a core, it can communicate with that core.

NOTE: When using certificate-based remote control, target devices must be in the core database
If you're using certificate-based remote control security with devices, you can only remote control devices that have an inventory record in the core database that you're connected to. Before contacting a node to launch remote control, the core looks in the database to ensure the requesting party has the right to view the device. If the device isn't in the database, the core denied the request.

To copy a certificate/private key set from once core server to another
  1. At the source core server, go to the \Program Files\LANDesk\Shared Files\Keys folder.
  2. Copy the source server's <keyname>.key, <keyname>.crt, and <hash>.0 files to a floppy disk or other secure place.
  3. At the destination core server, copy the files from the source core server to the same folder (\Program Files\LANDesk\Shared Files\Keys). The keys take effect immediately.

Care should be taken to make sure that the private key <keyname>.key is not compromised. The core server uses this file to authenticate devices, and any computer with the <keyname>.key file can perform remote executions and file transfer to a Management Suite device.

Agent configuration in mixed-language environments

When creating agent configurations in mixed-language environments, make sure the agent configuration name uses only ASCII characters (English character set). An English core server is compatible with all supported languages. However, if the agent configuration name uses a non-ASCII characters, such as Japanese, Chinese, or Russian, the agent configuration must be created on a core/console of that same language and will only work on devices using the same language. For example an agent configuration that includes Japanese characters must be created on a Japanese core, and must be deployed to a Japanese client.

Uninstalling device agents

Prior to Management Suite 8.5, anyone could uninstall Management Suite agents by running wscfg32.exe with the /u parameter. Since wscfg32.exe was in the LDLogon share, which managed devices could access, it was relatively easy for users to uninstall Management Suite agents.

With Management Suite 8.5 and later, the /u parameter has been removed from wscfg32.exe. There's a new utility called UninstallWinClient.exe in the LDMain share, which is the main ManagementSuite program folder. Only administrators have access to this share. This program uninstalls Management Suite or Server Manager agents on any device it runs on. You can move it to any folder you want or add it to a login script. It's a Windows application that runs silently (without displaying an interface).

Running this program won't remove a device from the core database. If you redeploy agents to a device that ran this program, it will be stored in the database as a new device.