Error 1619. This installation package could not be opened. Verify that the package exists and is accessible, or contact the application vendor to verify that this is a valid installer package. I send this package to 8 computer and 6 go well and 2 failed.

Issue

• PolicySync.exe.log shows errors

Request: exception - The remote server returned an error: (503) Server Unavailable. Request: failed get response from APMService. Exit PolicySync.exe with code -3

• Task may be stuck with a status of "Client has initiated asynchronous policy execution"
• IIS log shows:

POST /ApmService/PolicyRequest.asmx - 80 - 127.0.0.1 - 503 2 0 62

Cause

This is a Microsoft IIS error indicating your environment has maxed out its allowed number of connections to IIS.

• 503.2 - Concurrent request limit exceeded.

Resolution

Note:  Because this deals with modifying configuration information for IIS, users assume all responsibility when implementing changes or modifications outlined in this information.

Increase the allowed number of concurrent requests in IIS as outlined by Microsoft in the article:

Click Start and then click Run.

In the Run dialog box, type notepad %systemroot%\Microsoft.Net\Framework64\v2.0.50727\CONFIG\machine.config, and then click OK.

Locate the processModel element that looks like this: <processModel autoConfig="true" />

Replace the processModel element with the following value: <processModel enable="true" requestQueueLimit="15000" />

Save and close the Machine.config file.

 

For Windows Server 2008, in the Run dialog box, type appcmd.exe set config /section:serverRuntime /appConcurrentRequestLimit:<#of users * 1.5>.

 

- Modifying the ASP.NET Request Queue Limit

Note: appcmd.exe is located at %systemroot%\system32\inetsrv\appcmd.exe. It may be necessary to change directories within the command window to successfully initiate this command.

• Purpose
• Software Distribution Process
• Where to start?
• Client Side Troubleshooting
• Core Side Troubleshooting
  • Software Distribution Logging
  • Log Locations:
    • Client Side
    • Core Side
• Other Information

Purpose

One of the most commonly used components of Ivanti Endpoint Manager 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.  Occasionally there are 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 about specific issues.

Software Distribution Process

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 Ivanti 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 in 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. About the Diagnostics Utility

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

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 a 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 Tasks - 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 Ivanti Endpoint Manager, almost all verbose logging is controlled by a feature we call XTrace. This provides a 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 on the Ivanti EPM 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 Ivanti EPM Software Distribution Landing Page for more information.

Description

Ivanti EPM Portal Manager delivers apps, documents, and links to end users so they can install items that are approved for use in your organization or required for that user's hardware

General steps

1. Create a new Macintosh distribution package
2. Create a scheduled task
3. Select Policy as delivery type
4. Run the task, right now the task status would be Pending
5. Run Software Portal on the Mac client as below
   
6. The portal will open automatically
   
   

Problem Description

The following are the issues that may be encountered  when you use the software portal:

1. The portal could not pop up, no response when you click the portal as in step 5.
2. The newly updated policies cannot be found.

Troubleshooting

1. From the MAC machine, Go to Folder  /Library/Application Support/LANDesk/landesk.log, and check if the client received a new policy
   
   Normally you would get the error message as below:
   

   soap:Fault Soap session could not be invoked between the client and web services server
   Sep  7 15:41:21 tests-Mac-mini-2.local ldapm[1570] <Info>: APM: No new policies

   
   
2. From the console side, check current  Mac software Distribution task status, make sure the affected device is on the task pending list.
3. If there is any task status issue or error return code reported, you can check it through the normal SWD troubleshooting steps.

This article only applies if the majority of the task targets are able to run the task properly, but one or a few targets get stuck in Asynchronous Policy Execution state.  This indicates an issue with the devices themselves.  If ALL devices in the task get stuck in this state, it usually indicates a core-side issue which is addressed in these documents:

How to troubleshoot tasks hung with a status of "Client has initiated asynchronous policy execution"

"Client has initiated asynchronous policy execution" - Return Code 1354

