LDMS 9.6 SP2

Patch 0706B , 0701A , 0722F

This is a question about a very old post, has anyone lately been able to run this little app?

LANDesk Active Scheduled Tasks

I get an error "loging failed for user...."

I'm trying to get some additional information regarding the running tasks so I was testing this tool.

Regards.

Hi

Is there a possibility to install certain Software only, if user is inactive (lock screen or screen saver).

Regards,

Arnaud

This is the purpose of the document is to provide a high level overview of the changes to Software Distribution in LDMS 9.6. Links will be embedded to other documents for further information the specific changes.

Software Distribution under went many new changes in LDMS 9.6 fundamentally changing how tasks are handled configured and then processed on the client side. These changes include:

1. Global Scheduler rewritten to run leaner and faster.
   1. Time Zone Aware targeting has been added.
   2. Targeted Multicast has been deprecated in the LANDESK Global Scheduler in favor of Self-Organizing Multicast.*
   3. Scheduled Task Handler and Application Policy Management have been consolidated.*
2. Delivery Methods have been deprecated and their settings relocated to the Task Properties, Distribution and Patch Settings, and Reboot Settings.*
   1. Task Properties.
   2. Distribution and Patch Settings.
   3. Reboot Settings.
3. Link Manager has been deprecated, and links are now managed the same as any other Distribution Package.
4. Self-Organizing Multicast built into clients for quicker more efficient multicasting.
   1. Multicast Domain Representatives deprecated.*
5. PEDownloader.exe added to clients to simplify downloading of files, and troubleshooting download issues.

                  *Legacy Support still exists for LDMS 9.5 and older clients, although it is recommended to upgrade Agents as soon as possible.

1. Global Scheduler rewritten to run leaner and faster.

The LANDESK Global Scheduler has been rewritten to increase speed in processing tasks. Part of this upgrade called for the consolidation of Scheduled Task Handler (Used for Push Tasks) and Application Policy Management (Policy Tasks) into one optimized delivery system. The short and sweet of it is ALL tasks are now processed as Policies. You can still select to use a Push, Policy-Supported-Push, or Policy type of task, but these options have been moved in the Task Properties. To further lean down the Global Scheduler we have removed Targeted Multicast, in favor of Self-Organizing Multicast which is all handled on the client side taking the load off the server. And we have added the feature of Time-Zone Aware Targeting of Tasks, this allows a task to start at a certain time local to the machine, instead of going out to all targets at the same time it is started on the core.

1.1 Time Zone Aware Targeting

        Time Zone Aware Targeting for Distribution Tasks

1.2 Targeted Multicast has been deprecated in the LANDESK Global Scheduler in favor of Self-Organizing Multicast

To improve performance on the Scheduler Service, and also reduce the amount of work the Core took on in Multicast tasks we have removed Targeted Multicast. The multicast process is now completely handled by the client machines and is able to run faster and more efficiently than ever. For More information on Self-Organizing Multicast please see the section dedicated to it below.

1.3 Scheduled Task Handler and Application Policy Management have been consolidated

To further reduce the load on the core server's resources, optimize the processing of clients for Distribution tasks we have consolidated the Scheduled Task Handler (Push Tasks) and Application Policy Management (APM) engines into one. The end result is much closer to APM than Task handler, and as a result all tasks now behave similar to policies, although they can still be scheduled as a Push or Policy Supported Push type task as well, they all arrive to the client in the same manner.

All tasks now have XML files associated with the task that contain all the needed task info the agent needs to install the software. On the core server these files are located at \LANDESK\ManagementSuite\landesk\files\ClientPolicies\. Once downloaded to the client machine the policies are stored in C:\ProgramData\LANDESK\Policies. A windfall of this change is now it is much easier to find the status of a given policy and troubleshoot it. The LDCLientDB.db3 no longer exists on clients in LDMS 9.6.

2. Delivery Methods have been deprecated and their settings relocated to the Task Properties, Distribution and Patch Settings, and Reboot Settings

Along with the consolidation of Task Handler and APM and the addition of an Agent Setting specific to controlling reboot behavior associated with Software Distribution and Patch Management tasks, it made sense to move away from Delivery Methods and move the options found inside those methods to new locations.

2.1 Task Properties

In addition to selecting the Task Type (formerly Delivery Method) you can select some of the specific settings for the task to use such as:

