All, we've recently been asked to install a font set on all of the machines in our network (around 3,000 machines). I've scoured the web and the community but just seem to be more confused than when I began. Here's what I'm working with:

• we've placed the font set in a centralized location on our software distribution folder
• we're targeting c:\windows\fonts all our machines
• we have our landesk service account and the local admin account to work with

I thought it woud be as simple as finding a way to copy the files to c:\windows\fonts; however, I've read where end users would need to be power or admin users OR there would need to be registry entries.

Sooo...long story short, how many of you have deployed font sets to 1000+ machines? How did you accomplish this (any details or scripts would be greatly appreciated)?

Software Distribution for LANDESK Management Suite

• This is a list of highly recommended documents for increasing overall knowledge of this component.
• The article's listed below are applicable to LANDesk Management Suite 9.0 and may apply to 8.8.
• If you want to review additional content regarding this component, please use Documents or Discussions buttons on the overview page.

Changes in Software Distribution for LDMS 9.6 SP1

• Whats new for LDMS 9.6 SP1 Software Distribution

• Scheduled Tasks and Diagnostics Utility

• Package Relationships new in LDMS 9.6 SP1

Initial Install and Configuration

• Video: Software Distribution Fundamentals: Creating Distribution Packages
• Video: Software Distribution Fundamentals: Scheduled Tasks
• Software Distribution (LDMS) Desktop Manager Configuration Guide
• How to Configure a Preferred Package Server
• How to set up a HTTP share for a Preferred Package Share
• Using LANDesk Content Replication
• Deploying a Virtualized Application via LaunchPad Quickstart Guide
• AdminStudio 2013 Limited Edition for LANDesk® Management Suite
• Quick Start Guide for using AdminStudio to repackage a software installation into an MSI package.
• Best known methods to configure and use Fuse

Additional Options and Information

• How to keep files in the SDMCACHE directory for a longer period of time
• SDCLIENT.EXE Command Line Switches
• Understanding Batch File Distribution Packages
• Working With Registry Keys in a Batch File
• How to use Reboot Settings
• Time Zone Aware Targeting for Distribution Tasks

Troubleshooting this Component

• How to quickly troubleshoot a Software Distribution job.
• How to Troubleshoot Agent Discovery
• Policy Tasks Run on Clients After Tasks Have Been Deleted From the Core Server.
• The Scheduler Service stops after each completed task
• Troubleshooting "Failed to download additional files"
• Advanced Install and troubleshoot Fuse
• ClientDBUtil.exe Application Error

Notice: Any E-Learning content is available by default to Members who have a minimum support agreement at Professional level.

NOTE:This article is not a comprehensive list of documents and issues. You can continue to search the rest of the community or the portion specific to Software Distributionif this page hasn't helped.

I been following this doc

HTTP repository for SWD/Preferred Server in IIS 7.5

I have set it up with anonymous authentication. leaving the IUSR as specific user, this work well in network and via CSA  (I added the local IIS_IUSR as well)

Can some one explains how steps 7 and 8 work? (I do not understand when is necessary to change the specific user and when to use Application Identity)

7. In the Actions pane, click Edit to set the security principal under which anonymous users will connect to the site (Do I need to change this)

8. In the Edit Anonymous Authentication Credentials dialog box, select one of the following options:--  Specific user, ( IUSR )--  Application pool identity, if you want IIS processes to run by using the account that is currently specified on the property page for the application pool. By default, this is the Network Service.

Now, as mentioned by Davidg5700 on this tread Software Distribution using CSA

leaving the system configured this way (anonymous) leaves the directory open to anyone, so I changed the anonymous to basic.

This makes the Software Distribution Task to use the Credentials entered in the preferred server, before I had my core set as the preferred server so the directory and credentials worked just fine) I found that is better to NOT use the core as a preffered server so I'm trying to use one of my domain machines for this.

Following this Doc  How to Configure a Preferred Package Server

So I created a folder/structure exactly as in my Core (name and directory structure as the source referenced in the distribution package) the UNC works.

Do I need to share this directory?

Which credentials this screen is referring to? It says read credentials necessary to manage nodes to download files from the server, what does this means?

I have tried my admin credentials on this, I can get to the UNC but can not get to the HTTP

