I have checked the core Shared Files folder and the certificate exists. I also checked the registry on the core server to see if the registry key points to the correct certificate and it does. All of my agents now say that there is no certificate.

Can someone help? What else should I do? It does not allow me to enter the certificate manually on the agents.

any help is appreciated!

ISSUE:

Scheduled agent deployment for terminal server and it's failing with error from log wscfg32.xlg

Agent was failing on 1 Windows 2003 R2 SP2 server.

Error from vcredist_x86.log:

MSI (s) (7C:4C) [10:49:57:974]: Running install from non-console Terminal Server session.

MSI (s) (7C:4C) [10:49:57:974]: Machine policy value 'EnableAdminTSRemote' is 0

MSI (s) (7C:4C) [10:49:57:974]: Rejecting attempt to install from non-console Terminal Server Session

MSI (s) (7C:4C) [10:49:57:974]: Note: 1: 1729

MSI (s) (7C:4C) [10:49:57:974]: Product: Microsoft Visual C++ 2008 Redistributable - x86 9.0.30729.6161 -- Configuration failed.

MSI (s) (7C:4C) [10:49:57:974]: Windows Installer reconfigured the product. Product Name: Microsoft Visual C++ 2008 Redistributable - x86 9.0.30729.6161. Product Version: 9.0.30729.6161. Product Language: 1033. Reconfiguration success or error status: 1640.

MSI (s) (7C:4C) [10:49:57:974]: MainEngineThread is returning 1640

MSI (s) (7C:64) [10:49:57:974]: No System Restore sequence number for this installation.

Info 1640.Only administrators have permission to add, remove, or configure server software during a Terminal services remote session. If you want to install or configure software on the server, contact your network administrator.

c:\03295e29844420b3ff2ca852\vc_red.msi

SOLUTION:

Installing a Windows installer package will automatically install in Terminal Server Install mode. Other types of setup.exe packages may use the following methods to install:

•          Use the Install Application on Terminal Server option in Control Panel to install the program.

•          Before you install a program, run the change user /install command from the command line. After the program is installed, run the change user /execute command to exit from Install mode.

NOTE: You must add all users who you want to be able to connect to the terminal server to the Remote Desktop Users group, and you must install all programs via the Add or Remote Programs Control Panel applet. Ensure users are assigned to Remote Desktop Users group and Domain Admins Group (if Domain environment)

Changed status on server to allow installation on Terminal Server Session

Installing an application will create a .ini file in the TS system directory. The first time a user runs the application, the application looks in the home directory for its .ini file. If none is found then Terminal Server will copy the .ini file from the system directory to the users home directory. Each user will have a unique copy of the application's .ini file in their home directory.

Environment: Various (April 2014 this worked on 9.0SP2)

Question:

How to uninstall the LANDesk agent?

Warning: Do not use the /forceclean switch on a core server when removing an agent from the core.  This will break the core server!!!!!!!!

Answer:

Run UninstallWinClient.exe. This program is located in the ldmain share on the Core Server. It can be run from that share or copied to the local client and executed. It is standalone and doesn't rely on any other files to run. Uninstallwinclient.exe removes the Windows agent only.

By design, uninstallwinclient.exe will remove:

• All LANDesk files except some in ‘all users\application data\’ such as the APM DB

• All LANDesk start menu shortcuts

• All LANDesk services

• All registry values and keys except the common API keys containing the LANDesk GUID

UninstallWinClient.exe has the following command-line options:

If you want to uninstall the agent remotely, Uninstallwinclient.exe can also be deployed as an Executable Distribution Package.

• No additional files need to be added to the distribution package.

• It's recommended to use the /NOREBOOT switch in the package if there is an end user using the client so that the machine doesn't reboot and cause the user to lose work.

• When you distribute this package, the agent will be uninstalled but the status of the task will remain "active" until it times out and eventually fails. This is because the agent is no longer able to report status back to the core.

If uninstallwinclient.exe is failing to remove part of the agent and is causing problems:

• Try the version of uninstallwinclient.exe from the newest service pack.

• Notify customer support.

Related questions:

How to uninstall the LANDesk client without rebooting?

What are the UninstallWinClient.exe command line options?

Related errors:

Xtrace log shows : FAILED: bCriticalError is true. Setting exit code to ERROR_INSTALL_FAILURE

Hi All

LDMS 9.0

We have many machines that communicate to the Core Server only over the Management Gateway, these computers will never be on the network.

I want to update some of the agent settings for these machines. When I create a "Schedule update to agent settings" task, I don't have the option of choosing the delivery method, it is set as a push only.

As I cannot push to machines over the Management Gateway, how do I update the agent settings for these remote machines?