• Task Settings
  • Frequency: Control if the task runs Once, Hourly, Daily, Weekly, or Monthly on the client. This does not cause the task to restart, but for the client to re-execute it. Formerly specific to Policy delivery methods.
  • Additional Push Options: Some setting here are from Delivery Methods, others like Accelerated Push are new.
  • Download Options: Would you like the task to Run from Source, Download and Execute, or to just Pre-Cache the files for execution later?
• Agent Settings
  • Select the Distribution and Patch settings, and Reboot settings specific to the task if they need to differ from the defaults already assigned to the agent.
• Schedule Task
  • Time Zone Aware Targeting

2.2 Distribution and Patch Settings

The majority of the setting you could find in the Delivery Method have been moved in the Distribution and Patch Settings.

• General Settings - Everything here applies to both Software Distribution and Patch Management.
  • Network Settings
    • Preferred Server / Peer Download Options
      • Peer
      • Preferred Server
      • Source
      • Multicast
    • Bandwidth Throttling
  • Policy Sync Schedule
    • Moved out the Agent Configuration to here.
  • Notifications
    • Allow user to defer and cancel tasks.
    • Show UI.
    • Use a custom message.
• Distribution-only Settings
  • Offline
    • How the agent behaves if it cannot contact the Core Server
  • Logged Off User Options
    • Control behavior if no user is logged on the machine, useful for tasks that require logged on user credentials to install the package.

2.3 Reboot Settings

     How to use Reboot Settings

3. Link Manager has been deprecated, and links are now managed the same as any other Distribution Package.

The LaunchPad Link manager tool has been removed from the Management Suite Console. Now to manage all your existing links you create and schedule then just like any other software distribution package.

4. Self-Organizing Multicast built into clients for quicker more efficient multicasting.

With the removal of Targeted Multicasting from the Global Scheduler on the Core, we have switched to a more efficient method called Self-Organizing Multicast. If the Multicast box is checked in the Distribution and Patch settings, then all the client in the task will communicate with other machines in the task on their same subnet, they will elect a machine to be the Multicast Domain Representative (MDR), who will be the sole machine downloading the files from the best location (Peer, Preferred Server, or Source) and will then multicast each file out the other side while the next file is downloading.

Previously the Core would elect the MDR, which depended on whether or not the network allowed subnet directed boradcasts, then the Core would push the files from the source to the MDR and once he had all the files he would begin the multicast. It was a drawn out process that took longer than desired in many cases, but allowed for minimum network traffic across WAN connections.

The new method is faster and more efficient on network communication overall.

**Detailed documentation coming soon**

5. PEDownloader.exe added to clients to simplify downloading of files, and troubleshooting download issues.

Have you ever copied the sdclient.exe out of the Boot.wim used in Provisioning tasks to simplify downloading files for tasks? Well those days are now gone. With the new PEDownloader.exe application that is part of every Windows Agent there is a simple way to download the needed files for a task. Located at:

C:\Program Files (x86)\LANDESK\LDClient\PEDownloader.exe

This utility allows you to more easily download files and folder from Source, Preferred Servers, Peers, or via Multicast. You can use this in your scripts, tasks, and troubleshooting.

PEDownloader is capable of testing every function of the LANDESK Downloader (lddwnld.dll).

For a list of commands, and some sample commands lines simply run "PEDownloader.exe /?" from the Command Prompt.

LANDESK Management Suite 9.6

Hello!

My organization is currently in the process of migrating our numerous installation bundles from our ZCM environment into our new and growing LDMS 9.6 SP2 environment.

This migration includes a large number of already written batch deployments that we will need to modify to take advantage of functionality in LDMS. Understanding Batch File Distribution Packages has been very helpful.

Unfortunately there are a significant number of these scripts that depend on Nircmd's great infobox or qbox functionality to prompt or notify the user during the delopyment if necessary.

For example, we have a batch script that will install a particular MS Word plugin. Word must not be running for the install to work, so in the script will check to see if Word is running. If it is, we prompt the user with Nircmd asking them please save their work and close Word. With ZCM, this prompt would be visible to the user even if the script were running as SYSTEM. In LDMS, this dialog box appears outside of user land and the script stalls waiting for input that it will never receive.

I realize that this will probably require a shift in the way we do things. For example, we could prompt the user ahead of time when they launch the install from the portal and fail the install if Word is still running. Not ideal, but workable.

