Kaseya Community

Sending alerting to different email addresses with Policies

This question has suggested answer(s)

We have turned off the built in monitoring that comes out of the box, as it was unconfigurable.  Have now set up our own policies that we apply to all our clients.  However, we have some clients that wish to receive alert emails as well as our central support email address.

Has anyone successfully set this up so alerts can also be sent to the clients nominated email address as well as the default one entered in the policy?  The #Severity3# variables can only be used when the automated monitoring is turned on.

The only work around at present is copying the monitoring sets, changing all the alert email addresses as required, then apply to the Organization.  Which duplicates policies, and creates yet another set of policies to remember to change when making global changes or improvements.

Hope I have explained it OK. 

All Replies
  • What you do is you copy the policy that has the monitor set that you want and rename it or put a tag at the end to identify it as an override policy for that customer. I normally keep the policy name the same and just put the company name in between brackets at the end.

    Edit your new custom policy and edit the Alarm options for the monitor set/s. Now assign the new policy to the machine group and make sure that it is above your normal/default policies. This is known as an override policy.

    I found this method work best if structuring your policies into the following 4 folder levels;
    0 - Zero level (Policies that would apply to all agents and that should never be overridden)
    1 - Customer Override Policies (Create sub folders for each Org and then again for each network/machine group)
    2 - Default Policies (All your default configuration and monitor set assignments etc goes in here)
    3 - Manual Policies (Folder used to store individual policies meant for manual assignment)

    And I like to add a 5th "Development" folder to store template policies and my policies in that I work on.

    (1) contains polices that I template'd from the polices in (2), and then stored in their customer/machine group folders

    As mentioned above you breakup you Custom override policies by Customer Org and then by site/machine group

    Assigning the Policy Folder is simple and done like in the image below;

    [edited by: HardKnoX at 3:46 PM (GMT -7) on Aug 29, 2013]
  • hmmm, it looks like it will become more complicated that I'd like.  I was hoping to keep the policies area as simple as possible.  The more I use Kaseya, the more "work-arounds" I end up having to put in place because the functionality is not there.

    I understand the limitations of hierarchical policies, but it would be nice to be able to make changes, mark them as authorized compliant, and not be wiped out by clearing overrides.  Clearing Overrides can wipe out a lot of work at the touch of a button, that you may not have been aware that another tech has done.

  • tonijo
    The more I use Kaseya, the more "work-arounds" I end up having to put in place because the functionality is not there.

    Did you read my job description somehow?

    I keed, I keeeeeeeed.

    I've found that Machine Custom Fields and Organization Custom Fields are your Friends.

    I'm still working with KSupport on getting #vOrgCustomFields.[ref]# implemented; however, I will say this: Once you get your Policies based on MCFs and OCFs, it will make your life so much easier.  In the interim, you always have #vSystemInfoManual.[ref]#.

    All of my policies are based on Machine Custom Fields, inheriting down settings from Org Custom Fields.

    If, at the Org level, I'm told to not monitor "AntiVirus," I'll just add this to the Automatic_Monitoring-Excluded* Org Custom Field.  That inherits down to the Machine Custom Field (through magic voodoo which may or may not be supported by KSupport in the near future) and determines which Polices are applied (reference the #vOrgCustomFields.[ref]# View from earlier).

    Overriding MCFs must happen at the Machine level.  If the OCF overrides the MCF, but the MCF has been set manually, then the MCF wins.  This is hard to implement, but once you figure this out, you're golden.  That's all I can say legally Wink

    Also... remember that Policies that are applied at the Org level are taken in a higher priority than those that may have been applied at a Global level.  Use this to your advantage.  If you have a company that does not want you to allow Remote Control of their Workstations without consent of the currently logged-on user, then you can apply a Policy at the Org level that would override your Policy at the Global level that says, "Always allow" Remote Control.

    Everything you want to do can be done through the VSA... but sometimes it takes some lateral thinking Smile

  • Not complicated at all, was more complicated to figure it out then to put it together. If you break it down you could get away with only 2 tiers;

    1 - Override Policies

    2 - Default Policies

    Think of your Default Policies as the company standard and Override Policies as the company standard with custom settings.

    Also you can easily add exclusions via a Custom Field and filtering them using you Policy View FIlters

  • Looks like I will be spending some time looking at Machine Custom Fields to help us achieve what we need.  I see that Custom Fields at the Org level are limited - in that you can only have 20.  

  • Hi,

    We are planning on providing additional token support for policies like the patch and sev1-3 Alert Email tokens in a future release of Kaseya and a UI to manage these also, but for now, if you want to set these tokens manually for an Organization, here is a SQL approach you can use to set them without configuring them via the Systems Management Config Wizard.  These 4 SQL Queries will do the trick:

    --set the #patchAlertEmail# token

    insert into policy.policyPropertyValue ([id], [partitionId], [assocType], [assocGuid], [policyPropertyFK], [value]) select dbo.fn_GenerateKid(), 1, 2, id, 30000000001, 'patchalerts@mycompany.com' from kasadmin.org where ref like 'mycompany'

    --set the #sev1AlertEmail# token

    insert into policy.policyPropertyValue ([id], [partitionId], [assocType], [assocGuid], [policyPropertyFK], [value]) select dbo.fn_GenerateKid(), 1, 2, id, 30000000002, 'sev1alerts@mycompany.com' from kasadmin.org where ref like 'mycompany'

    --set the #sev2AlertEmail# token

    insert into policy.policyPropertyValue ([id], [partitionId], [assocType], [assocGuid], [policyPropertyFK], [value]) select dbo.fn_GenerateKid(), 1, 2, id, 30000000003, 'sev2alerts@mycompany.com' from kasadmin.org where ref like 'mycompany'

    --set the #sev3AlertEmail# token

    insert into policy.policyPropertyValue ([id], [partitionId], [assocType], [assocGuid], [policyPropertyFK], [value]) select dbo.fn_GenerateKid(), 1, 2, id, 30000000004, 'sev3alerts@mycompany.com' from kasadmin.org where ref like 'mycompany'

    All you need to do is change the email addresses and the ref like 'mycompany' for the actual orgId you want to configure.

    Hope this helps,

    Matt Warburton

    Kaseya Professional Services

  • Hi,

    I should also mention that you can then use these four tokens in your own Policies which you of course have the flexibility to configure as you desire.


    Matt Warburton

    Kaseya Professional Services

  • Thanks Matt.  Do you have any ETA for this to be included in a future release?  (crosses fingers)

  • Wow - 4 years later and nothing has been implemented to help with alert email addresses by Org.  :-(

  • Looks like Matt hasn't worked for Kaseya since 2013. Not surprising to me now that we haven't seen any follow up here.

    I’ve implemented this with nearly all of our policies and now every time I setup a new user, I have to manually run a series of SQL scripts to get this primed before applying policies. It works, but it’s not perfect and there are some bugs. One of the unfortunate bugs with Matt's approach is that if we (1) create a new organization, (2) deploy agents, and (3) assign policies that use the token, if we haven’t ran the sql scripts to insert a record for that organization in the policy.policyPropertyValue table, it uses the first record in the policy.policyPropertyValue table. We’ve had this happen a few times where the client email in that first record received alerts for agents that were not in their organization. That said, this workaround is becoming quite dated and I worry about how long we can ride it out until a more polished feature is released. Any updates on the progress of such a feature?