Has anyone else solved this problem? Is there maybe a script that could be scheduled as a policy to do this?

I am hoping that the answer is not that I have to install a full agent every time.

Cam

Environment

LDMS 9.x

Question

How do I verify my UDD results are accurate and working correctly?

Configure your UDD settings (in this case I am using the default settings)

Be sure to note the specific options because each option will change the way the scan will work.

Run ProcessExplorer while your UDD task is ran from the LDMS management console and look for the nmap.exe task.

Double click to open the nmap.exe task to see additional properties like the nmap command that was launched.

In this example see how nmap was launched;

"C:\Program Files (x86)\LANDesk\ManagementSuite\nmap\nmap.exe" -v -PN -T4 -sS -F -O --script smb-os-discovery.nse --osscan-guess -iL "C:\Users\Administrator\AppData\Local\Temp\0ul6hdmp.scanlist" -oX "C:\Users\Administrator\AppData\Local\Temp\0ul6hdmp.xml"

Notice that the command points to a Temp folder on my core for writing the outputs of these scans;

Explanation of these files

The *.scanlist file has a list of IP addresses that were scanned

The *.xml file will be created and then updated with the correct results while the UDD task is running. After the task is complete you can analyze to see the results.

The *.tmp file does not have any data in it so you don't need to worry about it

Comparing the results from the Core to running nmap manually. This will help prove or disprove an issue with the core or nmap.

Take the nmap command that the core used, and run it through a command prompt:

NOTE -- You will want to rename or backup the *.xml file in the Temp directory prior to running this manually. If you don't then it will be overwritten. Notice for my test I renamed 0u16hdmp.xml to 0u16hdmp1.xml.

What difference if any do you see between the output files from the core VS running from CMD?

To learn more about nmap: http://nmap.org/

To learn more about OS Fingerprinting:

NMAP - OS Fingerprinting Ports Used in LANDesk 9 SP2

Note that if you DO NOT use OS Fingerprinting then LDMS does NOT use nmap. Instead we will do a ICMP ping sweep and use NetBios to find the host name.

Hi,

I have just been given the task of LANdesk operator..

I am attempting to create an installer for windows XPE 2009, however when it runs i get a text file saying done and no icon in the system tray and when landesk scans the machine doesnt have the agent software.

i tried the scheduler to push the agent, but alas i dont have the script to push this to Wyse XPE2009 units...

can any one help?

Easyk

Have a question I have installed and uninstalled an agent on a Optiplex 7010 several times. When I go to my Landesk console I see the computer but when I try to remote into it, it is giving me an error that says: " The remote computer is not managed by your server". I have also ran inventory scan on that pc several times as well. Any assistance on this issue will be greatly appreciated. Please take into consideration that I have done this many times....

Environment

LDMS 9.x

Problem

My LANDesk agent installation task is failing to run. This could happen for a lot of different reasons but one in particular is that the host name is not being discovered correctly during the UDD task. If the UDD discovery does not get the hostname right, agent install will fail because IPCheck.exe checks the target hostname to the actual hostname of the system. I have sometimes noticed that if the firewall is enabled, it doesn't get the hostname. Instead it reports the hostname as the second half of the MAC address of the device causing the client install to fail.

Solution

Verify the Device Name is correct in the core:

If it is incorrect then run UDD again to see if it gets it right. If it is still incorrect you could check the firewall on the client to make sure it is allowing the UDD task to return the name correctly.

Agent Deployment for LANDesk Management Suite

General Information

  Standard Push:The agent files are located on the core server and distributed via a push task. The credentials used in the Scheduler configuration on the core server are critical for this type of distribution.

    Self-Contained Executable: Agent files are compiled into a completely self-contained executable that is portable. This method is efficient and helps with a lot of network configurations however the executable does not get updated when the configuration changes or when files are updates by patches or new releases. It is recommended to keep these executables in a central location and perhaps date them as well so that they can be rebuilt as needed. Two self-contained executables are created for this option one with status (shows GUI to the user) and one without.

    Advance Agent: The primary purpose of this agent deployment method is to control the amount of bandwidth used during agent install. However, the design has many other uses. The agent is broken up into two files (and MSI and an EXE). The MSI will install a temporary service on the client where it will gradually stream down the main executable and install the agent. The temporary service is removed. Since the temporary service comes in MSI form this design also makes it favorable for deployment using an Active Directory login script. (Note: Including security definitions with the agent can make the primary executable very large and greatly increase agent download/install times)

     Wscfg32.exe: This is an executable located on the core server in the ldlogon sub-folder. When executed on a client it will pull the settings in a default windows configuration and launch an agent install window. Changes can be made to the configuration before starting the agent install.

     Other Operating System Information: Macintosh and Linux/Unix agents will work somewhat different than Windows based ones. For details on those agents please check their component landing pages.