That said, is there any way at all to interact with the user during a batch distribution?

Thanks for your help!

Description

This document covers the preparation and silent installation of Microsoft Office 2013 using both the Office Customization Tool (OCT) and LDMS.

Using the Office Customization Tool (OCT)

We will start by using the OCT to create an MSP to guide the unattended installation. From the Microsoft Office install root directory, launch "setup.exe /admin"

NOTE: The OCT is only available when using volume licensed versions of Windows Installer-based Office 2013. Versions that do not fit the criteria will result in the following error:

This will start the OCT. In the Select Productwindow, select the product that we'll be customizing and click OK. (Generally, only one will be available).

The following window will open which lists customization options for the installation of Office 2013. Since LANDesk only handles the download and execution portion of this job, we'll only need configure the Licensing and user Interface portion to ensure a fully silent install.

•     Enter the Product Key
•     Select None as the display level. Since we run the package silently, this package will fail if any other display level is selected.                                                                                                

•     Check the box to accept the terms of the License Agreement
•     Be sure to select Suppress Modal and No cancel     

    Configure other options as desired. For more information on using the OCT, please reference Microsoft's Office Customization Tool Reference for Office 2013.                                                                                                             

• Once completed, click File > Save As from the Menu Bar and save the MSP file to the updates folder in the package root directory. The name of the file isn't important.

    Its a good idea to now run the installation manually to ensure that it installs without error. Setup.exe will automatically search the update folder for any MSP files, so double-clicking it will now result in an automated install.

Create a new Package using the LDMS Console

Ensure that the Office 2013 installation package is on a network share in a preferred server. The download portion of the task will likely fail is these prerequisites are not met. For more information, please reference this Community Document on Preferred Servers.

In the LDMS Console, go to Tools > Distribution > Distribution Packages > New Distribution Package and select New Executable Package.

• In the Package Information section, browse to the share location and specify setup.exe as the primary file.
• In the Additional Files section, include all files in the directory excluding setup.exe and click the double arrow to move the files over.                                                                                                                                                                       

• Select Yes when prompted with this window asking to include all sub directories.

• Configure the remainder of package as needed. For more information, please reference this LANDesk Space Page on Software Distribution.
• Click Save.

                  NOTE: At any point if the package content needs to be changed, its important to right click the package and select "reset hash" after saving.

Create a new Scheduled Task to Deploy Office 2013

Right click the newly-created distribution task and select Create Scheduled Task. This will open the Scheduled Tasks tool with a new entry for the distribution task.

Drag and Drop the desired devices into the Scheduled Task, Right Click the task, and select Start Now > All Devices.

The installation will install completely silently with no display to the end user.

Applies to LDMS 9.5 SP2 with the BASE 04-17 component patch

Problems/Symptoms

When you scheduled any custom script (this includes OSD scripts) that contains calls to sdclient.exe it will fail if no users are logged into the target machines. The error message in the "Result" column of the schedule task would be "No user has logged onto the system, cannot process user specific options". The error code in the CJ-<name of the task>*.log for the sdclient command would be "-1818107508".

Cause

The "/enableloggedoffuserinstall" switch needs to be added at the end of the sdclient.exe command.

Fix

If your sdclient command looks like the following:

You need to add the "/enableloggedoffuserinstall" switch in the following way:

On 9.6 if this error is encountered- replace "sdclient.exe" in the script example above with "pedownloader.exe" as sdclient is no longer used for these functions. With pedownloader.exe there should be no need to manually add in the /enableloggedoffuserinstall command.

All, we've recently been asked to install a font set on all of the machines in our network (around 3,000 machines). I've scoured the web and the community but just seem to be more confused than when I began. Here's what I'm working with:

• we've placed the font set in a centralized location on our software distribution folder
• we're targeting c:\windows\fonts all our machines
• we have our landesk service account and the local admin account to work with

I thought it woud be as simple as finding a way to copy the files to c:\windows\fonts; however, I've read where end users would need to be power or admin users OR there would need to be registry entries.

Sooo...long story short, how many of you have deployed font sets to 1000+ machines? How did you accomplish this (any details or scripts would be greatly appreciated)?

Hi,

1. I want my Landesk clients to update policy and check if their is a application to download and install every hour.

I think i have found this setting under (Distribution and Patch) -> Policy Sync schedule, is this correct?

