I am a newbie to LANDesk. I set up a core server and that part went pretty well.  Then I started using the wizards to begin making configurations, and then deployed some agents.  As soon as the agents were deployed, we had several end-users who could no longer print to their default printers. It was as if their driver had been removed.  All our printers are networked using TCP/IP, and we do not use print servers; we just set the desktops to print directly to the printer's IP address.  So immediately after deploying about 2 dozen agents, 4 or 5 people were no longer able to print to their HP LaserJets.  Each of these people was still able to print to MFP/copiers that were also set up on their PCs, but they could not print to their default printers (which are various HP LaserJets such as the 4050, the P2055, and the P3015).  Does anyone know the best way to fix these printer issues?  When I removed the agent completely from one of the desktops with the printer woes, it still did not fix the issue, but I still feel certain LANDesk is part of the issue, because I have not seen such widespread issues like this, in years, if ever, and nothing else was changed except installing these agents.

Thanks in advance to everyone.  If you can help me with this I will be extremely thankful.

Best,

Flux B.

Hello!

My organization is currently in the process of migrating our numerous installation bundles from our ZCM environment into our new and growing LDMS 9.6 SP2 environment.

This migration includes a large number of already written batch deployments that we will need to modify to take advantage of functionality in LDMS. Understanding Batch File Distribution Packages has been very helpful.

Unfortunately there are a significant number of these scripts that depend on Nircmd's great infobox or qbox functionality to prompt or notify the user during the delopyment if necessary.

For example, we have a batch script that will install a particular MS Word plugin. Word must not be running for the install to work, so in the script will check to see if Word is running. If it is, we prompt the user with Nircmd asking them please save their work and close Word. With ZCM, this prompt would be visible to the user even if the script were running as SYSTEM. In LDMS, this dialog box appears outside of user land and the script stalls waiting for input that it will never receive.

I realize that this will probably require a shift in the way we do things. For example, we could prompt the user ahead of time when they launch the install from the portal and fail the install if Word is still running. Not ideal, but workable.

That said, is there any way at all to interact with the user during a batch distribution?

Thanks for your help!

Hi,

1. I want my Landesk clients to update policy and check if their is a application to download and install every hour.

I think i have found this setting under (Distribution and Patch) -> Policy Sync schedule, is this correct?

2. When creating a schedule task for an application, and i want the deployed application to evaluate 1 time / day that it is installed.

What settings should i use? In schedule task i have found under (Task settings) -> (frequency) that you could choose (once, houry, daily, weekly) is that an evaluation of a application?

or is it under (Schedule task) where you can set (Repeat every: hour, day, week)

As long as the application is detected Landesk will not install it again? Correct? Or will some of this setting override the detection?

Regard

Johan

Purpose

Method for remote unprovisioning of vPro clients, for troubleshooting and correcting issues that may require the client to be unprovisioned.

The Intel(R) AMT Unprovision Utility is a simple command line utility that allows users to remotely unprovision an Intel(R) AMT system without requiring a

separate management console.

Note: This test will make use of the free 3rd party application Intel Unprovision.exe. LANDESK does not endorse nor support any 3rd party software. Users assume all liability when working with 3rd party software.

Steps

1. Download the Intel UnprovisionEx.exe tool.
2. Unzip the files to your Software Distribution Storage.
3. In the Management Suite Console, create a new Software Distribution Executable package.
4. In the Package Information section use the UnprovisionEx.exe as the primary file.
5. In the Install/Uninstall Options section add the following switches into the install/uninstall options: -hostname %computername% -user admin -pass P@ssw0rd -full
   • For the password please use the admin password for your vPro machines .
   • The -hostname can be either the listed variable, FQDN or IP address.
6. Save the package and schedule it out to the vPro devices you would like to unprovision.
7. Once these machines are in the pre-provisioned state attempt to zero-touch provision these devices.