Then I shared the directory on the preferred server and granted me access, but still get the same error.

Please If some one can help me with this, I been doing my homework but still can't get it to work, I'm missing something?

Regards

Hi,

I am trying to add and application that will be a link to a Portal Manager user guide.

Application type:  Executable

Patch : "c:\program files(X86)\Microsoft office\office14\winword.exe"

Parameters: "\\server\shared folder\user guide.docx"

The application is not showing up in the portal after I deployed the new settings to my machine.

I had done the same to launch with explorer.exe to launch a web page and it worked.

Any idea?

Thanks

Im new to Landesk Management Suite, but i have worked with SCCM and Altiris for many years.

I have created some groups in Network view and added computers.

How can i add those groups in queries?

I'm usedto work with collections/filters in SCCM/Altiris, doesnt Landesk have the same structure?

Running 9.6 SP2.

I'm having an issue with a scheduled task that I had set to run on a targeted query. I can run the query and it shows the workstations I'm looking for just fine. It also shows up correctly under the task properties in the Target devices>Targeted Queries.

When I run the task, it does not appear to resolve the query and the task is never ran on the workstations. Checking the SchedQry.exe.log file I see this error:

ResolveTasks: Error, console user for task: [214] does not exist, restart task with a new user

Any idea what would cause that and how to fix this?

Thanks,

Andrew

Purpose

This article covers how to troubleshoot software distribution from the client side.

Software Distribution Process

Logs

These logs will be used in diagnosing the issue:

• C:\Program Files (x86)\LANDesk\LDClient\Data\sdclient.log
• C:\Program Files (x86)\LANDesk\LDClient\Data\sdclient_task##.log

Get the Task ID

Each scheduled task gets a unique Task ID value. We will use this value to track the task, and identify where the actions got to.

• Right click the Scheduled task and choose Info
• Locate the number in the ID field

Example: Task ID 3601

Did the Policy xml download to client?

Check the Policies directory on the client to see if the policy xml for the task was downloaded. The xml will be named CP.{TaskID}.....xml.

Example: C:\ProgramData\LANDesk\Policies\CP.3601.RunNow._zJo9YNYzZGuoUqvHKI955qjYuB0=.xml

Yes

Go to: Did sdclient run the task?

No

Go to:  {policy sync article}

Did sdclient run the task?

When Policysync executes an /enforce, it will run any unprocessed policies. The C:\Program Files (x86)\LANDesk\LDClient\Data\sdclient.log will indicate if it processes the task specific policy.

Example:

RunAppMain: command Line : /policyfile="C:\ProgramData\LANDesk\Policies\CP.3601.RunNow._zJo9YNYzZGuoUqvHKI955qjYuB0=.xml"

Yes

Go to: Did sdclient_task## run the primary file?

No

Review C:\Program Files (x86)\LANDesk\LDClient\Data\sdclient.log for errors.

Did sdclient_task## run the primary file?

When sdclient processes a task specific policy, it will generate an sdclient_task log which contains the task ID:

Example: C:\Program Files (x86)\LANDesk\LDClient\Data\sdclient_task3601.log

When processing the policy, sdclient will call and execute the primary file in the distribution package with whatever switches are listed in the package.

Example:

Execute Msiexec.exe with command Line: "Msiexec.exe"  /quiet /norestart /i "C:\Program Files (x86)\LANDesk\LDClient\sdmcache\ldlogon\swd_packages\7zip\7z920.msi" REBOOT=ReallySuppress

Yes

Go to: Did sdclient_task## receive an exit code?

No

Review the sdclient_task##.log for errors.

Example: Primary file fails to download

Thu, 20 Aug 2015 07:43:24 DoDownloadFromSourceSteps: DOWNLOAD_ERROR_GENERAL_FAILURE

Thu, 20 Aug 2015 07:43:24 Download Error: err=1, path=\\96-core3\ldlogon\swd_packages\7zip\7z920.msi

Thu, 20 Aug 2015 07:43:25 processing of package is complete, result -1918107543 (0x8dac0069 - code 105)

Did sdclient_task## receive an exit code?

When a package finishes running, it will give a return/exit code to sdclient which will be logged in the sdclient_task##.log.

Example:

processing of package is complete, result 229392420 (0x0dac4024 - code 16420)