2. When creating a schedule task for an application, and i want the deployed application to evaluate 1 time / day that it is installed.

What settings should i use? In schedule task i have found under (Task settings) -> (frequency) that you could choose (once, houry, daily, weekly) is that an evaluation of a application?

or is it under (Schedule task) where you can set (Repeat every: hour, day, week)

As long as the application is detected Landesk will not install it again? Correct? Or will some of this setting override the detection?

Regard

Johan

Hello,

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

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

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

Thanks

Multicast Domain Representative (MDR) Discovery in Targeted Multicast

In order to perform Multicast domain discovery the Multicast server must be able to discover subnet representatives.

Multicast enables you to send a single packet to multiple targeted clients, greatly reduces the amount of bandwidth used.

There are three major components in the targeted multicast architecture as below diagram

TMC server: Runs on the core server and is responsible for managing multicast domains

Multicast domain representative:Performs the multicast to the individual multicast domains.

TMC agent:  Resides on each managed nodes and receives the multicast file data and places it in the local cache of the managed node.

TMC Job Flow

1. Subnet representative discovery The TMC server (on the core server) continues through the various discovery methods until a subnet/multicast domain representative is found. When a representative is found using UDP broadcast discovery the TMC server does not attempt the Target list discovery step. The check for targets w/file method only works after domain discovery has been accomplished, so it is never used in selecting a representative as part of domain discovery.
2. UDP scanning Because several of the discovery methods use a UDP ping sweeping technique to locate a multicast representative the protocol used is outlined here below: For each machine in the target list, or preferred representative list, for the subnet or multicast domain the TMC server sends a "Can anyone be a subnet Rep?" message to the target. If the target can be a subnet representative, it responds with "I can be subnet Rep". If the TMC server does not receive a response after approximately 20 milliseconds, it moves to the next target. The TMC server uses the first machine responding as being capable of being a multicast representative. If no responses are received the multicast discovery method will fail, and the next method will be tried.

An advantage of UDP scanning over UDP broadcast is that its point-to-point communications allow it to get past routers that are configured not to forward UDP broadcasts.

• Preferred representatives discovery

• Preferred representatives are defined in the "multicast domain representative" alias file. The representative is located using the UDP scanning as outlined above. The TMC server scans through the list of preferred representatives and will use the first representative to respond.
• Cached file discovery
  • when performing a multicast domain discovery the TMC server obtains information about computers that have a portion or the entire file to be multicast. If the TMC server is configured to use domain information in the registry and cached file discovery is enabled, the TMC server performs a cached file discovery. When a cached file discovery is performed the TMC server groups the subnets according to the information in the registry. Then a multicast domain discovery is performed. This does not provide further consolidation of subnets but does discover cached file information. The TMC server uses the information about the machines that have the cached file to determine the multicast representative.
• UDP broadcast discovery
  • The UDP broadcast discovery method can be enabled/disabled through the registry. The TMC server locates a multicast representative using a UDP broadcast as shown in the following diagram.
• Target list discovery
  • the discovery method of last resort. If no other discovery method succeeds in finding a multicast representative this method attempts to locate a multicast representative. This is done by performing UDP scanning on all targets for the multicast domain in the target list.

Description

LANDesk 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 step

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 as below would pop up automatically.

Problem Description

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

1, The portal could not pop up, no any response when you click Software portal as General step 5.

2, We could not find the new updated policies.

Trouble Shooting

1, From the MAC machine, Go--Go to Folder  /Library/Application Support/LANDesk/landesk.log, and check if the client received 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 in task pending list.

3, If there is any task status issue or error return code reported, you can check it as normal SWD trouble shooting guide.

Hello All,

What is the time that a change in a bundled package will sync to the assigned task.

When changing a package. I normally reset the hash and re-run the task to have changes to the package.

For changes to a bundled package this time is much longer but how long is the refresh time of a bundled package ?

LDMS SP2

I have created a task to pre-cache a specific application.

The tasks runs fine and the file is in the pre-cache folder.

Then I get a new file that has the same name as the previous one, replace the old app with the new one in my Software Distribution Folder and run the task again.

Shouldn't my app be updated with the new file? I have reset the hash and rerun but still the task completes, but the file in the client is never updated.

Any help is appreciated.

Regards.

Purpose

This document outlines possible causes why a Preferred Server may fail