Supported Platforms and Compatibility Matrix for LANDesk Management Suite

Install and Configuration

• Video:Agent Installation Methods
• Video:Agent Configuration
• Video:Management Suite 9 Fundamentals Agent Configuration
• How to create an Advance Agent
• How to create an Advance AgentDocumentation for Agent Configuration and Deployment (Best Known Method for LANDesk 9)

Troubleshooting and Known Issues

     General Troubleshooting Recommendations:

• The LANDesk agent (just like any other program) can be affected by Anti-virus, Spyware, and other blocking programs. Closing or suspending such programs may help with agent installation.
• When right-clicking on an agent two of the options will be "Schedule agent deployment" and "Schedule update to agent settings". The difference between these two is that the update will not deploy any files and only make changes to when scan run etc. If a new feature is added to the configuration or removed then a full agent deployment will be required.
• If an error occurs during the creation of the agent (advance agent or self-contained) a log file is generated. Typically the agent configuration was told to include a certain file and the process either couldn't find the file or didn't have access to it.
• Troubleshooting Agent Installs

• Advance Agent install process and troubleshooting tips
• Why can't I install the Advance Agent over itself on a client?
• UninstallWinClient.exe may not run correctly on Windows 7 under UAC
• How to completely remove LANDesk from a remote console or client device

Additional Options and Information

• Video:Agent Deployment via Login Script
• Video:Agent Deployment via WSCFG32
• Customizing the LANDesk Agent using the NTSTACFG.IN# file
• How to uninstall the LANDesk Agent on Windows Platforms
• How to uninstall the LANDesk Agent on Macintosh Platforms

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

NOTE: 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 Agent Deployment if this page hasn't helped.

Environment

LDMS 9.x

Scope

This document is intended to help you to narrow down or resolve agent installation problems in general.

Assumptions

You should have a basic understanding of how to create and push out LANDESK agents, and how to use the LDMS core.

Here are some basic troubleshooting questions and steps that will help you to narrow down the error(s) that you are seeing

Does the problem you are seeing happen on all systems across the board or just a few of them? Have you tried to run the same task on a fresh VM or PC to see if the issue still exists? If the problem happens on all devices and or fresh VM's or PC's then it is most likely an issue with the agent installation files on the core, and you should look at them more closely. Specifically, you should look at the following files on the core in the \ldlogon folder;

"Put your Agent Name Here".msi

"Put your Agent Name Here".ini

You can open, view, and edit the agent.ini file with your favorite text editor, I like notepad++. The agent.ini file will show you all of the configuration options that this agent will install with, so open it and make sure that it has the correct options. You could compare it to another agent.ini if you have one that is working and one that isn't.

You can open the agent.msi to see if everything looks good. When you are having problems, it is good to compare the agent.msi with the problems to one that is known to have succeeded. To view the agent MSI you will need an MSI editing tool, I like to use Orca from Microsoft.

Typical size for an agent.msi is about 310KB and anything smaller could indicate a problem. Most of the important actions will be stored in the CustomAction section of the MSI.

If you suspect problems with any of these core side files you could do a "Rebuild All" task from the core. This should rebuild all agent configurations including the agent.msi and agent.ini files so you should see the date and timestamp change for these files in the ldlogon folder.

If a rebuild all task is still not doing the trick you may want to try a rebuild all from a CMD prompt. In some rare cases we have seen issues with "Rebuild All" from the console so running this from a command prompt might help you.

To rebuild all from a command prompt, go to the \LANDesk\ManagementSuite folder, and run this command: CreateClientConfiguration.exe /rebuild

Note -- Check to see that the ldlogon directory on the core has updated time stamps for these files after doing the rebuild. If you see files that are NOT updating then rename the originals to *.OLD and then run the task again, new ones should be created.

If you are pretty confident the files on the core look good then let's move on to the client:

Right after you start the task on the core go to client and look for a $lddir$ or $ldcfg$ folder that gets created on the root of the C drive. If you don't ever see this share get created then most likely you have a communication or sharing problem. If this is the case verify the following;

a. Can you ping from the core to the client and the client to the core?

b. Does the hostname resolve to the correct ip address?

c. Does the scheduler user that is configured in the core have rights to that box? Remember an agent push task is ran by the scheduler service in the core. If this is on a domain it is usually best to make this account a domain admin.

e. Check that "Simple File Sharing" is enabled on the client.

As a test you could login to the core with the same user that the scheduler service is using, and try to map a drive to \\clienthostname\C$.

Moving on, if the core files look good, and you see the shares being created, then you will need to look at the agent install logs to see where it is failing.

The agent install logs would be in any of the following locations depending on how the task is being run;

