Issue:

Sometimes drives run out of space quickly due to patching. This guide will walk you through altering the retention of files within the SDMCache Folder

9.5 SP1 and Later Solution:

Within your Agent Settings locate the Client Connectivity options. Go to the Download Tab and alter the Number of days files stay in cache to whatever value you would like.

9.5 and Earlier Solution:

Previous versions will require a registry key to be altered on the client machines. This can be done with a bat, script, or the provisioning tool. You will need to alter the following keys:

32bit

• HKLM\Software\Intel\LANDesk\LDWM\Distribution\Multicast\Discard Period
• HKLM\Software\Intel\LANDesk\LDWM\Distribution\Multicast\Subnet Rep Discard Period

64bit

• HKLM\Software\Wow6432Node\Intel\LANDesk\LDWM\Distribution\Multicast\Discard Period
• HKLM\Software\Wow6432Node\Intel\LANDesk\LDWM\Distribution\Multicast\Subnet Rep Discard Period

Default Data for Discard Period is set to (604800) in seconds = 7 days

Default Data for Subnet Rep Discard Period is set to (1209600) in seconds = 14 days

I schedule the task and after it goes to downloading it immediately fails. I can go directly to the file path and it will download the file with no problem but for some reason when it tries to download from Fuse it always fails. Also if I delete the task for some reason it still appears in Fuse for that device.

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.

The following does not have to be done from the core, but it does have to be done with an account with administrative rights.

NOTE: The below method works fine. However, in my opinion, the better method is found in  community article 10362.

Step 1:  Map a drive to the client machine’s C$.

Example: \\clientmachine\c$

Step 2: Launch your database tool. In this instance I used SQLite Manger for Firefox. You launch this tool under the “Tools” section once you have downloaded the tool from here.

Step 3: Select the Database under “Database” and navigate to the client’s database using your mapped driver. The location of the client side database is “C:\Documents and Settings\All Users\Application Data\LANDesk\Database”.

NOTE: By Default SQLite will look for SQLite extensions not the *.db3 extensions that LANDesk uses.

Step 4: Delete the following three entries from the database.

                TIP: Make sure that you have the “Browse & Search” tab selected.

1-         From the ClientOperations table find the corresponding task xml file. In this example the task was task 3. The corresponding Filename is      SDClientTask.LDMS8.3.xml.

2-         From the LastPolicyResponse find the corresponding task xml file. In this example the task was task 3. The corresponding Filename is           SDClientTask.LDMS8.3.xml.

3-         From the PackageState find the corresponding PackageGUID. In this example the task was task the corresponding PackageGUID is Package-3.

The policy will then be re-applied once the policy.sync.exe runs. Commonly this occurs once a day but can also be manually executed.          

Hi Guys,

I found an easy way to set up wallpaper to windows machines through LANDesk. Just follow the steps...

1. Select a bmp file as wallpaper

2. Rename the file as wallpaper.bmp

3. Keep the file in the network share with atleast read permission

4. Create a batch file like this

_________________________________________________________________________________________________________

@echo off
copy .\wallpaper.bmp %windir% /Y
call :quiet>nul 2>&1
goto :EOF
:quiet
REG ADD "HKCU\Control Panel\Desktop" /V Wallpaper /T REG_SZ /F /D "%SystemRoot%\Wallpaper.bmp"
REG ADD "HKCU\Control Panel\Desktop" /V WallpaperStyle /T REG_SZ /F /D 0
REG ADD "HKCU\Control Panel\Desktop" /V TileWallpaper /T REG_SZ /F /D 2
%SystemRoot%\System32\RUNDLL32.EXE user32.dll, UpdatePerUserSystemParameters

_________________________________________________________________________________________________________

5. Save the file in the same shared location of the wallpaper.bmp file

6. Create a distribution package for batch file

7. Select the batch file as a primary file (in UNC path)

8. Add the wallpaper.bmp as additional file and save the package

