Description:

The idea of this document is a resource for what to look for when an Software Distribution job fails.  It's intent is to help anyone using the LDMS product narrow down the cause of a failed Software distribution job.  This document is not intended to cover high level troubleshooting (I.E. using Xtrace and Packet captures).

                Assumption:

This document is assuming that the Software Distribution job has actually attempted to run on a system.  This document is not going to cover scenarios or problems that may occur with "Scheduling" a Software Distribution job.  Troubleshooting the "Global Scheduler" is an entirely different topic.

                  Understanding how Software distribution tasks run:

The first and worst assumption that is always made is the following:  "The software installs fine if I browse to the location and run it manually".  This is the biggest misconception that almost everyone makes when trying to diagnose a Software Distribution task.  When a task is run using this method, it is ran as the logged in user, or if desired the "Run as" option is selected and it runs as a specific user.  By default LANDesk runs it's tasks using "LOCAL SYSTEM".
The only way that a Software distribution job should ever be tested is trying the run them as " LOCAL SYSTEM".  The following document will walk you through testing an application as "LOCAL SYSTEM".  http://community.landesk.com/support/docs/DOC-2316
Once you have brought up the "LOCAL SYSTEM" CMD prompt do the following.  Use the "NET USE" command to map a drive to the software location.  Make sure that when the application is selected the switches that may have been added when creating the task are used.  (For Example: msoffice.exe /q)

If the application still fails

• The application should always be tested on a multiple systems.  It is possible that a single test system may have a problem.
• Make sure "LOCAL SYSTEM" has the appropriate rights to the share.
• If the same failure occurs on all test systems a call should be made to the vendor of the application that you are trying to deploy.  The vendor is always going to have the most insight as to why their applications fail to install.  It could be something as simple as a switch that cannot be passed, or something as unlikely as certain operating system patches have to be applied first.
• Before any Software Distribution packages are created using LDMS it should be tested using the above method first.  Verify all is working as expected.

I can now run the software as "LOCAL SYSTEM"

                What should I check on the client side:

The sdclient_taskXXX.log in the ldclient\data folder.  This log contains almost everything that should be know about the task.
Open this log and scroll to the bottom.  If the job is failing something like this will be seen:

Fri, 23 Jan 2009 12:40:47 .\AdditionalFiles.cpp(62): (8DAC4026): Failed to download file http://LANDesk.Gateway@10.4.42.98/ldlogon/FileLists/taskmanifest.WLUDEV071119.154.2303.ini : (80070002)
Fri, 23 Jan 2009 12:40:47 processing of package is complete, result -1918091226 (0x8dac4026 - code 16422)

According to this log the taskmanifest file is not being downloaded to ldclient\sdmcache.

What to do with this information:

At this point we have an failed result code that is highlighted in red.  You should go to http://community.landesk.comand search for what is highlighted in red.  I would first put both together.  If I get nothing search for the results separately.  -1918091226 first.  If I get no hits search for (0x8dac4026 - code 16422).  These questions are usually answered in the community.  If not, you know what to talk to the support tech about.

Downloaded http://ci-ldms/Ldpackages/SWDistribution/JR142_18b/Ldms/Onefile/JR142_18b.exe did not match the hash, expected o23uEj6jKNWh+0pDt9oK1g== actual JE1ajAIxHFHUTV11Hs73fQ==
Mon, 15 Dec 2008 11:55:17 .\AdditionalFiles.cpp(227): (8DAC4027): Failed to download and hash all additional files.

According to this log there is a problem with hashing of files.  There is already a great document on this issue.  http://community.landesk.com/support/docs/DOC-8224.

Also searching the results in http://community.landesk.com is always a good thing to try.

Note:  No matter the error message seen in the console.  It is always best to review the sdclient_taskXXX.log first.

               What if I know my task installed successfully, but the status on the core server is not reflecting a success.

There are a couple of reasons that can cause this issue:

1.  Return Codes- Some vendors will send back a return code that is a non "0" for a success.  LANDesk interprets anything that is not a "0" return code as a failure.  This is common in applications like Office 2007.  In the case that a vendor goes away from the standards and uses non "0" return codes as success.

In LDMS 9.0 or newer, the Return Code Template that is associated with the package can be changed to include this non-zero exit code as a successful exit code http://community.landesk.com/support/docs/DOC-7489

In 8.8 and older versions, the resolution is to use a batch file.  See article:  http://community.landesk.com/support/docs/DOC-2320