Windows\Temp folder

%temp% folder

LDClient folder

Below are the key logs to look at. Note that these are NOT all of the logs, and in some cases you may need to look at others, but these are most likely to have problems.

agentmsi.log (the log file for the agent.msi)

wscfg32.xlg (the log file for the agent installer wscfg32.exe)

If the agent.msi has a problem, double check your agent.msi looks good on the core. You could also copy the agent.msi manually from the core and launch it manually from the client with the showui switch to see if the Windows installer is broken on your client. If your xlg log has errors then you may need to involve support for further help, or search the community for your specific error.

Additional quick troubleshooting tips:

Build a self-contained agent on your core and copy it to the client and manually run it. Does it work? If so then that will at least prove that the files in THAT exe are good. Be sure that the self contained EXE that you are using is current, if you are using a 2 year old exe then it will not have the same files that you are trying to push the agent with.

Does the client you are trying to install the agent on already have a LANDesk agent? If it does, as a test you may want to run the UninstallWinClient task on it, followed by another install attempt to see if the issue only occurs during the agent upgrade.

Follow this article for more on UninstallWinClient: How to uninstall the LANDesk Agent

Prior to running the agent install task, verify the Device Name is correct for the device(s) you are attempting to install to: Agent install fails because UDD didn't discover host name correctly

Verify UAC is turned off

Try installing the agent on a different OS? Maybe your issue is only related to a certain OS. Note that you need to build a separate agent configuration for Windows Server OS's, Windows OS's, and Windows Embedded OS's (WES).

Use Process Explorer and Process Monitor tools available from microsoft to diagnose problems. These should run on the client when the install is happening and could be monitored to watch the progress.

I've recently had to reimage a couple of PC's.  No hardware has changed with the exception of a HD in one of the machines, hostnames were reused in both instances.......neither of these workstations show up in UDD.  Any ideas?

Running LD 9.50.0.530

Environment

LDMS 9.x

Scope

This document is intended to help you to narrow down or resolve agent installation problems in general.

Assumptions

You should have a basic understanding of how to create and push out LANDESK agents, and how to use the LDMS core.

Here are some basic troubleshooting questions and steps that will help you to narrow down the error(s) that you are seeing

Does the problem you are seeing happen on all systems across the board or just a few of them? Have you tried to run the same task on a fresh VM or PC to see if the issue still exists? If the problem happens on all devices and or fresh VM's or PC's then it is most likely an issue with the agent installation files on the core, and you should look at them more closely. Specifically, you should look at the following files on the core in the \ldlogon folder;

"Put your Agent Name Here".msi

"Put your Agent Name Here".ini

You can open, view, and edit the agent.ini file with your favorite text editor, I like notepad++. The agent.ini file will show you all of the configuration options that this agent will install with, so open it and make sure that it has the correct options. You could compare it to another agent.ini if you have one that is working and one that isn't.

You can open the agent.msi to see if everything looks good. When you are having problems, it is good to compare the agent.msi with the problems to one that is known to have succeeded. To view the agent MSI you will need an MSI editing tool, I like to use Orca from Microsoft.

Typical size for an agent.msi is about 310KB and anything smaller could indicate a problem. Most of the important actions will be stored in the CustomAction section of the MSI.

If you suspect problems with any of these core side files you could do a "Rebuild All" task from the core. This should rebuild all agent configurations including the agent.msi and agent.ini files so you should see the date and timestamp change for these files in the ldlogon folder.

If a rebuild all task is still not doing the trick you may want to try a rebuild all from a CMD prompt. In some rare cases we have seen issues with "Rebuild All" from the console so running this from a command prompt might help you.

To rebuild all from a command prompt, go to the \LANDesk\ManagementSuite folder, and run this command: CreateClientConfiguration.exe /rebuild

Note -- Check to see that the ldlogon directory on the core has updated time stamps for these files after doing the rebuild. If you see files that are NOT updating then rename the originals to *.OLD and then run the task again, new ones should be created.

If you are pretty confident the files on the core look good then let's move on to the client:

Right after you start the task on the core go to client and look for a $lddir$ or $ldcfg$ folder that gets created on the root of the C drive. If you don't ever see this share get created then most likely you have a communication or sharing problem. If this is the case verify the following;

a. Can you ping from the core to the client and the client to the core?

b. Does the hostname resolve to the correct ip address?

c. Does the scheduler user that is configured in the core have rights to that box? Remember an agent push task is ran by the scheduler service in the core. If this is on a domain it is usually best to make this account a domain admin.

e. Check that "Simple File Sharing" is enabled on the client.

As a test you could login to the core with the same user that the scheduler service is using, and try to map a drive to \\clienthostname\C$.