9. Create a schedule task for this distribution package

10. Drag and drop the target machines and start the task

Note:

The user must be logged in to the machine for the wallpaper setting to take effect.

Guys..if you have other simple ways to do this please share with us !

Regis

Targeting LDAP users and groups from Novell eDirectory requires the following patch:

SWD-2356188.2-2

There are two folders in the extracted patch directory.  The SWD-2356188.2-2 patch must be run on the core.  The SWD-2356188.2-2-client folder is the client side patch.  Running this will update the files on the client and will install the following registry key:

HKLM\SOFTWARE\LANDesk\ManagementSuite\WinClient\DisableNDSLdapUsage = 1

The setting of "1" means that the functionality is disabled, and will not be used.

After the patch is installed on the core and any existing clients, the following registry keys must be set to a value of "0".  This will enable the eDirectory location and group scanning functionality.

HKLM\SOFTWARE\LANDesk\ManagementSuite\WinClient\DisableNDSLdapUsage = 0

HKLM\SOFTWARE\LANDesk\ManagementSuite\WinClient\DisableLdapGroupEnumeration = 0

To make this configuration a permanent part of the default Agent configuration, do the following.

Browse to the LDLOGON share on the core server.  Open the ntstacfg.in# file with notepad.exe.  Search for ldap, which should take you to this section:

; LDAP groups can be enumerated on the client, this provides more information in the inventory
; database and faster targeting of LDAP groups.  This also generates network traffic between the
; client and the LDAP server, the following registry value can be used to disable this option

REG54=HKEY_LOCAL_MACHINE, SOFTWARE\LANDesk\ManagementSuite\WinClient\DisableLdapGroupEnumeration, 0, , REG_DWORD

The default value for LDAP enumeration is 1 which is Disabled.  Change this to 0, and save the file.

Add this line:

REG555=HKEY_LOCAL_MACHINE, SOFTWARE\LANDesk\ManagementSuite\WinClient\DisableNDSLdapUsage, 0, , REG_DWORD

This will enable the eDirectory LDAP reporting.

On the LANDesk Core server, go to Configure | Services | Inventory and restart the Inventory Service.  This will kick off stamper.exe, which builds the ntstacfg.ini file from the ntstacfg.in# file.

Next, in the LANDesk Console, go to Tools | Configuration | Agent Configuration and click the "Rebuild All" button.  This will rebuild the Agent_Name.ini file from the ntstacfg.in# file.

After doing this all of the LANDesk Windows Agents will have Novell eDirectory LDAP enumeration enabled when the agent is installed.

These settings will tell ldapwhoami.exe to gather LDAP information from Novell eDirectory and to put that information into inventory.

See the following screenshot for an example of eDirectory information pulled by ldapwhoami.exe with the DisableNDSLdapUsage enabled (Set to 0 in registry) and the DisableLdapGroupEnumeration enabled (Set to 0 inregistry).

The following groups are listed under the User:

• LANDESK TEST GROUP in the masterOU container
• LANDesk Software Dist Group in the masterOU container

These groups and the Novell eDirectory user "admin" can now be targeted through a LANDesk Software Distribution job using Directory Manager.

When the DisableNDSLdapUsage registry is set to the default value of 1 (Disabled), the ldapwhoami.exe will show the following LDAP output from Active Directory.

The difference can be seen in the output.  The machine is now configured to report the Active Directory LDAP information.

NOTE:  There are some limitations to using this functionality.

1.  Please note that only one LDAP source can be used for targeting machines.  This means that you can target LDAP users and groups through Active Directory OR Novell eDirectory.  You cannot pull information from both sources.

2.  In a large environment, the traffic added by the machines getting LDAP information and sending it can be considerable.  Please test this setup carefully and know your environment before making a system wide change to enable these settings.

I will be keeping a list of all updates that a customer using LaunchPad should apply.  If you are using LaunchPad it is recomended to bookmark this article.

