AdhocAdam
commented
3 years ago I've been doing some investigation into this and believe I've found the error as I can now repro it on demand.
Given the two opening lines lines to the ELSE statement in Attach-FileToWorkItem:
$attachment.Load()
$base64attachment = [System.Convert]::ToBase64String($attachment.Content)If an email is sent in with at least 1 attachment that is another Exchange object (such as an email message or calendar item), then Attach-FileToWorkItem will correctly .Load() the attachment but fail to parse the byte/content stream because the .Content property does not exist. This is due to the fact that attached Exchange objects are considered an Item Attachment and not a File Attachment.
Describe the bug This is if the attachment type does not match the "mime*" pattern and the "else" section is followed. Suspect that attachment object may be null at this point. Error message: Exception calling "ToBase64String" with "1" argument(s): "Value cannot be null. Parameter name: inArray" At line:XXXX char:13
Help us reproduce the bug Version of the connector you are using: 1.4.5 Features/variables you have enabled (i.e. $enableAzureCognitiveServicesForNewWI): multiple mailboxes
Expected behavior If attachment is null/nonexistent, this operation should not be attempted. Unclear why there are null objects in the collection of attachments being looped through, though.
Location and Environment Where are you running this from? Task Scheduler? SMA? Workflow server?: SMA What SCSM version are you running? (i.e. 2012R2, 2016, 2016 UR3, 1801, etc.): 1807
Additional context This is likely the result of connection problems caused by DB deadlocks. The solution is likely to be the addition of checks to make sure that the script does not continue to operate when it cannot connect to either SCSM or Exchange.