hi everyone,

i'm unable do install a software using a provisionning task, in my SCDCLIENTHANDLER.log i get stuck to :

Sdclienthandler.exe checking for sdclient Mutex,

and still repeating this action.

for the same package, i can install it using a schedule task.

is any body can't tell me what's wrong ?

Running endpoint manager 2016 sp3.

I have tried several scripts I found in the forum and outside the forum but can't get any to work to install a printer through a software distribution task.

My script writer is in the hospital with cancer and I don't write scripts.

Any help?

Hi

We have just downloaded the LANDESK 9.50 on a server. It is still running in trial mode. Im trying to test Distribution packages.

Im distributing a msi package. The destination has the new agent and it appears to be working fine. When I run the task it fails on a return code 105.

Here  is an extract of what I see in the "view log file" option.

Processing package : Cisco VOIP Agent
Wed, 10 Apr 2013 10:14:23 File (\\-----\-----\------\-------\-------AgentDesktop.msi) is not in cache
Wed, 10 Apr 2013 10:14:23 Will attempt Peer Download.

Wed, 10 Apr 2013 10:14:23 Will attempt Preferred Server Download.

Wed, 10 Apr 2013 10:14:23 About to call DownloadFiles (1 files) with these settings:
Wed, 10 Apr 2013 10:14:23 m_allowedBandwidthWAN: 100
Wed, 10 Apr 2013 10:14:23 m_allowedBandwidthLAN: 100
Wed, 10 Apr 2013 10:14:23 m_maxDiscoveryThreads: 15
Wed, 10 Apr 2013 10:14:23 m_discardPeriodSeconds: 604800
Wed, 10 Apr 2013 10:14:23 m_preserveDirectoryStructure: 1
Wed, 10 Apr 2013 10:14:23 m_bUseWanBWForPush: 0
Wed, 10 Apr 2013 10:14:23 m_bSynchronize: 0
Wed, 10 Apr 2013 10:14:23 m_downloadControl: AttemptPeer
Wed, 10 Apr 2013 10:14:23 m_preferredServerControl: AttemptPreferredServer
Wed, 10 Apr 2013 10:14:45 processing of package is complete, result -1918107543 (0x8dac0069 - code 105)

Where should I be looking to resolve this and any ideas what my problem might be?

Regards

Mike

Purpose

This document provides a quick guide for setting up replication. It will not go into detail on all areas of this component, but rather gives a getting started style view at setting up replication.

For more information on Replication please see: How to use Ivanti EPM Content Replication

Set up share on Core Server

The point of replication is to duplicate files from a source to a preferred server. So to start we need a share that will be used to store the files we are going to replicate.

Note: In this document I create a new share, but you could use any share such as ldlogon and it should be ok.

• On the Core create a new directory
  • C:\share
• Share the folder
  • I share mine to everyone with read/write permissions. It just makes it easier.
• You now have a share \\core\share
• Copy some files into the share folder to be replicated
  • Example: \\core\share\firefox.exe

Set up Client Share

Replication copies files from one share to the clients share of the same name. This means that any machine that will be replicated to must have a share setup of the same name as the source.

We previously created \\Core\Share, so the client must have a share set up as \\Client\Share.

The physical location on the drive won't matter, so long as the naming convention is the same.

(i.e. C:\Share creates the same UNC share path as C:\Temp\Share. They both become \\client\share)

Add Preferred Servers

In Content Replication add a preferred server for:

• Core (this will be where files are replicated from originally)
• Client (this will be who gets the files in the end)

Add Sources

• In Content replication click Sources, and choose New Source.
• In the Source Properties window, fill out the Configuration section
  • Name:
    • This can be anything, it is a unique way to tell what the source is.
  • UNC or http path:
    • This needs to be the path to the share we originally setup
  • Connect as user
    • A user account that has rights to the share.

Configure Client Preferred Server

• In Content Replication, select Preferred Servers
• Double click the Client Preferred server to open it to edit
• Click Selected Replicator
• In the list of devices shown, pick the Replicator that will be in charge of copying files from the source to this Preferred Server.
• Click Select

