EPM 2017.3

i need to restore a snapshot before sending an install task on some clients, the vms are running in vmware, I was able to complete an script using powershell (in conjunction with powercli) to restore the snapshot, the thing is that to run the script, the machine that runs it has to have certaing prerequisites installed, powercli and some variables.

So as far as I can see it now (I don't really know) I need to:

1. Run the script from a machine with this configuration (I would need to have a machine in stand by just to run the powershell/powercli commands)

2. Run my normal Software distribution task after the restore is completed.

Is there another way to do this?

I found this: Creating and deleting snapshots the reference doc is for hyper-v for which Normal powershell would work (installed on the core) but no the additional powercli requirements.

Can I install powerCLI in my core?

Any reference is appreciated.

Best.

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

Hello,

I have created a scope called "OS reinstall" and I setup certain updates to be autofixed for all devices in this scope (global patch settings - do not autofix). This scope selects systems based on device group called "OS reinstall". Another words - I move my systems manually to group "OS reinstall" and I expect these systems to autofix all patches for "OS reinstall" scope. Problem is that for some reason after I move system to group this system is still not able to apply patches - it acts like these patches do not have "Autofix" enabled. Do I need to do something like "wake up agent" or "update agent settings" so agent knows it is inside "OS reinstall" scope?

Dear All,

I have a problem with software distribution and TaskHandlerProxy.exe reports: error: unable to find user 'domain\SYSTEM' in the ConsoleUser table

FYI this is newly installed server

It never yet successfully distributed the patches.

Thanks for hints,

Adam

Overview

The purpose of this document is to outline how Bandwidth Throttling works in Ivanti EPM and to identify which network type is being used. In efforts to increase efficiency and be less network intrusive, Ivanti EPM utilizes a Burst/Sleep cycle which prevents total consumption of the network. The information contained in this document is intended for the advanced Ivanti Administrator but is comprehensible and advantageous for administrators at all levels to be aware of. This information is applicable to the design process for the 9.6 Management Suite version and newer.

Bandwidth Download  Routes

                                                                Click image for full size

When a client makes a file request, a broadcast message is sent over the network, asking "Who has what I'm looking for?" If the file is found on the peer or if the distribution is using multicast, the Local Area Network (LAN) bandwidth will be used. If the file is found on the preferred server or source, the Wide Area Network (WAN) bandwidth will be used.

Configuration Location

To set the total available bandwidth percentage used when data transmissions take place, navigate to the desired Distribution and Patch agent setting and adjust the bandwidth accordingly:

Tools | Configuration | Agent Settings | Distribution and Patch

• Right-click, select properties | Network settings

                                        Click image for full size

Burst/Sleep Cycle  Formula

Data transmissions are restricted to an Ivanti EPM block size of 1418-Bytes. These transmissions are predicated on a percentage of the available network bandwidth, not total network bandwidth.  Data transmissions (in relationship to file downloading) are sent on Burst/Sleep cycles. The burst equates to the amount of time it takes the "sender" to transmit a block of data. Sleep equates to the amount of time the "requester" will rest. All of this is based on the bandwidth configuration you set in your Distribution and Patch agent settings.

Bandwidth Throttling

                                                                Click image for full size

The bandwidth percentage is directly related to the number of packets sent per burst. For each percentage of bandwidth, 4 packet will be sent per burst.

For information regarding download failures please reference How to troubleshoot Download Failures in Software Distribution (Advanced)

Description

   Preferred Servers are a popular option when looking to minimize network traffic during deployment tasks. Preferred Servers can provide files over both UNC and HTTP shares, however, it is not a requirement that the Preferred Server have IIS for clients to get files from an HTTP address. When the Ivanti Agent is looking for a file on the Preferred Server it will automatically translate the path between UNC and HTTP.

   For example, if a distribution package lists the source file location as "http://server/share/file.exe", the agent will try to hit "http://preferredserver/share/file.exe" and if it fails to get the file through that method, it will try again with a UNC path "\\preferredserver\share\file.exe" without any extra configuration. However, it is important to remember that this auto-translation only happens when the Agent is trying to download from a Preferred Server. It will not do this when trying to download from a Source.

   When running Software Distribution, Patching, or Provisioning tasks the Ivanti agent will automatically run down a list of four locations it is allowed to download files from:

1. Verify if the file is already downloaded in the SDMCache.
2. Peers devices on the same multicast domain.
3. Preferred Servers.
4. Source.

  When an agent requests available preferred servers from the core it may write that information into a PreferredServers.dat file, or it may also write it into the verbose logging for the task making the request. When that request is made, the client does not send its identifying information to the core server. Instead, it sends a blank SOAP request, and whatever the IP address that IIS sees the request come from is what the list of servers is based on. This can lead to complications in NAT environments where the agents talk to the Core Server through a NAT connection as the NAT IP may be the address seen by IIS and responded to, instead of the client's IP.

Solution

Where to look to ensure you are downloading from the Preferred Server

Ivanti logs where we are downloading files from in multiple places the following files will help you determine where your files are downloading from. The following client-side logs will help determine where files are downloading from.

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

After enabling XTrace the following logs become more verbose: How To: Enable XTrace Diagnostic Logging for the Ivanti EPM Core and Clients

Software Distribution: C:\Program Files (x86)\LANDesk\LDClient\Data\sdclient_task###.log

Patch Manager: C:\ProgramData\LANDesk\Log\Vulscan.log

Provisioning: C:\ProgramData\LANDesk\Log\MapToPreferredHandler.log

Verifying you are receiving the correct Preferred Servers

  Sometimes necessary to make a manual request to the PreferredServer.asmx web service outside of a task for troubleshooting purposes. Below is an explanation of how to do this using a popular web development tool called Postman. You can download Postman on Windows and MacOS as an extension for the Chrome browser, or from the Postman website as a stand-alone tool. The following instructions assume you have already downloaded Postman to the machine.

1. In PostMan, next to the URL field at the top of the tab change the Type from "GET" to "POST"
   
   
2. In the URL field enter: http://CoreNameOrIP/landesk/managementsuite/core/PreferredServer/PreferredServer.asmx
   
3. Go to the Body tab. Select the "raw" radio button.
   
4. To the right of "raw" click on the drop down arrow by "Text", select "XML (text/xml)".
   
5. Copy and paste the following into the text field (Do not change anything, as the servers response will be based off of the requesting machine's IP, not the content of the request, but the request does have the be properly formatted):
   

   <?xml version="1.0" encoding="utf-16"?>
   <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
   <soap:Body>
   <GetPreferredServers xmlns="http://tempuri.org/" />
   </soap:Body>
   </soap:Envelope>

6. Click the blue "Send" button.
   
7. Once you click the Send button, you will receive a response with the preferred servers for that device listed. You will need to verify this against your Preferred Server configuration to ensure you have the servers you are expecting to receive.

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

• 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

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

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

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

I've built about a dozen software distribution packages that all silently install quite nicely. When I build a provisioning template and add each of these distribution packages using the "Distribute Software" task, some of them will display windows and other bits of UI on the client-end during installation, despite originally being silent. One of them even had a prompt for reboot that I was forced to decline on the client machine before it would continue to the next task. I've tried unchecking "Show client UI" in the provisioning template's "options" area, but this just disables the UI for the provisioning task itself, not the UI that comes up from the individual distribution packages.

What gives? Is there some way to make all of this silent once again?

Hello all,

    I have been trying to use InstallEase to create MSI packages for deployment.  I have been unable to create an installer that successfully performs the process. 

I have had a variety of errors in my testing.  One consistent one referenced some registry keys that had no value, and the MSI could not be created.  This persisted no matter how much I removed from the snapshot.  I did an easy one, where I copied files to the Program Files (x86) directory and then created links to those files and placed them on the desktop.  I was able to complete the process and an MSI file was generated.  After reverting the changes I made so I could test the installer, I attempted to use this MSI.  The "Gathering required Information" part takes longer that I have seen on other MSI installers.  I am not sure if that is related.  I get an error that it could not write a value to a key in the registry.  That I should check if I have sufficient privileges.

For reference, the details of this test environment are.  The OS is Windows 10 (latest build and updates) running as a VM (hyper-V).  Using a local user account that has admin privileges.  The Host OS is also a Windows 10 (latest build and updates) running on a Workstation laptop (Xeon processor, ECC RAM, etc).

Any thoughts are appreciated.

Sincerely,

  Pat

Hey Folks,

Been having an issue with false positives when deploying the OffScrub10.VBS script to workstations. Within Endpoint Manager the task succeeds, however Office 2010 is not actually removed from the workstation. when you examine the logs generated by the VB script you get the following message at the end of the log.

Successfully rolled back the uninstall of package: Office64WW path:C:\MSOCache\All Users\{90140000-0011-0000-0000-0000000FF1CE}-C\Office64WW.MSI

SystemRestore : Attempting to cancelling System-Restore-Point for Product [Microsoft Office Professional Plus 2010] (with RestorePointType [1, Removed]).

SystemRestore : Successfully cancelled System-Restore-Point for Product [Microsoft Office Professional Plus 2010] (with RestorePointType [1, Removed]).

Not showing completion dialog because it was not requested.

Reboot requested never.  Skipping reboot attempt.

Catalyst execution finished: 03/26/2018 21:21:08.  Return code: 1913.

PERF: TickCount=266371 Name=RunSetup Description=End function

i have added the 1913 return code to the Default non MSI template to return a failure, but i am still encountering a scenario where the task succeeds according to Endpoint Manager but does not "actually" succeed.

Has anyone had any experience with this particular issue? Also how have you been tackling office 2010 uninstalls during the migration to O365?

Introduction

Best known methods are only intended to be a starting point while finding what works best in any given environment. This guide will assist Ivanti Administrators with creating a software distribution package for Microsoft Office 365 Click-to-Run and deploying it with Ivanti EPM. When distributing Microsoft Office to multiple computers it is important to obtain the volume license for that product version. This document does not make reference to volume licensing.  For more information on Microsoft Volume licensing please go direct with Microsoft.

Installing Office 365 Click-to-Run

Download Office Deployment Tool (ODT) to a Network Share

There are (2) Deployment tools available. If you are managing Office 2016 product please use the 2016 version. For this example, the 2013 version was used.

• ODT_2013 Click-to-Run
• Office_2016 Deployment Tool
  

• The server this Network share is on does not have to be your Ivanti EPM Core server as long it has the correct NTFS and Share permissions. If you elect to use a server other than your Ivanti EPM Core you will need to ensure you have that server configured as an Ivanti EPM Preferred Server  (How to configure a Preferred Package Server)

For this example, the Core's LDLogon share was used and I created an Office sub-folder.

Run the Executable

• Run the downloaded .exe file as an administrator. The process will create a setup.exe and a configuration.xml

Customize the Configuration.xml

• Microsoft now offers a Configuration XML Editor which presents you with a GUI assisting in the creation of the xml file.

Below is an example of what the Configuration file will look. You can modify the attributes to your liking through the Configuration XML Editor tool or by manually editing the file.

<Configuration>      <Add SourcePath="\\share_server_name\share_folder" OfficeClientEdition="32" >          <Product ID="O365ProPlusRetail">                <Language ID="en-us" />          <Product ID="VisioProRetail">                <Language ID="en-us" />          </Product>  </Add><Updates Enabled="TRUE" UpdatePath="\\share_server_name\share_folder" /><Display Level="Full" AcceptEULA="TRUE" /><Logging Level="Standard" Path="%temp%" /><Property  Name="AUTOACTIVATE" Value="1" /></Configuration>    

Execute the Setup File

Now that your configuration xml file has been completed, open up an admin command prompt, navigate to your share and run the following:

setup.exe /download configuration.xml

This creates an "Office" folder with all the required files to complete your install.

Installing via Batch Distribution Package

• Create a batch file with the following command and save it to your share:

\\server_name\share_name\setup.exe /configure \\server_name\share_name\configuration.xml

   

Create Batch Distribution Package

• Create a distribution package to point to your batch file and distribute it out to your targets.

Installing via Executable Distribution Package

• Create a distribution package to point to the setup.exe file located in your share location.

• Select Install/Uninstall options and add the following command line switches:

/Configure configuration.xml

• Select Additional files, navigate to your share location and add the configuration.xml file and your Office folder to the additional files list.

• You can now Save your Executable package and schedule it out to your desired targets.

Related Articles:

• Ivanti Endpoint Manager and Endpoint Security - Software Distribution Frequently Asked Questions

Management Suite 2016.3 introduced Categories for the Software Catalog within Workspaces. Categories appear at the "Top" level of the Software Catalog, and include both a descriptor and an image.

This documented is intended to cover creating and utilizing Categories within the Software Catalog.

Creating Categories

Begin by opening the Distribution Packages tool within Management Suite by selecting Tools > Distribution > Distribution Packages in the Management Suite Menu Bar.

Once inside the Distribution Packages tool, select Configure Settings along the toolbar. The icon is a small cog.

The Default Package Settings window will open. In the left column, select Categories.

To add a Category, type in the desired name of the first Category and select Add. The newly created Category will appear in the List of Items box.

To add an image to a Category, select the created Category from the List of Items box and select Add Image. Browse to the stored location for the desired image and select OK.

Adding Categories to Workspaces

Now that the desired Categories have been created, the next step is too add them to Workspaces. To do this, Categories will have to be associated with various Distribution Packages.

In this case, the NotePad++  Distribution Package is being added to the Utilities category created in the above section. In the Distribution Packages tool, Right-Click the desired Distribution Package and select Properties.

In the Properties window, select Categories under the Metadata section in the left tree. Enable Categories by selecting Enable Categories and select the desired Category in the drop-down list.

Click Save.

The next step is to Schedule the Package and make it available to Managed Devices in the Workspaces Software Catalog. This is done in the same method as Portal Manager. For more information, please see this Community Document.

Once the Policy has been made available to the Managed Workstation, click Refresh in the Workspaces Software Catalog and the available Categories will appear.

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?

Purpose

This article discusses an issue where the client cache location is not updated on a Client/Preferred Server after a change.

Issue

After updating the Client Cache Location (via Client Connectivity Settings) files downloaded to a Device or Preferred Server still revert to SDMcache.

Cause

After updating the Client Cache Location within Client Connectivity Settings (seen below), the downloadmulticastconf.xml file on the Client is not updated properly.

Verification

Verification can be done by opening the downloadermulticastconf XML file (located at \ProgramData\LANDesk\TMCdownload on the client), and seeing one of two things:

1. The XML file shows the following line:

Original

<CacheDirectory>C:\ProgramData\LANDesk\ManagementSuite\sdmcache</CacheDirectory>

This line shows that the sdmcache is still the primary Client Cache location.

2. The XML file will be completely blank upon opening.

Resolution

Delete the existing XML file from the \TMCDownload\ directory.

From the client device open a run prompt and enter the following:

Once the update has completed, verify the <CacheDirectory> line within the downloadmulticastconf.xml file (this will be re-written with the changesettings task) to verify the updated location of your Client Cache.

I am trying to use the Windows Action Connect UNC share.

Diagnostics show the following

Fri, 06 Apr 2018 14:22:03 Installation result -1918091202

Fri, 06 Apr 2018 14:22:03 RunPackageInstall: stop on returncode=8dac403e of package=Map Drive Test

Fri, 06 Apr 2018 14:22:03 processing of package is complete, result -1918091202 (0x8dac403e - code 16446)

any help would be greatly appreciated.

When pushing out software to certain machines I am seeing an error

Mon, 09 Apr 2018 08:54:47 ExpandEnvironmentVariables Result: /s

Mon, 09 Apr 2018 08:54:47 LSWD or Executable Client Thread

Mon, 09 Apr 2018 08:54:47 PackagePath: [http://servername.com/EPM/packages/software/software.exe]

Mon, 09 Apr 2018 08:54:47 Processing generic executable

Mon, 09 Apr 2018 08:54:47 Launch failed GetLoggedOnUserProcessToken - err=1008

Mon, 09 Apr 2018 08:54:47 GetHighPrivilegeToken: GetTokenInformation return=6

Mon, 09 Apr 2018 08:54:47 Error, failed to launch application as the specified user!

Mon, 09 Apr 2018 08:54:47 Installationresult 8DAC4040

Mon, 09 Apr 2018 08:54:47 RunPackageInstall: stop on returncode=8dac4040 of package=Software

Mon, 09 Apr 2018 08:54:47 processing of package is complete, result -1918091200 (0x8dac4040 - code 16448)

Tried doing some research on the issue but haven't had any luck finding what could potentially cause this.