2.  Client is simply not sending the status back to the core-  This can be narrowed down by looking at the following article.  http://community.landesk.com/support/docs/DOC-2919

               What can be done to make sure I limit the possibilities that LANDesk is going to be the reason a job fails.

1.  Make sure your core & clients are on the latest service pack.

2.  Make sure that your clients have the latest version of lddwnld.dll, and tmcclnt.dll.

3.  Configure the Core Server and all shares the software packages are stored on to be Preferred Servers.  This is easily configured on the Core server under Tools | Distribution | Content Replication/Preferred Servers.  An IP range does not have to be configured.  See Article: http://community.landesk.com/support/docs/DOC-1385

NOTE:  See the following for more information on Troubleshooting Policies: http://community.landesk.com/support/docs/DOC-3245

Purpose

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

Steps

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

Related Documents

LDMS 9.6 Additional Logging Options

Hello.

I'm in a situation where I would like to make both the MUIs and proofing tools for Office 2013 available to my users (we are a global company), but I do not want to put 15 MUI tasks and 15 proofing tools tasks in each users Desktop Manager as it would simply be too excessive and clutter things up.

Does anyone have a good idea how to handle such situation?

My own initial thought was to create my own "launcher" for this so I would only have 1 task for installing MUIs and 1 task for installing proofing tools (or maybe even combine them so only 1 task in total). This task would run an application that listed all the available languages and the user can then tick a number of boxes to have certain languages installed. The "launcher" would then via LANDesk SDCLIENT.exe with the correct parameters do the installation just as if started as a normal task.

While this seems to work via manual testing, there are some downsides to it:

• Getting the correct parameters (correct hash values and such) for each task takes a little time (assign the task to a device using a delivery method that supports deferral, defer the task and get the parameters from local scheduler)
• If the package is modified, then the hash will change and parameters needs to be collected again and "launcher" updated with new parameters
• The normal sdclient_taskxxxx.log files are not used - everything is logged to sdclient.log
• Not much central visibility over which devices ran which MUI and proofing tools tasks (except for querying for installed software)
• The "Inventory settings" in "Agent settings" are not used, so no task history in inventory or updating inventory after install

Other issues may exist as well, but those are the most obvious to me.

So while it might work, there is a fair amount of work to be done before it's ready to use and some amount of work in maintaining it.

The ideal situation in regards to sdclient.exe would be that you could launch a task by simply using the taks ID as a parameter and then it would get all the information from the CORE, but that doesn't work and I can see several obvious reasons for such feature not to be implemented.

Any suggestions on how to best solve this situation is greatly appreciated.

Thanks in advance.

Have yet to upgrade to 9.6, we were waiting for the service pack to come out. How has it been working/any major problems encountered?

Is there a way to distribute software to devices using multicast distributing if there is a machine at that location already on LDMS 9.5?

I am trying to get all devices on subnet on LDMS 9.5 without having to touch every machine, its about 700 computers...

One of these days maybe I wont have to say this . . . . I'm pretty new to Landesk.  I have deployed new agent on a domain of about 1000 computers. I have also started software distriribution and begun managing patch management.

Multicast still confises me a bit.  I remeber a few years back and I set up a computer and somone ELSE remoted in and set up IIS to turn that computer into a peer repository (still unfamiliar with all the terms - yes I am devouring the manaual.).  Fast forward two years and a different netowrk with Landesk 9.5.

Without anything but a core server and many clients that have no additional settings other than current agent installed and running normally,spread across many subnets, how does multicast work. If I deply a msi software package acriss the entire domain, will the first few machines on any subnet that receive the distribution then begin to act as repositories for peers on the same submet?  This happens without any additional configuration?

Now, what about TARGETED multicasting?  Is this where I "seed" the network with the package on a few machines on every subnet and then, once in place, push out the MSI to everyone?  Is the different between this targeted approach and just setting multicasting on a package without any TARGETING simply that I am controling the placement and WAN to LAN switch over so to speak and it is much more controlled whereas multitasking wthout any such seeding is more of a shotgun blast and let LANDesk sort it out from there?

Amd what's the differenct between this and what this person was attempting to do a couple years ago.  I suspect this was trying to set up a DISTRIBUTION server.   I understand the concept of distribution servers and that I can have different agents look to different servers. But i need to understand multicast strategy better.

Thanks!

