1 of 1 people found this helpful
If this is something that you're looking at as a regular method, you will want to look a policies.
Policies have the benefit that you can attach a dynamic query, so as we re-resolve query (AD or whatnot), we add the new relevant devices, and - in the case of policies - the clients will pick them up as required / install automatically if you make them as required packages.
So you will want to look at BKM's / the sections of the manual for policies, that should probably be a good starting point for what you're trying to acheive (with minimal overhead effort on your part). The details will vary on what version of LANDesk you have.
The trick though (or key detail) is to make sure that clients *DO* check for policies in regular intervals (days / weeks / whatever) .
- Paul Hoffmann
LANDesk EMEA Technical Lead
Thanks.. I feel like an idiot. I was already doing that. What messed me up was say I had a query with 5 computers in it, once I ran the policy the "unknown" part disappeared. I just had to go into the properties and see that the query was still attached. Works like a charm!
Ok, I spoke too soon. I think I'm close but can't quite finish.
I have a package to deploy to a group of laptops. In this case its a remote backp software that goes on any laptop in our "Remote Users" OU. For now I want it to just appear in the deployment portal. That part is working.
But if I schedule the policy to repeat, what happens is the software shows up in the portal on a computer, I install it, and the core console shows done/successful. Then the next hour (or however often it runs) the job shows up again as waiting. It gets redployed to the client. What I'd like to do is NOT have it show up if its deployed already.
Perhaps the way to do this is in my query, only have it show laptops that need the software? I'm sure that will work but it doesn't seem quite right. I have chosen "once" in the frequency of policy in the delivery method.
Well - what you can do is to use this as a "REQUIRED" policy - that way it doesn't show up (as such) in the policy portal, it just gets installed.
From the general tone of your post, this might be more what you're after (i.e. "I don't care whether people get to see this - this needs to be installed most importantly").
I'm a bit unsure why you schedule the policy to repeat (this could be either a "thinking error" or an unfortunate case of expression) ... once you've set a policy to be active, you shouldn't need to restart it as such in most cases. A bit more of a background here would be useful.
Or in short - what exactly is it you're trying to acheive here, exactly? It could be eaiser to begin with that and work from there, rather than to go through this piecemeal.
- Paul Hoffmann
LANDesk EMEA Technical Lead
(P.S.: I'll be out for a while after today, with highly irregular access to the WWW - so it may be a few days before I respond)...
If I have a policy that applies to a query (say computers/devices in an OU), and I later add computers to the query/OU - after the policy has been started - do they automatically get picked up by the policy? So for example this policy is responsible for deploying a backup package, and a computer gets put into the target OU, will the computer see the policy to apply?
The great thing about queries and required policies is that it is a 'set it and forget it' type of distribution. In the Landesk services configuration area under the Scheduler tab is the 'Interval between query evalutions'. Based on this interval for each distribution associated with a query it will re-resolve the query. So, if I base a query off of a LDAP group and put users/computers in that group, then based off the interval the core server will repopulate the targets for this task. This is the beautiful thing about queries... they're dynamic. Therefore, you don't need to restart the task, the core server is handling it for you.
However, as you've noticed, if you do restart the task you lose the 'install status' and everything goes back to zero. This is because a restarted tasks cleans the slate and starts new. Try this for yourself though, either with a regular query or an ldap query. Create a simple task (I usually do a launchpad that starts notepad.exe) and apply the query. If you're using an LDAP query drop a user/machine into the group and start the task. Let if finish, then drop another user/computer into the group and wait for the interval (whatever time you have set on your core) to elapse. Based on the timing you have on the core and how often your clients check in, this should work quite well for your purposes.
Excellent description, I'm not sure why I didn't understand this. I was starting down this path before but I think I had a problem with my query so it looked like it wasn't re-evaluating. This all makes sense.
Thanks both for your help - I knew I was close and this should be pretty easy!