1.  Make sure that SP2a is applied to the Core Server and Clients.  There are several LaunchPad and Policy updates that can only be gotten from Sp2a.

http://community.landesk.com/support/docs/DOC-1001

2.  The following update resolves an issue with LaunchPad links not working when an executable with more then 8 characters is used.

http://community.landesk.com/downloads/patch/SWD-1962988.2-2.zip

3.  If you highlight a link in the LaunchPad Portal and then select the "enter" key everything goes blank for a long period of time.
Note:  If you create a category called "favorites" this feature will not work.  A "favorites" category has been pre-configured.

http://community.landesk.com/downloads/patch/SWD-2080188.2-2.zip

4.  If a LaunchPad task leverages an LDAP user query and more than one person share a machine.  The users that were not targeted for the task see the URL link.

http://community.landesk.com/downloads/patch/SWD-2080688.2-2.zip

5.  Delta Scans with a Deleted Section for LaunchPad tasks, cause a 4100 Exception for the inventory server.

http://community.landesk.com/downloads/patch/INV-2123388.2-2.zip

6.  NEW:  Custom Icons are not showing up for web URL's in launch pad.

http://community.landesk.com/downloads/patch/SWD-2111488.2-2.zip

Note:  This will only resolve the issue with new links.  Not existing links.

NOTE:  See the Best Known Methods for LaunchPad:http://community.landesk.com/support/docs/DOC-4454

Description

This document describes how to deploy Windows XP Sevice Pack 3 using LANDesk Management Suite and a Distribution Package. This is most easily done using the patch content in Patch Manager, however, it is possible to manually create a distribution package.  This document describes how to manually create this distribution package.

Step 1 - Obtaining the Software

Download XPSP3 from Microsoft.  Make sure to download the full version for network installations.

http://www.microsoft.com/downloads/details.aspx?FamilyId=5B33B5A8-5E76-401F-BE08-1E1555D4F3D4&displaylang=en

Step 2 - Placing the Software on a Web Share or UNC Share

Put XPSP3 on the web share or UNC share where you packages are stored.  If you have not created a web share or a UNC share, create one now. Remember that the Core Server and the agent workstation must be able to access this web share or unc share.

Step 3 - Determine the Command Line Parameters to Use

Run the executable with a /? or /help to obtain a list of the possible command line parameters.

You probably only want one switch: /quiet.  But you may also want to use the /norestart if you don't want to reboot right away.  Or if /forcerestart if you really want the restart to occur.  If you no you don't ever want it uninstalled, you can add the /n switch to not backup files needed for the uninstall.  Open a command prompt on a test XP box and try out the switches until you have the ones you want.

Step 4 - Creating the Distribution Package

In the Console create a new Distribution Package of type executable.

1. Provide a name and description.
   
   
2. Configure the primary file to point to the executable on the UNC share or web share with that has the file.
   
   
3. There is a place in the Distribution Package to add the command line parameter that are desired.
   
   
4. Save the Distribution Package.
   
   

Step 5 - Create the Scheduled Task

Create a new Scheduled Task.

1. Add the distribution package
   
   
2. Choose your delivery method.
   
   
3. Save the Scheduled Task.
   
   
4. Drag some nodes to the scheduled task.
   
   
5. Right-click and choose Start now to start the deployment.
   
   

Important! The Service Pack has an option to extract the service pack first before deploying it. Using that method with LANDesk is only recommended if a Delivery Method is used that is configured to "Run from source".

Steps to create an SWD package to push out a shortcut to the desktop of a user</h2>

One of the more common software distribution tasks is to place a shortcut for an application onto a users desktop.

This is very easy to do using LANDesk Enhanced Package builder.

Please follow these steps:

1.  Install the LANDesk Package Builder Software on the machine that you are using as the "Source" machine.

Browse to the "
YourCoreServer\ldmain\install\Package_Builder" directory.  Run the enusetup.exe installer.  This will install the Package Builder Software onto the target machine.