As of LDMS 9.6 we have introduced Reboot Settings, in doing so we have integrated the reboot behaviors of Software Distribution and of Patch Management. All the settings discussed here apply to both Mac OSX and Windows allowing for a more unified approach to managing reboots on your client machines. This document is to walk though and explain the features and how to include them into your tasks.

When you have scheduled a Software Distribution or a Patch repair task you can specify which reboot settings you would like the clients machines to use to fit your needs.

1. To Create New Settings:
   1. In the Management Suite Console go to Tools - Configuration - Agent Settings.
   2. Expand My Agent Settings, select Reboot Settings.
   3. Right click in the settings list, and select "New..."
2. To Apply Settings To A Task:
   1. In the Management Suite Console go to Tools - Distribution - Scheduled Tasks.
   2. Locate the task you would like to change the reboot settings on.
   3. Right click on the task and select Properties.
   4. Go to the Agent Settings section.
   5. In the "Settings" column, double click on the "Keep agent's current settings" next to "Reboot settings"
   6. Select the desired Reboot Setting from the drop down list.
   7. Click Save.

               **If you have already started the task, you will need to restart the task for the change to take effect. Any machines that receive the task after that will use the newly assigned setting.

Let's review the Reboot Settings options and features.

• Reboot Setting: General Section
  • Here you can select to reboot Always, If Needed, or Never.
  • Once your Reboot Settings are configured you can easily review the reboot conditions.
  • Select if a certain settings is to be assigned as the default.

• Reboot Setting: Prompt Section
  • Customize the reboot prompt message, and branding users will see when prompted to reboot.
  • Allow users to Snooze the reboot X amount of time.

• Reboot Setting: Automatic Reboot section
  • Place conditions on when to automatically force a reboot on the machine.
    • Logged out for X amount of time.
    • Locked or logged out for X amount of time.
    • No response to reboot prompt for X amount of time.
    • Reboot deadline exceeds X amount of time
  • Create a specific reboot window.
    • Can be limited to a certain window during the day, on any day of the week.
    • Only applies to LANDESK initiated reboots on Distribution and Patch tasks.
      • If a package or patch install attempts to reboot we may not be able to stop it. In which case proper command line parameters need to be placed on the install to prevent reboot.

• Reboot Setting: Do Not Disturb section
  • Prevent reboots from happening if certain processes are running (i.e. Powerpoint, Keynote, etc..)
  • Add any EXE or APP process you need, will apply to OSX and Windows as needed.
  • Specify if the app has to be in Full Screen (presentation) mode, or if it only has to be running.

Whichever setting is applied to agent as its default will update automatically whenever vulscan.exe runs (Once per day by default).

LANDESK Management Suite 9.6

Platform:

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

Problem:

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

Scenario:

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

Solution:

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

2. Next find the script named Package Sync;

3. Then right click on it and schedule it;

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

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

I'm trying to put together a MSI distribution package for ApplicationXtender Desktop 6.5 with retrieval only option.  It is a MSI install, and I have the command line as:

/i /quiet ADDLOCAL=DocumentManager /norestart

The installation files are stored on network storage.  I have double checked the path and it matches what I have set up in LANDESK.  I added the whole ApplicationXtender Desktop installation directory into "Additional files," minus the MSI itself.  Scheduled the task and ran it, but keep getting this error:

"One or more of the depend files could not be found."

Error code 16418.

I have tried resetting the package hash, and also tried starting over by deleting and re-creating the distribution package, but nothing seems to work.  What am I missing here?

Environment:

LDMS 9.6

Problem:

After beginning task clients are stuck in an active state with a task status of "Client has initiated asynchronous policy execution", and never progresses.

Purpose:

This document is designed to help identify the point of failure that lead to the task hanging in the console, whether that was a problem with Core communication, or clients failing after receiving the task. As you go through the steps, when you identify the step in the process with the error you will shift into troubleshooting that particular step of the process as the following steps are dependent on the success of the preceding steps.

Cause:

While this status is NOT an error message, it simply means that the core tried to contact the device and told it to check in and grab the task that it needs to install. However, sometimes the machine does not respond that it received the task and does not run it, and since the core at this point is waiting on a response from the client machine it leaves the task in an active status. We need to look at the clients and find out why they did not get the task.

Troubleshooting Steps:

A. Core and Client Communication:

1. Check the PolicyTaskHandler.log on the core for errors. It should have discovered and sent the sync command to each client, if successful it should look like this. If there are errors there, investigate further.