Issue: Tasks are stuck in active with the result "Client has initiated asynchronous policy execution"

More Info

Asynchronous Policy Execution is not an error, but a status message.  It indicates that the task has not started on the target device because it is waiting for something else to complete.  This could be a vulnerability scan (vulscan.exe), a software install (sdclient.exe) or a process initiated by sdclient.exe or vulscan.exe (msiexec, wusa, cmd etc.).

Under normal circumstances, the other process will finish and close out allowing the task to move beyond Asynchronous state.  However, on occasion, the actions being initiated get stuck, preventing other tasks from continuing.  This document is intended to troubleshoot and address this condition.

Troubleshooting

First, check task manager on the device in question. Look for any of the following processes:

• vulscan.exe
• sdclient.exe
• MSIExec.exe
• sdistbat.exe
• cmd.exe

Sometimes, simply ending task on these processes or rebooting the client device will clear up the Asynchronous state.  If this doesn't work, or if none of these processes are running, then we will move on to clearing out stuck policies on the core and client.

1. On the core, locate the device in question in Network View, right click, and select Scheduled Tasks and Diagnostics.  This window will list all tasks the device has been targeted by from the core.  Look for any old tasks that are still in an active, working, waiting or any other state besides Done or Failed:
   
2. Double click the bad task, which will open it up in Scheduled Tasks.  You can then delete the task or remove the device in question from the target list.  This removes the policy for this task on the core.
   
3. Next, we want to clear out the policies on the client.  Open %ProgramData%\Landesk\Policies\ and delete all .xml and .STAT files.  Open the subfolders and delete any files in there as well. 
   
4. Back on the core, delete the original scheduled task in which the device is in asynchronous state, and recreate it.  Target the device and start the task, and it should now run successfully.
   
   

Attached to this article is a .ldms file that you can import to your managed scripts to accomplish this remotely or for many devices at once.  Select the version that matches your LDMS version.

PLEASE NOTE:  This script is provided as a courtesy only and may need to be edited or adjusted for your particular needs - Ivanti Support does not support custom scripts and will not be able to assist if this script causes unexpected issues.

The purpose of this document is to convey the process Ivanti EPM uses to handle Status Updates for Scheduled Tasks, and what to look for if things aren't working as desired.

What is SOAP and why does Ivanti EPM use it?

SOAP (Simple Object Access Protocol)is a protocol specification used for exchanging information for implementation by Web Services. SOAP features include:

• Extensibility, Neutrality, and Independence
• Uses Extensible Markup Language (XML) Information Set for its message format, which allows processes running on various Operating Systems (Windows, Linux, Etc.) to communicate freely.
• Relies on Application Layer protocols, usually Hypertext Transfer Protocol (HTTP) for message transmission.

For more information, please reference this Microsoft Document.

Ivanti EPM clients utilize SOAP actions to communicate Task Status updates to the core. The following is an example of a client doing so in the SendTaskStatus.exe log:

Sun, 32 Sep 2016 36:57:24 SendRequest: SOAPAction:http://tempuri.org/ResolveDeviceID

Task Start

When a task is first initiated from the console, the core is responsible for updating the status of the task until the policy has been made available. The applications involved are:

Console.exe

• Saves the task to the Ivanti EPM Database (LDTASK Table) in an "Active" state.

TaskHandlerProxy.exe

• Initiates PolicyTaskHandler.exe with the specified ID of the task being run.

PolicyTaskHandler.exe

• Attempts to resolve the devices within the Task and create Policies for each device. Once PolicyTaskHandler is finished, the client is responsible for updating the status going forward.

Send Task Status Flow (2016)

Send Task Status Process (2016)

Software Distribution:

• Resolve Device ID
  
  • Sdclient.exe > SendTaskStatus.exe > ProxyHost.exe - WSVulnerabilityCore/Vulcore.asmx.
    • The Web Method ResolveDeviceID is then invoked utilizing the COMPUTER table in the Ivanti EPM Database.