2.  Once the software is installed, go to Start | Programs | LANDesk Management | LANDesk Enhanced Package Builder.

3.  Click the New document icon or go to File | New to create a blank project.

4.  Under BASE INSTALLATION choose File.

5.  Click on the Select Files button as shown with the red circle above, and browse to the desired Shortcut file.  In this case, we are pointing to a shortcut for Mozilla Firefox.

6.  Click the Open button.  This will place it in the window, but not in the above section.

7.  Click in the Destination Copy to: box, and then select the System Variable button.  This will pull up a list of available system variables.  Select the $ALLUSERSDIR$ variable which is first in the list.

8.  In the Destination Copy to: box, append \desktop to the $ALLUSERSDIR$.  It will end up looking like this:  $ALLUSERSDIR$\Desktop.  This tells Package Builder to place the shortcut onto the desktop directory for all users.

NOTE:  If the icon exists and needs to be overwritten select the Overwrite drop down and change from Default to Yes.

9.  Click the Add button which will put the entry into the upper pane with a 0001 FILE: entry.

10. Click File | Save As... and save the project to a directory.

11.  Click Build | Build

12.  The Build Install window will come up.

Select the One File Install option, and specify a folder for the build directory.  It will create the directory if it does not exist.  The Build completed window will come up with the location of the SWD package.

It will be in the build directory specified, in a directory called "Onefile".

13.  The resulting EXE file can either be run manually, or be pushed out through LANDesk using Software Distribution.

NOTE:  When creating the Software Distribution Package the type of package must be an SWD package, and NOT an EXE package.  Any package created with Package Builder must be an SWD package as seen below.

1. On the core server navigate to c:\program files\landesk\managementsuite directory.

2. Open the apmservice.ini and add a logging section and the the following value:
Keepevents=on

Should look like:

[Logging]

Keepevents=on

3. Stop and restart the APM service
Verify that the ldmain\sdstatus\stored directory was created.  If the stored directory does not get created.  Please create it.

4. Enable XTrace for sdclient

5. Rerun the policy or detached task

6. Check the sdclient log to make sure the status is being sent by sdclient.

7. Verify that the status XML file was forwarded by the alert service by checking the alert.log in the %ProgramFiles%\landesk\shared files folder. This log should list the status for the HTTP post to the core server.

Should look something like:

2009-03-03 22:30:10(5252-5544) alert.exe:Processing alert internal.192_168_0_15.swd_sdclient.status instance
  2009-03-03 22:30:11(5252-5544) alert.exe:Alert transmitted to http://LANDesk.Gateway@192.168.0.15/incomingdata/postcgi.exe?prefix=sdstatus\&suffix=.swd.xml

8. Check the IIS log on the core for the HTTP POST results. Verify event is in the stored policy events ldmain\sdstatus\stored. Also verify that the event was not put into the badstatus directory (Ldmain\sdstatus\badstatus).

9. Check APMStatusUpdateHandler.exe.log for errors.  (LDMS 9.0sp2 and later)

10. Check the version of the Core Server. The latest support packs must be installed. See Community article 1001.

It is sometimes useful to invoke an application on a remote device using a specified user context instead of the LocaSystem user.

To achieve this result, it is possible to use the attached VBS that uses WMI to invoke a process on a remote machine.

There are some limitations:

• The machine should not have the personal firewall on or it needs to be configured for WMI remote invocation.

• The process can not be interactive ( so no GUI )

