We're migrating from 8.8 to a brand new 9.0 SP2 core and database. Having read the "Best Known Methods for Agent Config & Deployment" (http://community.landesk.com/support/docs/DOC-7474), we discovered the agent, unlike previous versions, requires a reboot. LANDesk Support confirmed this is because of the new v8 AV engine. I have checked the state of a deployed agent and all is fine except the AV service (and system tray icon) are no running until after a reboot. It doesn't matter whether it was a full client push, Advance Agent or GPO deployment; the machine still needs to be rebooted to start the AV service. This poses the obvious deployment headache surrounding how we reboot users machines. We could:-
1) Select "do not reboot devices after configuration" but it is not uncommon for many users not to reboot their machines for days or weeks or even longer.
2) Select "reboot devices if necessary" but this forcibly reboots the machine without any warning and will cause users to loss unsaved work, which is not an option.
3) Select "reboot with user option to cancel" but the message is ambiguous so users will be inclined to select cancel; they will likely cancel even if they understand the consequences. The options to delay or reboot (without cancel) would have been better here.
4) Deploy the Advance Agent MSI as a computer GPO during the startup scripts which installs the agent then reboots the machine before the user can logon. Despite having to rely on users rebooting their machines, this may be the best option we can think of but we need to test it works in our environment where all users do not have admin rights.
Would others agree? Is there a better deployment option we have overlooked that would install the agent & reboot with minimal of disruption please?
Thanks in advance
Apologies for resurrecting an old thread.
We need to migrate 8.8SP3 agents to 9.0SP3 then prompt users to reboot with delay options to prevent data loss. We are struggling to automate this. The closest we have come to automating this is to:-
1. Deploy the Advance Agent with no reboot
2. Query on machines where the LANDesk Antivirus service is "stopped"
3. Deploy a 'push' task to those machines that prompts the user to reboot with delay options (this cannot be done during an Advance Agent deployment). We have tried to automate this by targeting the query and setting the task to schedule "every hour" but this causes the reboot prompt on *all* machines which is no good because we don't want to disturb users who have already rebooted.
Is there a way to fully automate the Advance Agent install and 'safe' reboot (with delay options) of all machines please?
Every hour is a bit tricky. What you need to make sure of is, that after the reboot the device sends an inventory scan, so it is registered that the service is started. You can do this, if this is not common in your environment, by pushing out a Custom Script and after the reboot command let the script sleep a bit and use remping to wait for the system to come back up and than execute the inventory scan. Also tricky with a1 hour schedule isnthe fact that queries in tasks are re-evaluated only 1 per hour by default. Maybe schedule the above script on 3 different times per day? Morning, lunch, later afternoon? Frank Axle-IT
Frank, thanks for your reply.
So we need to create a Custom Script that handles the reboot, remping & Inventory Scan? If so, this sounds good but we cannot see any Delivery Methods for Custom Scripts. We must give users the option to delay the reboot twice for 24 hours to prevent avoidable interruption and data loss.
So how do we control the reboot delay options with a Custom Script so that users are prompted to delay or reboot please?
Scott, no, sorry, no delivery method for custom scripts... A counter to shutdown with the option to do it immediately? Might be a reasonable alternative, no? Frank -Axle-IT
Sorry Frank, we categorically cannot forcibly shutdown machines without giving users the chance to save their work. We need a solution that prompts users on-screen. Having never used it I cannot be sure but can Provisioning do this please? If so, any help would be appreciated.
Originally, we created an MSI Distribution Package of the Agent and created the Scheduled Task linked to a Delivery Method that provides reboot delay options. It worked perfect in testing but we were advised not to deploy the MSI (or EXE) because it passes control to SDCLIENT.EXE which will itself be un/reinstalled as part of the process so could lead to undesired results on some machines.
Has anyone else experienced a problem deploying the Agent as an MSI or EXE please?
Using any of LANDesk's deployment methods to reinstall the LANDesk agent (unless using an Advance Agent) are problematic because you cannot avoid the need to replace files that are in use.
Rather than using a Push that repeats hourly, have you considered using a Policy that is required once? Target the policy at your query that detects the stopped service. Any machine that reports the service as stopped will fall into the policy and run the task when it next performs a policy sync.
Even if it takes some time for the inventory to update and reflect that the service is now running, it won't repeatedly reboot the machines as the policy states they should only run it once. Using a policy rather than a push means you don't schedule the task to repeat hourly - you simply run one and leave it to work.
Appreciate your response Richard
Just to claify...
I understand we should deploy an Advance Agent to avoid the need to replace files that are in use. But there are no Delivery Method options for an Advance Agent (only "Overview", Target Devices" & "Schedule Task"). So I assume you are referring to the separate reboot task? If so, we found that setting this task as a Policy and targeting the query is only good for adding machines automatically but the task does not start without manually selecting "Start Now" (unless of course we set it to repeat every hour or day but this applies to all machines, frustratingly). Policy Sync runs once a day but this further delay is not ideal because AV is stopped so we would be better manually selecting "Start Now" as soon as new machines are detected as 'vulnerable'. Not ideal bevause it's not an automated solution.
Have I misunderstood anything or is it impossible to automate an Advance Agent with immediate reboot delay options please?
Short answer: no, Advance Agent deployment can't handle reboots in a graceful way.
Long answer: Will be in my next post...
And sorry I wasn't clear in my last post - I was indeed referring to the reboot task.
Right, long answer time...
I'm going to do my best not to get into a rant about agent deployment, but generally it's just a pain. I've never been happy with they way they're handled and the options that are available to us.
You cannot select a delivery method for an Advance Agent task as it doesn't actually use any of the LANDesk agent capabilities. As far as I know, it basically makes standard RPC calls to the client to copy over the MSI and run it. It has to work this way by design, as you can deploy Advance Agents to machines with no LANDesk agent at all.
You can pretend to work around this by creating a Software Distribution package to install the Advance Agent MSI (SWD tasks have delivery methods) but that actually doesn't work because of the mechanics of the Advance Agent.
Advance Agent installation completes the moment the AA service is installed and running. That is not when the agent itself has installed. In fact, at that point, it hasn't even downloaded the real agent installation files to the client. That means there's no easy way to track and trace when installation completes. That also means that it can't manage the reboot; if you do enable reboot prompting in your agent configuration, it's handled by the basic UI provided by the standard installer which, as you've already highlighted, doesn't cut the mustard.
I'd like to see LANDesk implement some kind of status report in the Advance Agent service, perhaps submitting miniscan-style status updates to the inventory so you can run queries and reports based on Advance Agent status. It would also be good to have the Advance Agent service handle graceful rebooting. Perhaps that would make a good Enhancement Request.
Back to working around your problem at hand...
I'll admit we're not in quite the same situation as you so I'm making some creative supposition here; we don't use LD Antivirus. In fact, the problem you're having (or rather the root cause, which is that it's inextricably linked to the LD agent) is one of the many, many reasons it failed our evaluation, but that's neither here nor there. For us, the only thing that doesn't work between an agent replacement and a reboot is Remote Control, so it's not critical for that reboot to be handled promptly.
Using a query-targeted policy to initiate a reboot should work (I've done it before), but it sounds like it's being hindered by the fact you only schedule a policy check once a day. Can't really get around that without increasing the frequency. We have our agents checking every few hours. Policy checks are pretty low-bandwidth affairs, although I don't know how many machines you have in your environment, or what your network infrastructure is like, so I can't recommend one way or the other.
Another option might be, if you use Agent Watcher, you could configure it to monitor the Antivirus service. You could then add an alert handler that, when Watcher detects the service has stopped, it locally executes vulscan with /rebootifneeded which would then present the end user with graceful reboot options. Actually, that might be quite a tidy approach. Although, I guess there's a risk that a permanently broken antivirus service would leave the machine with a perpetual desire to reboot.
Following up on what Richard says about Agent Watcher. I wonder, I havent tried this, but is worth a try... If you schedule to repair vulnerability AV-101, with desired settings including the reboot immediately after your agent deployment...
Richard/Frank, many thanks for your help so far. I'll give it a go and let you know how I get on.
Following your advice, I created and published a new Alert Ruleset (AR) to monitor the LANDesk AV services and if detected to reboot the client using an Action that executes "C:\Program Files\LANDesk\LDClient\vulscan.exe /rebootifneeded". I included this AR to the 'master' AR, published it then distributed the AR to my test client. I can see the "AgentWatcherSettings_Agent Watcher Settings (AV only) TEST.ini" in the LDClient directory so I know it has applied successfully.
I created a new Agent Watcher (AW) to monitor the LANDesk AV Service with polling set to 30 seconds (just for test purposes). I then right-clicked the client in network view, clicked "Update Agent Watcher Settings" and selected my AW. Now, I can see the AVService firing up every 30 seconds but neither the service starts nor does the reboot occur. I see this in the AVService logfile:-
Tue, 21 Feb 2012 18:57:58 1872 18700 Checking if Kaspersky requires a reboot.
Tue, 21 Feb 2012 18:57:58 1872 18700 Must reboot first because a pending uninstall of the klif service was found.
Tue, 21 Feb 2012 18:57:58 1872 18700 Reboot needed.
Tue, 21 Feb 2012 18:57:58 1872 18700 Reboot needed before installing the driver: true
Tue, 21 Feb 2012 18:57:58 1872 18700 kave will NOT be initialized. The old version of KLIF was found and a reboot is required.
Tue, 21 Feb 2012 18:57:58 1872 18700 Core server name found in HKLM\SOFTWARE\Intel\LANDesk\LDWM: LANDESK
Core server name found in HKLM\SOFTWARE\Intel\LANDesk\LDWM: LANDESK
Tue, 21 Feb 2012 18:57:58 1872 18700 AV history msg: <Action name="Error (not a virus)" code="25" date="1329850678" type="80" user="PINSENTMASONS\dslds1" >
<status>You must reboot before you can complete the upgrade process and initialize LANDesk Antivirus. (800404D5)
Tue, 21 Feb 2012 18:57:58 1872 18700 Sent alert : internal.ldms.LDAV.AVServiceFailedToStart for (, You must reboot before you can complete the upgrade process and initialize LANDesk Antivirus.)
However, I don't even see the alert being logged in the Logs on the core.
Any advice where I go from here would be much appreciated.
I tried your suggestion too but when I created a repair task of AV-101 with desired settings and pushed it to my test client it fails with the error:-
"Cannot complete the requested action. The device must be rebooted first" (return code = 437).
It seems to need a manual reboot before it will automate anything...?