11/24/2014 22:37:13 INFO  5936:1    RollingLog : [Task: Firefox 26++ - 10/29/2014 1:42:08 PM, TaskID: 2080, ProcID: 5936] : Discover: Discovering machine: [Client123] using it's known ip address [10.14.111.50]...

11/24/2014 22:37:15 INFO  5936:1    RollingLog : [Task: Firefox 26++ - 10/29/2014 1:42:08 PM, TaskID: 2080, ProcID: 5936] : Discover: Successfully discovered machine: [Client123]

11/24/2014 22:37:15 INFO  5936:1    RollingLog : [Task: Firefox 26++ - 10/29/2014 1:42:08 PM, TaskID: 2080, ProcID: 5936] : TargetMachineContainer.MachineTargetOS: Operating System is: [Microsoft Windows Server 2012 R2 Server Datacenter Edition (full installation), 64-bit] for machine: [Client123]

11/24/2014 22:37:15 INFO  5936:1    RollingLog : [Task: Firefox 26++ - 10/29/2014 1:42:08 PM, TaskID: 2080, ProcID: 5936] : SyncPolicyTask: Synchronizing policy with the command: [C:\Program Files (x86)\LANDesk\LDClient\PolicySync.exe -taskid=2080], to machine: [Client123]

    **On LDMS 9.6 the PolicyTaskHandler.log is located on the Core Server at \Program Files\LANDesk\ManagementSuite\Log\PolicyTaskhandler.log

2. Check the ServiceHost.log on the client machine to verify it received the command to synchronize and execute the task. If it was successful  you should see the following line in the log.

Mon, 24 Nov 2014 22:37:15 4856: Exec: Exec: Launch request <"C:\Program Files (x86)\LANDesk\LDClient\PolicySync.exe" -taskid=2080> (sync 0, timeout 2147483647)

    **In LDMS 9.6 without any Service Packs installed the ServiceHost.log file is located in the following locations:

          32-Bit Clients: C:\Windows\System32\ServiceHost.log

          64-Bit Clients: C:\Windows\SysWOW64\ServiceHost.log

    ***In LDMS 9.6 SP1 and later the ServiceHost.log is located at C:\Program Files (x86)\LANDesk\Shared Files\ServiceHost.log

B. PolicySync.exe

1. On the client machine look at the PolicySync.exe.log checking for any error messages. If it was successful you should see something similar to the following. If there are errors, investigate further. Note that HTTP errors will be placed in this log, you can double check the error code and match it to the error code in the IIS logs on the core server if present.

11/24/2014 22:37:18 INFO  244:1     RollingLog : Run PolicySync.exe -taskid=2080

11/24/2014 22:37:19 INFO  244:1     RollingLog : Request: Request policies

11/24/2014 22:37:20 INFO  244:1     RollingLog : Request: GetWebResponse ok

11/24/2014 22:37:20 INFO  244:1     RollingLog : Request: Has 1 targeted policies

11/24/2014 22:37:20 INFO  244:1     RollingLog : HandleRunNow: has 1 run now policies

11/24/2014 22:37:20 INFO  244:1     RollingLog : Exit PolicySync.exe with code 0

C. SDClient.exe and Vulscan.exe

1. Once the policies synchronize PolicySync.exe calls on SDClient.exe (Software Distribution) or Vulscan.exe (Patch Management) to execute the task. It is at this point that the core will finally receive its first update to the task status and will not longer show the "Client has initiated asynchronous policy execution" message. You can find the logs for SDClient and Vulscan.exe on the client machine, from there you can verify any errors.

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

C:\Program Files (x86)\LANDesk\LDClient\Data\SDClient_task##.log

-OR-

C:\ProgramData\Vulscan\Vulscan.log

C:\ProgramData\Vulscan\Vulscan.1.log

C:\ProgramData\Vulscan\Vulscan.2.log

C:\ProgramData\Vulscan\Vulscan.3.log

Unfortunately there is not a one size fits all response to tasks get hung with that status. However, it is a fairly safe bet that if multiple machine in the same task got hung up, they got hung up for the same reason. So fixing the issue on one machine may fix it for the rest. However, as always if you have any questions, or get stuck during the troubleshooting process please contact LANDESK Support to assist in finding and resolving the problem.

Hi Friends,

Please help me with how to uninstall VS studio 2012 silently from the landesk SW distribution. I have tried the below script manually that worked fine. Kindly help me on this

@ECHO ON

