Applies to LANDesk Management Suite 8.8
Applies to LANDesk Management Suite 9.0
When adding new machines discovered with UDD to an agent deployment task, the machines may fail to complete the agent install.
When pushing an agent that was discovered with UDD, precautions are taken to verify the task is targeting the correct machine. If there are any DNS problems in the environment, the agent push may fail.
The resulting \LANDesk\ManagementSuite\Log\ScheduledTaskHandler_xx.log on the core will look like this:
Tue, 01 Jun 2010 07:40:33 THLAB04 Sending C:\Documents and Settings\Svcldmsadmin\Local Settings\Temp\tmp9BDE.tmp to C:\$ldcfg$\tmp9BDE.tmp
Tue, 01 Jun 2010 07:40:33 THLAB04 creating dir C:\$ldcfg$
Tue, 01 Jun 2010 07:40:41 THLAB04 Copying to C:\$ldcfg$\IPCheck.exe
Tue, 01 Jun 2010 07:40:42 Remote execute of application 'C:\$ldcfg$\IPCheck.exe', params 'THLAB04' on THLAB04 (3814200a)
Tue, 01 Jun 2010 07:40:43 THLAB04, CBA discovery & IPCheck failed
Tue, 01 Jun 2010 07:40:43 THLAB04 Removing temporary directory
Tue, 01 Jun 2010 07:40:43 Remote execute of application 'cmd', params '/c rmdir /s /q C:\$ldcfg$' on THLAB04 (3814200a)
Tue, 01 Jun 2010 07:40:45 THLAB04 DONE: retCode=-1 machineRetCode=1081
The log shows that the target machine was contacted, C:\$ldcfg$ was created, and IPCheck.exe was copied and executed. IPCheck.exe calls the Winsock GetHostName function and compares that information with the same information on the core servercore server. If the NETBIOS name does NOT match exactly, IPCheck.exe will return a failure and the agent install process will abort.
A quick way to test this scenario is to use NSLOOKUP <TargetMachineName> from both the core server and the target machine to see if the entries match. If they do not, DNS corrections will need to made before an agent push can be successful.
A current workaround is to push an AdvanceAgent instead of a regualar agent push since AdvanceAgent does not use IPCheck.exe (this may change).
If the NSLOOKUP comparison returns a match, but the job is still failing, Use IPCheck.exe with verbose output to see if name or IP is failing.
IPCHeck.exe does not output to stdout, so the output must be piped to MORE (as seen below)
\\thlandesk90\ldlogon\IPCheck.exe |more (Help info)
\\thlandesk90\ldlogon\IPCheck.exe <hostname> <ip address>
\\thlandesk90\ldlogon\IPCheck.exe <hostname> <ip address> -v |more (Verbose output)
Return value 1 is success, 0 is failure
Important Note: While the help says that 1 is success and 0 is failure, it is not. 0 is success and 1 is failure. The help text was corrected after SP1 shipped.
The -v or /v parameter will provide more verbose output. Note that it is only available when testing both the hostname and ip address as shown here. It is not available when testing just the host name. Order is again important as in the previous case. The -v or /v parameter is expected to be last on the command-line parameter list. It is required to pipe the output through the “more” command as shown so that the output from the verbose mode will be visible to the user.
Watch the root drive of the target machine and see if c:\$ldcfg$ gets created. It will get created and then deleted in a matter of seconds, so watch it closely (or use filemon or procmon from Sysinternals.com).
If the folder never gets created, make sure the user the Scheduler Service on the Core Server has rights to the target machines C$ and Admin$
For further troubleshooting of IPCheck, try the following:
- On the client computer run Process Monitorr (procmon.exe) from SysInternals and watch for the ipcheck.exe process. When run, note the command-line parameters passed to it.
- Once the command-line parameters are obtained, run ipcheck.exe manually on the client. Because it can be challenging to get the exit code of an application from within a windows console (i.e. cmd.exe), use a batch file such as the following which will show the verbose output and will print the exit code from ipcheck.exe:
- ipcheck HostName IpAddress -v | more
- echo %errorlevel%