I wrote this some time ago, but it is still relavent
A few ago when we went from not patching anything to now patching over 10K systems fully within a week every month we began first by creating a Custom Group, named it "Baseline Patches" and add all MSxx-xxx patches that have not been superceded. We began patching that group in the method described in the article found in the link above.
After a couple months of doing that we added some of the Non- MS patches, which today are the most vulnerable, such as Flash Player, Java, Firefox, etc.
As our comfort grew and our systems came up to date we added even more patches to the baseline group.
Today we pretty much patch almost everything LANDesk has content for that is repairable.
BTW, on Auto-fix, it is a great tool, but a 'feature' of it is, it will only try to fix a patch once on a computer, if it fails, it will not try to Auto-fix again. A way to reset that is to go to your group of patches, select all that are set to Auto-fix (do a find for "yes" on Autofix) and right click on them after selecting all, click "clear scan/repair status, leave as default and click OK.
I'd like to know if you had any problems with computers or servers rebooting?
We used the WSUS server and always had computers rebooting and servers. I spoke to a Microsoft Tech and was told even with Group Policy set to not reboot they would still reboot.
I notice alot of the patches say reboot if necessary. All my scan settings in my agents say No Reboot . Does this really keep things from rebooting?
We have not started patching yet but I will soon.
We have not had any troubles with this, there are couple ways to control reboots in LANDesk, the Scan & Repair Setting and the ability to set the agent to never reboot.
In the scan and repair setting that you choose when you create your repair task, make sure the reboot option is the way you want it. We have several groups within our company and most have settings for "normal" systems, and other settings for Servers and or special use systems. For our "normal" systems we usually use the "reboot if needed" option and allow from 24 - 48 hours for the user to reboot.
Our server settings vary by group, but most use a "never reboot" in the scan & repair settings and they go and manually reboot the servers when the task is done.
In your Agent Configuration you can set the Agent to "Never Reboot", I usually do not recommend this except for your critical systems. It removes the ability to reboot the systems if you wanted to.
We control the reboot exclusively through the "Scan and Repair" settings..........have never had a machine reboot due to a patch being applied. As James said - I would not set the Agent itself to never reboot as this is a global setting. Just tell the agent to use a scan and Repair Setting that is set to Never Reboot. You can also control bandwidth throttling in there as well (if that is a concern).
Sorry to bring up a different subject but you wrote a script policy-cleanup.bat and in it is the line del c:\program files\...........\sdmcache\landesk\files\*.xml. This line has been carried forth on other scripts I've seen including one in my landesk console. This path is not there, was this a carryover from older version of Landesk?
We use Autofix and it works great. We have a "non autofix" agent for a handful of PC's that we want to control if and when they get patched, but all the rest get autofixed.
When new patches come out, I roll them out to selected test users to verify that there are no problems, once that process is complete, I just set them to autofix.
If a patch fails, I do have to follow up and clear the status, etc, but the vast majority of patches have no issues.
I had a situation with creating my baseline repair group folder and setting it to repair. It repaired fine on my pilot group, and for all users in my extended pilot group except for two users. Two users had a situation where they were prompted by LANDesk that a reboot was about to occur and there was no cancelling it. This reboot happened consistently to the user throughout the day. My team had to use the uninstal utility to remove LANDesk from their PCs since I was on vacation and could not stop the scheduled repair task from occuring. I had set the baseline folder to repair every 4 hours using a Scan and Repair setting that was specifically designed to not reboot upon installation of patches.
Reading the above posts, it looks like this should not be possible since the reboot options are set in the Scan and Repair settings. I was wondering if anyone else who used your method to reach a baseline reported similar issues with random users having a reboot occur suddenly. Any insight will be extremly valuable.
There are (at least) two places you need to check in regards to reboots, the Scan and Repair Setting (S&R Setting) used for specific tasks, and the setting selected in the agent configuration under the scan and repair section.
If the S&R Setting is set to Never Reboot for the task you have chosen, that task when run should not reboot. Now there is always a chance that one of the patches has bug that causes the reboot, but I have not seen one of those in the past 4 years.
When the patches are run, if a reboot is needed, it will write a value to the registry. This is not specific to LANDesk, it is common practice. If you have your reboot set to "If needed" LANDesk will look at this registry location and call a reboot.
The reason I mention that is, if the default setting you have in your agent uses a "reboot if needed", when it runs its daily scan, if a reboot is pending, for whatever reason, even if a user installed some software that wrote to this pending reboot registry location, a reboot will occur.
Now, one thing that I am confused about is this, you state you have the repair task set to run every 4 hours. Where did you set this? I do not know where you can set a 4 hour repeat.... You can choose once and hour, once a day, once a week.
I will have to take a look at what Scan and Repair settings are in the configuration deployed to those users. I will not count out the possibility that the problem lies there.
I gave you misinformation. I use 4 hours as a baseline for scheduled tasks when setting them for different servers. I had my repair task set to run every hour.
I have one more question for you. We have a lot of remote users who are randomly connected to our VPN and are able to communicate with the LANDesk server. In this case, those users are the users who come up as failed in the repair task. I don't mind this because I know at some point they will be connected to the VPN long enough to receive the updates. What method did you use to remove the successful devices from the repair task? I have just been going into the repair task and selecting the successful users and remove them from the task until all users have reported successful. Is there a way to remove users from the scheduled repair task as soon as they reach a successful status?
MrGadget and others,
I have re-done my "Clear Client DB" script that cleans up corrupted client side database files, this is usually evident when a users Software Portal does not update properly to reflect new additons or removals. Also, when software dist. jobs get stuck in a delayed state.
I created a new "Document" here on the forums, it is pending approval, the link will be http://community.landesk.com/support/docs/DOC-26360
If that is not working yet, this is what I wrote in it.... Also, I found while I was calling a path called ...sdmcache\landesk\files\*.xml as Mrgadget asked about earlier in this thread, but I had called the wrong path, I wanted to call:
%ALLUSERSPROFILE%\LANDesk\ManagementSuite\landesk\files\*.* /s /q (or slightly different for XP)
The clients LANDesk Database has been known to get corrupted from time to time.
Symptoms of a corrupt database included Software Portals (Desktop Manager) that would not update to reflect new policies or removed policies, software tasks stuck in delayed or quesed
A couple years ago I wrote a bach file that would:
Stop the policy service
Delete the clientside database file
Delete various .xml and other files that would regenerate at the next policy sync
Create new client side databases and 'validate' them
Start the policy service and force a policy sync
Many of you have used that script and we use here at my work location often, but it needed some work. The original version was for Windows XP only, I later made a seperate one for Win x64 and I found a couple pathing issues that did not do any harm, just failed to delete some files.
Today I have created a new version of the script that will work on Win XP, Win 7x86 and Win 7x64.
To use this, save the attached file, change the .txt to .cmd and put it on a share or in your patch folder.
Use can then use Software Dist. to push it out silently as needed.
BTW, There is a similar tool that some LANDesk Employee's have called "DeleteTaskQueue" that I had been given a copy of from a prior employee and I have seen "LANDeskWizrd" mention it in a post, but I do not know if it is widely available nor do I know exactly what it does as it involves and .exe file. If you search for "DeleteTaskQueue" you will find the post.