Agent settings: Client connectivity
Tools > Configuration > Agent Settings > Client connectivity
Use the Client connectivity settings dialog box to specify and save a collection of client connectivity settings.
About the General page
Use the General page to name the client connectivity setting that you're configuring. You can have multiple profiles for client connectivity settings, but one must be set as the default for agent configurations. By selecting the Set as default option, the setting will be the default selection in the Agent Configuration tool.
About the Core information page
Use this page to configure certificate-based security and what scope devices using this configuration will have.
Core certificates the client will trust
Select the core server certificates you want devices to accept. Devices will only communicate with cores and consoles they have certificates for.
Below the trusted certificates box, you can modify the core server that devices using this agent configuration will communicate with. By default, this box contains the current core server. The core name can either be a Windows computer name, an IP address, or fully-qualified domain name. A fully-qualified domain name for a core may be necessary if you'll be pushing agent configurations to devices in multiple domains or anytime a device can't resolve the core name unless it is fully-qualified. Managed devices will use the information you enter here to communicate with the core server, so make sure the name you enter is resolvable from all devices that will receive this configuration.
The core name you enter here as part of an agent configuration is added to a device's registry under:
- HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Intel\LANDesk\LDWM\CoreServer
Once you've selected trusted certificates, and changed the core name if necessary, you can test them. When you click Test, a message box appears indicating whether the device name or IP address you entered was resolvable. Note that the Test button doesn't ping the device you entered or verify that the name or IP address belongs to a core server.
Core address
This needs to be a resolvable name or IP address that managed devices will use to communicate with the core server.
Location (scope)
If you want devices to be included in scopes that are based on custom directories, enter a directory path in the Path field. The path you enter here defines the device's computer location inventory attribute. Scopes are used by Endpoint Manager role-based administration to control user access to devices, and can be based on this custom directory path.
Custom directory paths use a format that's similar to a file path, but with forward slashes as separators. If you want to use custom directory-based scopes, first decide how you want to categorize your devices for role-based administration. You might categorize devices by geographic locale, department or group name, or any other organizational detail you prefer.
Directory paths you enter here as part of an agent configuration are added to a device's registry under:
- HKLM\Software\Intel\LANDesk\Inventory\ComputerLocation
You don't have to fill in this field. If you leave it blank, the device's computer location attribute is defined by its Active Directory or NetWare eDirectory path.
When the inventory scanner is run on a device, it records the device's computer location inventory attribute. If you entered a custom directory path in the Path field, that path is the directory the scanner records. If you left the custom directory path blank, the scanner tries to populate the computer location inventory attribute with the device's Active Directory or eDirectory path. If neither a custom directory path or an LDAP-compliant directory is found, the computer location attribute isn't defined. However, the device can still be accounted for in both query scopes and device group scopes.
For more information on how scopes are used in Endpoint Manager role-based administration, and how you can define a scope using custom directory paths, see Role-based administration overview.
About the Cloud Services Appliance page
The Cloud Services Appliance (CSA) page has the following features:
- Enable Cloud Services Appliance communication: Select this if you've installed one or more CSAs and you want an agent configuration to use the appliance to connect to the core server.
- Available items and Selected items: Lists the available and selected CSAs that you've configured for this core server. Select the one you want to use. There isn't a limit to the number of CSAs that you can add.
Use the CSA failover policy for CSA load balancing and to set what happens if there's a connection failure when a client tries to communicate with a CSA. When there's a connection failure, the client will try connecting to other CSAs in the Selected items list. When a CSA connection failure happens, the client won't try to use that CSA for 24 hours.
- Use ordered list as shown in the selected items: Clients will attempt to connect to the first CSA in the Selected items list. If that fails, clients will connect to the next CSA in the list until all CSAs have had a connection attempt.
Use this mode when one CSA is preferred over others for clients. For example, you may want devices for employees working in one country to use a CSA in that country as the top priority and some from other countries as backup systems. - Use random order: Clients will connect to a random CSA in the Selected items list. If that fails, clients connect to the next randomly selected CSA in the list until all CSAs have had a connection attempt.
Use this mode when there are several CSAs of equal preference to a client, but you want to spread the workload across these CSAs. For example, devices for employees in one country may have three CSAs set up for them to use. Using the random order selection would generally distribute the work load across these CSAs and still provide failover if one stops working.
When you have enabled Cloud Service Appliance communication, you have three ways to connect to the core:
- Dynamically determine connection route: This is the default and the most flexible choice. If the agent can connect directly, it will. If it can't connect directly, it tries to use the CSA. This mode may take a bit longer to connect since it tries each connection mode.
- Connect directly to the LDMS core: Always connects directly to the core.
- Connect using the Cloud Service Appliance: Always connects to the core via the CSA.
About the Download page
Use the Download page to block peer downloads over adapters that you specify. You can exclude adapters that are wireless. You can also exclude adapters by using case-sensitive keywords. If any of the keywords entered are found in the description field of the adapter, it will not use that adapter. As you can see by the default keywords, this method is used for disabling peer download over a VPN adapter.
You can also change the number of days files stay in the download cache on clients.
About the Preferred server page
Use the Preferred server page to control preferred server behavior:
- Update preferred server list from core every: Preferred server list update interval. This is the maximum amount of time a client will use the list of preferred servers before going to the core for a potentially new list. The default is once a day. The preferred server list is also discarded every time the IP address changes.
- Number of preferred servers to attempt before falling back to source: The default is three servers.
- Number of files not found on preferred server before the server is moved to the end of the preferred server priority list: The default is three files not found.
About the Self-electing subnet services page
Use the Self-electing subnet services pages to configure SESS. The recommended defaults for communication are allowing both multicast and broadcast. SESS will still work if one of these is disabled, but it may be slower.
- Enable self-electing subnet services: Whether SESS is enabled. Enabled by default.
- Allow multicast to join subnet: Allow SESS to use multicast communications. Enabled by default.
- Allow broadcast to join subnet: Allow SESS to use broadcast communications. Enabled by default.
- Report election status frequency: Controls how frequently elected service subnet representatives report to the core server and check to see if the elected subnet service has been enabled or disabled. If you enable or disable an electable subnet service, up to this amount of time may pass before the change takes effect. The default is 60 minutes.
About the Extended device discovery page
Use the Extended device discovery page to customize ARP and WAP extended device discovery scan settings.
Use address resolution protocol
- Duration ARP entry stats cached (in seconds): How long devices with the extended device discovery agent keep an address in the ARP table. Devices in the ARP cache won't be pinged after the initial discovery ping. The default is 24 hours (86,400 seconds). The minimum value is 900 seconds.
- Maximum delay before pinging an unknown device for the Ivanti agent (in seconds): When a new ARP is recognized by a device with the extended device discovery agent, the device waits two minutes for the detected device to boot and then waits a random amount of time within the value you specify here. The agent with the shortest random wait will ping first and then UDP broadcast to the subnet that it took care of the ping for that device. If you have multiple extended device discovery agents installed, this prevents devices from generating excess traffic by all pinging at the same time. If you set this too high, unmanaged devices may leave the network before they can be pinged. If you set this too low, multiple agents may ping and report the same device. The default is one hour (3,600 seconds).
- Frequency the cached ARP table is refreshed (in seconds): How often the device writes the ARP cache to disk so the data isn't lost in case the device shuts off, crashes, or reboots. The default value is five minutes (300 seconds).
- Logging level: The local extended device discovery logging level for errors (1), warnings (2), or everything (3). The default level is 1- errors only. Logs are stored locally in C:\Program Files\LANDesk\LDClient\xddclient.log.
- Force logging level: Overrides the log level setting from the core server. If you clear this option, you can set the log level manually on a particular device. This can be useful for troubleshooting a particular device without having to change the log level on all devices. This is enabled by default.
Use wireless access point discovery (WAP)
- Frequency of WAP scan (in seconds): Specifies how often the extended device discovery agent scans for WAP points.
- Logging level: The local extended device discovery logging level for errors (1), warnings (2), or everything (3). The default level is 1- errors only. Logs are stored locally in C:\Program Files\LANDesk\LDClient\xddclient.log.
- Force logging level: Overrides the log level setting from the core server. If you clear this option, you can set the log level manually on a particular device. This can be useful for troubleshooting a particular device without having to change the log level on all devices. This is enabled by default.
About the PXE page
Use this page to enable the PXE boot protocol. For more information, see PXE-based deployment.
About the Agentless scanner page
Use this page to enable the Agentless scanner. For more information, see Agentless inventory and vulnerability scanner.
About the Agent state page
Use this page to enable an agent state tracking representative on each subnet. This information is used when targeting devices in a scheduled task to make the process more efficient. The agent state representative tracks three possible agent states for devices on the subnet and reports to the core server:
- Offline and not available
- Online and available
- Unknown
Without an agent state representative, the core server instead has to ping devices individually to determine if a target is available, which is slower and generates more network traffic.
For more information, see this article on the Ivanti Community: Agent State Overview And Troubleshooting Information.
About the Network mapping page
Use this page to manage the network mapping settings. For more information, see Network map.
About the macOS Content Caching control page
Use this page to enable macOS Content Caching controllers. Content caching is an Apple technology that allows macOS devices to locally share software distributed by Apple, reducing internet bandwidth usage. Apple has more information about content caching here.
About the Local scheduler page
Use the Local scheduler page to configure how often the local scheduler checks for tasks and network bandwidth.
The local scheduler agent enables Endpoint Manager to launch device tasks based on a time of day or bandwidth availability. The local scheduler agent is most useful for mobile devices that may not always be on the network or may connect to the network via a dial-up connection. For example, you can use the local scheduler to allow mobile device package distribution only when those devices are on the WAN.
When you schedule software packages for distribution or when you create application policies, you can specify the minimum bandwidth the packages or policies require before they are applied.
The local scheduler runs as a service on Windows devices.
The Local scheduler page contains the following features:
- General frequency: How often the local scheduler checks for tasks. The default is 10 seconds. The polling interval you select is stored on the local device.
- Bandwidth detection frequency: How often the local scheduler should check bandwidth. The default is 120 seconds. Bandwidth checks happen only when there's a pending scheduled task.
The local scheduler also enables bandwidth detection between devices and the core server. You can limit Endpoint Manager actions such as software distribution based on available bandwidth. Use this option if you have remote devices or devices that connect to the network via a slow link.
- ICMP or PDS: Select whether to use ICMP or PDS for bandwidth detection. ICMP sends ICMP echo requests of varying sizes to the remote device and uses the round-trip time of these echo requests/responses to determine the approximate bandwidth. ICMP also distinguishes between LAN (high speed) and WAN (slow, but not dial-up connections). However, not all routers or devices support ICMP echo requests.
If your network isn't configured to allow ICMP echo requests, you can select PDS. The PDS bandwidth tests aren't as detailed, but they detect either a LAN or a low-bandwidth RAS (typically dial-up connection). The PDS method only works if the PDS service is running on the package server. You can install this service by deploying the standard Ivanti agent to the package server. - Bandwidth detection LAN threshold: The threshold that classifies a connection as WAN rather than LAN. The default is 262144 bps.