• Status Update
  • Sdclient > SendTaskStatus > ProxyHost - WSStatusEvents/EventHandler.asmx.
    • The Web Method SetPatchInstallStatus2 is then invoked utilizing the LDTASK table in the Ivanti EPM Database.

Patch Manager:

• Resolve Device ID
  • Vulscan.exe > ProxyHost.exe - WSVulnerabilityCore/Vulcore.asmx.
    • The Web Method ResolveDeviceID is then invoked utilizing the COMPUTER table in the Ivanti EPM Database.
• Status Update
  • Vulscan.exe > ProxyHost - WSStatusEvents/EventHandler.asmx.
    • The Web Method SetPatchInstallStatus2 is then invoked utilizing the LDTASK table in the Ivanti EPM Database.

Send Task Status Flow

Send Task Status Process

Software Distribution:

• Resolve Device ID
  • Sdclient.exe > SendTaskStatus.exe > ProxyHost.exe - WSVulnerabilityCore/Vulcore.asmx.
    • The Web Method ResolveDeviceID is then invoked utilizing the COMPUTER table in the Ivanti EPM Database.
• Status Update
  • Sdclient > SendTaskStatus > ProxyHost - WSVulnerabilityCore/Vulcore.asmx.
    • The Web Method SetPatchInstallStatus2 is then invoked utilizing the LDTASK table in the Ivanti EPM Database.

Patch Manager:

• Resolve Device ID
  • Vulscan.exe > ProxyHost.exe - WSVulnerabilityCore/Vulcore.asmx.
    • The Web Method ResolveDeviceID is then invoked utilizing the COMPUTER table in the Ivanti EPM Database.
• Status Update
  • Vulscan.exe > ProxyHost - WSVulnerabilityCore/Vulcore.asmx.
    • The Web Method SetPatchInstallStatus2 is then invoked utilizing the LDTASK table in the Ivanti EPM Database.

Troubleshooting

A client may occasionally fail to upload its status as it works through a task. This section can help pinpoint the location that the problem occurred.

Log Locations

IIS:

• C:\inetpub\logs\LogFiles
• C:\Windows\System32\LogFiles\HTTPERR

Core:

• WSVulnerabilityCore.dll.log - %ldms_home%\log
  
• StatusEvents.dll.log - %ldms_home%\log
• Console.exe.log- %ldms_home%\log
• PolicyTaskHandler.exe.log - %ldms_home%\log
• TaskHandlerProxy.log - %ldms_home%\log

Client:

• ProxyHost.log - C:\Program Files (x86)\LANDesk\Shared Files
• SendTaskStatus.log - C:\ProgramData\LANDesk\Log
• Sdclient_Task#.log(Distribution)- C:\Program Files (x86)\LANDesk\LDClient\Data
  
• Vulscan.log (Patch Manager)- C:\ProgramData\LANDesk\Log

IIS Manager

Internet Information Services (IIS) Manager can be used to verify that LANDESK Web Application Pools are up and running.

In terms of Task Status Reporting, the applicable Application Pools are LDAppStatusEvents and LDAppVulnerability . Ensure that they are both in a Started state. It might be worth "Recycling" each Application Pool as shown in the screenshot above.

IIS Reset

If IIS on the core is found to be unresponsive, sometimes running an IIS Reset can resolve the issue.

Open an administrative command prompt on the core and run "iisreset." Once this completes, attempt to produce the issue again.

We currently have 11 Preferred Servers which each also acts as the Replicator. With this being the case we have a patches folder (D:) and also the sdmcache folder (C:) becomes populated.

Last week we became concerned that the sdmcache folders were taking up a large amount of disk space. Therefore we decided to "limit the number of days file are kept in the cache" to 14 days from within Run options of the Preferred server options. Replicaton ran over night but the sdmcache folder was still the same size.

We contacted support who informed us that this was controlled via "Client Connectivity Settings".Configured a new Client Connectivity settings called Preferred Server Client Connectivity Settings with "number of days files stay in cache" set to 14. And pushed this successfully to two preferred servers as a test.

