Tokens in Email Notification?

Hi All,

Need to notify a support group via email once a baseline has been completed. This support email will vary from server to server, so I ended up storing this value as a client setting in Bigfix hoping I could use this.

Notification requirement is pretty basic, so I was looking to use Bigfix email notifications;

https://www.ibm.com/support/knowledgecenter/en/SSQL82_9.5.0/com.ibm.bigfix.doc/Platform/Config/sa_commonnotificationusage.html

I would like to be able to substitute the email To: field for this custom setting and also return the hostname as part of the email. This is what I’ve tried, however emails are never sent unless I set the To: field to a static value.

// NOTIFICATION_START 
// to: "{( value of setting "AppInstallCompleteNotificationEmail" of client)}"
// from: "Notifications@thebusiness.com" 
// subject: "'{actionName}' quarterly patching on {hostname} is complete" 
// body: "Baseline '{actionName}' with ID {actionID} has completed on server '{(hostname)}'"
// scope: "parent" 
// NOTIFICATION_END  

Are there limitations to what can be used with substitution here? Can I use a custom setting and the hostname property in this way? I suspect I am missing something pretty basic as I can’t seem to find much discussion particular to this issue.

I don’t know if there is a limitation there, but based on the doc I’d be surprised if there is.

I’d check for the client setting existing and being in the right format (comma-separated list), and especially that the value itself does not have any embedded doublequotes that would mess up the “to:” value.

Thanks Jason,

Using QnA on the target test server I run everything between the braces in the To: field and I am returned the email address I am expecting. Only have a single email address in this client setting and the notifications task is only set to send to a single address. If I replace everything inside the quotation marks with the exact same email address as set in the client setting it seems to work fine.

Also, the substitution never appears to take place for the hostname property. The actionName and actionID are the only examples given in the doco which seem to work fine. Interestingly, echoing this same custom setting and hostname property out to a text file in the same action script seem to make the substitutions no problems.

createfile until _end_
Value of AppInstallCompleteNotificationEmaill = {(value of  setting "AppInstallCompleteNotificationEmail" of client)}
Value of hostname = {hostname}
_end_
move __createfile c:\temp\BF-Email-Test.txt

I haven’t much looked into the email notifications myself, but there was a note in the doc about static-targeting the action. It makes me think there might be some special handling on this one, maybe similar to the Javascript that makes Parameterized Fixlets work. I will have a look at the fixlet tomorrow, but it’s possible those substitutions are being made by the console itself when we Take Action on the fixlet/baseline, so it may not be able to use client settings directly.

1 Like

Thanks again Jason. I’ve not been able to find anything further around how this email notification service can be customised. I managed to get a 30 second corridor chat with our Bigfix administrator who said he thought it was very limited in terms of customisation, but would need to get back to me with specifics. Would indicate the same as you highlight in that content here is treated a bit differently. Thanks for your assistance.

Hi Nicoloks,

I’m failry familiar with the notification service and in the past I’ve looked to modify in the same way. Essentially, I wanted to dynamically fill some of the lines with relevance, pulling the “to” field dynamically from a custom setting (server owner) on the cleint.
However, the notification service template needs to be filled eaxactly to the template, and the already avaialble variables are catered for specifically in the java script when it picks this up. So its not possible to add your own variables without modifying the java app which the notification service is based on.
I also anticipated issues when a large group of servers is targeted, and there is the same owner for multiple servers - they would get flooded with one email for each of the servers int he baseline.

At thsi point, I looked down an alternative route using Webreport’s notification service, and the triggers and variables avaialble there.

However, I did think of an idea arround this, using the REST API.

Essentially, you could have session relevance lookign for sepcific content, in this case the Baselines, and have it trigger an action through the API to generate the notification taks drectly ont he BigFix server, which follows the formatting of the template.
Because you are generating the task on the fly, you could use variables in the building process, which outputs exactly the lines and format that the java app is expecting. This way, you could also account for duplicates, and have a single email cater for multiple servers.
On the face of it, it sounds doable, however I may be over simplifying it a little, so I would anticipate some hurdles that I’ve not thought of if you wanted to go down that route.

Triggering an action over the API is fairly easy, and the session relevance for the trigger should also be fairly straig forward. However the dynamic creation of the action may need fome fettling to get right :thinking:

Another issue woudl be that, when targeting a large group of servers with a Baseline with multiple server owners within it, you ideally need one email notification for each unique server owner, unless you copy everyone into a single mail (which is supported by the notification service). But then you end up with a fairly long list of “to” emails, and the body would then need to be a consolidated list of all those servers and success/failure, which actually is no better than a simple automatically generated report in WebReports.

Thanks mate, started looking into it however I think we’ll probably build something out of PowerShell. If we are building something quite custom, don’t want to lock ourselves onto a specific platform.