Remedy Email Engine SSL Error
SSL Errors
We had the email engine working fine for quite some time (ARS 7.1 on Solaris).
Then – one magical day after server patching – it quit. The error messages reported in the email error logs form said this:
Connect failed
javax.mail.MessagingException: Connect failed;
nested exception is:
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at com.sun.mail.pop3.POP3Store.protocolConnect(POP3Store.java:148)
at javax.mail.Service.connect(Service.java:275)
at javax.mail.Service.connect(Service.java:156)
at com.bmc.arsys.emaildaemon.ReceiverModule.initializeIncommingMailbox(ReceiverModule.java:1876)
at com.bmc.arsys.emaildaemon.ReceiverModule.doWork(ReceiverModule.java:216)
at com.bmc.arsys.emaildaemon.ThreadBase.run(ThreadBase.java:288)
at java.lang.Thread.run(Thread.java:595)
….and it looked like this…
Remedy Email Engine SSL Error
As it turned out – it was a pretty easy fix.
For some reason the patching (OS level patching by another group) had overwritten our CACERTS file. We didn’t notice immediately because the replacement file had approximately the right size and date.
So – if you run into the “PKIX path building failed: unable to find valid certification path to requested” error – re-import or otherwise replace your SSL certificates.
-William
Configure the BMC Remedy Email Engine with Gmail
Someone recently asked me if the BMC Remedy Email Engine can retrieve/process email from Gmail.
The answer is “Yes” – although I’m not sure why you’d want to do that. I’ll just assume there’s a legitimate business reason for doing so.
To do this you have to do just two (maybe three) things:
1.) Configure GMail to allow POP access
2.) Configure the Remedy Email Client to retrieve email, and optionally configure the Remedy Email Engine to send through Gmail via SMTP
Step One: Configure Gmail to enable POP3 Access:
Fortunately this is quite easy. Gmail has laid out the instructions for enabling POP3 process for us (click to enlarge):
Gmail POP enabling instructions
Step Two: Configure the Remedy Email Engine to use Gmail
This is also quite easy. I’ll assume you know where/how to open the proper configuration forms in Remedy. If not, you can contact me for more information. The information you need to know is all located at Gmail’s configuring other mail clients page for both incoming and outgoing email (click to enlarge):
Gmail Email Configuration for the BMC Remedy Email Engine
That’s all – it’s a breeze. The only other thing you’ll have to worry about is whether or not your organization has blocked access to Gmail.
Part 5: Updating Incidents from Incoming Email with the Remedy Email Engine
This is a 5-part post. It began in part one where I started discussing how to automate service with the Remedy Email Engine.
The previous post deals with how to create an Incident with the Remedy Email Engine (in ITSM 7.x).
Updating an Incident from an incoming email is quite easy. The real trick is simply identifying which emails are updates to Incidents and which are new Incidents.
Fortunately this should normally be handled in the title of the email. If you are using any sort of normal ITIL process (or out of the box Remedy notifications) the notifications will include the Incident # in the title of the email. For example, the following process may occur:
- Customer emails help desk
- Our previously created parts create an Incident
- Standard workflow responds to the customer via email with a subject similar to “Incident ISS000000001234 was created from your email”
One important note here – your notification sent by step #3 may need some slight modification. Many organizations set up their ”Reply To” email address as something like DoNotReply@XMYCorp.com for standard notifications. In this case we actually WANT the users to reply. So, our notification for #3 above should be altered like this:
Also, the text of this email should encourage the customer to reply if they have a question/issue/further information.
That said – when they do reply – how do you know what to do?
That answer is easy. Let’s assume the following is still true (based off of the previous workflow):
- The Email Message will arrive successfully
- The Email Message will get directed to our Email Processing form
If those things are true then we just run a simple test on the email with another filter – we look for the Incident ID # in the Subject line like this:
From this point it’s a simple matter of writing workflow to strip out the Incident ID # and process the email.
**Edit on 6/8/2009 – I have received a question for more detail on how to do this – so I’m pasting it in below.
Stripping the Incident ID is handled by doing the following steps in the filter listed immediately above:
1.) Add 2 temp number fields to the form named something like IncStart and IncEnd. You should also have an Incident ID field.
2.) Set up a filter with a “Run If” like this:
‘Subject:’ LIKE “%INC[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]%”
3.) Add these 3 “Set Fields” actions:
-Set IncStart to:
STRSTRC($Subject:$, “INC”)
-Set IncEnd to:
$IncStart$ + 14
-Set Incident ID to:
SUBSTRC($Subject:$, $IncStart$, $IncEnd$)
*End edit
Specifically all we do – once the Incident ID is stripped out – is a simple Push Fields action to HPD:Help Desk.
If you want more information on that feel free to contact me.