Content replication then ran overnight.

Next day checked Content Replication task history to make sure this had been successful, which it had. Checked the sdmcache folder and this was still the same size.

We decided to run "Start content replication now" against both preferred servers to look at a log file but after 10 minutes the Status of requested actions "Lost contact" on both. Decision was then made to revert both servers back to the original Client Connectivity settings they previously had.

Problem now is that the task created for this constantly sits at an ACTIVE state and never changes. Checking the inventory of these two Preferred Servers shows that they are still using the new settings created above.

We have checked the other 9 preferred servers who have the original settings and these are all able to replicate with no issues.

Also strangely enough the scheduled replication seems to have been succesful over night!? BUT still the sdmcache folder is the same size. We have checked all ports are open and they are. We have also checked client access and all approved.

Could anyone help with this rather time consuming issue!?

Thanks

Neil

Issue

When attempting to execute a PowerShell package from source the following output is displayed in the sdclient_task log file on the client located in %ldms_local_dir% (ldclient\data)

Cause

The targeted device's policy execution is set to "restricted," not allowing the file to run from a share. To view the clients execution policy run the following command in PowerShell:

Get-ExecutionPolicy -list

Resolution

To successfully execute from a share the PowerShell package properties have to include the following syntax:

There are several parameters associated the ExecutionPolicy command. In this instance I elected the -Bypass parameter.

-- Bypass: Nothing is blocked and there are no warnings or prompts.

• Using the bypass parameter temporarily allows the execution. Once the task is complete, the execution policy will be set back to its previous state.

Please be mindful that execution policies are in place to assist in preventing the execution of scripts that may pose a security risk to your environment. For further details on this topic please view the following article:

https://technet.microsoft.com/en-us/library/hh847748.aspx

Добрый день. Можете проконсультировать по вопросу о Portal Manager? Правильно мы поняли, что обойтись без вмешательства в процесс установки ПО администратора консоли нельзя? То есть сейчас для того, чтобы пользователь смог что-либо установить, нужно создать задачу в консоли, добавить его ПК в эту задачу и только уже после этих действий у пользователя отобразиться список ПО, которое он сможет установить. Или все-таки есть возможность сделать так, чтобы пользователь открывая клиентскую часть сразу мог самостоятельно установить любой пакет ПО, который мы заранее обозначим как возможный к установке.? То есть это будет какой-то набор ПО, который доступен всем ПК/пользователям какой-то конкретной группы (например из LDAP) без добавления каждого ПК руками в задачу администратором консоли. Надеюсь понятно описал. Хотим минимизировать наши трудозатраты, выделяемые на установку стандартного набора софта.

I can install office 2016 with out any issues when deploying it as a software dist. package.  However, when I try to include it with an OS Provisioning Template, the Office setup just stalls out.  Any thoughts or suggestions?

Hi there

I would like to use Patch & Compliance to push out up to date versions of applications.

However, the issue I am seeing is that if, say, my device has Software X v10.1 then the security scans detects this as a vulnerability and suggests it needs v10.2.

But I am wanting to install 10.4

If I try to deploy v10.4 using Patch & Compliance it completes but doesn't install as it Ivanti doesn't see it as a vulnerability.

Is there a way I can deploy the latest version using Patch & Compliance without, as it seems is the case, having to deploy the versions in between first?

Cheers

Phil

How To:

This is a guide on how to display web pages inside of portal manager.

Step by Step:

     1.) Go to agent settings, select portal manager, and click the create new settings icon.

     2.) Select Applications, highlight Service Manager and select Copy.

     3.) Enter a name into the two fields at the top, and the website URL into the Parameters field and save.

     4.) Move the new application into the Show in portal manager box to the right and save.

     5.) Click the create a task icon and select Change settings.

     6.) Select the portal manager agent setting desired, target machines with the task and start it.

     7.) Open Portal manager on a client that was targeted by the task and you will see the application.

     8.) Click on the application and the web page will display in portal manager!