• Next click Sources
• Select the Source we added earlier and choose Include
  • This defines that the client will receive the files from this source.
• Click Save

• Next click Write Credentials
• Provide credentials that will have write permissions to the share
  • Since we are copying to this machine, we write the files onto it. Only machines that will receive replicated files need the Write Credentials.
• Click Save

Start Replication

• In Content Replication click All Tasks | Not Scheduled
• There will be an entry showing the Source and Preferred server we just setup
• Right click this entry and choose Start Content Replication Now

• If everything was setup correctly, it should show as successful.

Hello,

I have few end user machines for which not to target any deployments in business hours, So i need to create maintenance window for these machines to avoid deployments in business hours.

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

Hi,

I really like Actions and I want to use them more in my Packages.

But I really miss how I can address the additional files.

The Actions seem to start Somewhere in C:\Windows\System32

So I have to tell the action how to find the Files, with something like this:

$installer=$env:TMC_CACHE_DIR+$pkgdir+"\"+$pkg+".exe"

Has somebody a better solution?

Thank you, Marco

I receive during (landesk) Ivanti 2017.03 installation

Fail Intralling Identrity server

Reboot of the server done

Check of IIS certificates done and none landesk certificates found there.

Log checked but do not get what to do in attachment

I have built a .msi distribution package for Primavera P6 Pro that installs as intended, but it asks for the information to set up the database.  I was wondering if anyone knew how I could fix my distribution package so that I do not have to touch it during install?  I have done research and cant find anything.  I am a newbie so probably missing the right verbiage for the search.  Any help or guidance would be greatly appreciated!!

I have seen references in some places about being able to publish provisioning templates in the portal.  But no matter what I do, I am unable to get it to show up in my portal.

About the Portal Manager

Adding items to Portal Manager

The default Portal Manager deployment doesn't include any launchpad items. Use software distribution to add items to Portal Manager.

Items you can add to Portal Manager include:

• Mobile Android and Apple iOS packages
• Universal links, streamed documents, and OS provisioning templates

This is what I ended up doing, though it did not work.

I created the os provisioning template and added actions.  In Distribution Packages I made a new universal package | Provisioning.  I included the template I had created before.  I created scheduled task, went into the task, associated it to my workstation, set it to policy push, kicked it off.  It shows as active in the progress window but nothing ever shows up in the Portal, even after I refresh it.  I can add and remove typical distribution packages and it is reflected in the Portal window, so I know I can get some things to work.

I looked around and have yet to find documentation showing how to do this.  Anyone know where such documentation would be?

Hi

What is the best way of pushing out software to our devices so that they begin the installation the next time the user logs in?

Thanks

Phil

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.

Hi, the reason of this thread is the following.

I use Ivanti Portal Manager in a lot of computers in my organization. When I start Windows and try to install any software from Portal Manager, it works fine. But after the computers get suspended (and resumed), locked or just used for other things for a couple hours, the Portal Manager stops working ok.

When any user try to install a software, the progress bar in the Portal stays in "Download pending" forever, at the moment the only solution I've found was restart the computer, but is not practical at all for the user...

I've tried restarting manually the Ivanti services but doesn't work, and looked for similar posts in the community but doesn't found anyone reporting the same problem, which is weird.

Ivanti 2017 v3.

Windows 8.1, 10

Let me know if I can help adding any other info.

Thanks in advance!

Hello,