Yes

If an exit code was returned, this indicates that the package finished or terminated. Searching the exit code in the LDMS community, or online can provide more information regarding the error.

Common Exit Codes:

• 0 - Success
• 3010 - Reboot Required

Other exit codes may have different meanings depending on the vendor of the application.

MSI packages use standardized exit codes which are listed here

.

No

If the primary file was listed as being executed, but no exit code has been returned, this typically means that the file is still 'running'.

• Open windows task manager, and view the list of running processes
• Right click the column headers and choose 'Select Columns'

• Check the box for Command Line and press Ok

• Look for the primary file as a running process
• Check under the Command Line column and see if it contains any switches

By default LDMS will install software hidden from view. This means that most applications require a silent/unattended switch to install without asking for any user interaction. If the software is called without switches, it will launch, and the software believes it is waiting for user interaction, however the windows are hidden which puts the software in a 'frozen' state of waiting.

To correct this:

• Terminate the stalled process on the client
• Provide necessary silent switches in the package on the LDMS Core
  • Switches can vary between software vendors. Consult programs whitepapers for info on silent installation. (typically you can search online for "{program name} silent install")

Note: MSI's are the exception to the switch rule.

MSI's are standardized and use the same switches for installing. As such, LDMS automatically provides necessary switches for MSI packages.

Did the task return a status?

Mon, 17 Aug 2015 10:05:54 Sending task status, cmd line -coreandip=96-CORE3.evdomain.local -taskid=3603 -retcode=229392442 "-ldap=CN=Nevans,CN=Users,DC=evdomain,DC=local" -pkgid=1089

Exec: Launch request <"C:\Program Files (x86)\LANDesk\LDClient\PolicySync.exe" -taskid=3601> (sync 0, timeout 2147483647)

Reviewed: November 2014

Versions effected: LDMS 9.5 and 9.6

Problem/ Scenarios:

You have different departments. 2 of 5 are already working with LDMS. Now, the admin of a third department is testing LDMS to decide if they want use LDMS.

Scenario 1

You have found a problem: The 3rd department can delete and edit every package which has not the 'Public User' as Owner in 'Public packages'. They have NO 'edit public' permissions, they just have 'edit'.

Scenario 2

The software engineer for LDMS creates packages in the team folder. He tests the packages and if the tests are OK, he moves them into 'Public packages'. When he moves the packages into public, the owner will not be set as 'Public User'.

The owner would not be the problem, the problem is that the permissions are in relation with the owner. So when the owner of a package is not 'Public User', every user with a simple 'edit' permission can do everything.

Firefox package with wrong Owner

Cause:

When moving packages from one folder to another the owner does not change and the permissions needed or associated with each package are derived by who the owner of the package is. So as described above if the package is moved from a team folder or a 'my' folder then the original owner will stay and the permissions associated with it as well.

Solution:

It is highly recommended that you change the owner and therefore the permissions of every package manually to 'public owner' to prevent the above problems. And then include the action of changing the owner from orginal owner to the public user in the process of testing and making the packages ready for deployment,

If you have a lot of packages with this issue already within the public packages folder you can run the following query on the LDMS database to fix the permissions on the packages and change the owners to 'Public user' quickly.

It is recommended that you make a backup of the database before applying this query as a per-cautionary step.

USE [name of LDMS DB]
-- Declare the variable to be used
DECLARE @PublicPackageidn int;

-- Initialize the variable.
SET @PublicPackageidn = (SELECT PACKAGE_IDN
  FROM [PACKAGE] where NAME = 'Public packages');

WITH SubStruc(Parent, Child, Name) AS
  ( SELECT RELATIONSHIP_IDN AS Parent,
                 PACKAGE_IDN AS Child,
                       TYPE AS Name
   FROM PACKAGE_RELATIONSHIPS AS T
   WHERE T.RELATIONSHIP_IDN = 0 -- IDN of start

   UNION ALL SELECT Parent,
                 Child,
                       TYPE AS Name
   FROM SubStruc AS S
   INNER JOIN PACKAGE_RELATIONSHIPS AS T ON S.Parent = T.PACKAGE_IDN-- going down inside the structure
)
update PACKAGE set ConsoleUser_Idn=(SELECT [ConsoleUser_Idn] FROM ConsoleUser WHERE UserName = 'Public User')
where PACKAGE_IDN in (SELECT Child FROM SubStruc)