\\ Servername\VISUAL_STUDIO\VS_Premium_2012_English_Core_MLF_X18-35860\vs_premium.exe /uninstall /force /quiet /silent /noweb /norestart

EXIT /B 0

Thanks

We are attempting to perform a standard push of Adobe flash and clients are reporting "Task has been placed in Transport Queue" return code 1003.

Landesk 9.5 SP1

Does anyone know if there is a way to either limit the number of times a user can install the same software title assigned to them via Landesk, or is there a way to block a user from installing software on any machine they log into?

for the most part, software is assigned to an user's machine. But for a large number of users, the software is assigned to their ID so the software is available to install as soon as they log into their new machines. Those users in particular can install software assigned to them on any machine they log into. We are researching possible ways to restrict this. Like looking for a way to block faculty from installing software assigned to them on their graduate student machines or TA machines or on lab machines, etc. A few have realized they can do this... Perhaps we can limit the number of times a specific user can install a specific software title?

Banner is our parent system, some of that information is passed to AD which our LANDesk is connected to.

Any help is greatly appreciated!

Explanation

There are many new features to Software Distribution in LDMS 9.6 SP1. Some are visible, and some are enhancements that took place behind the scenes to improve performance. Below you will find a list of the most important and exciting changes.

Distribution Package Changes

1. Signed PowerShell Scripts

  LDMS 9.6 SP1 has the ability to deploy signed PowerShell scripts adding another layer of security to PowerShell deployments. However this requires that the environment be configured correctly ahead of time to allow the signed scripts to run. Basically put you have to be able to run them securly outside of LANDESK before you will be able to deploy a signed PowerShell script inside of LANDESK. For this you have to import your PowerShell certificate into each client that will be running the scripts.

  Also to control whether LANDESK is going to handle the script as signed or not we have added PowerShell Security Options to the Package UI. By default this value is unchecked, making no change for existing PowerShell packages. The default value can be changed to always pre-check this box in the Distribution Package Properties by clicking on the Default Package Settings cog icon in the toolbar. Select PowerShell security, check or uncheck the box as desired, click Save.

2. Metro App Distribution Packages

  Also new in LDMS 9.6 is the ability to deploy Metro Apps for Windows 8.1. Due to the security constraints placed on Metro Apps by Microsoft, the apps are only able to be "sideloaded" by LANDESK, and thus it requires your clients be configured to allow sideloading apps. You can find more information on this process here (Sideloading Requirements).

  To create a new Windows Metro Application package, in the console go to Tools - Distribution - Distribution Packages, in the toolbar click on "New Distribution Package", and select "New Windows Metro Application package." Point to the .APPX file as your primary file, and add any necessary additional files. Then schedule and deploy as you would any other software distribution task.

3. Link Package Icons

  In line with changes made in LDMS 9.6 to allow you to use JPG and PNG files for your Portal Manager and Fuse icons, we have now extended that capability to Link Packages. Current packages with the standard .ICO files will continue to function the same, however any NEW Link Packages will require the link icon be provided as a JPG or a PNG file. For the best result please use a PNG that is formatted as 320x200 pixels in size.

Core Server Changes

4. SchedQry.exe and SchedLDAPResolver.exe improved, what took hours may only take minutes.

  The processes for resolving queries when tasks are started, and also in charge of running once an hour (Default schedule) to re-resolve those queries and add or remove machine from tasks as necessary has been improved with Multi-Threading and also Results Caching. With the Multi-Threading the processes are able to resolve queries much more rapidly, also we have implemented very strict logic to control how many threads are used to ensure the best use of resources. Likewise, we also employ results caching so that we avoid re-resolving the same query for each task it is targeted at, improving resolution time, and taking some of the load off of the database.

5. Enhanced Accelerated Push options

  A new option to control how long a task spends actively pushing out to clients has been added. "Maximum Task Run Time" allows you to choose how long you want a task to keep actively pushing out to devies before failing the task. This allows you to run a push, but ensure that it stops rolling out to machines after a certain amount of time to not overlap any other tasks that may need to run. By default the task will stop pushing out after 30 Minutes, this is also the smallest amount of time that you can set the Maximum amount to (option can range from 30-240 minutes), if the task finishes running before this, it is done and will move to a completed status. This setting only controls how long the core will actively try to contact machines to run the task, the minimum time of which is 30 minutes and if you have a task that takes longer than that to contact all the machines, you can allow up to 240 (4hrs) for the core to contact all the devices in the task.

  To access this option go to the Console and click on Tools - Distribution - Scheduled Tasks, click on the cog icon in the Scheduled Tasks toolbar, and select Default Scheduled Task Settings. Look at the Accelerated Push settings to see the slider bar to set the Maximum Task Run Time.