I have had a couple clients whose portal is broken. It doesn't have the launchpad and a reboot doesn't help.

Anything I can try to get it back other than uninstalling and reinstalling the agent?

Running Ivanti 2017.3 SU3.

Description

With the release of Endpoint Manager 2018.1 there are some new features to help improve your Software Distribution deployments. Please review the attached document to see the new features for Software Distribution in EPM 2018.1.

This procedure can be used to set up a web repository with anonymous access for software distribution/Preferred Server using IIS 7.5

1. Start > Administrative Tools > Internet Information Services (IIS) Manager
2. Server name > sites, then right click the "Default Web Site" > "Add virtual directory" and fill in the name and the path to the directory to be shared
3. After the virtual directory appears under the Default web site tree, right click on it > edit permissions > Security > edit
4. Add:  the local IUSR, ANONYMOUS LOGON and NETWORK SERVICE they need at least "Read" and "List folder contents" rights
5. Switch to feature view, in the central pane double click "directory browsing" and click "enable" under the action pane on the right   (Be sure your newly created virtual directory is highlighted)
6. In Features View, double-click Authentication > On the Authentication page, select Anonymous Authentication.
7. In the Actions pane, click Edit to set the security principal under which anonymous users will connect to the site.
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 account.

If you are using IIS 7, please visit: HTTP Repository for SWD in IIS7

Please also review this document: How To: Distribute Software via CSA

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. Only the .xml file is downloaded, the .stat file is dynamically created and updated by policysync.exe.

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://localhost:9592/apmservice/policyrequest.asmx using a browser on the client machine.
      1. Adding port 9592 will force the request through LANDESK's proxyhost.exe application using the client's loopback address. The results of this activity will be written to the proxyhost.log file.
   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 Tasks - Core Side
3. Request: Signature Verification Failed
   1. Update COM+ objects on the core with a correct Domain User account.
   2. Restart COM+.
   3. More information about this error can be found here:
      Error: "Signature Verification Failed" from PolicySync.exe
      
      

• Purpose
  • Services
  • Software Distribution Process
  • Software Distribution Stages
    • Stage 1: Discovery (Core initiated)
    • Stage 2: Asynchronous Policy Execution (Client has initiated processing)
    • Stage 3: Task Has Started
    • Stage 4: Downloading
    • Stage 5: Complete
  • Software Distribution (IIS)

Purpose

This document is designed to help diagnose and resolve common issues that happen in Ivanti EPM Software Distribution from the perspective of the core server.

Services

A few notable services core side that must be started in order for the Software Distribution process to function correctly are as follows:

• LANDESK Scheduler Service
• LANDESK® Management Agent Service
• LANDESK Policy Server Service

Software Distribution Process

The following process outlines how Software Distribution works Core side.

Upon creation of a scheduled task from a Distribution Package, a Client Policy file is created which contains all client side information you've configured in the task properties as well as the ID number of your Distribution Package. This file will be contained in the following directory on your core server and will be in the following format :

Path:  %ldms_home%\LANDESK\Files\Client Policies

 

File Format:  CP.TaskID.RunNow.xml   

Software Distribution Stages

• Stage 1: Discovery (Core initiated)

When the task is initiated on the core,  the Landesk.Scheduler.Global Scheduler will communicate with TaskHandlerProxy who in turn will talk to PolicyTaskHandler (see above diagram) in efforts to make the task information available to the targets in the task. This series of events will place the task in the Discovery Stage.  For more info on the discovery process please reference How to troubleshoot Agent Discovery.

In order to attain more logging around the discovery process please enable verbose policy task handler logging by navigating to:

Tools | Distribution | Scheduled Tasks

Configure Settings	Default Scheduled Task

Below is an example of this sequence of events from a logging perspective:

LANDESK.Scheduler.GlobalScheduler.exe.log	TaskHandlerProxy.exe.log	PolicyTaskHandler.exe.log

Synchronizing policy with the command: [C:\Program Files (x86)\LANDESK\LDClient\PolicySync.exe -taskid=1099], to machine: [WIN8196]

