I recently setup a new 2016 LANDesk server and installed the Management console. We also created a new SQL database. We currently have now in place an older 9.5 server with a SQL database. After setting up the 2016 server I proceeded to run the unmanaged device wizard on my test group of pc's. Problem is that they have the 9.5 agent on them and I was wondering if this is the reason the 2016 server will not see them in the unmanaged device wizard and will I have to uninstall the 9.5 agent before I install the new 9.6 agent or am I missing something with the wizard.
New 2016 LANDESK Management and Security installation
LANDesk(R) Extended device discovery service (LDXDD) start with interactive right
Hi all,
Do you know if "LANDesk(R) Extended device discovery service" nead really to be started with "Interact with destop" right?
For some reason, this is not allowed in company and many alerts is generated.
Do you know if it's possible to disable this option without any issue with this fonctionnality?
Thank's by advance,
Regards,
Thomas.
Only Extended device Discovery showing under Client Connectivity Settings/Self-electing Subnet Services
Our core was updated to 2016.3su5 and under the new Self-electing Subnet Service section of the Client Connectivity settings only Extended device discovery is listed.
How do we get the other options to show for configuration via the agent?
David
Agent Watcher Information
Description
The purpose of this document is to provide information on the Agent Watcher. The Agent Watcher allows you to actively monitor devices for selected Ivanti agent services and files. The Agent Watcher restarts agent services that may have been stopped and resets the startup types for services that have been set to automatic. The utility also removes monitored agent files from lists of files to be deleted on reboot, in order to prevent deletion. Additionally, Agent Watcher alerts you when agent services can't be restarted, when agent files have been deleted, and when agent files are scheduled to be deleted on reboot.
You can enable the Agent Watcher within the agent configuration or, at a later time, with a separate Update Agent Settings task. In other words, you don't have to enable Agent Watcher during a device's initial configuration. It can be done at any time directly from the console for one or more managed devices
The Agent Watcher runs under the collector framework on client systems. This agent piece, LDRegWatch.exe is run by collector.exe as needed to let it monitor the system. LDRegWatch will periodically update its copy of the configuration settings stored in its corresponding INI files (e.g. “AgentWatcherSettings_Agent Watcher Settings 1.ini”). It then verifies that what the settings are, are properly applied to the system (i.e. start services and update files). The following depicts the general architecture of the Agent Watcher process:
Port Information
LDregwatch, by default, will use port(s) 53000/53001 as seen within the LDCLIENT\landesk.provider.ldms.collector.startup.xml file. These ports will need to be open on your network to utilize this feature.
在win10装代理与服务器通信不正常(MAC终端上跑win10虚拟机)
在win10装代理与服务器通信不正常(MAC终端上跑win10虚拟机)
Inventory failed to send to console - Linux Agent - CentOS 7 x64
Target : Virtual Machine running CentOS 7 x64 with Internet Access
Direct access to the Core Server (IP and FQDN OK)
- Installation method :
sudo -i cd /tmp && wget http://coreserverip/ldlogon/unix/nixconfig.sh sh nixconfig.sh -i Core_Server_FQDNl -i all -p
- Output
all goods (dependencies, download tgz, etc.) but ath the end :
Launching initial inventory scan. terminate called after throwing an instance of 'std::out_of_range' what(): basic_string::substr FAIL - /opt/landesk/bin/plugin: [0xb00006e] Inventory failed to send to console. :27:56 CET 2018: Warning: Initial inventory failed to complete. :27:56 CET 2018: Attempting initial launch of vulnerability scan as background process. :27:56 CET 2018: Initial vulnerability scan launched successfully. :27:56 CET 2018: nixconfig.sh done.
Trying to launch manually with no luck :
- Inventory
/opt/landesk/bin/inventory -c /opt/landesk/etc/inventory.conf terminate called after throwing an instance of 'std::out_of_range' what(): basic_string::substr FAIL - /opt/landesk/bin/plugin: [0xb00006e] Inventory failed to send to console.
- Vulscan
/opt/landesk/bin/vulscan -c /opt/landesk/etc/vulnerability.conf terminate called after throwing an instance of 'std::out_of_range' what(): basic_string::substr
The device does not show up on Inventory.
Tests on Ubuntu will be done tomorrow.
Any help ?
TIA.
Mac Agent Deployment Fails with Error 1083 after Upgrading to 2017.3 SU1
Title pretty much explains it all. We upgraded from EPM 2017.1 to EPM 2017.3 SU1 and when I schedule a Mac agent push it fails. The return code is 1083 and result "The agent setup program returned an error." I am able to successfully push out the Windows agent, just not the Mac agent. I have double checked to make sure that I have an account from the Mac in the scheduler service alternate credentials.
Not sure where to go from here, any input would be helpful.
Enhanced Vulscan Self-Update Feature
Enhanced Vulscan Self-Update Feature
In LDMS version 2016.3 and later releases, the Self-Update feature that runs during vulnerability scans has been enhanced to grant additional capability and flexibility.
Vulscan Self-Update
In version 2016.0 SU5 and older, vulscan checks the ldlogon folder to see if any of the core-side self-update files are newer than those same files found on the client. If so, those files would get updated regardless of OS version and LDMS agent version. In version 2016.3 and later, the self-updating process is smarter and vulscan includes the option to check for a minimum OS version and/or a minimum LDMS agent version if configured to do so. If the core is not so configured, then self update will occur as usual.
The main benefit to this new system is that you can cause vulscan self-update to use one set of files for devices that meet or exceed your OS and Agent version specifications, and a different set of self-update files for devices that are below your specifications. This is most helpful if you are still managing Windows XP or Server 2003 devices.
Support for Windows XP and Server 2003 has ended. See these documents for more information:
About the Ivanti support program for Windows XP and Server 2003 patch content
How to support Windows XP in your environment after upgrading to LDMS 2016.3 or greater
Which Files Are Updated?
The following files are monitored and can be updated:
- LDReboot.dll
- ldavhlpr.dll
- ldReboot.exe
- LDSystemEventCapture.dll
- localsch.exe
- ltapi.dll
- RollingLog.dll
- sendtaskstatus.exe
- softmon.exe
- softmon.sig
- vbscript.v55
- vulscan.exe
- vulscan.sig
Initial Setup and Configuration
If you wish to implement OS and Agent version checking for self-update, create a SelfUpdate subfolder in ldlogon and create an AppliesTo.ini folder within:
The appliesto.ini folder should have the following text:
[Requirements]
MinAgentVersion=10.1
MinOSVersion=6.1
In the example above it is configured for LDMS agent version 10.1 and OS version 6.1 (Windows 7) and is appropriate for the scenario of preventing XP devices from self-updating to the new agent version. However you should change this to correspond to the actual versions you want to use if you have a different use case.
How it Works
When vulscan runs on a client, it will check with the core server to see if ldlogon\selfupdate folder exists and contains the appliesto.ini folder. If found, vulscan will use the enhanced process and will use the files in the Self-Update folder for devices meeting or exceeding the versions specified. Devices not meeting the agent and OS versions will self update from the ldlogon folder. If the self-update folder or the appliesto.ini file are not found, vulscan will self-update all devices from the ldlogon folder.
Therefore, place the self-update files from your LDMS 2016.0 SU5 WinXP agent into the ldlogon folder, and place the updated files that match your upgraded core version into the self-update folder. This will cause XP devices to retain self-healing properties through vulscan self-update, but use only the correct files for it's agent version of 2016.0 SU5. Devices newer than XP will self-update using the correct and proper files that you have placed into the self-update folder.
What credentials does installing an agent use
I'm running 2016.3 no patches
When I try to push out a updated Agent I am getting a lot of failures. So I made a batch file to run the self-contained agent with domain admin credentials and I have better luck with it,
More then half the computers are logged in as power users and fail the conventional agent push. so I'm assuming the Normal agent push is trying to use local system credentials is trying to access a remote share.
1. Is there a way to change what credentials the agent runs under?
create agent for workgroups
Have current windows agent defined for domain.
Need help creating an additional windows agent that I can push to "workgroup" computers that do not authenticate to the domain.
Agent push fails if no one is logged in
I'm running Landesk 2016.3
I keep getting a agent push fail if there is no user logged in. I don't think this happened when I was on 9.6.
Is this a bug?
Advance Agent install process and troubleshooting tips
Advance Agent Creation
Two files are created when and Advance agent is created on the core server.
- <advance agent name>.msi
- This is a ~1 MB MSI package. When this package runs on a device it installs the LANDESK® Advance agent service. The Advance agent service downloads the associated full agent configuration package and initiates the install.
- <advance agent name>.exe
- This is the real agent installation file and it will call wscfg32.exe to install the LANDESK agent.
When creating an Advance agent, the dialog prompts for a path and a name for the Advance agent configuration. The path and name of the agent configuration are coded into the MSI along with the hash value of the EXE. The Advance agent service will use the name and hash to determine the package to download and install. In the Advance agent configuration window bandwidth-friendly distribution options can also be configured. All settings configured in the Advance Agent dialog are included in the Advance agent MSI and are used by the Advance agent service after the MSI is installed.
Deploying the Advance Agent
The Advance agent can be deployed a few different ways. One is to create an advance agent push job from the LANDESK Management Suite Console. This job can be created from the Scheduled Tasks pane.
Deployment Steps
- When the Advance Agent Push scheduled task is started from the core server, the LANDESK scheduler service will create $LDDIR$ folder under C drive on the client and will copy AdvanceAgent.msi to this folder.
- Msiexec.exe will run this AdvanceAgent.msi. This will create C:\Program Files\LANDESK\LDClient folder and will install AdvanceAgent.exe and other files to this folder.
- AdvanceAgent.msi will install the advance agent registry keys,install the advance agent service, install the files to C:\Program Files\LANDESK\LDClient folder, open the firewall policy for AdvanceAgent.exe and so on. And the AdvanceAgent.exe will download <advance agent name>.exe
Note: An AdvanceAgent.log for this particular step will be created on C:\Windows\TEMP\ folder. - AdvanceAgent.exe will create a service called "LANDESK Advance Agent". This service will create C:\Program Files\LANDESK\LDClient\sdmcache\ldlogon\AdvanceAgent folder and download <advance agent name>.exe to this folder.
Note: Another AdvanceAgent.log will be created for this step under C:\Program Files\LANDESK\LDClient folder. This log file will log the download process. - After the <advance agent name>.exe is downloaded to the client machine, Explorer.exe will execute the file, then wscfg32.exe will install the agent.
Troubleshooting
There are two logs on the core that may be useful for troubleshooting advanced agents that fail coreside:
- \Program Files\LANDesk\ManagementSuite\log\core.secure.dll.log
- \Program Files\LANDesk\ManagementSuite\ldlogon\AdvancedAgent\(((AgentConfigurationName)))).exe.log
There are two log files on the client machine for advance agent deployment:
- AdvanceAgent.log under C:\WINDOWS\TEMP folder, this is the log file for advanceagent.msi. After the deployment, this log will not be deleted.
- AdvanceAgent.log under C:\Program Files\LANDESK\LDClient folder, this is the log file for LANDESK Advance Agent service, this will log the download of the EXE file. After the EXE file is downloaded successfully, this log file will be deleted. But if the EXE file is not downloaded successfully, the log file will be there.
Here is a screenshot of these files:
I have the process monitor capture file, IF anyone is interested in researching this, I can offer the file(It's huge, about 400mb, so I can't attach it in this article)
I also attached the AdvanceAgent.log file under C:\WINDOWS\TEMP folder for an example.
Standard Agent Push Failure
I'm running Landesk 2016.3
Just upgraded to 2016.3 and was trying to get all my clients agents updated. Thought I would put down some of the problems I ran into.
1. After pushing out several 1000 scheduled agent push about 30% of my clients failed. What I've done to fix it is go to Windows\temp, delete anything related to landesk and also any .tmp files, plus a $ldtmp$ folder. Then run again, I got 100% success.
2. Tried running a scheduled Advanced Agent on 300 computers. 80% failed and removed the management agent leaving the remote service still running. Now I think I'm screwed as no push will go to client with management agent missing.
I set up PSEXEC to run a bat file remotely to the client to run the cb8inst.msi from the remote computers ldclient folder, this reinstalls the management agent service. However the in the shared files\cbaroot\certs folder it does not put back the certificates so a inventory will not run. I copy the certs from my computer over to the remote computers certs folder. So now the computer is communicating to the console again. I go into the windows temp folder and do #1 above then scheduled a agent push and all is updated.
This is not a question just thought it might help others.
Agentless Scanner Criteria
I'm running 2016.3
Just upgraded to 2016.3 and trying to upgrade my clients with a new agent. I noticed in the Network View under Agentless I have a bunch of computers listed.
Some after checking C drive program files or program files (x86) have a full new agent install and others are missing files in the shared files folder.
The ones that seem to have a full newest agent installed, if I try to do a inventory scan, it pops up a message " 1 agentless devices have been marked for an inventory scan in the upcoming scan cycle" My scan cycle should be when a user logs in after 1 hour or every 2 days.
So my question is what makes these computers part of the agentless scanner group?
Application used to display HTML based dialogs has stopped working: Upgrading Agent 9.6 to 2017.3
Can install agent without dotnet?
Hi,
I'm running LDMS 2017.3 SU1 and must install LANDesk agent in Windows server 2008/2012 that run dotnet 3.5, 4.0.
The server team they don't want to install dotnet4.5 on their servers. How can I install agent without dotnet or any suggestion?
Thank you.
Recuring ESENT errors in eventlog
Hi,
on one of our Servers we see every 5 minutes recuring ESENT errors in eventlog.
services (484) An attempt to create the file "\\server.tld.org\ldlogon\new.sdb" failed with system error 5 (0x00000005): "Access is denied. ". The create file operation will fail with error -1032 (0xfffffbf8).
services (484) Unable to write a shadowed header for file \\server.tld.org\ldlogon\new.sdb. Error -1032.
services (484) Database recovery/restore failed with unexpected error -1032.
We have uninstalled the landesk agent but no succes. We have no clue whats triggers this error every 5 minutes.
Thankful for any help
Best regards
Heino
Periodic problem with pushing and then managing an agent
Hello, any help would be appreciated. here's what's happening. I'd say in 1 in 5 attempts i'm getting this behavior:
I install windows 10 on a client, join it to the domain then do UDD and schedule agent deployment. Most of the times it works just fine, but sometimes i know the issue is back right away when UDD cannot for whatever reason get the "device name" (it is blank) - i can make agent deployment work by manually editing the device name to match, but then, when the device appear in the inventory, i can't manage it (as in no agent status, no options to Scan or Security and Patch information).
I can't figure it out, the process is fairly standard, but it just happens time to time. There is no difference (hardware, software, networking ect) between the machines that fail and process just fine.
I'm on version "2016.3.3"
Thanks!
Update: i was able to resolve this. my issue was related to the database EventID 4100 (windows application log) - in my case coming from VIDEO table. I suspect that all affected machines shared same component - a specific ATI 6-monitor video card, that was causing exceptions. Increasing the field sizes in the Landesk DB fixed it.
Ivanti Endpoint Manager Agent Installed/Included and Supported .NET Versions
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.6.x |
How changes to Agent Configurations and Settings are propagated to clients?
I changed some settings in my Portal Manager in Agent Settings, this is part of a deployed Agent Configuration, after I saved the changes, how do I push those changes to the clients?
I set the auto sync to Yes, in both the Portal Configuration an in the Agent Configuration, do I have to wait x amount of time for the changes to be sync? Or auto sync is for a complete different task?
I ran a update to agent settings task which ran successfully, but the changes to the portal are not reflected. Any idea?
Thank you!
Message was edited by: Carlos Sosa Changed the title to reflect the point more accurately. Auto Sync refers to a different thing (Between Cores and not Agent settings). Thanks to @JonnyB for his help understanding this.