6. New option for when users are logged off their machine.

  We now have the option that if a user is logged off their machine, the task can be automatically delayed to Run at Next Logon. This allows flexibility in controlling when tasks are run on client machines. Also of note, is even if a user is logged on, you can also automatically defer the task until the next logon to ensure a cleanly logged in machine for installing packages. This is great for tasks that require programs to be closed when installing, as the install happens before the user opens their programs to begin their work.

  These options are found in the Distribution and Patch settings. In the console go to Tools - Configuration - Agent Settings, expand All Agent Settings and click on Distribution and Patch. Select the settings you would like to alter from the list or create a new setting. Once inside the Distribution and Patch setting Properties do the following:

• Logged Off User, Run at Next Logon option
  1. Expand Distribution Only Settings
  2. Select Logged Off User options
  3. Set the behavior to Run at Next Logon.
• User Logged On, Automatically Defer Until Next Logon option
  1. Click on Distribution-Only Settings
  2. Check the option "Defer Until Next Logon"

7. Task Visibility - Stages

  One of the most informative new features of LDMS 9.6 SP1 is the ability to see at a glance what stage machines are in while running a task. The stages from beginning to end are:

1. Core Initiated - Core is processing task, and contacting clients.
2. Starting - Client has received task and is preparing to run it.
3. Downloading - Client is downloading files.
   • During this stage, if "Send Detailed Task Status" is enabled, a progress bar showing the download percentage is visible in the task progress view.
4. Installing - Installation is running on client.
5. Completed - Task is done running on client machine (regardless of failed or successful status)

8. Scheduled Tasks and Diagnostics Utility

Learn more about it here:

Scheduled Tasks and Diagnostics Utility

9. Package Relationships UI

Learn more about it here:

Package Relationships new in LDMS 9.6 SP1

Product Version:

LDMS9.0 SP3 and later

Problem Description:

When you trying to use policy supported push delivery method deploy a patch but failed saying: “Error downloading package" or in the sdclient.log showing ldrunner.exe is not in cache.

Error message and all the strange behavior:

1. In the schedule task Result: Error downloading package

   Return code: 105

2. <<CLIENT SIDE LOG>> sdcliend.log 

Processing package : Repair MS13-038_MSU (INTL) -sco-it-55263