• Stage 2: Asynchronous Policy Execution (Client has initiated processing)

  During this stage, the client policy file has been made available to the client, and the client is in the process of retrieving the file from the core. If successful, the CP.TaskID.RunNow.xml or CP.TaskID.xml file will be downloaded to the (Programdata\LANDESK\Polices) directory. A status (.stat) file will be created by policysync.exe. This file corresponds to the activity taking place by sdclient.exe. For a listing of what the return codes mean in the .stat file please reference How to Interpret Client Policy .Stat file Status Codes.

• Stage 3: Task Has Started

        During this stage, the sdclient process on the client has been initiated. There will now be a sdclient_taskXXX.log file (XXX = taskID) on the client in %ldms_local_dir%.

• Stage 4: Downloading

  During this stage, the LANDESK download utility has begun downloading the files contained in the Software Distribution package. These files will reside in the %ldms_local_dir%\..\sdmcache directory.

• Stage 5: Complete

  During this stage, the sdclient process has completed processing the client policy task made available to the target.

Software Distribution (IIS)

There are a variety of web requests made over the HTTP protocol related to the Software Distribution process. To properly troubleshoot the process, you will need to understand what sites and web services are at play.

To access IIS Manager, open a run prompt and type in INETMGR. This command will take you to IIS.

Run Prompt	IIS Manager

The APMService site handles all Software Distribution activity and the LDAppAPM application pool serves the site.

APMService	LDAppAPM

The two (2) primary web services in the APMService site are as follows:

• Packageinfo.asmx (contains all pertinent information about the package being distributing to the client)
• PolicyRequest.asmx (contains all pertinent information configured in the task properties)

             

The operations contained in each web service allow the transfer of information from the core server to the client.

PackageInfo	PolicyRequest

In the event a targeted client cannot get a policy file or package information, review the IIS log files to determine if the attempt made it from the client to the core. If no entry from the time frame of the request is contained in the IIS logging file, the traffic was dropped/blocked in route to the core or never left the client. To view the IIS logging please navigate to the following location on your core server:

%SystemDrive%\inetpub\logs\LogFiles

The purpose of this document is to go over the Best Practices and Expectations when Distributing Batch File Packages in Ivanti Endpoint Manager.

Things to Consider before Starting

• Simplify packages; they more commonly result in a success and are easier to troubleshoot.
• Allow Ivanti EPM to handle downloads of any additional files required rather than attempting to do so in the batch.
  • Batch files are run under Local System by default, which can often cause problems when attempting to access network shares.
  • The Ivanti Endpoint Manager Console will likely not be able to differentiate between a failure to download or install if both are being done by the batch file.
• Ensure that the batch file and any accompanying files exist in the same directory on the network share.
  • Ivanti Endpoint Manager will in turn download all necessary files to the same location in the workstation SDMCache.
  • This allows the batch files to address all files locally.
• Distributed batch files should end in Exit /b %errorlevel%
  • SDCLIENT.EXE will acknowledge the last return code sent by the batch file. Ending it with this line will ensure SDCLIENT acknowledges the final error level generated from the batch.
• Consider what permissions will be needed in order to run the batch file.
  • Batch files are run under Local System by default. This may not produce sufficient privileges depending on what the batch is intended to do.
  • Distribution packages can be configured to run under Local System, Current user's account, or a Specified User.
    
• For more information on creating Batch Files, please reference this Community Document.

Creating the Package Share

The batch file and all included files should be in the same network location. This will result in Ivanti EPM downloading all files to the same location on the workstation within the SDMCACHE.

The files should exist on a Preferred Server - this still needs to be the case even if the files are on the core. For more information on configuring Preferred Servers, please reference this Community Document.

The example in this Doc will run a batch file creates a directory called "Chrome" on the root of C:, moves a file called "Chrome.txt" to that directory and then install Google Chrome.

Note how the Batch file calls everything locally. This will ensure the highest level of success.

