This knowledge article may contain information that does not apply to version 21.05 or later which runs in a container environment. Please refer to Article Number 000385088 for more information about troubleshooting BMC products in containers.
Check the following approaches and possible causes for this to happen:
1 - Check and make sure the Approval notification is generated according to $SERVER$ parameter in the template.
The approval URL is generated like this (example):
=======================
<td width="11%"><strong><a href="mailto:?subject=Approve request CRQ000000000825&body=#DO NOT MODIFY FOLLOWING TEXT#%0AAction:Modify%0AServer:$SERVER$%0ASchema:AP:Detail-Signature%0ARequest%20ID: 000000000000654|000000000000449%0AApproval Status!13191!:1%0A%0AStatus Template:Approval_By_Email_Status_en%0AResult Template:Approval_By_Email_Result_Approve_en%0A##Modify##:"><font face="Tahoma, sans-serif" size="2">Approve</font></a></strong></td>
<td width="9%"><strong><a href="mailto:?subject=Reject request CRQ000000000825&body=Justification*!14518!:%0A%0A%0A#DO NOT MODIFY FOLLOWING TEXT#%0AAction:Modify%0AServer:$SERVER$%0ASchema:AP:Detail-Signature%0ARequest%20ID: 000000000000654|000000000000449%0AApproval Status!13191!:2%0A%0AStatus Template:Approval_By_Email_Status_en%0AResult Template:Approval_By_Email_Result_Reject_en%0A##Modify##:"><font face="Tahoma, sans-serif" size="2">Reject</font></a></strong></td>
<td width="39%"> </td>
<td width="34%" align="right"><strong><a href="$HOMEURL$/forms/$SERVER$/Approval%20Central"><font face="Tahoma, sans-serif" size="2">Launch Approval Central</font></a></strong></td>
</tr>
</table></td>
</tr>
</table></td>
</tr>
</table></td>
</tr>
</table>
<input type="hidden" name="Action" value="Modify">
<input type="hidden" name="Server" value="$SERVER$">
<input type="hidden" name="Schema" value="AP:Detail-Signature">
<input type="hidden" name="Request ID" value="000000000000654|000000000000449">
</body>
</html>
===============================
But if the template contains the actual AR Server name instead of the parameter $SERVER$ then the error will appear. Below an example of a template where the actual server name is present:
===============================
<td width="11%"><strong><a href="mailto:#$18087$#?subject=Approve request #$$Request ID02 Ticket$$#&body=#DO NOT MODIFY FOLLOWING TEXT#%0AAction:Modify%0AServer:remedyprod%0ASchema:AP:Detail-Signature%0ARequest%20ID: #$$Detail-Sig-ID$$#%0AApproval Status!13191!:1%0A%0AStatus Template:Approval_By_Email_Status_en%0AResult Template:Approval_By_Email_Result_Approve_en%0A##Modify##:"><font face="Tahoma, sans-serif" size="2">Approve</font></a></strong></td>
<td width="9%"><strong><a href="mailto:#$18087$#?subject=Reject request #$$Request ID02 Ticket$$#&body=Justification*!14518!:%0A%0A%0A#DO NOT MODIFY FOLLOWING TEXT#%0AAction:Modify%0AServer:remedyprod%0ASchema:AP:Detail-Signature%0ARequest%20ID: #$$Detail-Sig-ID$$#%0AApproval Status!13191!:2%0A%0AStatus Template:Approval_By_Email_Status_en%0AResult Template:Approval_By_Email_Result_Reject_en%0A##Modify##:"><font face="Tahoma, sans-serif" size="2">Reject</font></a></strong></td>
<td width="39%"> </td>
<td width="34%" align="right"><strong><a href="https://server.name.com.au/arsys/forms/remedyprod/Approval%20Central"><font face="Tahoma, sans-serif" size="2">Launch Approval Central</font></a></strong></td>
</tr>
</table></td>
</tr>
</table></td>
</tr>
</table></td>
</tr>
</table>
<input type="hidden" name="Action" value="Modify">
<input type="hidden" name="Server" value="$SERVER$">
<input type="hidden" name="Schema" value="AP:Detail-Signature">
<input type="hidden" name="Request ID" value="#$$Detail-Sig-ID$$#">
================================================
Check the "Approval_By_Email_Content_en" based on "AR System Email Templates" form to ensure the parameter set in it is $SERVER$
===============================
In another case, suggested customer adding the $Detail-Sig-Id$ since the value was blank in the Email.
===============================
2 - Check for multiple incoming/outgoing mailboxes defined in the EmailDaemon.properties file.
Confirm that all of the Email Engine's mailboxes are listed in the EmailDaemon.properties file or the entry does not have a value defined.
This triggers the Email Engine to process all mailboxes listed or if value blank then all mailboxes will be processed.
If there are multiple Email Engine instances running make sure that all mailboxes are accounted for between the two EmailDaemon.properties files.
Make sure each incoming and outgoing mailboxes have an associated mailbox.
Additional Information
Article: Remedy - Email Engine - Can I configure Email Engine to read from a specific mailbox?
3- Mappings on the Notes / Detailed Description field.
For example, having the below mapped in the Notes / Detailed Description field
..................
Notes: zzzzz
Source Data Center: zzzz
Source IP/Subnet/Mask: zzzz
Destination Network Segment: zzzz
Destination Data Center: zzzz
Destination IP/Subnet/Mask: zzzz
Protocol: zzz
Action: Allow
Configuration Type: zzzz
If Temporary, Active Period: zzzz
..................
The "Action: Allow" causes a conflict with the Email Engine when processing the approval as observed on a scenario having an Email Engine Debug binary. There are special keywords when following by the colon ':' character that cause the Email Engine to treat these as special instructions therefore affecting the check sum value when validating the 'Modify Key' in the email message therefore invalidating the key.
For example below the checksum generation additional keyword is getting added as per the below string when "Allow" keyword is added.
"AllowModifyCBTCNBITSMAPPAP:Detail-Signature000000000050608|000000000049401"
However while decoding the generating checksum "Allow" keyword is not added.
"ModifyCBTCNBITSMAPPAP:Detail-Signature000000000050608|000000000049401"
When using text in the Notes section and below notes are evaluated as #$$Email Message Body$$# in the "Approval_By_Email_Content_en" in notes section "Action: Allow" text is specified.
The "Action" keyword is also getting evaluated while the checksum generation which is causing a problem.
For Successful approvals Notes section does not have "Action" keyword specified. Other keywords include 'Server:', 'Modify:'
Removing "Action: Allow" and change it to "Request Type: Allow / Deny" in the notes section, the error is avoided.
For a list of these keywords use the following URL to the Email Engine documentation.
https://docs.bmc.com/docs/display/public/ars91/Using+label-value+pairs+in+templates
4- Run Email Engine in debug mode and search on '##Modify##' to see modification key.
On email client side, check the email message and you can see spaces in the modify key string.
For example web based email and mobility devices such as Android replace the plus character '+' with a space.
Using Outlook thick client the modification key is always intact and problem not encountered.
5- Make sure there is no custom workflow setting/replacing the original recipient (from the "To:" field of the AR System Email Messages form) and add in multiple email addresses.
The "To:" should only contain 1 recipient and not multiple recipients.
Only one approval can be approved by one approver. If there are multiple recipients, the Email Engine will not generate the ##Modify## key.
This is not a defect and it is working as designed. There is a defect SW00466373 log against this but this is only to add an error message when this particular scenario is encountered (i.e.: Message Number: 4935 Message Text: The modify key is missing from the incoming modify action email message, unable to execute Instructions).
6- If you running a single instance of Email Engine, make sure com.bmc.arsys.emaildaemon.Mailboxes= in EmailDaemon.properties is set to empty string. In one case, customer has set the parameter to the outgoing mailbox name, Email Engine does not generate the ##Modify## key.
Note: Make sure com.bmc.arsys.emaildaemon.Mailboxes should be present on all servers in server group.