Kaseya Community

Question about how the "view" filter works against a selection of agents

This question is not answered

What I want to do is create a couple of views:

1. "Mising 10+ patches"

2. "Mising 1+ patches"

 

I then want to create two seperate policies, and have different schedules apply against each (e.g. have those that are missing more than 10 patches attempt to update more often).

My question is, how often does the policy re-run the view to update which agents it should apply to?

Is it only once at the creation of the policy?

Is it everytime the policy affects something?

Is it everytime the policy complience check is run by the scheduler?

All Replies
  • I've assumed that it is either #2 or #3 (and preferably #2) - because #1 would completely defeat the object.

    I'll run some tests today and let you know...

    ...unless, anyone from Kaseya can confirm this?

  • I am hoping that it is either 2 or 3 aswell.  Like you said, if it is 1, then there is problems, because a "view" can be either varible or static in which agents it applies to.

  • mango4
    My question is, how often does the policy re-run the view to update which agents it should apply to?

    In KPM v1.0, policies are assigned to machines based on their view membership at the time that the policy is applied to and Org, Group, or Machine.  We are considering enhancements to this functionality in a future release.

  • you got to be kidding so if I add a policy to a group and its say Windows XP SP3 Machines and I am missing 3 machines off that as they have SP2 but then we install SP3 on the two machines your saying that the policy does not apply to those two machines because they were not part of the original group.

  • @Kevin Frank

    That is highly disappointing.  If the “view” filtering is to be static and not dynamic, then KPM loses a significant amount of potential.

    When you say: “We are considering enhancements to this functionality in a future release.” what does that mean?  Are we talking a soon to be release hotfix, or are we talking months or years down the track?

  • @Kevin:  Wow. this is stunningly bad if this is the case.  I mean, staggeringly bad.

    This pretty much makes the whole module absolutely useless.  This means that I have to periodically go through each policy and re-apply it somehow, manually, before new machines will get the policy.  We are basically no better off than the old template method.  This might explain why we can't apply template at the top level, as this would imply that the policy would trickle down ***automatically***.

    This is such appalling design bad behavior that I really need you to double check this and confirm that this is the case.  An if so, when the hell its going to be fixed!



    [edited by: jdvuyk at 3:00 PM (GMT -7) on 6-26-2011] .
  • apparently no one on the development team at Kaseya has actually used Novell NDS or Active directory before.

  • I think before we all start jumping up and down lets get some confirmation from Kaseya on this or a user who is actually using it.

  • jdvuyk
    This might explain why we can't apply template at the top level, as this would imply that the policy would trickle down ***automatically***.

    To clarify, you can apply Policies to an Organization, or to a group, and that Policy will automatically 'trickle' down to the lower level Groups and Sub Groups.  Also,  as new machines appear in group, or move from one group to another, all of the policies associated with the Group will be applied based on the machines View membership at that point in time.

  • Thanks for the update.  This is at least partially useful.

    The problem is that people need to be careful how they use this.  Policies can NOT be used to apply something to agents that dynamically move from one view to another.  

    For example, I have a custom field that I type a yes/no into depending if the agent is part of a 'premium' support plan. Various report and other actions get applied based on this field.  This kind of thing CANNOT be used with policies because this view changes dynamically from time to time based on me updating this field.  The view will never get checked and the agent will not get any policies applied based on this field.  There are many other examples which have similar workflows.

    People need to be very clear that polices need to be used with static views.  An agent is a permanent member of a view, or it is permanently not.

  • If you check the Dashboard for Policy Management each day - like you check the other dashboards for things that need to be done - there is a pending items section, if anything is in it I noticed you simply just goto Policies Page and click the button up top that says "apply all policies" and the agents that have moved will then pickup the new policies at that time.

  • @jdvuyk

    From reading Kevin Franck's origional reply this is the interpretation I received from it.  It is a little dissapointing that agent views are not dynamic in their application.  So much is to be gained by making them dynamic.

  • mango4
    When you say: “We are considering enhancements to this functionality in a future release.” what does that mean?

    It means that at this instant we have not yet had a chance to identify a specific time frame for enhancing the way that KPM deals with View membership changes.  We are actively looking at what it would take to change this functionality, and we are determining whether or not the changes can be safely released as a hot fix.  If all goes well, we hope to release a change within the next several weeks.  We cannot make any promises until we are further along with the development and testing effort.

    Here is a description of initial enhancements that we are contemplating:  A new automated process will be added that periodically checks for changes in View membership.  When this new process detects that a machine appears in a View for the first time, any policies tied to that View (and associated with the machine via Org or Group) would be applied for that machine.  Initially, this new process will be automatically scheduled to run once per day (in a subsequent release, we will consider adding a UI that would allow you to control the schedule and perhaps run the process more than once per day).  We will also be enhancing the Policy Management / Machines / Reprocess Policies button.  If you select one or more machines, and click the Reprocess Polices button, changes in View membership will take effect immediately for the selected machines (note: you can select all machines, but should consider the potential processing overhead associated with re-applying policies to all machines).  The Reprocess Policies button will be a way to manually force the application of Policies based on current View membership if you don’t want to wait for the scheduled process to run.

    As mentioned by @jdvuyk, you should exercise caution when tying Policies to Views.  Kaseya does not recommend that you tie policies to ‘dynamic’ Views where the View membership changes frequently.  KPM is intended to apply policy based on ‘static’ machine characteristics (e.g. a machine is a SQL Server, or an Exchange Server, etc.).

  • Tom Fehlberg
    there is a pending items section, if anything is in it I noticed you simply just goto Policies Page and click the button up top that says "apply all policies" and the agents that have moved will then pickup the new policies at that time.

    This is true; however, changes in View membership will not be automatically picked up via the ‘Apply All Policies’ button.  As mentioned previously in the thread, we are considering making enhancements to deal with changes in View membership.

    In the mean time, here is a workaround to deal with View membership changes: Call up one or more View definitions and click Save for each View that you wish to reprocess (you don’t need to change anything, just click Save).  If you check the KPM dashboard, you will notice that ‘Pending Events’ section will list ‘View Changed’ events.  Any view membership changes will be processed upon the next ‘Automatic Policy Deployment Interval.'  If you want to effect the changes immediately, you can use the ‘Apply All Policies’ button.

  • Maybe there can be a DTS SQL job that can be run on the server that goes through once a day and refreshes the views….might do the trick….

     

    From: Kevin Franck [mailto:bounce-kevinfranck@kaseya.com]
    Sent: Tuesday, June 28, 2011 1:31 PM
    To: community_policymanagement@kaseya.com
    Subject: Re: [Policy Management] Question about how the "view" filter works against a selection of agents

     

    Tom Fehlberg:

    there is a pending items section, if anything is in it I noticed you simply just goto Policies Page and click the button up top that says "apply all policies" and the agents that have moved will then pickup the new policies at that time.

    This is true; however, changes in View membership will not be automatically picked up via the ‘Apply All Policies’ button.  As mentioned previously in the thread, we are considering making enhancements to deal with changes in View membership.

    In the mean time, here is a workaround to deal with View membership changes: Call up one or more View definitions and click Save for each View that you wish to reprocess (you don’t need to change anything, just click Save).  If you check the KPM dashboard, you will notice that ‘Pending Events’ section will list ‘View Changed’ events.  Any view membership changes will be processed upon the next ‘Automatic Policy Deployment Interval.'  If you want to effect the changes immediately, you can use the ‘Apply All Policies’ button.