Moving on, if the core files look good, and you see the shares being created, then you will need to look at the agent install logs to see where it is failing.

The agent install logs would be in any of the following locations depending on how the task is being run;

Windows\Temp folder

%temp% folder

LDClient folder

Below are the key logs to look at. Note that these are NOT all of the logs, and in some cases you may need to look at others, but these are most likely to have problems.

agentmsi.log (the log file for the agent.msi)

wscfg32.xlg (the log file for the agent installer wscfg32.exe)

If the agent.msi has a problem, double check your agent.msi looks good on the core. You could also copy the agent.msi manually from the core and launch it manually from the client with the showui switch to see if the Windows installer is broken on your client. If your xlg log has errors then you may need to involve support for further help, or search the community for your specific error.

Additional quick troubleshooting tips:

Build a self-contained agent on your core and copy it to the client and manually run it. Does it work? If so then that will at least prove that the files in THAT exe are good. Be sure that the self contained EXE that you are using is current, if you are using a 2 year old exe then it will not have the same files that you are trying to push the agent with.

Does the client you are trying to install the agent on already have a LANDesk agent? If it does, as a test you may want to run the UninstallWinClient task on it, followed by another install attempt to see if the issue only occurs during the agent upgrade.

Follow this article for more on UninstallWinClient: How to uninstall the LANDesk Agent

Prior to running the agent install task, verify the Device Name is correct for the device(s) you are attempting to install to: Agent install fails because UDD didn't discover host name correctly

Verify UAC is turned off

Try installing the agent on a different OS? Maybe your issue is only related to a certain OS. Note that you need to build a separate agent configuration for Windows Server OS's, Windows OS's, and Windows Embedded OS's (WES).

Use Process Explorer and Process Monitor tools available from microsoft to diagnose problems. These should run on the client when the install is happening and could be monitored to watch the progress.

Have a question I have installed and uninstalled an agent on a Optiplex 7010 several times. When I go to my Landesk console I see the computer but when I try to remote into it, it is giving me an error that says: " The remote computer is not managed by your server". I have also ran inventory scan on that pc several times as well. Any assistance on this issue will be greatly appreciated. Please take into consideration that I have done this many times....

Environment

LDMS 9.x with any supported client OS

Problem

The LANDESK agent install can fail for many reasons. This document is intended to be a quick guide for some of the basic things to look at. For a more detailed troubleshooting guide see: http://community.landesk.com/support/docs/DOC-31663

Solution

If in the course of attempting to deploy a client configuration to a new client (i.e. client without the LDMS agents installed), you can check the following things to determine what the problem is:

1. A common reason for failing is that the DNS database is misconfigured.  Check by pinging from the core to the client and the client to the core.  If the IP addresses don’t match up and if the pings don’t complete successfully, address this first before trying UDD again.
2. Check the scheduled task handler log file for errors:  In the “c:\Program Files\LANDesk\ManagementSuite\log” folder you’ll find a couple of files to check:
   1. raxfer.log: log info for the remote-copy and remote-execute actions taking during the agent deployment.
   2. ScheduledTaskHandler_XXX.log:  The XXX is the number the corresponds to the task ID.  This contains log information for the task handler that deploys the agent.
   3. SchedSvc.log: Log info for the scheduler service.
3. On the targeted client computer, monitor the root of the C drive (i.e. the C$ share) and look for a new directory created called $ldcfg$.  If this doesn’t get created it is likely that “Simple File Sharing” hasn’t been disabled on a Windows XP client or that the username and password in the service config utility on the core isn’t correct for this client. (As a test you can try mapping a drive from the core server to \\clienthostname\c$ to see if it works using the username and password entered in service config for the client.  If this fails, agent configuration will fail.)  After being created the $ldcfg$ folder should have a few files in it such as IPCheck.exe, tmpXXX.tmp (where XXX is a random set of characters), LandeskClientInstallStatus.txt.  When the install has completed this folder should be deleted automatically.
4. Watch the Windows Task Manager and look for the following process that should run during the client deployment: 
   1. tmpxxx.tmp: Yes, this is an executable even though it has a .tmp extension.  If this fails to run, the service manager may be having trouble starting a service remotely from the core server.
   2. IPCheck.exe: Runs very quickly, it is likely you won’t see it run.
   3. wscfg32.exe: This is the main installer.  It takes a while to run.
5. Ping the core from the client and make sure you get a response. If you don’t:
   1. Win2k 8– Go to firewall advanced settings and make sure network discovery is turned on.
   2. Win2k3 – Go to firewall settings, turn on the fire wall and check the following exceptions:
      • File and Printer Sharing
      • Remote Desktop
      • UPnP Framework
   3. Ping from the client and get a response from the server.

For Additional Troubleshooting see:

Agent Deployment Results in error: "Unable to contact the specified machine"
http://community.landesk.com/support/docs/DOC-2112

Documentation for Agent Configuration and Deployment for LANDesk 9 release
http://community.landesk.com/support/docs/DOC-7474

Problems/Symptoms:

How to upgrade LANDesk Agents

How to patch LANDesk Agents with Service Packs

Fix:

-Upgrade

Perform a full Agent Push to upgrade an existing Agent to the latest Core version. This can be accomplished by right-clicking on the Agent Configuration name from the Console and selecting 'Schedule'

-Patch

To apply a patch or Service Pack to an Agent, either perform the full Agent install as described above, or install the patch.

To apply a service pack or patch to clients, follow these steps:

1. Update the Core to the latest Service Pack (if deploying a Service Pack).
2. Download updates in Security and Patch Manager to update content.
   1. Click on Download Updates.
   2. Make sure the LANDESK Updates check box is selected.
   3. Click the Update Now button.
   4. Wait for this to finish.
3. Click on the All Items Folder.
   1. Locate the Service pack or patch that you want to upgrade.
   2. Right Click on the Definition and Choose Download now.
   3. Click on all selected Items.
   4. Right click on the "Client" patch and choose download.
   5. Let this Finish.
4. Make sure that the Definition is in the Scan folder.
   1. If the definition has a X or a ? on it it is not in the scan folder and you will need to move it to the Scan folder.
5. Run a Security Scan against client machines.
   1. Click on Create a Task.
   2. Choose Security Scan.
   3. Check the Box that says Scheduled Task.
   4. Click ok.
   5. Drag all the computers into the Scheduled task that was created.
   6. Start the Scheduled Task.
6. Wait for all the computers to Scan.
7. Repair the Service Pack using Patch Manager.
   1. Right click on the Definitions Choose Repair.
   2. Check box that says Scheduled Task.
   3. Click OK.
   4. Drag all the computers into the Scheduled Task.
   5. Start the Scheduled Task.

Alternately, you can apply the Agent Service Pack or patch manually.

• Note: Do not use the Schedule Update feature to upgrade or patch an Agent. Schedule Update only updates settings on an existing Agent. Updating the agent settings performs the following actions:

1) Uninstalls the LANDesk Remote Control Service, LANDesk Targeted Multicast, and LANDesk(R) Software Monitoring Service services.

2) Runs the agent configuration MSI for the specific agent configuration (this is not the full agent install).

3) Reinstalls the LANDesk Remote Control Service, LANDesk Targeted Multicast, and LANDesk(R) Software Monitoring Service services.

4) Runs an inventory scan to ensure changes are reported to the core server.

Description: This article describes the steps involved in completely removing a remote console, agent, and other settings from a remote device. The article will include standard methods for removal but it will also include steps to thoroughly check and manually remove services, files, drivers, etc that may be left behind when an application becomes corrupted. These steps may be necessary when experiencing difficulties installing an agent or remote console.

Step 1: Use the pre-designed removal applications.

• Remote Consoles: Use Add/Remove Programs in Windows.
• Remote Control Viewer: Use Add/Remove Programs in Windows.
• Agent: The following applications will attempt to automatically remove the agent: Uninstallwinclient.exe, Uninstallmacagent.sh, and Linuxuninstall.tar.gz. (Uninstallwinclient.exe will have a switch /forceclean that will more thoroughly remove information) (Note: All of these applications will be located in the C:\Program Files\LANDesk\ManagementSuite folder on the core server)

Step 2: Manually Stop and Remove Services (if necessary)

• Open services.msc from the RUN line in Windows and search for any services that start with "LANDesk". If they are found attempt to stop them and manually delete the corresponding registry key from HKLM\System\CurrentControlSet\Services. (Searching this key for LANDesk is usually a good method)

Step 3: Delete files that may be left over.

• C:\Program Files\LANDesk
• C:\Documents and Settings\All Users\Application Data (hidden folder by default)
• The documents and settings path will vary on newer versions of Windows.

Step 4: Delete registry keys that may be left over