Fri, 31 May 2013 11:08:32 File (http://CFLANDESK01.metcash.com/landesk/files/ldrunner.exe) is not in cache

Fri, 31 May 2013 11:08:32 Will attempt Peer Download.

Fri, 31 May 2013 11:08:32 Will attempt Preferred Server Download.

Fri, 31 May 2013 11:08:32 Do not go to source for download.

Fri, 31 May 2013 11:08:32 About to call DownloadFiles (1 files) with these settings:

Fri, 31 May 2013 11:08:32 m_allowedBandwidthWAN: 100

Fri, 31 May 2013 11:08:32 m_allowedBandwidthLAN: 100

Fri, 31 May 2013 11:08:32 m_maxDiscoveryThreads: 15

Fri, 31 May 2013 11:08:32 m_discardPeriodSeconds: 604800

Fri, 31 May 2013 11:08:32 m_preserveDirectoryStructure: 1

Fri, 31 May 2013 11:08:32 m_bUseWanBWForPush: 0

Fri, 31 May 2013 11:08:32 m_bSynchronize: 0

Fri, 31 May 2013 11:08:32 m_downloadControl: AttemptPeer

Fri, 31 May 2013 11:08:32 m_preferredServerControl: RequirePreferredServer

Fri, 31 May 2013 11:08:48 processing of package is complete, result -1918107543 (0x8dac0069 - code 105)

3. On the client side there is @@partial@@ldrunner.exe showing in this location C:\program files\landesk\ldclient\sdmcache\landesk 

Cause and reasons

a. There will be a distribution package created automatically once the policy support delivery method are created to download the ldrunner.exe.

b. ldrunner.exe is a helper application for patch manager when patch are triggered by policy support delivery method.

c. ldrunner.exe will trigger the patch manger to do the installation when the prerequisite are meet.

Here are possible steps you can check:

1. Check if the file share can be access from the client side.

2. Make sure all the "Allow source" option are checked:

   a. Check scan and repair setting->Network settings->Make sure "Allow source" are checked.

   b. Check delivery method->Policy delivery method->Network usage->Check "Allow source" option.

3. Check in the schedule task->delivery method->Correct delivery type and delivery method are choose?

4. Try to reset the hash of the package by follow this document. http://community.landesk.com/support/docs/DOC-9309

Hi!

I'm traying to deploy an .MSI package with this batch:

mkdir "C:\Program Files\Interactive Intelligence"
mkdir "C:\Program Files\Interactive Intelligence\ICUserApps"

MSIEXEC /i "\\10.181.112.73\c$\Users\CCGS5425\Desktop\ITAU\Fabio\Eficacia Comercial\UserApps_32bit\ICUserApps_32bit.msi" /qn /norestart /l*vx "C:\Program Files\Interactive Intelligence\ICUserApps\ICUserApps_32bit.log" ICSERVERNAME=clstgcicp00v1 ADDLOCAL=Feature_InteractionClient,Feature_ICNE
MSIEXEC /update "\\10.181.112.73\c$\Users\CCGS5425\Desktop\ITAU\Fabio\Eficacia Comercial\UserApps_32bit\ICUserApps_32bit_SU5.msp" /qn /norestart /l*vx "C:\Program Files\Interactive Intelligence\ICUserApps\ICUserApps_32bit_SU5.msp.log"
MSIEXEC /i "\\10.181.112.73\c$\Users\CCGS5425\Desktop\ITAU\Fabio\Eficacia Comercial\UserApps_32bit\LanguagePlugins\ICUserApps_LanguagePlugin_es.msi" /qn /norestart /l*vx "C:\Program Files\Interactive Intelligence\ICUserApps\ICUserApps_LanguagePlugin_es.log"
MSIEXEC /update "\\\10.181.112.73\c$\Users\CCGS5425\Desktop\ITAU\Fabio\Eficacia Comercial\UserApps_32bit\LanguagePlugins\ICUserApps_LanguagePlugin_es_SU5.msp" /qn /norestart /l*vx "C:\Program Files\Interactive Intelligence\ICUserApps\ICUserApps_LanguagePlugin_es_SU5.msp.log"

But for some reason i can make the deployment.

The files are 4:

And also try to make the deployment thru "New MSI package":

/i /update "\\10.181.124.122\Patchs\Eficacia Comercial\UserApps_32bit\ICUserApps_32bit_SU5.msp" /qn /norestart

But still NO luck

Can anyone help me!!!

thanks!!

Start Registry Editor (Regedt32.exe), and then create the following path and keys in the registry: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer

Reg_SZ: Logging

Value: voicewarmup

The letters in the value field are the options that are available to use with Windows Installer logging. You can use the options in any order. Each option turns on a specific logging mode. For MSI version 1.1, the function of each option is as follows :

v - Verbose output

o - Out-of-disk-space messages

i - Status messages

c - Initial UI parameters

e - All error messages

w - Non-fatal warnings

a - Start up of actions

r - Action-specific records

m - Out-of-memory or fatal exit information

u - User requests

p - Terminal properties

+ - Append to existing file

! - Flush each line to the log

• - Wildcard, to log all information except for the v option. To include the v option, specify *v. It is recommended that you use this service only for troubleshooting. Leaving the service turned on creates a new Msi*.log file every time you use the Add/Remove Programs tool in Control Panel. This activity adversely affects system performance and disk space.

The file name of the new log varies, but the file name begins with the letters "Msi" and ends with a .log extension. To find the location of the new log in the Temp folder, type cd %temp% at a command prompt, and then press ENTER. Sort on the File Date and the new log should come to the top.

Environment

8.7 to 9.6

Description

If a machine is off when a local scheduler task is set to run, the task will be started immediately after the machine starts and the local scheduler is available.

Exception

The exception to this is if there is a time of day filter setup on the task.

For example, if a task is set to run at 6 AM and the machine is off, it will usually run when the machine is turned on.

If there is a filter set on a machine to only run during certain times then if the logon time is outside of that filter the task will not start.

We have also included a Maintenance window in our newer versions (9.5) which behaves in a similar way as this filter.

Environment

8.7 to 9.6

Delivery Methods

When using the Management Gateway, 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 prestage 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 prestage files in environments where Multicast is either not desired or not functional.