Symptoms

• Replication tasks to the preferred server fail. The replicate.log on the client shows Code: 64 (0x40).

Mon, 14 Sep 2015 07:56:54 Connecting to '\\win7x64\replicateshare\'

Mon, 14 Sep 2015 07:57:05 Failed to connect to share (\\win7x64\replicateshare).

Mon, 14 Sep 2015 07:57:05 WNetAddConnection2 Error = (64).

Mon, 14 Sep 2015 07:57:05 Share count for '\\96-core3\replicateshare': 0

Mon, 14 Sep 2015 07:57:05 Disconnecting from previous share (\\96-core3\replicateshare).

Mon, 14 Sep 2015 07:57:05 Last status: Failed.  Error: 64 (0x40)

Mon, 14 Sep 2015 07:57:05 Reporting connection failure to core

Mon, 14 Sep 2015 07:57:05 Reporting status Failed to connect to share '\\win7x64\replicateshare\'.  Code: 64 (0x40)

• When trying to test credentials within the LDMS Core against a UNC share for a Preferred Server, the credentials fail.

UNC authentication failed.

• When trying to open the C$ on the preferred server, the connection fails.

\\computer\c$

The target account name is incorrect.

Cause

This particular set of symptoms has been seen when the client device has broken it's connection with the domain.

Related Article:

Troubleshooting AD Replication error 1396: Logon Failure: The target account name is incorrect.

Resolution

Because the cause of the error may vary, the not all resolutions may be applicable.

• Rejoin the device to the domain.
  • This has been seen to correct the issue in a variety of situations.

Since we are a large organization, we have one core server specifically used for Servers.  We are moving to LANDesk Management Suite 9.6 SP2 and would like to ensure we have the right settings.

Since the clients are servers, the priority is reducing downtime.  Nothing is Autofix, and all reboots are scheduled. There are currently no prompts, no deferment, no countdowns, etc.

We would like two patching options controlled through “Scheduled Tasks”.

1. Scan against the Compliance group, Stage/repair detected vulnerabilities, and wait for a scheduled reboot task.  Nothing after the reboot.
2. Scan against the Compliance group, Stage/repair, immediately reboot.  Repeat until completely compliant.  Once compliant, revert back to normal agent settings.

With the new changes in 9.6 we are worried about getting all the right settings.

Thanks in advance.

Environment:

LDMS 9.6

Problem:

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

Purpose:

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

Cause:

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

Troubleshooting Steps:

A. Core and Client Communication:

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

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

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

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

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

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

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

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

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

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

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

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

B. PolicySync.exe

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

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

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

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

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

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

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

C. SDClient.exe and Vulscan.exe

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

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

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

-OR-

C:\ProgramData\Vulscan\Vulscan.log

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

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

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

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

Has anyone had any success pushing the click to run Office 365 installation to users in there domain. I am having an issue with push. I have downloaded the ODT(office deployment tool) and the click to run Office 365 sources. I have created a bat file to run the setup.exe and configured my configuration.xml file but it will not run in LanDesk.

If you have any tips or example scripts for pushing this would be greatly appreciated.

Thanks,

James P

LANDESK Content Replication can be used to keep files updated and current throughout an enterprise. The process uses a LANDESK managed node assigned as a Replicator to move files from configured Sources to target Preferred servers. There are several steps in the process and LANDESK uses existing agent functionality and tools to perform the replication.

For more information on Content Replication and Preferred servers see : Using LANDESK Content Replication

Creating the File List

The first step in a replication task is started is creating the file list. The Replicator will start with a Source and replicate it to all assigned Preferred servers. The Replicator will first compare the files and hashes that are on the Source with the ones that are already on the Preferred server. Any files that are missing or where the hash doesn't match will be replicated to the Preferred server.

The manifest of files is only created every 30 minutes.

The replicator.log will show the following to indicate if it recreated the manifest or not:

  "Manifest file is old or missing so will be re-generated"

or

  "Manifest file will NOT be regenerated."

Download the Files

Once the Replicator has identified the files that need to be replicated to the Preferred server, it will download the files needed to the cache on the Replicator. This will be located in C:\Program Files\LANDESK\LDClient\SDMCache. The download will use the bandwidth throttling settings configured in the Replicator settings. All files that are downloaded will remain in the cache of the Replicator for a period of time. This time can be configured as part of the Replicator settings.