Results below:

Owner corrected

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

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.

Description

This document is intended to assist in the troubleshooting of the Policy Sync (PolicySync.exe) process on the LANDESK Agent. Policy Sync is the primary method used to deploy both Software Distribution tasks and Patch Manager tasks to client machines. PolicySync.exe communicates with the Core server via HTTP (port 80), and is responsible for pulling down policy tasks that are targeted to the client machine. Also, PolicySync.exe is responsible for running recurring policy tasks on the client machines.

Symptoms

Some symptoms of a failed policy sync could include, but are not limited to:

1. Tasks in the console are hung with a status of "Client has initiated asynchronous policy execution."
2. When refreshing Workspace or Portal Manager new packages and links do not appear.
3. Core server can contact clients, but the client never executes the task.

Diagnose

Reading the PolicySync.exe.log

• Successful Policy Sync Log examples
  • A successful attempt initiated by a Push Task:

07/13/2015 15:23:48 INFO  3844:1     RollingLog : Run PolicySync.exe -taskid=1

07/13/2015 15:23:48 INFO  3844:1     RollingLog : Request: Request policies

07/13/2015 15:23:49 INFO  3844:1     RollingLog : Request: GetWebResponse ok

07/13/2015 15:23:49 INFO  3844:1     RollingLog : Request: Has 1 targeted policies

07/13/2015 15:23:49 INFO  3844:1     RollingLog : HandleRunNow: has 1 run now policies

07/13/2015 15:23:49 INFO  3844:1     RollingLog : Exit PolicySync.exe with code 0

07/13/2015 15:23:49 INFO  3804:1     RollingLog : Run PolicySync.exe /enforce

07/13/2015 15:23:49 INFO  3804:1     RollingLog : EnforcePolicies: check and run RunNow and Reoccurring policies

07/13/2015 15:24:11 INFO  3804:1     RollingLog : Exit PolicySync.exe with code 0

• A successful attempt for a normally scheduled Policy Sync:

07/13/2015 16:43:15 INFO  2424:1     RollingLog : Run PolicySync.exe

07/13/2015 16:43:15 INFO  2424:4     RollingLog : LoadLocalPolicyInfo: load local machine

07/13/2015 16:43:15 INFO  2424:4     RollingLog : LoadLocalPolicyInfo: load user

07/13/2015 16:43:15 INFO  2424:3     RollingLog : Request: Request policies

07/13/2015 16:43:19 INFO  2424:3     RollingLog : Request: GetWebResponse ok

07/13/2015 16:43:19 INFO  2424:3     RollingLog : Request: Has 2 targeted policies

07/13/2015 16:43:19 INFO  2424:1     RollingLog : RunPolicySync: ProcessRequestedPolicies

07/13/2015 16:43:19 INFO  2424:1     RollingLog : LoadLocalPolicyInfo: load local machine

07/13/2015 16:43:19 INFO  2424:1     RollingLog : LoadLocalPolicyInfo: load user

07/13/2015 16:43:19 INFO  2424:1     RollingLog : HandleRunNow: has 1 run now policies

07/13/2015 16:43:19 INFO  2424:1     RollingLog : Exit PolicySync.exe with code 0

07/13/2015 16:43:20 INFO  2836:1     RollingLog : Run PolicySync.exe /enforce

07/13/2015 16:43:20 INFO  2836:1     RollingLog : EnforcePolicies: check and run RunNow and Reoccurring policies

07/13/2015 16:43:46 INFO  2836:1     RollingLog : Exit PolicySync.exe with code 0

Solutions

Some common solutions are listed below. You can find the one that fits your scenario and follow the steps to try resolving the issue.

Is the problem on the Client or is it on the Core?

The easiest way to determine this is to try running a Policy Sync on multiple clients and see if you get the same error on each client.

• If only one client is receiving the error it is likely that the problem is localized to that one client machine.
• If the error is present on all clients when running a Policy Sync the problem is likely to be on the core, or in the connection between the clients and core.

Did the policies download correctly?

If you look on the client machine at C:\Programdata\LANDesk\Policies you should see policy XML and STAT files.