as you can read in the Title, im trying to use WoL to Patch devices and shut them down. The script is working without any problems, but the devices wont want to shut down after the task was sucessfully executed (I've waited more than 2 hours after completion).

As you can see in the Screenshot, Wake up devices is checked (Most of the devices are waking up, but not allways every device).

Is there something i am missing?

Many thanks!

More information about how a replication job works can be found in LANDESK Content Replication Process

Components

There are a few components involved in the Content Replication process that are all used to create and manage a replication setup.

Ivanti Endpoint Manager Console

The configuration of all settings is done in the Ivanti EPM Console. The console also contains information about running, pending, and unscheduled tasks. There is also a task history with progress, status and logs for each replication task. Additionally, the console allows the Ivanti EPM administrator to quickly stop any running replication jobs or disable job(s) from running in the future. For more information about the tools available in the Ivanti Endpoint Manager Console see:

Ivanti EPM Content Replication - Console Options and Tools

Preferred servers (Targets)

These are the preferred servers that the clients will use to download files from. They are also the target servers that files will be replicated to from a source location. Any existing configuration of the Preferred servers will persist through an upgrade and can still operate as preferred servers only, without replication if desired. For more information about all the configuration options available for a Preferred server please see:

Ivanti EPM Content Replication - Preferred Server (Target) Configuration.

The Preferred servers will continue to operate the same way they did with previous versions of Ivanti EPM. Clients will attempt to get files from Preferred servers first, before attempting to get them from the original source location. More information about how Preferred servers work and support clients can be found here:

How to Configure a Preferred Package Server

How to set up an HTTP share for a Preferred Package Share

Using Preferred Server in Patch Manager

Some of the configuration steps in the documents above have changed. For current configuration options see the various updated documents listed here.

The Preferred server must have identical shares that match any Source that is replicated to them. That means if \\FileServer\Software is replicating to PreferredServer1, then PreferredServer1 must have a Software share (\\PreferredServer1\Software). These shares must be created manually, but any folders inside the shares can be created by the replication process.

A Preferred server that will be a target for replication can be any UNC compatible device, including NAS devices.

A Source can also be a Preferred server. For example, a "master" Source may replicate to "child" Sources. Then those "child" Sources replicate to more Preferred servers. In this case, a "child" Source would be both a Preferred server (for the "master" source) and a Source (for the final Preferred servers).

Sources

A source is any UNC or HTTP share that contains data and files that need to be replicated to Preferred servers. A source can be configured as an entire share or a specific folder inside a share. All subfolders and files are included as part of the source. For example, if a source is configured as \\FileServer\Software, it will include all the files and folders inside the Software share. However, if it is configured as \\FileServer\Software\Microsoft, it will only include the files and folders inside the Microsoft folder. For more information on the configuration of a Source see:

Ivanti EPM Content Replication - Source Configuration

Any number of Sources can be configured. They can overlap if needed. They can all be managed independently and assigned to any combination of Preferred servers as needed to suit the environment. The share names must match and already be configured on any Target Preferred servers, but any subfolders will be created by the replication process.

A Source can also be a Preferred server. For example, a "master" Source may replicate to "child" Sources. Then those "child" Sources replicate to more Preferred servers. In this case, a "child" Source would be both a Preferred server (for the "master" source) and a Source (for the final Preferred servers).

Replicators

A Replicator is any Windows-based managed node and must be a Windows-based managed node. The Replicator is the machine that will do the replication work. It will identify which files and folders on the source need to be copied to the Preferred server (Target) then download those files and push them to the Preferred server (Target). The device used as the Replicator will need to have enough storage for the files being replicated to be stored in the cache.

The replication process is managed on the client machine by the LANDESK Local Scheduler and the client process that performs the replication is vulscan.exe. The Replicator configuration allows for scheduling replication, including a true maintenance window as well as bandwidth restrictions as needed. For information on configuring a Replicator see:

Ivanti EPM Content Replication - Replicator Configuration

During a replication job the Replicator will identify which files are missing from the Preferred server. It will then download those files from the Source and push those files to the Preferred server. All files that are downloaded to be pushed to Preferred servers will remain in the Replicator's cache. The time to keep these files can be configured in the Replicator settings. For details on the file replication process see:

Ivanti EPM Content Replication Process

A Replicator can be configured on a Source or a Preferred server. In this case, a single device would serve 2 roles. Also the device will have 2 copies of all files that were replicated. One in the share location and one in the SDMCache.

Replication Scenarios

A large variety of configurations and scenarios can be set up to meet many file replication needs using Ivanti EPM Content Replication. These vary from a single Source and single Preferred server to dozens of Sources and hundreds of Preferred servers, each needing different sets of files. Most needs can be met with good planning and some creativity. To get started, a few scenarios can be found here:

Ivanti EPM Replication - Scenarios

These scenarios are meant as a starting point or ideas in developing a replication configuration. Not all of the scenarios are in use in a production environment and should be carefully tested.

Applies to LANDesk Management Suite 9 SP2 and greater

Ivanti EPM Content Replication allows you to manage Preferred servers and replicating and copying files from sources to Preferred servers. The Preferred server configuration allows the configuration of IP address ranges, credentials, assigned sources, and the assigned replicator. The various settings and configurations are outlined below.

Configuration

• Server name: This is the name of the preferred server. It should be a name that can be resolved via DNS. It can be a hostname or an FQDN. This can be an IP address, but the IP address should only be used if there is no way to use the preferred server name or FQDN.
• Description: Can be used for further information or a description of the preferred server.
• Read-only credentials: These credentials are used by all client machines when trying to connect to this preferred server. This should be a read-only account. It is recommended that this be a domain service account with the password set to never expire.
• Test credentials: Clicking this will allow you to test the UNC and HTTP read access to the preferred server. This essentially tests if the clients will be able to connect to the preferred server. This test has no bearing or effect on Content Replication

IP address ranges

• These are the IP address ranges that this preferred server will serve. Any machines with an IP address in these ranges will be provided this preferred server and the credentials in order to connect and attempt to download the files. These can be any number or combination of IP addresses.
• Ivanti EPM will not validate or verify any IP address ranges configured here. That means if the range is configured as 192.168.1.1 to 192.169.1.255, Ivanti EPMwill send this preferred server information to a machine with an IP address of 192.168.1.25 and a machine at 192.168.127.240 and a machine at 192.169.1.224
• If you do not want this Preferred Server to be distributed to clients, configure an invalid IP address range such as 1.1.1.1 to 1.1.1.2. This will allow machines that know they need files from this server (such as HII or when it is the original package source) to get credentials to access the shares, but the server will not be handed out to clients to be used as a Preferred Server.

Selected Replicator

• Only one Replicator can be assigned to each Preferred server.
• A Replicator can be any Windows-based managed node.
• The selection window will only display 500 devices so a search is recommended.
• The column set cannot be modified and includes: Device Name, Type, OS Name, IP address, Primary Owner, LDAP location, and Settings applied.
• The Settings applied column will indicate if the machine has replicator settings already present on the device for Content Replication. It can be Yes, indicating the current settings are applied, No (out of date) indicating that there are replicator settings on the device but they need to be updated, or No (not reported) usually indicating the device has no replicator settings configured.
• Double click a machine, or press "Select" to designate the currently selected machine as the Replicator.
• The current replicator will appear in the bottom pane.
• For more information on Replicator, settings see: Ivanti EPM Content Replication - Replicator Configuration

Sources

• The pane allows the selection of which Sources will be replicated to the Preferred server.
• The top pane shows available Sources that are NOT assigned to the Preferred server.
• The lower pane shows the Sources that are currently configured to be replicated to the Preferred server.
• The Preferred server MUST have a share EXACTLY matching the share name of the source. For example, if the Source path is \\CoreServer\ldlogon\patch, then the Preferred server must have a share named ldlogon.
• Folders and subfolders inside the share will be automatically created during any replication job as needed. For example, if the source is \\CoreServer\ldlogon\patch and the Preferred server just has \\PreferredServer\ldlogon, the replication job will create the patch folder.
• For more information on configuration of Sources see: Ivanti EPM Content Replication - Source Configuration

Write Credentials

• Username: This is the user that will be used by the replicator to WRITE files to the Preferred server. The user should be in the form domain\username. This username will not be delivered to any client devices other than the replicator. It is recommended that the user be a domain user or service account with the password set to never expire
• Password: The password for the above user.
• Test credentials...: This will open a tool that will test the write credentials to ensure that all needed shares can be written to.

Test Credentials

• This tool is used to test the write credentials and verify that all needed shares can be written on the Preferred server.
• The available options are determined by which sources have been assigned to the Preferred server. If no sources are assigned, the test will not be available.
• Columns:
  • Share: This is the share that will be written on the preferred server. The share name comes from the Source
  • Path: This is the path that will be written in the share
  • Derived from: This shows the information about the source that is used to determine the share name and path
  • Status: This shows the test result. Success or failure messages will be updated in this column as the test is completed.
• Check the box for any shares that are to be tested and click Test
• The Status column will indicate the results of the test. Any failures will return a message to help with troubleshooting.

For more information on Content Replication and Preferred servers see:

Using Ivanti EPM Content Replication

• 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.

• • Purpose
  • Logs
  • Get the Task ID
  • Did the Policy xml download to client?
  • Did sdclient run the task?
  • Did sdclient_task## run the primary file?
  • Did sdclient_task## receive an exit code?
    • Common Exit Codes:
  • Did the task return a status?

Purpose

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

Logs

These logs will be used in diagnosing the issue:

• %ldms_local_dir%\..\..\shared files\proxyhost.log
• %ldms_local_dir%\sdclient.log
• %ldms_local_dir%\sdclient_task##.log
• %programdata%\landesk\log\policysync.exe.log
• %programdata%\landesk\log\policysync.log

Get the Task ID

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

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

Example: Task ID 3601

Did the Policy xml download to client?

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

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

Yes

Go to: Did sdclient run the task?

No

Go to: How To Troubleshoot Policy Sync

Did sdclient run the task?

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

Example:

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

Yes

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

No

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

Did sdclient_task## run the primary file?

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

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

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

Example:

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

Yes

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

No

Review the sdclient_task##.log for errors.

Example: Primary file fails to download

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

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

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

Did sdclient_task## receive an exit code?

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

Example:

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

Yes

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

Common Exit Codes:

• 0 - Success
• 3010 - Reboot Required

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

MSI packages use standardized exit codes which are listed here

.

No

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

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

• Check the box for Command Line and press Ok

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

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

To correct this:

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

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

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

Did the task return a status?

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

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

Problem:

In some high secure environments, users can encounter an issue with PowerShell scripts distribution via Ivanti Endpoint Manager. This issue occurs mainly for Windows 10 build 1709. Error message in log file (sdclient_task{taskID}.log - C:\Program Files (x86)\LANDesk\LDClient\Data \ C:\Program Files\LANDesk\LDClient\Data):

Thu, 15 Mar 2018 11:39:58 PowerShell file Client Thread

Thu, 15 Mar 2018 11:39:58 Powershell install value is: [0]

Thu, 15 Mar 2018 11:39:58 Powershell version is: []

Thu, 15 Mar 2018 11:39:58 PowerShell is not installed in the client system

Cause:

The SDCLIENT process to detect PowerShell installation relies on two entries in the registry. According to information from Microsoft - PowerShell v2.0 (https://support.microsoft.com/en-us/help/4034825/features-that-are-removed-or-deprecated-in-windows-10-fall-creators-up) is deprecated for Windows 10 Fall Creator Updates. Due to security reasons following registry entries might be removed what causes mentioned issue.    

OS x64:

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\PowerShell\1 value Install

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\PowerShell\1\PowerShellEngine

OS x86:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1 value Install

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\PowerShellEngine

Working device:

Not-working device:

Solution/Workaround:

For now, the only solution is restoring mentioned registry entries. Ivanti is currently working on redesigning our detection for PowerShell installation (DSI 345648).

If you have any additional questions, please contact Ivanti Support.

This is my first time posting but I have been trying to get a package built to use an unpacked iso to do an upgrade.  I was following the instructions from this posting (Windows 7 to Windows 10 1703 Inplace Upgrade ) but my packages hang on installing or when I tweak the command prompts I also see a Client has started processing task and nothing ever happens.

Under Install/Uninstall options I have /auto upgrade /quiet .  Has anyone else had success in doing in place upgrades?

Thanks,

Doug