This document has been written to specify what versions of .NET are deployed with the various currently supported versions of the Ivanti Endpoint Manager Agent and what versions are "supported" with those Agent versions. This effort is being made to help reduce conflicts with installed software in customer environments.
| Agent Version | .NET Version Installed | .NET Version Supported |
| 9.6 - 9.6 SU1 | 4 | 4.5 |
9.6 SU2 - 2017.1 SU2 | 4.5 | 4.6.x |
| 2017.3 | 4.5 | 4.7.x |
To maintain compatibility with legacy operating systems, a special agent must be created from older code sources.
A LANDESK EPM agent compiled from the older LDMS code branches is what must be used to continue using Ivanti EPM on these legacy Operating Systems. The Whitepaper attached to this article describes how to build/configure the "Legacy Agent".
The LDMS 2016.3 release and later no longer support the installation of the agent on Windows XP and Server 2003 systems. Existing agents on Windows XP/2003 will continue to function, but new features will not be available. If you have a large number of Windows XP devices and need to continue installing agents, it is recommended that you use LDMS 2016.0 with SU5. An agent installation can be created and preserved from the previous version, or Windows XP machines can be managed by a previous version of LDMS until they are updated to operating systems supported by Microsoft®.
REFERENCE: https://community.ivanti.com/downloads/Readme/Pages/LD2016.3.html
To create the LANDESK Agent 2016.0 that is compatible with Windows XP and/or Windows Server 2003, please perform the following.
REG46=HKEY_LOCAL_MACHINE, SOFTWARE\LANDesk\ManagementSuite\WinClient\Vulscan\CommandLine, /NoSelfUpdate, , REG_SZ
* Download LDMS 2016.0 from here .
** Download Software Update 5 ( SU5 ) for LDMS 2016.0 from here.
Landesk Management Suite 2016 / version 10.0)is using a new service called "Self-electing subnet services" (SESS): Self-electing subnet services
Under some specific circumstances SESS service may cause very high CPU usage in client machines and servers, sometimes intensive multicast network traffic is experienced as well (even if you have not configured your Agents to use Multicast).
Such incorrect behaviour can be identified by checking your Task Manager or Process Manager - you will see Targeted Multicast Client Service Executable (tmcsvc.exe) generating CPU load.
Solution:
Please first check the agent configuration settings for distribution and patch as 'tmcsvc.exe' can be used in multicast and peer-to-peer deployment, so on the agent settings set up for the agent configurations of the clients, you can disable "Attempt peer download" and "Use Multicast" (this can be found in Agent settings -> Distribution and Patch settings -> General settings -> Network Settings).
It will update all the clients at the next daily vulnerability scan run on the clients where this settings is configured.
If the above settings are not used (configured) then SESS can be deactivated in the agent "Client Connectivity Settings" set up on the agent(s) deployed on the clients.
To do that, go to Tools -> Configuration -> Agent Settings and then click 'Client Connectivity' settings and open 'Self-electing subnet services' tab and uncheck box "Enable self-elect subnet service", click 'Save'.
At the next daily vulnerability scan, on each computer having this settings, it will deactivate this option (alternatively you can create a task to deploy updated agent settings to the clients).
Once this is done please check if the the CPU load from tmcsvc.exe has decreased on the agents.
Additional information:
You can also go in the Management Console -> Tools -> Configuration -> Self-electing subnet services -> Select Extended Device Discovery on both LAN/Wireless -> Right-click each subnet and select disable (by default SESS is disabled for wireless networks but enabled for wired networks).
Some additional information on this topic can be find here: Agent 2016 - Targeted Multicast Client Service Executable - tmcsvc.exe very high CPU on all clients/servers
Description:
This article describes the steps involved in completely removing a remote console, agent, and other settings from a remote device. The article will include standard methods for removal but it will also include steps to thoroughly check and manually remove services, files, drivers, etc that may be left behind when an application becomes corrupted. These steps may be necessary when experiencing difficulties installing an agent or remote console.
Step 1: Use the pre-designed removal applications.
Step 2: Manually Stop and Remove Services (if necessary)
Step 3: Delete files that may be left over.
Step 4: Delete registry keys that may be left over
Step 5: Check for the Remote Control Mirror Driver
Additional Notes: At this time it may be a good idea to remove/reinstall pre-requisites for the Remote Console as well.
The purpose of this document is to show you how to update an Ivanti Agent via Patch Manager.
1. Please create a new agent settings model and ensure that "Ivanti Updates" & "Enable auto fix" boxes at the level of Patch-Only settings > Scan options are both checked within.
2. Download the latest Ivanti Software Updates definition
3. Download the latest Patch: Patch and Compliance > Vulnerability > Ivanti Update > Scan > latest SU > double click > latest SU for client > right click > Download Path
4. Drag and drop the latest SU downloaded to Autofix (global)
This article covers the different ways to update an agents settings. Explanations of the differences between an agent setting and an agent configuration, and best practices for managing agent settings in your environment. This article assumes that you already have agents deployed to your endpoints and that you are looking to update or change configurations on those already deployed agents. This article does NOT cover best practices for updating configurations after installing a new SU. Please see the following document for best practices on updating agents after upgrading to a new SU: How to download and install Service Updates (SU).
An easy way to think about the difference between those 2 modules is to think of the Agent Configuration as a bucket and the Agent Settings as the contents or items you put into that bucket. When you schedule a change to a machines agent configuration, you are replacing the configuration with a new bucket and contents. When you change a devices agent setting, it is only changing some contents of the bucket. Use agent configurations to initially deploy or change installed Endpoint Manager components and use agent settings to modify how installed Endpoint Manager components operate.
Additional information on Agent Configuration can be found at the following link: Working with agent configurations
Endpoint Manager uses agent configurations that you create to deploy agents and agent preferences to managed devices. Once devices have the Endpoint Manager agents on them, you can use agent settings to easily update your agent configuration preferences without reinstalling the agent. However, there are some settings that cannot be updated with an agent settings update. Instead, you need to run an agent configuration update. I will go over what is modified with an agent configuration update and the steps to push that update to the client.
To view your current list of all of the agent configurations in your environment Select Tools > Configuration > Agent Configuration:
To view what agent configuration is currently assigned to a machine, open the devices inventory and navigate to the following section in the devices inventory:
There are some settings such as "Never Autofix" and "Never Reboot" that can only be updated with an agent configuration update:
Unfortunately there is not an easy out of the box way to view what a devices global autofix and global reboot settings are. This information is in the devices registry and is set to whatever the global settings of the agent configuration was when the agent was installed, or what the global settings were the last time an update to the devices agent configuration was done.
We can add a registry entry to be scanned when the machine does a scheduled inventory scan using the following document:
How to Verify and Update the Global Autofix and Reboot Settings to Existing Agents
I would highly recommend adding that custom data to your devices inventory so you can keep track of the global settings on the clients easily through queries.
Agent Settings control how Ivanti Endpoint Manager services and other components operate on managed devices. These components and their associated settings are deployed to your managed devices as part of the initial agent configuration. These settings can be changed/modified by a separate install or update tasks, and change settings tasks.
If a component is installed on a managed device, changes to that component's settings don't require redeployment of the whole agent. Settings are stored as XML files and the managed device only needs an updated XML file to reconfigure how an installed component operates. Changes to a component setting are propagated to all devices with that setting installed automatically.
To view your current list of all of the agent settings in your environment Select Tools > Configuration > Agent Settings:
To view what agent settings are currently assigned to a machine, open the devices inventory and navigate to the following section in the devices inventory:
Open the Agent Configuration tool in to the console. Right click on the Agent Configuration that you would like to push to a client and select "Schedule update to agent settings". Don't let the name "Agent Settings" fool you, that menu option really means, "Schedule Update To Agent Configuration".
This will create a scheduled task that you can add devices to. The task properties should look like the screenshot below:
You should not see any "Change Settings" options in this window. If you do, you scheduled a change settings task and that task will not change the agent configuration on the clients. Make sure you are right clicking an Agent Configuration (and not an agent setting!) when you create the update task.
Once you have the devices added to the task, start the task to have the agent update its configuration. Once it reports back a successful return code, you will need to run Vulscan for the machine to pull down the settings for that new agent configuration. This change will occur when the machine does its regular Vulscan scan. You can expedite this change by scheduling/running a Vulscan on that machine.
Open the Agent Setting tool in to the console. Click on the "Create a Task" icon and select "Change Settings...".
Once the scheduled task is created, right click the task and select properties. Here you can change what settings are applied to an agent's configuration. Click on "Keep Agent's Current Settings" to select a different configuration to push to that machine. You can use the Edit/Configure buttons in this window to modify and edit agent settings as well.
Once your task is configured how you would like, add the devices that you would like to change the settings on and start the task. The machines will run a vulscan /changesettings and pull down those new settings.
Here are some recommendations that can be followed to help keep your agent settings and configurations organized.
The suggestions below are based off of issues seen in customers environments and are not hardline requirements from Ivanti. Implement these standards at your own discretion.
After upgrading Windows 10 to the latest version, the Windows Defender Firewall is corrupt and unable to be configured. You may see the service starting and stopping.
When in this state, the Microsoft store applications (MSstore, calendar, mail, etc.) are unusable. The start menu is also unusable until after a reboot.
This is caused by softmon.exe and its' spyware blocking functionality configured while Windows is trying to upgrade.
The firewall should be running and manageable at that point, which should restore most other functionality.
Disable/uncheck the box for Real-Time Spyware Blocking: Tools>Configuration>Agent Settings>All Agent Settings>Security>Other Security Settings>Properties of settings used>Spyware>"Enable real-time spyware blocking"
Push out Change Settings task to update the Other Security Settings: Tools>Configuration>Agent Settings>Create a Task>Change Settings...
After the clients get this update, they should be ready to upgrade Windows 10.
This should work in LDMS 9.5 and 9.6. It is assumed you are running MS SQL and have something like SQL Server Management Studio to run queries.
When trying to delete an Agent Configuration, a warning occurs indicating it is currently scheduled. The Agent Configuration is unable to be deleted.
Old LDMS Agent can't be deleted because it is currently scheduled.
The Agent Configuration exists as part of a scheduled task. While it is associated with a scheduled task, it will be locked and unable to be deleted.
Locate the Scheduled Task and delete it.
If you are unable to locate the Scheduled Task that is associated with the Agent Configuration, the following SQL Query can be ran to get a list of Scheduled Tasks that are utilizing the Agent Configuration. Once the Scheduled Tasks are identified, they can be deleted to release the lock on the Agent Configuration.
Query to show all Scheduled Tasks that correspond with an Agent Configuration
select t.ld_task_idn, t.task_name,tc.ld_Task_config_idn,tc.cfg_name, cc.Name from LD_TASK t join LD_TASK_CONFIG tc on t.LD_TASK_CONFIG_IDN = tc.LD_TASK_CONFIG_IDN join ClientConfig cc on tc.CFG_NAME = 'AgentConfig ' + CAST(ClientConfig_idn as nvarchar)
Query to find Scheduled Tasks for a specific Agent Configuration. In this query replace <INSERT AGENT CONFIG NAME HERE> with the name of the Agent Configuration in desired.
select t.ld_task_idn, t.task_name,tc.ld_Task_config_idn,tc.cfg_name, cc.Name from LD_TASK t join LD_TASK_CONFIG tc on t.LD_TASK_CONFIG_IDN = tc.LD_TASK_CONFIG_IDN join ClientConfig cc on tc.CFG_NAME = 'AgentConfig ' + CAST(ClientConfig_idn as nvarchar) where tc.cfg_name like ( select '%' + CAST(ClientConfig_idn as varchar) + '%' from ClientConfig where name like '%<INSERT AGENT CONFIG NAME HERE>%' )
Example: This example shows the query looking for any Scheduled Tasks for our 'Old LDMS Agent' configuration, and shows it is in use by the Scheduled Task called 'Deploy the 2007 Agent'.
The LANDesk Local Scheduler is a very powerful client-side component that is very popular and sees wide usage.
Yet at the same time, it is one of the most easily misunderstood components of the LANDesk Management Suite. The effects of such misunderstanding can range from being a negligible matter to being of serious impact indeed. Not to make too fine a point out of it - it is theoretically possible to configure your tasks in such a way as to ensure that they will never – EVER – run. Or, respectively, run without end.
With the Local Scheduler being such a powerful tool, informed caution is well advised. However, the focus here is not in cautioning, rather it is to inform, to educate.
This article aims to clarify one of the most commonly misunderstood processes of the Local Scheduler, and bring to attention the importance of using time-filter constraints – particularly in bandwidth/timing-sensitive environments.
That frequently misunderstood process is the timing and repetition of tasks.
There are primarily two ways to read data concerning Local Scheduler tasks.
The first (covered in II.A) is centrally – on the Core, as part of a clients’ inventory. The second (covered in II.B) is to generate an output-file locally on the client itself which can then be read in your text-editor of choice.
Both are quite viable. Both are demonstrated here, as certain situations may call for one (or the other) to be more convenient or more effective when querying a client directly.
For several versions now, LANDesk has been reporting all Local Scheduler tasks into inventory, and this information (individual to each locally scheduled task) can be found in any devices’ inventory as shown in the screenshot below.
In the screenshot below, the *RED* section serves to guide where in inventory this information can be found, whilst the *BLUE* square indicates the properties/details of that particular local scheduler task.
The meaning of the various task details will be discussed and clarified further below (in section II.C - HERE ).
NOTE: To get an output of local scheduler tasks into a text file run the following from the LDCLIENT-directory (By default – "C:\Program Files\LANDesk\LDClient\" or - for 64-bit systems - "C:\Program Files(x86)\LANDesk\LDClient\" ).
Localsch.exe /tasks >mytasks.txt
Some parts of a Local Scheduler task may be more intuitive than others – as a result, I will go through the various sections, and have highlighted the crucial bits of information in colour-code so as to match the screenshot presented in II.B.
This is simply a “complete” Local Scheduler task entry from beginning to end. In the output-file, the separation can be simply done by the listed number in the first space of an entry.
This is a unique identifier for a task, which is used when a particular task needs to be deleted or modified, for example.
Certain task ID’s are treated as reserved (and task ID below 1,500 should be regarded as reserved), with “normal” user-generated tasks usually having six digit handles (so as to better separate them from “reserved” tasks).
One of the reasons we start with such high, six-digit numbers is to prevent any problems with legacy clients, where smaller numbers were used.
The task Frequency is based on the number of seconds between repetitions of a task. Most tasks have a value of either 3600 (1 hour) or 86400 (1 day) as a frequency, but any sensible positive value is acceptable.
IMPORTANT NOTE– don’t panic when you see a frequency of “1” in the screenshot above. That particular task has got an additional filter (see below) that activates the task only when the IP-address changes.
Task Filters are additional conditional clauses you can attach to a task to give you more control under which conditions a task is run. Most commonly this is a filter based on the time of day (i.e.: “only run between the hours of 01:00 – 04:00).
It is important to point out here that filters are purely based on the CLIENT’S perception of things – i.e. its own local system clock, and so on.
Additional filters such as “on IP change” or “when no user is logged on” are also popular, and for a full list, I would recommend that you go through the Local Scheduler task UI (In “Manage Scripts”, you can create Local Scheduler tasks) to get a taste for what is possible. The screenshot below should hopefully help with any remaining confusion on where this is.
Note:ALL filters must be true for a task to run. There’s a distinct AND logic here, and a task will not run until ALL filters’ conditions are satisfied.
Therefore, be thoughtful when applying filters. Ask yourself if this is what you truly want, what you truly need – it’s a simple enough thing to misconfigure oneself and end up in an undesired state.
Local Scheduler will do EXACLY as it is configured to by you, not necessarily as you intended!
Since a task will ONLY trigger when ALL of its filters are true, let’s demonstrate how one can use filters badly, so as to never have a task running.
If you were to configure a task to run between 02:00 and 04:00 in the morning, and have an additional filter that REQUIRES a user to be logged in but this ends up being a condition that is never met (as people may not work in such late/early hours), you would end up with a task that never runs.
The most common misconception in relation to Local Scheduler is that the frequency of a task is based upon its START-time. In other words. – if a task is set to start at 10:00 on day 1, the expectation is that it will always start at 10:00, assuming a frequency of 1 day (86,400 seconds) is used.
Little could be further from the truth!
In fact, the frequency kicks in based on when a task has last FINISHED! So - if a task starts at 10:00, then has a 15 minute long random delay (10:00 => 10:15) and a 10 minute long runtime (10:15 => 10:25), the 1-day delay will apply to the end-time of 10:25.
This “time creep” is something of which you should be aware, as this will inevitably send tasks spiralling throughout all possible times. This is particularly likely if you’re combining long-running tasks with large, random time windows.
The best way to counter-act this is by confining tasks to run in a certain time-window. This shouldn’t be used too narrowly, as a long-running task with a narrow time window will cause loss of days very quickly.
As an example, the following table shows what can happen to a task with the following settings:
• Task must run between 10:00 and 11:00
• Task has a random delay of 0-60 minutes
• Task has a runtime average of 10 minutes
| Running Day # | Start Time | Random Delay | Duration | End Time | Next Effective Start |
|---|---|---|---|---|---|
| Day 1 (Start of the task) | 10:00 | 15 mins (Runs at 10:15) | 10 mins | 10:25 | Day 2 - 10:25 |
| Day 2 | 10:25 | 27 mins (Runs at 10:52) | 10 mins | 11:02 | Day 4 - 10:00 |
| Day 3 | 11:02 ** N/A | --- | --- | --- | Day 4 - 10:00 |
| Day 4 | 10:00 | 40 mins (Runs at 10:40) | 10 mins | 10:50 | Day 5 - 10:50 |
| Day 5 | 10:50 | 35 mins (Runs at 11:25) | 10 mins | 11:35 | Day 7 - 10:00 |
| Day 6 | 11:25 ** N/A | --- | --- | --- | Day 7 - 10:00 |
** Notice that we do NOT run the task on day 3, nor on day 6.
This is because 11:02 (Day 3) // 11:25 (Day 6) is ‘outside’ the TOD (Time Of Day) filter set to run the task between 10:00 and 11:00. What happens now is that whilst the task is “active”, we check every 20 seconds (default) to see if the filters are all OK. In other words, we wait until 10:00 am the next day to run/start it again.
* A task is deemed to have started as soon as its random delay kicks in. It doesn’t matter if the random delay pushes the task outside the time-constraint boundary (such as 11:25 for instance, in the above example, on day # 5). The task STARTED in the acceptable time-boundary, and the random delay is not deemed a factor here.
* A task that will END outside of the acceptable time-frame (such as 11:02, as on day # 2 in the above example), will still be checked on the next day for running conditions. However, since – in the above examples – there’s a constraint for a task to run from 10:00 to 11:00, the task will idle with the Local Scheduler continuously checking whether all filters can be satisfied.
* In this example, this is true on day # 4 at 10:00, since the task “started” (but was not LAUNCHED) on day 3 at 11:02 as the 10:00 – 11:00 filter was not satisfied … so the task was continuously active for just under 23:00 hours for all filters to be satisfied and finally being successfully launched.
* It is for this reason that one should be mindful not to use too many filters for a single task. The more filters that are used, the more conditions need to be simultaneously met, thus increasing the chances that one ends up with a task that will never run because all of the filter conditions CANNOT ever be all true at the same time.
With the information provided in this article, the reader should be more informed about some key points when using the Local Scheduler. It should be clear why task filters should be used with care, and why particularly the “Time Of Day”-filter is an important utility in overcoming the time-creep issue.
| Return Code | Status | Result | Meaning | Related Articles |
|---|---|---|---|---|
0 | Not Specified | |||
| 2 | Failed | The system cannot find the file specified. | ||
| 401 | Failed | Failed: Another instance of the agent is running. | ||
| 424 | Agent cancelled by user. | This is a confirmed defect for LDMS 9.0 SP2 | Re: 'Agent Cancelled by User' - Return code 424 | |
| 457 | Done | Removing LANDESK HIPS succeeded. | ||
| 458 | Failed | Removing LANDESK HIPS failed. | ||
| 1026 | Problem remotely executing the agent For Mac verify credentials. Check raxfer.log for errors ssh to the machine | |||
| 1074 | Active | Distributing package… | Deployment in progress. | |
| 1076 | selected delivery method and /or packages require features that are not provided by the agent installed on this target | |||
| 1081 | Failed | An error occurred while copying the agent software. | Drive full/lack of space on client IPCheck Fails (nslookup, if IP's do not match, ipconfig /registerdns on client) | |
| 1082 | Active | The agent software was copied. | Deployment in progress. | |
| 1083 | Failed | The agent setup program returned an error. | Failure during the install, search wscfg32.xlg for FAILED | |
| 1084 | The agent setup program ran successfully. | Deployment in progress. | ||
| 1086 | The agent setup succeeded and is now rebooting. | Deployment in progress. | ||
| 1087 | Failed | Unable to contact the specified machine. The machine may be off or unreachable. | The user account for the LANDESK Scheduler service does not have administrator rights on the client computers | Agent Deployment Results in error: "Unable to contact the specified machine" 1087 |
| 1110 | Off/Failed | Cannot find agent. Task should still be active | Device offline or is not accessible via the network. No agent currently installed. Task should still be active | |
| 1165 | Failed | The agent setup program started but communication is lost. | ||
| 1166 | Done | Success, reboot required. | Deployment in progress. | |
| 1205 | Failed | Could not copy to/from client | No admin rights to copy/install | |
| 1208 | Failed | An internal error occurred | LANDESK Scheduler Service login does not have admin rights on the destination device | |
| 1352 | Active | Machine was successfully discovered. | Deployment in progress. | |
| 1895 | Failed | CBA 8, the connection was not authorized. | refusing authorization to store unknown host-key | Agent Return Code 1895, CBA 8 The connection was not authorized. |
| 18946 | Failed | unable to create tmp file | To resolve the issue, deleted the files in the following temporary directories: 1. \Windows\temp 2. \Users\<user account for scheduler service>\AppData\Local\Temp | |
| 18945 | Failed | Failed to build the agent installation package. | Failure opening file to be stored in cabinet |
While deploying the Advance Agent MSI file via a GPO, the LANDesk Agent does not install. However, if the EXE file is started manually the installation succeeds.
Within the AdvanceAgent.log in the windows\temp directory, there are lines with “Attempting to download file” and “returned 80004005”.
Installing the AdvanceAgent via the MSI file is a two phase process. First the MSI installs an AdvanceAgent Service which then tries to pull the full installation (aka the EXE) and the starts the EXE do fulfil the installation.
The 80004005 means “Access Denied” to the share where the EXE file is located. But checking the permissions on the share shows that “everyone” does have read access.
The AdvanceAgent Service is running as “local system account”. So the Access to the server share is denied.
To solve this, “domain computers” have to be added to the permissions of the share to have read access. Now the AdvanceAgent Service should be able to pull the EXE and finish the installation of the agent.
Problem
While installing the LANDesk agent, the installation process fails while installing the LANDesk Power Management component. The installation halts while executing the ClientSideEnableWOL.vbs script.
Cause
Corrupted Windows Management Instrumentation (WMI) engine on the target machine.
Resolution
The script in question (ClientSideEnableWOL.vbs) leverages the WMI technology to enable necessary settings on the target machine. Follow these steps in order to repair WMI:
1) Download Microsoft's WMIDiag utility from this location: http://www.microsoft.com/download/en/details.aspx?id=7684
2) Execute the WMIDiag utility on the affected machine
3) Attempt to install the LANDesk Agent once again.
Applies To
LANDesk Management Suite 8.8
LANDesk Management Suite 9.0
This document contains the agent configuration and agent deployment best practices LDMS 9.0
The following is a list of Services and Executables run on the 9.0 SP2 LANDESK Agent.
SERVICES
LANDESK Message Service
LTAClientEnforcer
LANDESK Ping Discovery Service
LANDESK Remote Control Service
LANDESK Targeted Multicast
LANDESK (R) PXE MTFTP Service
LANDESK (R) PXE Service
LANDESK Policy Invoker
LANDESK (R) Antivirus
LANDESK (R) Management Agent
LANDESK (R) Software Monitoring Service
EXE
C:\WINDOWS\system32\msgsys.exe
C:\WINDOWS\system32\cba\pds.exe
C:\Program Files\LANDESK\LDClient\issuser.exe
C:\Program Files\LANDESK\PXE\System\PXEMTFTP.exe
C:\Program Files\LANDESK\PXE\System\PXESvc.exe
C:\Program Files\LANDESK\LDClient\LTAClientEnforcer.exe
C:\Program Files\LANDESK\LDClient\ActiveNotifyer.exe
Description: If it is determined that a local scheduler task should be removed from client computers it can be done through a script run as a scheduled task in the LANDesk Management Suite 32 bit console.
Resolution:
Create a Query
1) In the 32 bit console right click on My queries and click New Query
2) Under Machine Components go to Computer | Device Name
3) Click Exists and click Insert
4) Click the button labeled Select Columns
5) Under Machine Components go to Computer | LANDesk Management | Local Scheduler | Scheduled Tasks
6) Click on Handle and click the button labeled >>
7) Click on Executable Path and click the button labeled >>
Cause
Locate the Computer Inventory Record from all devices and delete it. Then rerun the UDD Scan
The computer has a entry in Pending Unmanaged Client Deployments.
From the Network View | Configuration | Pending unmanaged client Deployment, delete the Computer record. Then Rerun the UDD Scan.
The cba_anonymous account is created by ServiceHost.exe which is run under the the LANDESK Management Agent (CBA) service whenever an anonymous connection is requested. It is created as a member of the local machines Guest group.
**In the 2016.3 SU3 and 2017.1 release, CBA_anonymous has changed and no longer creates a cba_anonymous account. We have started using local account and GPO/permissions are no longer needed. The account can be deleted and will not be added when the new agent is installed.**
Q. How does LANDESK manage client access?
A. When a connection is made to CBA, the account will be created to provide the connection with guest account rights. You can manually make this request on the client by opening a web browser, then hitting url http://localhost:9595/allowed/ldping.
Q. Who creates the password and where does it get stored?
A. The password used by the account is randomly generated and stored securely in memory only. The generated password consists of multiple random generated sections using OpenSSL to meet even the most stringent password complexity requirements. Since the password is stored ONLY in memory it will be regenerated on reboot, service restart(then additional request), or if the current session has expired. The password will include at least the following: Upper Case, Lower Case, Number, Special character, and a length of at least 28 characters.
Q. Is there a way to remove the cba_annoymous account after an install and a log off?
A. The account is used with a randomly generated password for CBA communication. If the account is removed it will be recreated when needed by ServiceHost.exe.
Q. Is this account created on all Windows Operating Systems?
A. All Windows NT based Operating Systems use this account.
Q. Is this account created as a domain account?
A. No. cba_anonymous is a local account. The only time it will appear as a domain account is if the LANDESK agent is installed on a Domain Controller. Currently this is a supported configuration and should work. If you're having problems getting it to install, please open a case with support.
Q. Can I disable the cba_anonymous account?
A. No. The LANDESK core server calls cba_anonymous to do an LDping function on the client web service to verify the client prior to executing any functions on the remote agent. The LDping returns the host name and LANDESK Device ID. These are verified prior to the execution of a task on a managed node by the core server using the cba_anonymous account. Without this information, you will not be able to manage any machines as they will appear to be “off” since they can’t be discovered.
Tools > Configuration > Agent settings> Adaptivesettings
An adaptive setting is a list of one or more adaptivesettings rules ordered by priority. In the adaptivesettings agent configuration, you can select multiple rules from a list of available rules. The agent on the managed device will check the triggers for each rule in the selected rules list, starting at the top. The first rule the agent encounters with a matching trigger will be applied and rule processing stops. Only one rule can be active at a time. If no rules are triggered, the default settings specified in the agent configuration page will be applied.
Adaptivesettings allow agent settings to dynamically change on a device based on location (geofencing) or IP address. This is mainly oriented towards mobile devices and laptops. For example, you could have one set of agent settings while a device is connected to the corporate network, but when the device connects to an external network, the agent settings could be more restrictive.
For more information, see Adaptivesettings.
NOTE: Enabling adaptivesettings will cause .NET 4 to be installed with the agent.
The Adaptivesettings dialog box contains the following options:
Clicking New or Edit in the Adaptivesettings dialog box shows the Edit adaptive setting rule dialog box. An adaptivesettings rule associates a trigger with one or more agent settings to override when the trigger activates, along with additional one-time actions, such as locking the screen. For more information, see Adaptivesettings.
The Edit adaptive setting rule dialog box contains the following options:
The Edit trigger dialog box contains the following options:
In order for this service to be installed the Adaptive settings checkbox in the Agent Configuration must be selected. If this is not selected in the Agent Configuration the Adaptive Settings sent to a device will not be functional.
The LANDESK Adaptive settings are controlled on the client by the "LANDESK Adaptive Settings Service" service.
This executable related to this service is "C:\Program Files (x86)\LANDesk\LANDesk.PolicyUpdater.exe
Creating the following registry key on the client will enable debug logging
SYSTEM\CurrentControlSet\Services\LDPolicyUpdaterSvc Debug (DWORD) 1
Debug logging will be created in this format: C:\ProgramData\LANDesk\LANDesk.PolicyUpdater-2019-01-04-054736.log
This shows the date and time that the "LANDESK Adaptive Settings Service" started.
2019-01-04 05:56:14 [4252:12] [NOTICE] Network change detected - Current IP addresses:
2019-01-04 05:56:50 [4252:9] [NOTICE] Network change detected - Current IP addresses: [192.168.244.128]
2019-01-04 05:56:50 [4252:9] [NOTICE] test net 244: executing: C:\Program Files (x86)\LANDesk\LDClient\Vulscan.exe /changesettings
Ivanti has identified an issue affecting a very small number of customers who upgrade to 2017.3 SU5. In some cases the agent upgrade process encounters an error related to the resident agent that leaves the upgrade in a failed state and leaves the agent unresponsive.
Engineering is aware of this issue and is actively working on a code fix. In addition, there is a workaround:
It is important to consider that this issue is only affecting a very small number of customers. As you test the agent installer during pilot if you encounter the issue please use the workaround above. You may also contact support and reference bug ID# 473782. This thread will be updated when the issue is resolved.
UPDATE if you are affected by this issue please open a support ticket and ask your case owner to escalate as an automated work around is available on a case by case basis.
