I have multiple preferred servers in remote locations and I need a way to confirm that all of the clients in a particular subnet are configured to communicate (and are communicating) with my designated preferred server. Is there an field in inventory (or anywhere else) where I can confirm that the client is configured to talk to a specific preferred server? On a related note, how can I confirm that the preferred server is replicating properly. This is a secondary need. A wholistic view of the client config is more important at this time.

Thank you!

Hi,

Can the Multicast Domain Rep get the files/installer from Preferred Server? or the Multicast Domain Rep will get the files from source?

Thanks

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

/i /quiet ADDLOCAL=DocumentManager /norestart

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

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

Error code 16418.

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

Hi,

I have run into this issue a number of time and I am wondering if there is a quick way to clear the client side task history.

I have published a number of Applications via the LaunchPad Link Manager.

The idea is that if the user does NOT have the application installed, it will be pushed out as a distribution task.

If the user DOES have the application installed. It will just launch the application.

The problem I am running into is that occasionally, for whatever reason, when an application is launched via Portal Manager and is NOT installed, it generated the error "CreateProcess failed to launch executable; contact your network administrator"

Now, I know the Distribution package works because if I try immediately after on another machine, it installed without issue. It may be that the machine drops connectivity momentarily but for whatever reason it fails with this error. It seems to me like the install fails, but the Portal Manager believes it installed correctly so next time the application is launched, it actually tries to execute rather than install.

I don't have a problem with this, because I know that if I could just retry the task, it would install correctly. The problem is that I cannot retry the task, If i try to launch the task again, it generates the same error message immediately. It does not try to reprocess the task. So, what I would like to know is, is there a way to clear the task history on the client so that it will try and install again?

I have seen a number of threads which mention scripts to clear database history but I am hoping that there is an easier way to clear the history than that?

Thanks

Alex

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.

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.

     This article covers one of the reasons you might be facing this message. If you want to have a detailed troubleshooting guidance, please read the following article:How to troubleshoot tasks hung with a status of "Client has initiated asynchronous policy execution"

Environment

This message is present in LANDESK Management Suite 9.6    [26.11.14]

Description

When trying to deploy a package, whatever Task settings you use, you might see this message:

Client has initiated asynchronous policy execution

Cause(s)

This message tells you that the Client is trying to pull a policy from the Core Server and does not manage to get it as it looks to get stuck in a loop.

This highlights a communication issue between them.

It can be that:

• The IP Address has changed and has not bee updated which leads to a wrong identification process during Policysync
• The Common Base Agent is not installed / loaded and does not get contacted by the Core
• The Client has the wrong information in its registry that points to another Core Server

There might be other issues that will be reported if recognized.

Resolution

As explained earlier, we have to check these settings in order to ensure our Core and Client are ready not only to see each other, but to exchange data.

To do so, follow the next steps:

I.    Common Base Agent

From the Core Server

Right click on one of the client machine that has the issue and click "Properties"

What is important here is the Common Base Agent status.

If the status is: Not loaded

• You will have to uninstall properly the agent on your device by using the /forceclean parameter as indicated in this article: How to uninstall the LANDesk Agent
• Then delete the device from your Core Server inventory. If you want to be sure that the device is not anymore in the database, you can follow this article: Pending unmanaged client deployments - Devices are deleted but come back when refreshing
• After the device is deleted, double check the settings of your Agent configuration, then rebuild your agents, and schedule a deployment using our Unmanaged Device Discovery feature.
• Once the agent is properly and successfully deployed, check again the Common Base Agent status.

If the status is: Loaded

Go to the next step.

II.  Miniscan

Take note of your Client IP address, in our example:

192.168.1.63

Then go on your Client machine and check your actual IP address:

If the IP address is not the same as the one you had earlier on the Console, go to:

C:\Program Files (x86)\LANDesk\LDClient

And execute as an admin the following executable:

MINISCAN.exe

This will verify and update your IP address to the Core Server.

    This feature is automatically launched when modifying the IP address but an issue has been found and already fixed in the Service Pack 1 for LANDESK Management Suite 9.6 which has a soft release target of Mid to End December

Once this is done and you can see that your device now has the proper inventory data, you will be able able to recreate the scheduled task, target your device and start it:

If you see that your task remains in the "Task Queued at Client for Execution" status after that, please read the following article: How to resolve "Task Queued at Client for Execution"

I ran into an issue with a distribution task that had me a bit stumped.

The task was a simple vbscript to perform some custom developed application upgrades. I created a custom vulnerability definition that scanned for a specific file and version on the client computers. I then used the "create query for affected computers" option to establish the target for the software package and set the scheduled time for the task to kick off at a predetermined time.

All the required steps went according to plan except when the task launched at the specified time, every single client reported "the client has initiated an asynchronous policy execution". Then sat there and did nothing. After waiting nearly 45 minutes for the task to execute, I removed all the targets, then manually dropped them back in from the console and relaunched the task. They immediately started downloading and installing the software package and upgraded normally.

So my question is, why did this task do this and how do I prevent it in the future? Many of our software repairs for custom software require us to roll patches within a specified time window and I can't afford to babysit a task every time we need to update it.

Hi All,

I'm new to the LanDesk tool. I have been trying to resolve package deployment failures but no luck.

We deployed VC++ Runtime 2010 on a test pc where it already has the higher version of VC++ (2012) installed on it and hence the deployment failed.

After this, i tried to deploy other packages like Adobe, Office but the installation never gets triggered on the client PC. When i check the scheduled task for these packages, it shows the status as "Active", Result : "client has initiated asynchronous policy execution" and the Return Code "1354".

The last few lines of the sdclient.log file has these entries:

Wed, 17 Sep 2014 09:53:58 PostInstallInventoryScan: Successfully created inventory scanner task.

Wed, 17 Sep 2014 09:53:58 Sending task status, cmd line -coreandip=coreserver -taskid=198 -retcode=-1918091262 -complete "-log=C:\Program Files (x86)\LANDesk\LDClient\data\sdclient_task198.log" -pkgid=177

Wed, 17 Sep 2014 12:22:09

RunAppMain: command Line :

Wed, 17 Sep 2014 12:22:09

Wed, 17 Sep 2014 12:22:09 Task is not required to send status

Can anyone able to provide any advice on what can be done to overcome this issue?

Thanks,

Gopal

Had a custom script that ran without issue on 9.5 sp1, updated to 9.6 and now Fails.

The scheduled Task results are:

Status:Failed

Result:An invalid parameter was passed

Return Code:16408

The script is simple, it copies files and overwrites existing.

Contents:

[JOBPARAM]

STEPS=1

[MACHINES]

REMEXEC0=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="\\VSIM-LANDESK\ldlogon\Packages\XUpdate\PIN\PIN_ACW-TXT.exe" /dest="C:\XUpdate\PIN_ACW-TXT.exe" /lan=90 /wan=60

REMEXEC1=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="\\VSIM-LANDESK\ldlogon\Packages\XUpdate\PIN\PIN_CDS-TXT.exe" /dest="C:\XUpdate\PIN_CDS-TXT.exe" /lan=90 /wan=60

REMEXEC2=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="\\VSIM-LANDESK\ldlogon\Packages\XUpdate\PIN\PIN_CDL-TXT.exe" /dest="C:\XUpdate\PIN_CDL-TXT.exe" /lan=90 /wan=60

REMEXEC3=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="\\VSIM-LANDESK\ldlogon\Packages\XUpdate\PIN\PIN_CDG-TXT.exe" /dest="C:\XUpdate\PIN_CDG-TXT.exe" /lan=90 /wan=60

REMEXEC4=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="\\VSIM-LANDESK\ldlogon\Packages\XUpdate\PIN\PIN_DDD-TXT.exe" /dest="C:\XUpdate\PIN_DDD-TXT.exe" /lan=90 /wan=60

REMEXEC5=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="\\VSIM-LANDESK\ldlogon\Packages\XUpdate\PIN\PIN_DDL-TXT.exe" /dest="C:\XUpdate\PIN_DDL-TXT.exe" /lan=90 /wan=60

REMEXEC6=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="\\VSIM-LANDESK\ldlogon\Packages\XUpdate\PIN\PIN_FLL-TXT.exe" /dest="C:\XUpdate\PIN_FLL-TXT.exe" /lan=90 /wan=60