1. CP.{taskID}.RunNow.{hash}.xml
2. CP.{taskID}.RunNow.stat

If those files are not present, the policy likely did not download correctly.

Common errors in the C:\ProgramData\LANDesk\Log\PolicySync.exe.log file:

1. "GetWebResponse failed" or a "(503) Server Unavailable" message appear in PolicySync.exe.log
   1. Check that IIS is running on the core.
   2. Make sure that the LDAppAPM application pool is running on the Core.
   3. Attempt to connect to http://corename/apmservice/policyrequest.asmx using a browser on the client machine.
   4. Restart IIS.
2. "WriteNewPolicies.DownloadPolicyFile: exception-The remote server returned and error: (404) Not Found."
   1. This indicates the Policy XML file that should be located on the core at \Program Files\LANDESK\ManagementSuite\landesk\files\ClientPolicies is not present.
   2. Restart the associated task.
   3. Check Console.exe.log to see if there was an error when saving the task.
   4. Review How to Troubleshoot Software Distribution Task - Core Side
3. Request: Signature Verification Failed
   1. Update COM+ objects on the core with a correct Domain User account.
   2. Restart COM+.

• Purpose
• Where to start?
• Client Side Troubleshooting
• Core Side Troubleshooting
  • Log Locations:
    • Client Side
    • Core Side
• Other Information

Purpose

One of the most commonly used components of LANDESK Management Suite is the Software Distribution feature. Companies around the world use it to quickly and efficiently distribute software to hundreds, or even thousands of computers in a very short period. Some times however there are occasionally problems within a deployment task. This document will walk you through the basic steps of troubleshooting a Software Distribution task that has failed or is stuck in an active status. Also as working through the steps below you will find links to other troubleshooting documents that go into greater detail for specific issues.

Where to start?

Software Distribution has many moving parts so it is important to be able to quickly locate the failure point, and make sure to investigate the correct step in the process to resolve the issue. The following steps are commonly used by LANDESK Support to quickly locate the cause of a problem in Software Distribution.

1. Did the clients try to run the task? If yes, how many clients are affected by this error?
2. Is the problem on the Core or on the Client?
   
   • If only a single client, the problem is likely on the client itself.
   • If many clients are affected, the problem could be on the Core, Network Communication, or File Server.
3. Did the task fail immediately after being started in the console, or did it run for a while before failure?
4. Do the logs in the Diagnostics tool provide any extra information?
   1. Scheduled Tasks and Diagnostics Utility

Once we know some basic information about the failure we can move to troubleshoot it efficiently.

Client Side Troubleshooting

According to the questions above, if you find that the problem is on the client itself please refer to the following documents to continue the troubleshooting process.

How to Troubleshoot Software Distribution Task - Client Side

How To Troubleshoot Policy Sync

Core Side Troubleshooting

If from the above questions you find that you need to troubleshoot an issue on the Core Server please continue to the following documents

How to Troubleshoot Software Distribution Task - Core Side

How to Troubleshoot Agent Discovery

Software Distribution Logging

There are a couple of verbose logging options that can help provide more information on Software Distribution tasks to help in finding and resolving the issue. Some of these logs are VERY verbose, and may take some time to read through.

In the LANDESK Management Suite almost all verbose logging is controlled by a feature we call XTrace. This provides simple method of enabling the verbose logging on both the Core and Client. The following document provides the instructions for

How to enable XTrace Diagnostic logging in LANDesk 9.6 Core and Clients

Log Locations:

Client Side

C:\ProgramData\LANDesk\Log:

ServiceHost.log - Communication from the core to the client.

PolicySync.exe.log - Downloading of Policies from the core server.

PolicySync.log - Monitors the performance of the PolicySync program itself.

SendTaskStatus.log - Monitors the task status updates sent from the client to the Core.

LocalSch.log - Monitors the activity of the Local Scheduler on the client.

tmcsvc.log - Monitors the performance of the LANDesk Targeted Multicast service on the client.

C:\Program Files (x86)\LANDesk\LDClient\Data:

sdclient.log - Monitors the performance of the sdclient process.

sdclient_task{taskID}.log - Displays the progress of a specific software distribution task on the client.

Core Side

C:\ProgramData\LANDesk\Log:

