SMLets Exchange Connector not ingesting emails

Simon_Zeinhofer

Do you actually have anything written inside the customevents?

Are the workitems, which are created, some sort of abnormal? Is anything missing, which would lead to the step which errored out?

Bryan_Lalor

I have one function in the custom events that I input that looks for [Hardware] in the title then assigns it to a specific queue

Here is the full function

function Invoke-AfterCreateIR {

 # This function occurs after a new incident work item is created.

 if ($email.Subject -like "*[Hardware]*")

    {

 #set the IR Support Group as "Desktop Support"

      Set-SCSMObject -smobject $WorkItem -PropertyHashtable @{"TierQueue" = "cd712f91-a26b-8ff8-133d-36f9f4b40d46"}

    }

}

Simon_Zeinhofer

https://community.cireson.com/discussion/comment/24730#Comment_24730

can you change it to

function Invoke-AfterCreateIR {
 # This function occurs after a new incident work item is created.
 if ($email.Subject -like "*[Hardware]*")
    {
 #set the IR Support Group as "Desktop Support"
      try
      {
      Set-SCSMObject -smobject $WorkItem -PropertyHashtable @{"TierQueue" = "cd712f91-a26b-8ff8-133d-36f9f4b40d46"}
      }
      catch
      {
      $logMessage = $_.Exception.Message
      New-SMEXCOEvent -Source "CustomEvents" -EventId 25 -LogMessage $logMessage -Severity "Error"
      }    
   }
}

so you will see if an error is thrown when the incident should be changed.

But I guess the Set-scsmobject is not correct

1) I don't know if you can set a enum property just by using the ID, I guess it has to be the Name, in that Case "Desktop Support", the Enumeration object itself (presaved into a variable) or the Enumeration Name, for custom Enums its "Enum...."

2) As far as I can remember the variable for a newly created IR is $newWorkItem and not $WorkItem

But add the try catch to the function and then the error should be logged inside the event viewer AND the mail processing should continue

Bryan_Lalor

I will try that,

This function was a modification of a functioning script used in the cireson techs test instance.

I'll have to test this out after hours tonight or tomorrow morning as we only have a live environment.

My head was in the same place on this that the function may be the issue. I'm also going to try using an unmodified customevents.ps1 and see if the same issue reoccurred.

Adam_Dzyacky

Just wanted to echo a lot of what Simon is saying here and further help clarify a few points:

• Setting an Enum can be done a couple of different ways. You could use an entire enum object or by using its guid

By GUID

Get-SCSMObject -class $irClass -filter "name -eq 'IR2533'" | Set-SCSMObject -property Classification -value "b97a8a43-9802-d382-089f-f99eeee6f4a0"

By Enum Object

$classification = get-scsmenumeration -name "incidentclassificationenum$" | get-scsmchildenumeration | select-object -first 1
$ir = Get-SCSMObject -class $irClass -filter "name -eq 'IR2533'"
Set-SCSMObject -smobject $ir -property Classification -value $classification

I would also second the try/catch block when it comes to Custom Events as you'll want error handling and logging for your own customizations to the connector.

And finally - yes, a recently created work item in the connector uses the $newWorkItem variable.

Bryan_Lalor

Looks like making the modifications suggested did the trick. I updated $WorkItem to $NewWorkItem and added in the try catch for logging. I also found when opening the file in VScode that there was some unicode characters hidden that might have been a problem.

The email was properly moved to deleted after processing and successfully moved that ticket to the desktop queue. No errors were thrown from the catch.

Thank you for your help.

Simon_Zeinhofer

@Bryan_Lalor nice one you got that sorted out 🙂

So the script errored out because the $workitem variable has never been declared and initialized and therefor was $null.

I really recommend logging as much steps as possible inside the customevents, and surrounding it with a try catch - helped me a lot

Adam_Dzyacky

I also found when opening the file in VScode that there was some unicode characters hidden that might have been a problem.

If you could share these it would be incredibly helpful 😀

Bryan_Lalor

U+feff

Adam_Dzyacky

Excellent. Thanks for clearing that up and that it was located within Custom Events 👍️

Bryan_Lalor

I got one more thing to pick y'alls brain on.

I was working on setting up the above script as a switch, but it looks like it isn't catching the case statements. Is there a good way I can test this to troubleshoot without having to create tickets, or do you see an obvious flaw in the design?

function Invoke-AfterCreateIR { # This function occurs after a new incident work item is created. 
switch ($($email.Subject)) {
#set the IR Support Group as "Desktop Support"
  "*[Hardware]*" {
   try { Set-SCSMObject -smobject $NewWorkItem -PropertyHashtable @{"TierQueue" = "cd712f91-a26b-8ff8-133d-36f9f4b40d46"} 
    }
    catch { $logMessage = $_.Exception.Message 
    New-SMEXCOEvent -Source "CustomEvents" -EventId 25 -LogMessage $logMessage -Severity "Error" 
    }
}
  "*[Telecom]*" { 
#set the IR support Group as "Network Support"
    try { Set-SCSMObject -smobject $NewWorkItem -PropertyHashtable @{"TierQueue" = "8bc1381d-9bb6-ee7a-73ef-96eedbc8b95a"} 
    } 
    catch { $logMessage = $_.Exception.Message 
    New-SMEXCOEvent -Source "CustomEvents" -EventId 25 -LogMessage $logMessage -Severity "Error"
    }
}
#set the IR support group as "Server Support"
  "*[Exchange]*" {
    try { Set-SCSMObject -smobject $NewWorkItem -PropertyHashtable @{"TierQueue" = "6357bd59-252a-5d9d-744e-304ad275bfba"}
    }
    catch { $logMessage = $_.Exception.Message 
    New-SMEXCOEvent -Source "CustomEvents" -EventId 25 -LogMessage $logMessage -Severity "Error"
    }
} 
#set the IR support group as "Developement Support"
  "*[PRISM]*" {
    try { Set-SCSMObject -smobject $NewWorkItem -PropertyHashtable @{"TierQueue" = "cdf3896f5-3145-0546-4d25-e485de6765af"} 
    } 
    catch { $logMessage = $_.Exception.Message 
    New-SMEXCOEvent -Source "CustomEvents" -EventId 25 -LogMessage $logMessage -Severity "Error"
    }
  }
 }
}

Simon_Zeinhofer

https://community.cireson.com/discussion/comment/24745#Comment_24745

When using wildcards , you have to use

Switch -regex $email.Subject
{
'\[Hardware]'{...}
'\[Telecom]'{...}
}

Or

Switch -wildcard $email.Subject
{
'*[Hardware]*'{...}
'*[Telecom]*'{...}
}

I prefer the regex in my scripts

Bryan_Lalor

I'll give that a shot, I figured it had to do something with the cases not ever matching the switch, but it I couldn't figure out a good way to get it to display an output for review. Thanks again Simon.

Adam_Dzyacky

I would also suggest introducing a default case on your switch statement(s). In this case, it could be as simple as a custom log event that calls out that a match did not occur along with relevant details as you deem necessary from the email.

Bryan_Lalor

https://community.cireson.com/discussion/comment/24746#Comment_24746

I was able to get it to function when using Regex. When setting it up using wildcard it was managing to match multiple cases and would just be handed between support groups until it reached the last option available.