• HKLM\Software\Intel\LANDesk
• HKLM\Software\LANDesk
• HKLM\Software\Wow6432Node (same subkeys as noted before...this is for 64-bit OS's)

Step 5: Check for the Remote Control Mirror Driver

• A mirror driver for remote control usually installs with the agent and should be listed in Device Manager under Display Adapters. This can be removed manually or with setupmirror.exe or setupmirror64.exe located in the LDLogon folder on the core.

Additional Notes: At this time it may be a good idea to remove/reinstall pre-requisites for the Remote Console as well.

Description

Communication between the core and the agent is vital to many portions of LANDesk. Knowing that the core can connect to the client, on the right port, and receive a good response can make troubleshooting a lot easier. The LANDesk agent in many ways can be used as a basic web browser and can help with resolving problems with:

Remote Control failing to connect

Software Distribution

Invoking a Security and Inventory Scan from the Console

Agent Status (Icons in the console) failing to display

and much more...

1. Connect to the web server and see a LANDesk Management Agent title bar in a web page.
HTTP://Computername:9595

2. Perform an CBAPing and get the Computername, Operating System, and Inventory ID as a response.This is a good test to make sure DNS is working as well and the machine in question is really the machine you are attempting to connect with.
HTTP://Computername:9595/allowed/ldping

3. Connect to the Remote Control Service. (Note: The service doesn't have a web page so the following screenshot is a normal response)

HTTP://Computername:9535

4. To view running providers: (Note: A much longer list will be displayed if Real-time Inventory and Monitoring is enabled on the client. Without the longer list Alerting/Monitoring will not function properly)
HTTP://Computername:9595/LDClient/ldprov.cgi/index

Inventory and Security Scans Invoked Through a Right-click in the 32-bit Console (Process):

Process and log entries are located below. The following document has more detailed information on how to test/fix this functionality: DOC-5480

1. The 32-bit console makes a call to a webservice called corerequest.asmx: (Note: The 200 code in the line below indicates a success)

     Example IIS log entry:

     2011-11-03 18:48:40 POST /landesk/managementsuite/core/core.secure/corerequest.asmx - 80 SNOOPY\ADMINISTRATOR fe80::94c8:7e37:5edc:768d%11 Mozilla/4.0+(compatible;+MSIE+6.0;+MS+Web+Services+Client+Protocol+2.0.50727.4927) 200 0 0 5060

2. The webservice contacts the LANDesk Management Agent Service on the client. (C:\Program Files\LANDesk\Shared Files\residentagent.log) The Management Agent Service then launches Servicehost.exe:

     Example log entries:

          Thu, 03 Nov 2011 10:08:13 1772: Entering ServiceHostThreadProc, thread id 3012
          Thu, 03 Nov 2011 10:08:13 1772: Handling request from 192.168.47.210
          Thu, 03 Nov 2011 10:08:13 1772: Service host (process) 292 handlings request from socket 540
          Thu, 03 Nov 2011 10:08:13 1772: Socket error 0 was classified as non recoverable
          Thu, 03 Nov 2011 10:08:13 1772: Socket 540 closed gracefully
          Thu, 03 Nov 2011 10:08:13 1772: Socket closed, client has disconnected
          Thu, 03 Nov 2011 10:08:13 1772: Request handling complete
          Thu, 03 Nov 2011 10:08:13 1772: Exiting ServiceHostThreadProc

3. Servicehost.exe launches the application in question. (C:\Program Files\LANDesk\Shared Files\Servicehost.log) (Note: Servicehost.exe uses vulscan.exe to launch an inventory scan)

     Example log entry:

          Thu, 03 Nov 2011 10:08:13 292: Service Host Started, Host jtrafele-xpsp3.localdomain:9594, Peer 192.168.47.210, IP Address 192.168.47.147
          Thu, 03 Nov 2011 10:08:13 292: Public key path C:\Program Files\LANDesk\Shared Files\cbaroot\certs
          Thu, 03 Nov 2011 10:08:13 292: X509 Authentication via d301c06e
          Thu, 03 Nov 2011 10:08:13 292: Request Received "POST /services/exec HTTP/1.1"
          Thu, 03 Nov 2011 10:08:13 292: Exec: Exec: Launch request <"C:\Program Files\LANDesk\LDClient\vulscan.exe" /id=9 /run ldiscn32.exe /NTT=SNOOPY:5007 /S="SNOOPY" /I=HTTP://SNOOPY/LDLogon/ldappl3.ldz /NOUI -f> (sync 0, timeout 300)
          Thu, 03 Nov 2011 10:08:13 292: EOF encountered parsing HTTP headers, client closed connection.
          Thu, 03 Nov 2011 10:08:13 292: Service host has finished

Configured dynamic Preferred Servers will not work with AdvanceAgent  because the "scaled down" version of the downloader contained in  AdvanceAgent does not have full functionality for Preferred Server built in. This was done to keep the AdvanceAgent as small as possible for  deploying via group policy. This means that AdvanceAgent is not able to  get a dynamic list of preferred servers from the Core Server or able to use Preferred Server for authentication to locked down shares.

Even though dynamic discovery and authentication are not  supported by AdvanceAgent, the legacy Preferred Server method can still be used. You can enable the use of preferred server(s) by simply creating a registry key on the workstation before installing the agent.

Please note that LDMS 9.0 SP2 and later agent needs Microsoft Visual C++ 2005 to be installed on the Windows XP client prior to advance agent installation. Without MS Visual C++ advance agent service will crash. Windows 7 clients come with MS Visual C++ already included.

Important note: by default advance agent will use HTTP path to download the .EXE file. If your preferred server is not configure with IIS, you must change the path for the .EXE file to UNC path! Failing to do so will result the .EXE being downloaded from the core server instead.

Add the following key to the workstation before running your  AdvanceAgent.msi

[HKEY_LOCAL_MACHINE\SOFTWARE\LANDesk\ManagementSuite\WinClient\SoftwareDistribution]
"PreferredPackageServer"="THLANDESK;THLANDESK90"

Multiple servers are separated by a semicolon (as shown  above). Up to 3 Preferred Servers may be used.

Another way to accomplish this task is to edit the  AdvanceAgent.msi with Orca and add the registry key. This method will  allow installing the msi as you normally would without having to perform  additional steps.

1. Download and install Orca.msi (Google knows where this is)
2. Edit the AdvanceAgent.msi of the desired agent configuration with Orca
3. Scroll down to Registry then right click and select "Add Row"
4. Fill out all required fields (key value can be random numbers, then fill the other fields using the values from the registry key at the top of this article)
   
5. Set 'UsePreferedServer' to #1.
6. Save the .msi
7. Deploy the .msi normally (manually, GPO, scheduled task, etc)

Notice in the following xtrace of LDDwnld, that the original path in the AdvanceAgent setup http://landesk.com/ldlogon/AdvanceAgent/THLANDESK90 No Extras.exe has been escaped to http://THLANDESK/ldlogon/AdvanceAgent/THLANDESK90 No Extras.exe (THLANDESK being 1 of 2 preferred servers added with the registry key above.

LDDwnld.xlg (xtrace log) This log will verify that the download is coming from the Preferred Server(s) vs. the core.

04/15/2010 08:28:33.391    1016    440    lddwnld.cpp    2246    Calculating levels in 'http://THLANDESK/ldlogon/AdvanceAgent/THLANDESK90 No Extras.exe'
04/15/2010 08:28:33.407    1016    440    lddwnld.cpp    2265    UNC/URL prefix removed, calculating for 'THLANDESK/ldlogon/AdvanceAgent/THLANDESK90 No Extras.exe'
04/15/2010 08:28:33.407    1016    440    lddwnld.cpp    2279    current levels 1, remaining path '/ldlogon/AdvanceAgent/THLANDESK90 No Extras.exe'
04/15/2010 08:28:33.407    1016    440    lddwnld.cpp    2279    current levels 2, remaining path '/AdvanceAgent/THLANDESK90 No Extras.exe'
04/15/2010 08:28:33.407    1016    440    lddwnld.cpp    2279    current levels 3, remaining path '/THLANDESK90 No Extras.exe'
04/15/2010 08:28:33.423    1016    440    lddwnld.cpp    2281    Calculated 3 levels for path 'http://THLANDESK/ldlogon/AdvanceAgent/THLANDESK90 No Extras.exe'
04/15/2010 08:28:33.423    1016    440    lddownload.cpp    1322    AddFileToDownloadSet: called with sourcePath http://THLANDESK/ldlogon/AdvanceAgent/THLANDESK90 No Extras.exe, hash
04/15/2010 08:28:33.423    1016    440    lddwnld.cpp    2092    GetFileInformation - same path last=http://THLANDESK/ldlogon/AdvanceAgent/THLANDESK90 No Extras.exe current=http://THLANDESK/ldlogon/AdvanceAgent/THLANDESK90 No Extras.exe

Since the agent file hash is contained in the MSI, the original path in the AdvanceAgent setup does not need to be accessible. In normal LANDesk Software distribution jobs, the original source patch is contacted to verify the files on preferred servers are authentic.

Note: This registry key should be removed after full agent install to fully utilize dynamic Preferred Server capabilities.

To enable verbose logging for agent push jobs, create the following registry setting on the Core Server:

Using regedit, navigate to  HKEY_LOCAL_MACHINE\SOFTWARE\LANDesk.
Create a new DWORD Value named AgentPushVerboseLog and set the value to 1.

Example:

[HKEY_LOCAL_MACHINE\SOFTWARE\LANDesk]
"AgentPushVerboseLog"=dword:00000001

Also make sure the \LANDesk\ManagementSuite\ScheduledTaskHandler.ini contains the following (if the file does not exist, create it):

[logging]
verbose=true

The verbose logging will be added to the \LANDesk\ManagementSuite\log\ScheduledTaskHandler_(ID).log

NOTE -- On a 64 bit OS, you need to create the registry key here instead: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node