(To verify the provisioning state of the machine please reference https://community.landesk.com/support/docs/DOC-31903)

1. A preferred server can be any machine with a share (read only) correct?

2. Does it needs to have an agent?

4. Which account should be used for this share? Since we need to enter the credentials in the preferred server settings, would this be a local account? but wouldn't this credentials be passed creating a security risk?

3. A replicator is yet another machine that serves just as controller?

4. The source is the Core (or preferred server where the files will be taken from)?

I appreciate your recommendations.

Thank you.

Hi there,

We are suffering some performance issues when working with the LDMS 9.5 SP1 console in the core server. We have only two consoles including the Core Server LDMS console, and during working hours we were really annoyed because the LDMS console was real slow to respond to any simple action like opening a new console tool or presenting query results. After a bit of research we pointed out a bottle neck in the Oracle connection. There were hundred of open active connections to the Oracle data base originated from LANDesk and with a weird origin as the oracle connection report shows there are 50 console connections opened at a given time when we only have two consoles.There is also many other open active connections for other LANDesk Core Server processes against the Oracle server.

64 connections for  LANDesk.Scheduler.GlobalScheduler.Skeleton.exe

   5 connections for  LANDesk.Scheduler.GlobalScheduler.exe

70 connections for  w3wp.exe

51 connections for  Console.exe

We have other Oracle applications with many more consoles and hundred of users and these have not such a high number of concurrent Oracle open connections as LANDesk Management Suite have.

We are planning to deploy at least 20 new LDMS remote consoles (may be more) and we just feel a cold rush of fear when thinking about how many number of session could we find in our Oracle server when these new LDMS console become operative, maybe it could mount up to more 1000 simultaneous connections in a given period of time!!

Any ideas on why there are so many concurrent open Oracle connections with the Oracle Server?

Thanks!

I've been doing a lot of software distribution testing with our new Landesk 9.0 SP2 server. I have a couple of machines I use for testing the new tasks but lately all software pushes to those computers won't work. It goes straight into "policy has been made available" every single time on both of them. I'm using a policy-supported push delivery method and there is nothing else going out to these machines. Just the one task. I read somewhere that the problem could be a corrupt local database but after removing the database files I found local, removing the agent, and reinstalling the agent, nothing has changed. Thoughts?

I am trying to distribute a Bat file as a distribution package but it does not appear to work. I need it to run as administrator so I changed the Account options in the package properties to a Service Account in AD. The bat file adds a domain user to the Administrators group.

The bat file works fine if I do it locally on the computer. Any ideas?

Jerry

I can see that when a task is deleted, the portal items disappear as well, but the pre-cached software is still there.

Is a script the only way to delete it?

Regards

Issue:

When deploying a file transfer script it fails with the following error:
“An invalid parameter was passed”
The return code is 16408.

File transfer script task reports success but does not copy the files.

Solution:

Edit the script and replace all instances of SDCLIENT.EXE with PEDOWNLOADER.EXE.

Issue

Agents fails to discover during a task.

Status: Failed

Result: Cannot Find Agent

Return code: 1110

Agent Discovery Process

When a scheduled task is set to Push, these are the steps it goes through to discover a client to provide the task to.

Logs

These logs will be used in diagnosing this issue:

• C:\ProgramData\Landesk\log\PolicyTaskHandler.log
• C:\Program Files\LANDesk\ManagementSuite\log\PolicyTaskHandler.exe.log

Is the machine online?

Yes - Device is online

If the machine is online, and continues to fail discovery, continue on to Setup a Discovery Troubleshooting test.

No - Device is not online

The most common reason for a machine failing to be discovered is that it is offline. A machine that is not online, cannot be discovered.

Can you ping the device?

Can you validate through some other method it is online?

Setup Discovery Troubleshooting Test

When the LDMS core is attempting to discover an agent, it will send a 'discovery' packet to the client. When the client receives the discovery packet, it will respond with information about the device to let the Core know who received the discover request.

Follow these steps to setup a Discovery Troubleshooting Test.

Enable verbose policy task handler logging

When the Core sends a discovery packet, it will log the attempt in the PolicyTaskHandler.exe.log, if verbose logging for this process has been enabled.

• On the LDMS Core, in the Scheduled Task panel, select the Configuration Settings option (gear icon) and choose Default Scheduled Task Settings

• In the Default scheduled task settings window under Accelerated Push, check the box for Enable verbose policy task handler logging
• Click Save

Note: The changes will only take effect on Tasks started after the change has been saved.

Setup Wireshark on core

Because the Core is involved in a large amount of network traffic, we want to filter down the traffic that Wireshark actually listens for.

• In Wireshark choose Capture | Options.

• In the Wireshark: Capture Options window choose Capture Filter:

• In the Wireshark: Capture Filter - Profile: Default window click the New button
• Select New Filter at the bottom of the list
• Set the following -
  • Filter name: Arp or UDP Port 9595 or ICMP
  • Filter string: arp or udp port 9595 or icmp
    • (The filter string is case sensitive, so make it just as listed above)
• The entry in the list will now reflect the Filter Name entered
• Click Ok

• In the Wireshark: Capture Options window, the Capture filter will show the Arp or UDP Port 9595 filter.

Note: If the bar is green the filter is acceptable. If the bar is red, the filter is malformed. Go back and make it match exactly as above

• Click Start to begin the Capture

Example of malformed filter.

End Other PolicyTaskHandler Processes

If you have ran several tasks, you may have multiple instances of PolicyTaskHandler.exe running, all of which are sending discovery packets.

To limit the amount of traffic we gather in Wireshark, and in the PolicyTaskHandler.exe.log, we want to end any other PolicyTaskHandler.exe processes running. This can be done through Task Manager.

Note: Ending this process will stop any agent discovery occuring on that particular task. Because terminating the process will stop discovery, the Scheduled Task may stay in a 'Discovering Agent' state indefinitely. The task will need to be re-ran later for a status change.

Create Scheduled Task to Test

You can use an existing scheduled task if desired, so long as you terminated it's running PolicyTaskHandler.exe process as outlined above.

• Schedule the task, and assign machines to be pushed to.
• Right click the task and choose Info
• Take note of the TaskID
  • We will use this when looking through logs to identify which lines the task belongs to

Were Discovery Attempts Logged?

When the Core attempts to discover a machine, it will log the machine info attempting to be discovered in the PolicyTaskHandler.exe.log (so long as verbose logging was enabled).

07/20/2015 07:00:33.2837 INFO  6812:1    RollingLog : [Task: 7zip 9.20 - 7/20/2015 7:00:18 AM, TaskID: 1541, ProcID: 6812] : Discover: Discovering machine: [96-AGENT] using it's known ip address [10.14.130.61]...

07/20/2015 07:00:35.2996 INFO  6812:1    RollingLog : [Task: 7zip 9.20 - 7/20/2015 7:00:18 AM, TaskID: 1541, ProcID: 6812] : Discover: Successfully discovered machine: [96-AGENT]

Yes

Continue to Were Discovery Packets Sent?

No

• Verify that Verbose Logging is enabled
• Run the task again
• Were Discovery Attempts Logged?

If Discovery attempts were still not logged, verify that new entries are being logged at all to the PolicyTaskHandler.exe.log.

If PolicyTaskHandler.exe runs, it should log accordingly, and utilize the verbose option if enabled. If yours is not doing this, then it is likely that now PolicyTaskHandler.exe isn't getting to run which means the task will not go to 'Unable to discover agent'.

Verify the Landesk Scheduler Service is running.

Review other logs to identify if there are any errors that may indicate why PolicyTaskHandler was unable to run.

Example: TaskHandlerProxy.exe.log shows PolicyTaskHandler.exe couldn't be found.

07/24/2015 08:03:28.0657 INFO  8044:1    RollingLog : TaskHandlerProxy: C:\Program Files\LANDesk\ManagementSuite\PolicyTaskHandler.exe /TASKID=2554

07/24/2015 08:03:28.2991 INFO  8044:1    RollingLog : TaskHandlerProxy: run process exception - The system cannot find the file specified

Were All Discovery Packets Sent?

To verify the traffic we are looking at is for our test task specifically, do the following:

• In the PolicyTaskHandler.exe.loglook for the first line that lists Discovering Machine for our TaskID

Note: Our task ID is 1547

RollingLog : [Task: 7zip 9.20 - 7/24/2015 7:55:58 AM, TaskID: 1547, ProcID: 10500] : Discover: Discovering machine: [TABLET] using it's known ip address [10.0.0.6]...

• In the Wireshark trace, filter for only discovery packets for the first IP address that belongs to our task.

Example: udp.port == 9595 && ip.addr == 10.0.0.6

• The filtered trace should show the Source as the LDMS Core, and the Destination as the client IP address we got from the PolicyTaskHandler.exe.log

Example: LDMS Core - 10.14.130.58  Client - 10.0.0.6

Repeat this check against the 2nd and 3rd IP addresses as listed in PolicyTaskHandler.exe.log for the taskID.

Spot check a couple more from the list as well, sometimes only a single packet is sent to the first IP which is easier to identify by checking several in the list.

All Discovery Packets Sent

If the couple IP's checked did send discovery packets, continue to: Did the Client Respond to Discovery?

Only Single Discovery Packet Sent

If no discovery packets were sent to any of the clients on the task, but PolicyTaskHandler.exe.log shows that we attempted to discover a device by IP, Windows may have not got

Single Discovery Packet

ARP Responses Received, No Discovery Packet Sent or Single Discovery Packet Sent

• PolicyTaskHandler.exe.log shows many discovery attempts for a task
• Wireshark shows a single Discovery Packet go out

-or-

• PolicyTaskHandler.exe.log shows many discovery attempts for a task
• Wireshark shows ARP Responses to local subnet ARP Requests, but no Discovery Packets go out

This is typically caused by 3rd party security software on the LDMS core stopping the UDP Traffic, typically due to its resemblance to a UDP Flood Attack. We have seen Symantec Endpoint Protection (SEP) behave in this manner.  

To correct this issue:

• Configure the security software to allow UDP Traffic out from LDMS

-or-

• Remove the software from the LDMS Core

We have also seen instances where the discovery packet sent to a particular device loops or bounces between two or more nodes.  Each bounce decrements the TTL value until it reaches zero.  At this point a TTL error is sent back to the core and Windows shuts down further network communication for that task.  This results in failure to discover all remaining devices in the task. 

To correct this issue, the cause of the loop must be determined and resolved by the networking team.

Discovery Packets Started then Stopped

PolicyTaskHandler.exe.log showed attempting to discover devices, wireshark showed discovery attempts at first, but then stopped prematurely.

On each packet sent is a defined value for how long the packet should be allowed to move across the network. This is called the Timeto Live (TTL), and by default a discovery packet's TTL is set to 128. Each time a packet makes a hop on the network (switch, router, client etc) it diminshes this value by 1. So if it takes 3 hops to get from Core to Client, the TTL on the packet when the client gets it would be 128-3 = 125. A TTL of 128 is enough to get around the world, so it is plenty to get through your network.

If however the TTL bounces around so much that it hits 0, an ICMP packet is sent to the original source of the packet indicating Time-to-live exceeded (Time to live exceeded in transit).

Note: This is most commonly caused by a routing loop in the network.

In order to send packets out, LDMS passes parameters to a Windows method indicating what type of packet, and what IP address. The OS (Windows) responds indicating it received the request, and LDMS Logs the attempt to policytaskhandler.exe.log that we attempted to discover the client.

It has been seen where if a TTL exceeded ICMP packet is sent to the Core, it will terminate new UDP packets going out for current PolicyTaskHandler tasks at an Operating System level. This means that LDMS continues to pass parameters to the OS asking Windows to send out packets, and the method returns that it received the request successfully, LDMS logs the attempt, but the OS does not continue sending packets out for the existing PolicyTaskHandler process.

Example: A task contains 6 IP addresses: 10.0.0.1, 10.0.0.2, 10.0.0.6, 10.0.0.10, 10.0.0.17, 10.0.0.50

Discovery packets are sent until a TTL Exceeded ICMP packet is returned to the core.

PolicyTaskHandler.exe.log indicates that we continued passing parameters to the OS to send out packets for us, despite no more packets showing in Wireshark.

Discover: Discovering machine: [TABLET] using it's known ip address [10.0.0.1]...  

Discover: Discovering machine: [SQLTEMP] using it's known ip address [10.0.0.2]...  

Discover: Discovering machine: [JANE] using it's known ip address [10.0.0.6]...  

Discover: Discovering machine: [SAM] using it's known ip address [10.0.0.10]...  

Discover: Discovering machine: [NICK] using it's known ip address [10.0.0.17]...  

Discover: Discovering machine: [JOE] using it's known ip address [10.0.0.50]... 

To correct this issue -

This is typically caused by routing loops on the network. Running Tracert against the IP may provide more information regarding where potential loops exist.

• The preferred fix for this is to correct the routing loop. The packet has a high enough Time-to-Live value to get around the world, so it should not bounce around your network so many times that it was exceeded.
• Alternatively, if the IP triggering the TTL exceeded is for a device on a scheduled task, the device can be removed from the task which should prevent attempted discovery packets being sent to that address, and instead can be added to a task that is available via Policy. This would prevent the discovery packet from going out since it is a policy, and the client would still be able to get the task on check in.

Note: This issue has been seen to occur on after some TTL Exceeded packets, but not necessarily all. If Discovery packets stop being sent after a TTL Exceeded packet is received on the core, this address should be reviewed for potential routing loops and treated accordingly.

Discovery Packets Not Sent

PolicyTaskHandler.exe.log showed attempting to discover devices, but there were no discovery packets (shown on udp.port == 9595) going to it.

No ARP Response

When determining who to send the discovery packet to, Windows will check if the client IP address is in the same subnet as the sender. If the Core and client are in the same subnet, an ARP Request will go out, asking who currently has the target IP Address. If any machines on the subnet receive the ARP Request and contain information on who has the IP address, they respond with the client information so Windows can route the packet to the client.

Example: The Core (10.14.130.58) is trying to discover Client (10.14.130.61). Because they are in the same subnet, an ARP Request is issued asking who has the 10.14.130.61 address. An ARP Response is sent back from a machine on the subnet indicating which device has the IP, and the Discovery packet is issued.

If there is no ARP Response to the request, Windows will not know where to send the discovery packet, and it will not be sent.

Example: The Core (10.14.130.58) is trying to discover Client (10.14.130.250). Because they are in the same subnet, an ARP Request is issued asking who has the 10.14.130.250 address. No machines send an ARP Response to indicate who has the IP, so no discovery packet is sent.

Did the Client Respond to Discovery?

After the Core sends a discovery packet to the client, it looks for a response from the client indicating it is online and available.

In the wireshark trace, apply a filter to show only discovery packets and the client's ip address.

Example: udp.port == 9595 && ip.addr == 10.14.130.61

• There should be a discovery packet going from the LDMS Core (Source) to the Client (Destination). This is reflected in the first line of the screenshot.
• There should be a response from the Client (Source) to the LDMS Core (Destination).

Yes - Client responded

Continue to Client responds but is still marked 'Failed to Discover'

No - Client did not respond

Continue to Does the Client receive the discovery packet?

Does the Client receive the discovery packet?

Verify the client is actually online. If it is not online, it cannot receive the discovery packet.

If the device is online, install Wireshark on the client and trace the discovery attempt.

Example:  udp.port == 9595 && ip.addr == 10.14.130.61

{steps on manually doing a single discovery)

Note: Core IP = 10.14.130.58, Client IP = 10.14.130.61

No discovery packet received

Discovery Packet received, but no response returned to Core

Yes - Client received discovery packet

If wireshark shows that the Client did see the discovery packet, but did not respond to it, this could indicate an issue with the Agent. Things to try:

• Verify the LANDesk(R) Management Agent is started.
• Reboot the client

If the agent services are all running, and continue to not return a response to the discovery packet, check Client side logs under C:\ProgramData\Landesk\Logs for any errors.

No - Client did not receive discovery packet

If wireshark does not show that a discovery packet was received, this is an indication that the packet is not routing to the client correctly. This could be caused by:

• Firewall blocking packets/ports
• Network routing packets to wrong machines

Correct this issue internally to allow the client to receive the packet.

Client responds but is still marked 'Failed to Discover

In LDMS 9.6, discovery attempts now include client validation. This helps to verify that the machine responding to the Discovery attempt, is the machine we are intending to reach.

This is done by parsing the Clients Discovery response, which contains inventory information about the device who is responding.

You can simulate the discovery and view the response with the following command: pds2dis.exe ping {client ip}

Example: C:\Program Files\LANDesk\ManagementSuite\pds2dis.exe ping 10.14.130.61

Response:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<discover>

<response><address>10.14.130.61</address><XHSH>3D820E0A</XHSH><APID>ping</APID><MAID>FE495D5D-404A-234C-9CAB-697F258E8DB7</MAID><FQCN>96-Agent.evdomain.local</FQCN><MACA>000C29C44B0A</MACA><MASK>255.255.255.00.0.0.0</MASK><AGRP>EVDOMAIN</AGRP><OSFM index="7">Win32</OSFM><OSNM index="4">WinNT</OSNM><OSVR>060223f0</OSVR><CERT>;55e3c398</CERT><PONG size="8">Q0JBOAAAAAA=</PONG></response>

</discover>

If the response contains information that does not match the clients Inventory information in the LDMS core, it will be considered the 'wrong machine' and marked as 'failed to discover'.

This can be viewed within the C:\ProgramData\Landesk\Log\PolicyTaskHandler.log

07/20/2015 07:00:33.2837 PDS2CallbackFunc: not the same deviceId - ip=3d820e0a

Note: The ip address is listed here as a hexidecimal representation of the IPv4 address. Visit this article on how to convert the values to Dotted IPv4 addresses.

How to Convert IP from Hex to Dotted Format

Check Client with Real-time Discovery

A device that was PolicyTaskHandler.exe.log shows as failed to discover, but that Wireshark shows as having responded to the Discovery likely has Inventory data that conflicts with what was returned in the discovery.

This can be checked quickly by:

• Right click the client in Inventory and choose Scheduled Tasks and Diagnostics

• In the Scheduled tasks and diagnostics window click the Real-time Discovery button (globe in upper left corner)

• The Discovery Information window will open. At this point, the LDMS Core is sending Discovery packets to the client, waiting for returned xml data.
  • All fields stay at 'No data' - This indicates that we never got a response from the Client. This machine would be marked 'Failed to Discover'.
  • Discovery response XML populates, and all fields remain same color - This indicates that the Client responded, and appears to be the Client we were looking for. This machine would be a successful Discovery.
  • Discovery response XML populates, and one or more fields are red - This indicates that the Client responded, but the response contained data that conflicts what we have in Inventory. This machine would be marked as Failed to Discover, and not be given the task.

If Real-time Discovery shows a mismatch, correct the inventory issues at hand in order to Discover the affected client.

Environment:

9.5 and newer

Review Date:

Last reviewed November 9th, 2014

How to:

This document will outline the best known methods of stting up and configuring a software distribution package bundle. The "Package Bundle" option allows you to chain as many packages together as you want.

Step by Step:

1. Go into the Management Console>Distribution Packages>My packages>right click>New package bundle;

2. You can adjust many settings by right clicking on your new bundle and going to the properties;

3. From within the properties, you can set a name and description. You can also set it so that it can not be scheduled.

4. Here you can assign packages that are already created, you can also set the order that the packages get deployed with the up and down arrows.

5. Under additional settings you can input information such as the application vendor name, the estimated download and install times, and indicate if a reboot is expected.

6. If you have already created categories, you can specify that at this time.

7. Next you can upload a custom logo and screenshot that can display during the install.

8. Here you can assign it tags that are used to group the package in the portal.

                  ***These tags must first be configured as shown in this image.

9. Once you have the bundle configured as desired, right click on the bundle and schedule it to run.

The client machine deploy agent with portal manager.

The package cannot be shown on the portal manager when you click the 'refresh' button. There is no error happened but the package is not shown on portal.

The policy.sync.exe called lddwnld.dll to download from core server. The lddwnld.dll may have error.

The policy.sync.exe updated the task to client machine local DB file LDClientDB.db3. The DB may have error.

You can go through the following steps how package is updated to the portal manager. And confirm which step is failed.

You need to confirm the client agent patch level should be same with core.

• The schedule task is ready and wait status

• The file SDClientTask.<CoreName>.<TaskID>.xml in generated under folder on core:

.\Program Files (x86)\LANDesk\ManagementSuite\landesk\files

• When click refresh button on portal, the file SDClientTask.<CoreName>.<TaskID>.xml will be downloaded to client folder:
  • C:\Documents and Settings\All Users\Application Data\LANDesk\ManagementSuite\landesk\files (WinXP and Win2003)
  • C:\ProgramData\LANDesk\ManagementSuite\landesk\files (Win7 or Win2008 client machine)
  • The file is downloaded through lddwnld.dll, It is also be called by SDClient.exe and Vulscan.exe.
  • You may kill SDClient.exe and Vulscan.exe in task manager manually.

• The XML of task should be updated to the client machine local DB file LDClientDB.db3.
  • C:\Documents and Settings\All Users\Application Data\LANDesk\ManagementSuite\Database  (WinXP and Win2003)
  • C:\ProgramData\LANDesk\ManagementSuite\Database (Win7 or Win2008 client machine)
  • You can try to clean the database by: How to resolve "Task Queued at Client for Execution"
  • And the  policy.invoker.exe should running in task manager always. The policy.invoker.exe will check the DB every 3 secounds to launch the task.
  • If it is not running, you can go to services to start the LANDesk Policy Invoker.

• You can collect the following log files to support team:
  • C:\Program Files (x86)\LANDesk\LDClient\policy.sync.log
  • C:\Program Files (x86)\LANDesk\LDClient\lddwnld.xlg  (This required the XTrace log of lddwnld: How to enable XTrace Diagnostic logging for the LANDESK Core and Clients)
  • C:\Program Files (x86)\LANDesk\LDClient\Data\sdclient_task<TaskID>.log
  • C:\Program Files (x86)\LANDesk\LDClient\Data\SDClientTask.<CoreName>.<TaskID>.log
  • C:\Program Files (x86)\LANDesk\LDClient\Data\sdclient.log

If there is 'time out' error, you can go to this help document for help: 'Time out'  error when click the 'refresh' on portal manager

LANDESK Management Suite 9.5 SP2 + AEM 0417 Base

Environment :

LDMS 9.6 :

Added in LDMS 9.6-SP1 :

Problem/Symptoms

When running a scheduled script to a LANDESK Management Suite client, the following error occurs:

Remote System refused the network connection

and is recorded in the log file:

Error code -2147023671: Remote System refused the network connection

Cause

The certificate file on the client machine has either become corrupted or been deleted.

The file is found in:

C:\Program Files\LANDesk\Shared Files\cbaroot\certs

The Core Server does an initial check of the certificate file to make sure that it is a client with which it can communicate. Since the hash value is correct it will start the script; however during the full

verification of the certificate, the process will fail and the connection will be refused.

Solution

Copy the certificate file from the Core Server's from this directory:

C:\Program Files\LANDesk\Shared Files\keys

to the client's one:

C:\Program Files\LANDesk\Shared Files\cbaroot\certs

The certificate file has a .0 extension.

Reviewed: November 2014

Versions Effected: LDMS 9.6 and newer

Problem/ Scenario/ Question:

In LDMS 9.6 Software Packages will be downloaded on managed nodes in folder %ProgramData%\LANDESK\ManagementSuite\SDMCache.as opposed to
%Programfiles(x86)%\LANDesk\ldclient\SDMCache.

Erroneous Location

Correct Location

Cause:

This is caused by the file located here:

C:\ProgramData\LANDesk\TMCDownload\downloadermulticastconf.xml

The download location in the file is pointing towards the ProgramData location as opposed to our default one

Solution:

This has been identified as an 'engineering request' and has been resolved in LDMS 9.6 SP1.

Workaround:

The file that points towards this location is located here:
C:\ProgramData\LANDesk\TMCDownload\downloadermulticastconf.xml

To resolve this now you can either delete it or change the path under the 'Cache' Directory entry. Run vulscan on the end machines and this will point back towards the original location.

Environment:

LDMS 9.5+

Question:

For security or monitoring reasons, you need to download the Packages on a specific port other than the default Http port 80 or Https port 443 from a preferred server. But you also use a Replicator Server to copy data from the Source Data server to the Preferred Servers.

How can I set that up?

In that case, you need to configure 2 preferred servers with the same server; 1 which will receive the data from the source through the replicator and another 1 which will dispatch the data across the clients on the selected IP address LAN through a specific port.

Here is the setup details;

1- Source Server: Hostname "CORE95SP2" - where the data are stored (In this example; on the Core Server on http://CORE95SP2/landesk/files/TESTREP1/)

2- Preferred Server dedicated to deploy data to the clients: Hostname "CORE95SP2RS" with 8093 port added

3- Preferred Server dedicated to receive the replicated data from the Source server: Hostname "CORE95SP2RS"

4- Replicator Server: Hostname "WIN7PROSP1"

5- IP Address range of Nodes concerned: 192.168.1.2 - 192.168.1.254

6- Port: 8093

• Configuration of the Source Server and the Preferred Server dedicated to deploy data to the clients:

Follow instructions given in article How to: Deploy a Distribution Package on a different Http ports than 80/443 ports from a Preferred Server

• Configuration of the 2nd Preferred Server dedicated to receive the replicated data from the Source server:

a- Go on the LDMS Console > Tools > Distribution > Content replication / Preferred servers

b- On Content replication - Preferred servers (Targets), click on New to create a new preferred server configuration

c- On the tab "Configuration",

• Input the server name; In this example CORE95SP2RS
• Input the Read-Only credential; In this example sebdomain\administrator

e- On the tab "Sources", select the Source server; In this example CORE95SP2

f- On the tab "Write credentials", input the Credentials and click on "Test Credentials..." button to test the permission rights

g- Click on the "Save" button to record your configuration (see below a printscreen of the configuration)

• Configuration of the Replicator server:

a- Go on the LDMS Console > Tools > Distribution > Content replication / Preferred servers

b- On Content replication - Replicators, click on New to create a new Replicator server configuration

c- On the tab "Identification", select the Replicator Server; in this example WIN7PROSP1

d- On the tab "Preferred servers (Targets)", select the Preferred server; in this example CORE95SP2RS

e- Click on the "Save" button to record your configuration (see below a printscreen of the configuration)

A way to check if the data are indeed downloaded on the specific port on the preferred server:

You can use Process Monitor tool from SysInternal (see Process Monitor) from the Client. Here is below a printscreen of what you may see on this trace;

Platform:

LDMS 9.6 (this will work with any 9.5 and 9.0 platform as well)

Problem:

How do I kick of a policy sync manually on a device?

Scenario:

I have scheduled a required policy, and do not want to wait till the scheduled Policy Sync runs.

Solution:

1. There is a managed script that will run policy sync, you can find the managed script in the Management Console here;

2. Next find the script named Package Sync;

3. Then right click on it and schedule it;

4. Now drag your desired devices down to the task and “Start now”on “All”;

It may take a couple of minutes to run, but, if the machines are on, they should succeed. Once the sync runs, your scheduled policy should begin if there is not something preventing it from running (I.E. another dist package, or vulscan etc.).

This is the purpose of the document is to provide a high level overview of the changes to Software Distribution in LDMS 9.6. Links will be embedded to other documents for further information the specific changes.

Software Distribution under went many new changes in LDMS 9.6 fundamentally changing how tasks are handled configured and then processed on the client side. These changes include:

1. Global Scheduler rewritten to run leaner and faster.
   1. Time Zone Aware targeting has been added.
   2. Targeted Multicast has been deprecated in the LANDESK Global Scheduler in favor of Self-Organizing Multicast.*
   3. Scheduled Task Handler and Application Policy Management have been consolidated.*
2. Delivery Methods have been deprecated and their settings relocated to the Task Properties, Distribution and Patch Settings, and Reboot Settings.*
   1. Task Properties.
   2. Distribution and Patch Settings.
   3. Reboot Settings.
3. Link Manager has been deprecated, and links are now managed the same as any other Distribution Package.
4. Self-Organizing Multicast built into clients for quicker more efficient multicasting.
   1. Multicast Domain Representatives deprecated.*
5. PEDownloader.exe added to clients to simplify downloading of files, and troubleshooting download issues.

                  *Legacy Support still exists for LDMS 9.5 and older clients, although it is recommended to upgrade Agents as soon as possible.

1. Global Scheduler rewritten to run leaner and faster.

The LANDESK Global Scheduler has been rewritten to increase speed in processing tasks. Part of this upgrade called for the consolidation of Scheduled Task Handler (Used for Push Tasks) and Application Policy Management (Policy Tasks) into one optimized delivery system. The short and sweet of it is ALL tasks are now processed as Policies. You can still select to use a Push, Policy-Supported-Push, or Policy type of task, but these options have been moved in the Task Properties. To further lean down the Global Scheduler we have removed Targeted Multicast, in favor of Self-Organizing Multicast which is all handled on the client side taking the load off the server. And we have added the feature of Time-Zone Aware Targeting of Tasks, this allows a task to start at a certain time local to the machine, instead of going out to all targets at the same time it is started on the core.

1.1 Time Zone Aware Targeting

        Time Zone Aware Targeting for Distribution Tasks

1.2 Targeted Multicast has been deprecated in the LANDESK Global Scheduler in favor of Self-Organizing Multicast

To improve performance on the Scheduler Service, and also reduce the amount of work the Core took on in Multicast tasks we have removed Targeted Multicast. The multicast process is now completely handled by the client machines and is able to run faster and more efficiently than ever. For More information on Self-Organizing Multicast please see the section dedicated to it below.

1.3 Scheduled Task Handler and Application Policy Management have been consolidated

To further reduce the load on the core server's resources, optimize the processing of clients for Distribution tasks we have consolidated the Scheduled Task Handler (Push Tasks) and Application Policy Management (APM) engines into one. The end result is much closer to APM than Task handler, and as a result all tasks now behave similar to policies, although they can still be scheduled as a Push or Policy Supported Push type task as well, they all arrive to the client in the same manner.

All tasks now have XML files associated with the task that contain all the needed task info the agent needs to install the software. On the core server these files are located at \LANDESK\ManagementSuite\landesk\files\ClientPolicies\. Once downloaded to the client machine the policies are stored in C:\ProgramData\LANDESK\Policies. A windfall of this change is now it is much easier to find the status of a given policy and troubleshoot it. The LDCLientDB.db3 no longer exists on clients in LDMS 9.6.

2. Delivery Methods have been deprecated and their settings relocated to the Task Properties, Distribution and Patch Settings, and Reboot Settings

Along with the consolidation of Task Handler and APM and the addition of an Agent Setting specific to controlling reboot behavior associated with Software Distribution and Patch Management tasks, it made sense to move away from Delivery Methods and move the options found inside those methods to new locations.

2.1 Task Properties

In addition to selecting the Task Type (formerly Delivery Method) you can select some of the specific settings for the task to use such as:

• Task Settings
  • Frequency: Control if the task runs Once, Hourly, Daily, Weekly, or Monthly on the client. This does not cause the task to restart, but for the client to re-execute it. Formerly specific to Policy delivery methods.
  • Additional Push Options: Some setting here are from Delivery Methods, others like Accelerated Push are new.
  • Download Options: Would you like the task to Run from Source, Download and Execute, or to just Pre-Cache the files for execution later?
• Agent Settings
  • Select the Distribution and Patch settings, and Reboot settings specific to the task if they need to differ from the defaults already assigned to the agent.
• Schedule Task
  • Time Zone Aware Targeting

2.2 Distribution and Patch Settings

The majority of the setting you could find in the Delivery Method have been moved in the Distribution and Patch Settings.

• General Settings - Everything here applies to both Software Distribution and Patch Management.
  • Network Settings
    • Preferred Server / Peer Download Options
      • Peer
      • Preferred Server
      • Source
      • Multicast
    • Bandwidth Throttling
  • Policy Sync Schedule
    • Moved out the Agent Configuration to here.
  • Notifications
    • Allow user to defer and cancel tasks.
    • Show UI.
    • Use a custom message.
• Distribution-only Settings
  • Offline
    • How the agent behaves if it cannot contact the Core Server
  • Logged Off User Options
    • Control behavior if no user is logged on the machine, useful for tasks that require logged on user credentials to install the package.

2.3 Reboot Settings

     How to use Reboot Settings

3. Link Manager has been deprecated, and links are now managed the same as any other Distribution Package.

The LaunchPad Link manager tool has been removed from the Management Suite Console. Now to manage all your existing links you create and schedule then just like any other software distribution package.

4. Self-Organizing Multicast built into clients for quicker more efficient multicasting.

With the removal of Targeted Multicasting from the Global Scheduler on the Core, we have switched to a more efficient method called Self-Organizing Multicast. If the Multicast box is checked in the Distribution and Patch settings, then all the client in the task will communicate with other machines in the task on their same subnet, they will elect a machine to be the Multicast Domain Representative (MDR), who will be the sole machine downloading the files from the best location (Peer, Preferred Server, or Source) and will then multicast each file out the other side while the next file is downloading.

Previously the Core would elect the MDR, which depended on whether or not the network allowed subnet directed boradcasts, then the Core would push the files from the source to the MDR and once he had all the files he would begin the multicast. It was a drawn out process that took longer than desired in many cases, but allowed for minimum network traffic across WAN connections.

The new method is faster and more efficient on network communication overall.

**Detailed documentation coming soon**

5. PEDownloader.exe added to clients to simplify downloading of files, and troubleshooting download issues.

Have you ever copied the sdclient.exe out of the Boot.wim used in Provisioning tasks to simplify downloading files for tasks? Well those days are now gone. With the new PEDownloader.exe application that is part of every Windows Agent there is a simple way to download the needed files for a task. Located at:

C:\Program Files (x86)\LANDESK\LDClient\PEDownloader.exe

This utility allows you to more easily download files and folder from Source, Preferred Servers, Peers, or via Multicast. You can use this in your scripts, tasks, and troubleshooting.

PEDownloader is capable of testing every function of the LANDESK Downloader (lddwnld.dll).

For a list of commands, and some sample commands lines simply run "PEDownloader.exe /?" from the Command Prompt.

LANDESK Management Suite 9.6

Purpose

This document outlines how to enable xTrace logging for LDMS 9.6. Enabling xTrace on the device will make the original log files more verbose allow for better troubleshooting.

Steps

• Open registry editor (regedit.exe)
• Navigate to the logXTrace key
  • 32Bit OS - [HKEY_LOCAL_MACHINE\SOFTWARE\landesk\managementsuite\LogOptions\logXTrace]
  • 64Bit OS - [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\landesk\managementsuite\LogOptions\logXTrace]
• Right click logXTrace and choose Modify.
• Set Set logXTrace to have a value of 1 and click Ok.

Related Documents

LDMS 9.6 Additional Logging Options