SchedSvc.log - Monitors performance of Scheduler Service.

LANDesk.Scheduler.GlobalScheduler.log - Monitors the task initialization process.

LANDesk.Scheduler.GlobalScheduler.Skeleton.log- Monitors the task initialization process.

raxfer.log - Monitors the WOL discovery and sending of the wake up packets.

\Program Files (x86)\LANDesk\ManagementSuite\Log:

TaskHandlerProxy.exe.log - Gathers the task information to hand-off to PolicyTaskHandler.exe

SchedQry.exe.log - Monitors the performance of resolving LDMS queries to add target to tasks.

SchedLDAPResolver.exe.log - Monitors the performance of resolving LDAP queries to add target to tasks.

PolicyTaskHandler.exe.log - Logs the discovery and deployment of tasks to the clients.

WSvulnerabilityCore.Dll.log - Monitors task status updates from clients while tasks are processed.

Other Information

If you did not find what you are looking for with this document please see the LANDESK Software Distribution Landing Page for more information.

As I left-click to highlight the task, the right pane is unresponsive - as in it does not show the usual task status bars.  Also when I'm in the All Task group folder, right-clicking and Delete of the task doesn't seem to do anything...

I have full LANDESK Administrator rights.  I have also tried stopping the LANDESK Scheduler Service and tried deleting, but it still yields the same result.

Trying to Deploy Java JRE 8_u_25.exe using LANDesk Software Deployment and cannot get it to execute remotely!

The error I am getting is 1619 This installation package could not be opened.  Verify that the package exists and that you can access it, or contact the application vendor to verify that this is a valid Windows Installer package."

I have a batch file that has the following:

msiexec /i jre1.8.0_25.msi   -- which calls the Windows MSI installer, uses the switch /i for install, and then targets the MSI which is extracted from the executable you download from the website. 

It installs great locally but it will not execute remotely. 

I have tried using the silent switch on the downloaded .EXE file and it still threw the 1619 error.

I tried bypassing the bat file and putting the command directly into the task so it runs the executable with the /i command.

I tried using LD to copy the MSI and Bat file to the target machine, then launching the bat file on the station.

I downloaded another fresh installer from the java website to see if it was that – it wasn’t.

I tried installing it through Patch and Compliance scans and the patcher doesn’t install it.

I tried mapping a drive to a folder on the local server with admin credentials that had the install files in it and running it via mapped drive.

I verified that the installer worked by remoting to the target machine and running the bat file.  It installed just fine that way.

Need to ultimately run this installer across 3000 machines so would just soon not do it manually.  I am uninstalling a previous version of Java and installing this one in its place.  Has anyone else had luck deploying Java JRE using LD

Purpose

This article outlines how to Import/Export Distribution Packages. This can be useful for sharing customized packages.

Export

• In the LDMS Console, navigate to Tools | Distribution | Distribution Packages
• Right click the desired package, and choose Export

• In the Select Export Filename window, select a directory and provide a file name
  • The extension should be *.ldms
• Click Save

The *.ldms

file can now be imported for use on an LDMS Core.

Import

• In the LDMS Console, navigate to Tools | Distribution | Distribution Packages
• Right click the group to import the package to (i.e. My packages)
• Select Import

• In the Select File to Import window, navigate to then select the *.ldms file, and choose Open

• Double click the package from within the LDMS console now to edit its settings
• An error may appear:

The network name cannot be found.

This will occur if Primary or Additional files in the package were located at a network resource that is no longer accessible.

• Update the Primary and Additional files to point to a network resource that the new LDMS Console has access to then save the package.

Purpose

This document covers how to use Software Distribution with the package interface enabled. This can be useful when setting optional or recommended packages in Workspaces or the Portal, where the end user should have control over certain installation aspects (customization of the install).

Steps

Distribution and Patch Settings

To enable displaying the interface, a new Distribution and Patch setting will need to be used.

• In the LDMS Console select Tools | Configuration | Agent Settings
• Expand My Agent settings and select Distribution and Patch
• Click the Create New Settingbutton (green plus sign)
• Set the following:
  • General Settings: Set a name for the new setting
  • Notification: Set Progress Options | Show progress - Only when installing/removing
  • Distribution-only settings: Under Feedback check 'Display full package interface'
