Troubleshooting Client Reboot Issues
The purpose of this document is to answer some of the most common questions that are asked in terms of clients being rebooted. LANDesk offers several different methods for rebooting a computer. A reboot might be caused by a software distribution package or,by selecting the option to reboot in a scan and repair setting or delivery method etc. Since there are so many possible scenarios that could result in a reboot, finding the exact cause of a client reboot will require a review of some of the log files on the machine. This document will provide steps necessary to locate the cause of the reboot.
Stopping a Task
Question: Computers are being rebooted! Is there anyway to stop all jobs from running until I am able to determine the cause of the reboot?
Answer: If it is a scheduled task that is causing the reboot then stopping the LANDesk Scheduler Service will prevent the core server from sending the task out to any additional clients. However, if the client has already received the task and is processing it, it will not prevent the client from running the task. Stopping the Scheduler Service will only prevent the task from being distributed to any machines that have not already received the task.
Stopping a Policy
If it is a policy that is causing the machines to reboot then stopping the LANDesk Policy Server would prevent any further machines from checking back to the core server for a updated list of policies that need to be ran.
Useful Items When Troubleshooting Reboot Issues
What time did the client reboot? The application and system event logs will tell you the exact time the system was rebooted.
- Are there any error messages in the event logs prior to the machine being rebooted?
- A list of possible jobs that may have been scheduled on the machine that was rebooted.
- Sdclient and vulscan logs from the client that was rebooted.
- Are there any other applications on the client other than LANDesk that may have caused the reboot?
Reboots Caused by a Vulnerability Scan
This section of the document will focus on reboots that were caused by a job that was created in the Patch Manager (LDMS 88 and below) or the Patch and Compliance section (LDMS 9). The most common cause for a reboot when dealing with a vulnerability scan/repair is that a task was scheduled using a scan and repair setting that had either the Reboot only if needed or the Always reboot option selected. The steps below demonstrate how to verify which scan and repair setting was used during the scan.
Determining What Scan and Repair setting were Used During a Scan
The vulscan logs on the machine will display what scan and repair setting was used during vulnerability scan. The vulscan log files can be located in
- C:\documents and settings\All Users\Application Data\Vulscan. (Windows XP)
- C:\Program Data\Vulscan (Windows 7)
The vulscan log file will show what scan and repair settings was used during the last scan. Sort the vulscan logs by date and try and locate a vulscan log that took place right before the time that the client was rebooted. The vulscan log will show what command was actually passed to the client machine to run. In the following example the command that vulscan exacuted is "vulscan.exe /agentbehavior=JN-LD-CORE9_21". This means that a vulnerability scan was ran using a scan and repair setting named JN-LD-CORE9_21.
Clicking on the configure settings button in the Patch and Compliance window and selecting the scan and repair settingsoption will display a list of all of the different scan and repair settings that are available on the the core server. locate the ID of the scan and repair setting that was used during the scan and double click on it to bring up the properties window.
Reboot Options.
Select Reboot Options from the menu on the left hand side of the screen to view the reboot options for the scan and repair setting. If Reboot only if needed or Always reboot was selected under the reboot options of the scan and repair setting then the client machine would be rebooted after the scan was completed.
Reboot Task
Reboot task can be scheduled from the Patch and Compliance section of the console. If the client was rebooted because it was inadvertently added to one of these reboot task then the vulscan.log would show that the /rebootifneeded command was ran.
Reboots Caused by a Software Distribution Job
This section of the document will focus on reboots that were caused by a software distribution task. The most common reason for a client being rebooted after a software distribution task is that the task was ran using a deployment method that was configured to reboot a machine. The steps below will show how to find out what deployment method was used in the software deployment task.
Determining What Deployment Method Was Used In a Software Distribution Task
The sdclient log files will show what software was installed on the client machine during a software distribution task.
The sdclient logs are located in C:\Program Files\LANDesk\LDClient\Data directory. There will be a sdclient.log file as well as a sdclient_task#.log file. Sort the sdclient logs by date and try and locate a sdclient_task#.log file that was created around the time that the client was rebooted.
In the example below the last job that was ran on the client machine created a sdclient_task4.log file.
In this example we can see that the client ran http://JN-LD-Core9/ldlogon/apps/7z465.exe. The contents of this log file will show what command was executed on the client as well as the results of that command.
The task ID number that is used in the name of the sdclient_task#.log file can be used to view the properties of the task in able to determine what delivery method was used in the software distribution task.
In this example sdclient_task4.log was created. If the task still exist in the console you can view the properties of the task to determine what delivery method was used. there is a column in the scheduled task window that will show the Task ID. Once the task has been located double click on the task to view the task properties.
Right clicking on the task and selecting Properties | Delivery Method will display the name of the delivery method that was used for the scheduled task.
Locate the delivery method in the console by selecting Tools | Distribution | Delivery Methods.
Double click on the delivery method that was used during the software distribution task to view it's properties. Click on the Reboot option on the menu to view the clients reboot options.
Setting the delivery method to Reboot onlyif needed or Always reboot will result in the client being rebooted.
* Note: If the task has already been deleted from the console there is no way to determine what delivery method was used for the software distribution task.
The Sdclient.log file will also show any reboot commands that were passed to the client as a result of the last job and can be helpful in determining if the reboot was caused by a LANDesk task.
Wake On LAN Task
If the WOL option is selected in the scheduled task then core server will attempt to power on the client and run the scheduled task. Once the task is completed the client will attempt to turn the computer off again. To determine if this option was selected right click the task and select Properties | Targeted devices to view the properties of the scheduled task. Click on the Targeted devices option and verify if the Wake up devicesoption was selected.
LANDesk has seen issues where a client was powered on during a scheduled task. If it is a large package or a task with several clients associated with the task, then there may be a lengthy delay between the time the client is actually powered up and the time it receives the task and powers back down.
On Demand Reboot
It is possible to reboot a client from the LANDesk console by right clicking on a device and selecting the reboot option. If a client was rebooted using this method the then the servicehost.log file will show that poweroff.exe was executed on the client machine. The servicehost.log file will be located on the client in C:\Program Files\LANDesk\SharedFiles.
A poweroff.exe.log file will also be created under C:\Windows\System32