Creating a Batch File Distribution Package

In the Ivanti Endpoint Manager Console, click Tools> Distribution> Distribution Packages. Highlight My Packages and select New> Windows> Batch File.

In the Batch File Properties window, fill out the Primary File space. The primary file, in this case, will be the batch file.

Now select Additional Files and include the other files the batch will be calling. The additional files, in this case, will be the Chrome MSI and the Chrome Text File.

Note: the primary file cannot be added to the additional files section. An error will be displayed if this is attempted.

Click Save.

Deploying the Batch File

Right-click the newly created Distribution Package and click Create scheduled task(s)... A new task will be created in the scheduled tasks tool.

Download behavior should be verified before running the task on workstations. Right-click the newly created task and select Properties.

Click Task Settings and verify that "Download Options" is configured for Download and execute.

Note: The selection made here will trump the download options selected within the Agent Settings tool for Distribution and Patch. For information, please reference this Community Document.

Drag and drop the applicable workstations from the Network View into the task. Right-click the task select Start Now> All.

After a few moments, the files will begin downloading to the C:\Program Files (x86)\LANDesk\LDClient\sdmcache directory. Note how the files are written in the same directory path as they were copied:

Overview

This document outlines how to successfully create and test a .msi and .exe software distribution package. For the purpose of this document we will be discussing a silent install method.

Important sections of a distribution package

Package information

This is where you will select the exe/msi and give a description for the package.

Install/Uninstall options

This is where you will put the required switches for a silent install.

For msi packages the switches for a silent install are standard and if there are no special requirements for the package you can typically leave the Install/Uninstall options at the default. You can also find out the default msi switches using command prompt by navigating to the location of the msi and calling it with a /?. Example below

For exe packages the switches vary from vendor to vendor and typically a Google search will reveal the correct switches for a silent install. You can also try to call the exe with the /? switch, however in my experience a lot do not show the switches and just go to the install. In those cases using Google or contacting the vendor may be required. Example of an exe that gives switches below.

Additional files

Some installations require more than just the main exe/msi to complete successfully. This section is where you can add those additional required files. Deployments like Office use the functionality of additional files.

Accounts

This is where you can change the account that installs the package. By default all packages are created to be run by the system account and in most cases this is the best practice. However there are some applications that require being installed by the user profile that will be using the software. I do not have any known examples but I have seen applications that have to be installed on the user profile versus the computer itself.

Testing packages

Important: If you cannot manually install the software using the switches you have configured, then the Ivanti EPM install will also fail. It is vital that you fully test your software configuration manually before building the package in Ivanti EPM.

The most common issue is that the correct switches for a silent install were not used in the package creation. You can test this by calling the exe/msi manually with the switches you have in the package and see if it installs without prompting for any user interaction. Example below.

If there are any prompts visible you will need to continue working with the switches to get a completely silent install.

Once you have the correct switches and information in place it is now time to test. I recommend testing on a handful of machines you have access to in order to troubleshoot if needed. Pushing it out to a limited amount of machines you have full access to will avoid any widespread issues with the package.

If the install fails please see the following documentation.

- How to troubleshoot Software Distribution

If i have a application published to Portal Manager with setting:

Task Settings:

Frequency: Run Once

Checked: Optional (display in portal) and "allow users to run as desired (keep in portal after selected)

Problem 1:

First time i run the schedule task the software is availible in Portal Manager for my users.

What i have noticed is when a computer is re-installed with new OS the software will not be availible again in Portal Manager for the computer because it have already been succesfully publish to Portal Manager before.

Very annoying... any setting to fix this problem?

Problem 2:

First time i run the schedule task the software is availible in Portal Manager for my users.

If i choose "re-run task" on a computer that alrady successfully published a software to portal manager, it WILL INSTALL the software?! Even if i have the task setting: Optional (display in portal)

Or if i choose Task settings frequency to Run Daily, the first time it will publish to portal manager, the next day it will INSTALL the software...

This must be a bug?

Regards Johan