• Save the settings.

Software Distribution Package

Because the package is supposed to be running with the interface shown, in this circumstance there should be no silent switches defined on the packages properties.

• Open the Distribution Package properties
• Click Install/Uninstall Options
• Remove entries from within the 'Enter command line or select options above and edit command line for MSI package:'
• Click Save

Note: If using an MSI Package, Uncheck the 'Use Windows Installer to install and control installation (MSIexec)' option. This will remove the standardized MSI switches.

Scheduled Task

• Schedule the the Distribution Package
• Open the scheduled task properties
• Select Agent Settings
• Select the Distribution and patch row, and click on the settingscolumn and select the previously created Distribution and Patch setting.
• Save the task properties
• Start the task

Client Side

When SDClient calls the primary file, it should provide a notice that it is beginning the install of the Distribution Package, and the Package interface should be made visible for the end user to navigate through.

SDClient will remain active while the installer GUI is still open, and a status will not return to the core until the Package gui closes, and returns a code to SDClient to report to the core.

Scheduler task status codes

The LD_TASK table inside the LDMS database contains a TASK_STATUS column whose values are represent the status for each task.

Below are the code definitions for the TASK_STATUS column:

Machine Status

The LD_TASK_MACHINE table inside the LDMS database contains a MAC_STATUS column whose values are represent the status for each machine targeted in a task.

Below are the code definitions for the MAC_STATUS column:

Upgraded from LDMS 9.5 SP1 to LDMS 9.6 SP2. When I create a new task I can not save the changed the Legacy (pre-9.60) Settings / Delivery Method. Anyone else seen this?

I was recently tasked with deploying Lync2013 and OneDrive together as one single package for users that are not what is called an "E3".  An "E3" License allows a user to use the full Office 2013 on up to 5 machines with their e-mail address associated with their "E3" account.

The difficulty in doing this was to determine who currently has Office 365 installed, who has OneDrive installed and who has Lync 2013 installed (All Click 2 Run Technology).  I decided to write a VBScript to run to first check for the particular files, Lync.exe, Groove.exe (OneDrive), and Excel.exe.  If i find that Excel.exe in present, then I can assume that the entire Office 365 is installed, if Lync.exe is installed and neither of the other two are present then only Lync 2013 is installed.  See the logic?  While this may not be the best approach, it works very well for my environment.  I have this particular deployment as a self service installation in the Portal Manager.  If the user decides to run this, they will be prompted according to what is installed on their machine.

1. If Office 365 ProPlus with all apps is installed, then show a message box indicating such and end the script.
2. If Lync 2013 is installed, then install only OnDrive
3. If only OnDrive is installed, then install only Lync 2013
4. If Lync 2013, OneDrive, or Office 365 is not installed, then installed Lync 2013 and OneDrive

We needed this for users that are not an "E3" so they will be able to use Lync 2013 and OneDrive, but not the full Office 2013 (Word, Excel, and other apps).

If anyone is interested in the script, please send me an e-mail through this site and I will gladly provide it.

I have a scenario that I am working through:

- I have a large (3GB) Package (Package A) that I need to push to a number of PCs and run it.

- Package A is a pre-requisite to another package (Package B) that will be launched by the user from the Portal Manager.

- I plan to distribute Package A overnight.

- Users would be instructed to run Package B, at their leisure, from the Portal Manager.

- Package B would have Package A defined as a Dependent Package with detection. Detection is based on the existence of a file that only exists if it has been run.

When the user launches the job for Package B in the Portal Manager, it will only run Package A if it has not been run before. All is good with that.

The issue I have is that the user may not run the package for a while and even though Package A has been run, when the job for Package B is initiated, sdclient will download the file to the sdmcache even though the detection will show it is not required. That is fine for a small package but to download a 3GB package can take a while, especially over a slower connection!  (I know I can set a longer time to keep the file in the sdmcache folder as a workaround but would really like it if that wasn't necessary)

Is that expected behavior?

Wouldn't it make sense to do detection before the download occurs?

Any suggestions on how to accomplish a dynamic method for deploying office 2013?

I have DFS in place and the CAB/DAT files have been replicated to all 230 locations.

For the XML file, I was thinking of using an injected script via provisioning. Is there a variable that would translate to the Preferred Server?