REMEXEC7=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="\\VSIM-LANDESK\ldlogon\Packages\XUpdate\PIN\PIN_IRL-TXT.exe" /dest="C:\XUpdate\PIN_IRL-TXT.exe" /lan=90 /wan=60

REMEXEC8=<qt/>%LDMS_CLIENT_DIR%\sdclient.exe<qt/> /f /o /p="\\VSIM-LANDESK\ldlogon\Packages\XUpdate\PIN\PIN_LOL-TXT.exe" /dest="C:\XUpdate\PIN_LOL-TXT.exe" /lan=90 /wan=60

Please help and thanks in advance.

This video tutorial will show the basics of creating an executable distribution package, in this case Firefox.

If you have found this video helpful please like of bookmark.

I'm trying to deploy Symantec SEP 12 to out users, and I am getting the following error on a few of the machines:

"You were not connected because a duplicate name exists on the network.  Go to System in Control Panel to change the computer name and try again/"

I assure you, there is NOT a duplicate computer name on the network.  This is an AD domain, so you can't have duplicate computer names.

Could this be caused by someone cloning an OS with the LD Agent already installed, and not resetting the specific hardware ID in the registry?

Was curious on how to clear a selection in Portal Manager once you choose a background and want to go back to default.  Also if there is a way to not have any text involved in the name. If you clear it uses a default text also would be nice if instead of text it could be an image.

Hi everyone,

We encountered a problem while using Powershell Packages.

We set all our computers with an executionpolicy to Unrestricted.

Nonetheless when we use Landesk to execute a powershell script through a Powershell Package at the end of it the execution policy is set back to Restricted.

Our computers are Windows 7 SP1 x64 enterpise Edition and we are using Landesk 9.5 SP1

Does anyone encountered this issue? Do you know is Landesk SP2 or SP3 might fix this?

Best regards,

Charles.

Purpose

Method for remote unprovisioning of vPro clients, for troubleshooting and correcting issues that may require the client to be unprovisioned.

The Intel(R) AMT Unprovision Utility is a simple command line utility that allows users to remotely unprovision an Intel(R) AMT system without requiring a

separate management console.

Steps

1. Download the Intel UnprovisionEx.exe tool.
2. Unzip the files to your Software Distribution Storage.
3. In the Management Suite Console, create a new Software Distribution Executable package.
4. In the Package Information section use the UnprovisionEx.exe as the primary file.
5. In the Install/Uninstall Options section add the following switches into the install/uninstall options: -hostname %computername% -user admin -pass P@ssw0rd -full
   • For the password please use the admin password for your vPro machines .
   • The -hostname can be either the listed variable, FQDN or IP address.
6. Save the package and schedule it out to the vPro devices you would like to unprovision.
7. Once these machines are in the pre-provisioned state attempt to zero-touch provision these devices.

(To verify the provisioning state of the machine please reference https://community.landesk.com/support/docs/DOC-31903)

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.

Unexpected error in custom script source.  See agent log for details for two MS patches its affecting mos of systems ..i need help ?

This is probably a simple question but I cannot find the answer anywhere. We're moving to 9.6 from 9.0, and we use push tasks. Here in 9.6 testing, everything defaults to a policy (In the scheduled task properties, under Task Settings). Is there a settings to change to make the default a push?

Thanks in advance.

Explanation

A new feature we have added to LDMS 9.6 SP1 is the Package Relationships tool to allow you to quickly view all the relationships that Packages and Bundles have to other Bundles, Packages, and Tasks.

Overview

From this new window you can see the following information, in this case I selected a bundle named Bundle2:

1. Parent Bundle, you can see here the selected bundle is inside of "Bundle1."
2. Child Bundle, "Bundle3" is located inside of the selected bundle.
3. Child Packages, The LANDESK.com Link Package shown above is inside of the selected bundle, however the package located in "Bundle3" does not show in this view as it is not directly associated to the selected bundle.
4. Tasks, The last two items show Tasks that will deploy this bundle "Bundle1" and "Bundle2" are both scheduled and ready for deployment.

Summary

This new Relationship utility will help you to quickly resolve any relationship issues that arise when try to delete packages or bundles or simply trying to organize them effectively.