Push the Files to the Preferred server

The Replicator will next use the write credentials configured in the Preferred server settings to write the files to the Preferred server. The Preferred server must have a UNC share in order for the Replicator to write to it. The Preferred server can also deliver files to clients via HTTP, but UNC must be available for replication to work. For each files that is copied to the Preferred server the Replicator will write a hash file. The file contains details about the file including the hash. This file is written to a custom directory named LDHashDir that is created in each folder and sub-folder. The LDHashDir will contain a special hash file for each file that was written to the Preferred server by the Replicator.

Ending the Job

If the Replicator is configured to continue until the job is complete, it will copy all the files needed to a Preferred server, then move on to the next Preferred server assigned to the same Source. The Replicator will download any additional files needed for the subsequent Preferred servers. Once the first Source has been replicated to all assigned Preferred servers the Replicator will move on to the next Source.

If the job is configured to end after a certain amount of time, it will stop when the set time is reached. The time starts when the job starts. For example, a job is set to start at 8:00 PM and run for 4 hours. If the job drifts a little and starts at 8:30 PM, it will not end until 12:30. When the job reaches the maximum time period it will stop replication right where it is. If it is in the middle of a file, the partial file will remain on the Replicator.

Resuming a Job

There are a variety of reasons that a job may be interrupted or stopped before it is complete. It could have been manually stopped by the administrator, maxed out the allowed duration, or the Source, Preferred server or Replicator could lose power or network connectivity. LANDESK will resume the replication at or near where it left of the next time the replication job runs. Exactly where the job will resume depends on why the job stopped.

Manually Stopped

If the job was manually stopped by the administrator selecting Disable task in the LANDESK console, the job will resume right on the file that it stopped on

Ran Out of Time

If the job was stopped because it got to the maximum allowed duration, the job will resume right on the file where the job stopped.

Preferred server or Source Becomes Unavailable

The Replicator will update the core with the most current status and resume within a few files of where it stopped.

Replicator Becomes Unavailable

The Replicator frequently checks in with the Core server and sets a checkpoint every 200 files. If the Replicator loses power or crashes, the next replication job will resume at the most recent checkpoint that was sent to the Core server. For example, a Replicator gets to file 200 and sends a checkpoint to the core. Then it gets to file 375 and the power goes out. The next time the job runs, it will resume at file 201.

For more information on Content Replication and Preferred servers see:

Using LANDESK Content Replication

This document applies to LDMS 9.5 and older versions. For LDMS 9.5 SP1 and later please refer to the following document:

Altering Retention for content to remain within SDMCACHE

Issue:

How to change the time that files remain in the SDMCACHE directory.

The SDMCACHE directory is where LANDesk products store files that were downloaded during Software Distribution or Patching tasks. By default, this folder is purged every 7 days on normal agents and every 14 days on subnet representative agents.

Solution:

1. Change the following registry values on the client:

32bit

HKLM\Software\Intel\LANDesk\LDWM\Distribution\Multicast\Discard Period

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

64bit

HKLM\Software\Wow6432Node\Intel\LANDesk\LDWM\Distribution\Multicast\Discard Period

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

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

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

Increase the data value in seconds.

Note: When updating the registry, this will update the *.info files located in ldcacheinfo directory for the discard date.

2. Restart the LANDesk Targeted Multicast service on the client.

Note: This does not change the time for files that are already in the SDMCACHE directory. To change the time for existing files in Management Suite 9.0 SP2 or higher, delete the LDCACHEINFO subfolder from each directory containing files needing the longer discard period before restarting the service.

To verify that the files have been cached the intended amount of time, run "TMCsvc.exe /F|more" from a command prompt in the \LDClient directory. This command will output cached files "time to live" values to screen.

Environment

8.7 to 9.5 SP3

Question

How to deploy a software package silently.

Answer

For SWD and MSI based distribution packages:

In the delivery method, under "Feedback and Timing", choose the option of "Hide all feedback from user".

For packages based on executable packages:

All executable installers are different and support unique command line switches and answer files. There is no single way to silence all executable.

Methods for automating and silencing an executable install must be obtained from the vendor. Once this information is known, the executable distribution package can be configured to silence the install.

Running the .exe with a /? will sometimes show available options for installation. If there is a command line option to silence the executable, it can be added to the command line in the Install/Uninstall section of the distribution package.