• The process can not be called from the same computer when the script runs (this script can't run locally):
  If the script is executed on COMPUTER-A it is not possible to use the script with the option /COMPUTER:COMPUTER-A

• The script is given AS IS, unsupported and without any express warranty. This process does not use any LANDesk files or processes.

Syntax:

runAS /USERNAME:username /PASSWORD:password /COMPUTER:computer /COMMAND:program to run

NOTE: it is suggested to invoke the script with CSCRIPT interpreter.

Staging Files

LDMS 9.6

1. Schedule your Distribution Task.
2. Right Click on the task and select Properties.
3. Go to the Task Setting page, and select the following options.
   1. Task Type: Policy OR Policy Supported Push
   2. Download Options: Pre-cache
4. Save the task settings.
5. Add targets and run task.

LDMS 9.5

1. In the Management Suite Console go to: Tools - Distribution - Delivery Methods.
2. In the Delivery Methods tool, expand My Delivery Methods.
3. Right click on Policy, and select New Delivery Method.
4. On the Network Usage page of the settings, under "File Transfer/Source Download Options" select Pre-cache.
5. Other setting can be set as desired. Save the settings once complete.
6. Schedule the distribution package.
7. Right click the scheduled task, select Properties.
8. On the Delivery Method page, select Policy, and select your new Pre-cache method from the list of available delivery methods.
9. Save the task.
10. Add targets and run task.

Legacy Delivery Methods

When using the Management Gateway on Legacy versions of LDMS 9.0 and older, only Policy-based Delivery Methods can be used.  Such Delivery Methods do not allow for pre-staging a file but always run the primary file of the Distribution Package.

Workaround

In order to pre-stage a Distribution Package create a copy of the Distribution Package and move the current Primary File to be an additional file and replace the Primary File with a blank batch file.  Even though the Primary File will always run, it now does not matter because a blank batch will of course do nothing and will always run successfully.

This is also very useful to pre-stage files in environments where Multicast is either not desired or not functional.

Information on how to debug your Preferred Server configuration can be found here

http://community.landesk.com/support/docs/DOC-27151

For LDMS 9.0 and Newer Versions

Preferred Servers can be enabled in the LANDesk Console.  It now includes the ability to authenticate to a UNC share or a web share using the credentials configured for the preferred package server.  That way, when the share is accessed by an Agent workstation's Local System account, it will be able to access the share using the credentials specified instead of simply trying to authenticate as Local System.

1. In the LANDesk Console, click Tools | Distribution | Content Replication/Preferred Servers.
2. Click Add to add a new server, or click an existing entry and click Edit.
3. Enter the server information.
4. Click Test credentials to make sure the credentials you provided work.
   1. (Optional) If you want to use IP address ranges to lilmit which clients you want using this server as a preferred server, click on "IP address ranges" enter the the IP addresses and click Add.
      
5. Click Save.

For all versions of LDMS, the package server must have the exact same share name and directory structure as the source referenced in the distribution package. This works for both UNC and URL paths.  The folder structure on the Package Server must reflect the structure on that of the core server.

For example, if the packages on the core server can be found here:

CoreServer\packages\

Then on the package server called PackageServer, they should be found here:

PackageServer\packages\.

For web it is similar:

The preferred server settings are automatically updated on the clients every 24 hours. These settings are stored in the file %ProgramFiles%\LANDesk\ldclient\sdmcache\preferredservers.CoreServerName.dat

For LDMS 8.7 and 8.8

Preferred Servers can be enabled in the LANDesk Console.  It now includes the ability to authenticate to a UNC share or a web share using the credentials configured for the preferred package server.  That way, when the share is accessed by an Agent workstation's Local System account, it will be able to access the share using the credentials specified instead of simply trying to authenticate as Local System.

1. In the LANDesk Console, click Configure | Preferred server.

2. Click Add to add a new server, or click an existing entry and click Edit.

3. Enter the server information. If you want to use IP address ranges that you want this server to be available to, enter them and click Add.

4. Click Test credentials to make sure the credentials you provided work.

5. Click OK.

For all versions of LDMS, the package server must have the exact same share name and directory structure as the source referenced in the distribution package. This works for both UNC and URL paths.  The folder structure on the Package Server must reflect the structure on that of the core server.

For example, if the packages on the core server can be found here:

CoreServer\packages\

Then on the package server called PackageServer, they should be found here:

PackageServer\packages\.

For web it is similar:

The preferred server settings are automatically updated on the clients every 24 hours. These settings are stored in the file %ProgramFiles%\LANDesk\ldclient\sdmcache\preferredservers.dat

For LDMS 8.6.1 and Previous Versions

Modify this registry key on client machines:

HKEY_LOCAL_MACHINE\Software\LANDesk\ManagementSuite\WinClient\SoftwareDistribution\

Add a new string value named PreferredPackageServer. Set this to the name of the package server.

For  how to set up an HTTP share:

http://community.landesk.com/support/docs/DOC-6986

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:

Description

If you want to copy file(s) to a client machine using LDMS, you might see these errors:

• Batch file fails to copy file

If you want to update file(s) on a client:

• Error: Access Denied copying file

Resolution

These are two possible solutions using batch files with a Software Distribution task.

I. Create a batch file distribution package that has the files to be copied as additional files listed in the package.

1. Create a batch file distribution package in the LDMS Console
2. Copy the files to be copied to the same directory that the batch file is stored in.
3. Add the files to be copied as additional files in the properties of the distribution package.
4. In your script, set the batch file to copy the files from the sdmcache directory to the destination directory.

The syntax to use in the batch file would be:

xcopy file.exe "c:\program files\my program\file.ext"

Since the files to be copied will be downloaded to the same directory as the batch file in the sdmcache folder, a path to the files is not necessary.

NOTE: This is the preferred option for using a batch file to copy files.

II. Use a batch file distribution package, have the batch file copy the files from a network location to the destination directory.

The syntax to use in the batch file would be:

xcopy \\network share\file.exe "c:\program files\my program\file.ext"

This option can be problematic. It might be necessary to map a drive to the share in the script. Also, since LANDESK is using the Local System account to run the batch file the Active Directory group "Domain Computers" must be listed in the share permissions.

The client machine deploy agent with portal manager.

When click the 'refresh' button on the portal manager, there is 'time out' happened.

There is Anti-virus software installed on client and the Policy.Sync.exe might getting scanned heavily by Anti-virus software.

You can get the promon.exe to collect the log files and send to support team.

Disable the Anti-virus software and click the refresh button again. The refresh can be done successfully.

If there is no time out error but the package still cannot be shown on portal. You can go to this help document: How to troubleshoot when package is not shown on portal manager

LANDESK Management Suite 9.5 SP1 or SP2

Have a .pkg that I have zipped and created a Mac Distribution package for but it will not install silently on the client machine.  What are my alternatives?

Hello,

I have more than 100 content replication tasks, and i want to replicate only one source path.
In UI console, i can right clic/start content repication only on selected source path, but how to do the same with a scheduled tasks or a batch ?

A scheduled task replicate all sources for the specified target, this is not a solution.

I found in C:\ProgramData\vulScan\FileReplicationSettings.xml (found on client) that each source has a ID, but I don't know which switch can be used with vulscan.exe to put with.

Thanks

As a newbie struggling a little to find answers to im hoping some simple issues

Basically i created a bat file distribution package to simply copy some files to a device then move them to a new location

I tested on a single machine and all worked well

I tested on a 15 device pilot and again all went ok

i then updated the files that i wanted to copy (approx same size) and went for a 70 device pilot

Pretty much 100% failure rate with a return code of 16422

The package is the same barring the content (they are the same type of file and same size just a newer version)

So my question is

If i changed the files that it was sending do i need to rehash the job as i have read in a support doc this could be a cause of the issue

Or

I did notice while watching the job that the data transfer rate was a lot slower than when i did the 15 device pilot. Could it be a bandwidth issue at server end as at device end ping times are still within acceptable limits or am i missing something else

All comments would be a massive help

I schedule the task and after it goes to downloading it immediately fails. I can go directly to the file path and it will download the file with no problem but for some reason when it tries to download from Fuse it always fails. Also if I delete the task for some reason it still appears in Fuse for that device.