We're excited to introduce you to 14 new Remote Support apps as part of the existing Service Management Stream!
These modern, web-based, user and device management tools for Analysts help further maximize productivity, deliver faster problem resolution and increase end user satisfaction.
Check out our on-demand webinar to find out how these new apps fit into your existing Team or Service Management Foundation license, see a technical overview demo, and more.View the installation & setup webinar to learn how to get started with Remote Support.
SMLets Exchange Connector not ingesting emails
Bryan_Lalor
Customer IT Monkey ✭
We have recently installed the SMLets Exchange Connector environment using the method outlined in installing via management packs. Currently it is not ingesting emails even though the ps script isn't throwing any errors when firing it manually. I've already checked to make sure that none of the files related to the script or blocked which seemed to be the only common cause for it not functioning properly I could find.
Does anyone else have any other ideas of why it may be failing to pull in the emails from our test mailbox we have set up?
Best Answers
-
Simon_Zeinhofer
Customer Ninja IT Monkey ✭✭✭✭
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
1 -
Adam_Dzyacky
Product Owner Contributor Monkey ✭✭✭✭✭
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.
0 -
Simon_Zeinhofer
Customer Ninja IT Monkey ✭✭✭✭
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
1
Answers
Are there any related events in the Operations Manager or SMLets Exchange Connector Event Log?
I'm not sure where SMLets is storing it's event logs by default. As for Ops manager there are some warning regarding run time for some cireson related components, but none that directly reference the SMLets exchange connector.
As long as you've enabled logging in the Settings, make sure its set at verbose. It should create an Event Log on the workflow server called "SMLets Exchange Connector"
Looking at the Event Viewer information, it seems to be running repeating these events, Occasionally it is stating 0 processed and sometimes 1
I just upped the logging to verbose. I will update you as soon as it produces some new logs.
The additional logs it has generated thus far.
All of the above looks as though its connecting and processing items from Exchange. To continue forward with testing, I would just send a couple emails to it and watch them process in the Event Logs.
I have, they never appear inside of SCSM. I also configured the setting to delete the email after it's been scanned and it doesn't appear to be doing that.
Right now we have it running off a test mailbox we have set up which is different from the run as account. The install documentation also wasn't clear on whether we should have impersonation or Autodiscover configured.
Found out it was running. Just on the main mailbox and not our test mailbox. However, after correcting the run as account and making sure it was running I still ran into an issue with the intake. I had two requests, one that was successfully added to an existing SR the second one in the picture. It ran the processes, added the email as a comment and then deleted the email. However, the one that was emailed without a SR or IR just stayed in the mailbox looping and creating additional duplicate IRs. Do you know why it behaved differently in regard to moving items to the deleted items?
@Bryan_Lalor I am relatively new to the SMlet Connector but I had some trial and error as well :D
Have you activated logging? It really helps.
I also had the same situation, when I started configuring my customevent Script. My connector was running into an exception at every run. In my case it also created an incident everytime, but as it broke up before deletion the mail was never deleted.
Did you change anything inside the main script or added something inside the customevent Script?
I don't currently have any custom event script running, nor have I edited the main script. I have verbose logging on and the main difference between the one it properly deleted after running is Event ID 3 (which i believe is the marker for processed) never appears to run again It just cycles Event ID 2 "Messages to Process: 1" then the rest of the workflow.
What do you have configured as time, when the connector runs?
Do you ever receive the following message when the test mail, which never gets deleted, is inside the inbox:
Processed # messages in:
.
.
.
Can you try setting the logging level to 1 and try it again. I remember my connector ran into an exception when I had the logging level too high and the Get-scsmuserbyemailaddress was running.
I was unable to get it to process in for the test email. I tried again using a message with an IR in the title and that is still getting processed in. As for exceptions I haven't seen anything to that effect inside of the logs. the Get-scsmuserbyemailaddress appears to be functioning as intended. Below is how I configured the logic just in case it is a settings issue. I also attached a picture of the successful processed in message for the test email with an included IR.
ars to be functioning without issue.
@Bryan_Lalor
I guess you misunderstood me.
Is the "Processed # messages in...." Event also showing when only the test mail (which never gets deleted) is processed?
2nd question: What have you configured in the workflow stettings? Ho much time have you configured for connector runs?
It never "Processed # messages in..." for the test email without an IR or SR ID. Inside of Smlets settings I have it set for every 360 seconds.
🤔
I saw an old discussion post on the GitHub stating that a similar issue was happening to a user, but it seemed like that issue was centered around dynamic analyst assignment. Regardless I tried the solution which was provided on that post of making sure that we weren't using a default template for incident creation. After checking I confirmed it wasn't a default template.
I've really been thinking this one over and I think I can say you're officially at a point where you'd have to do some live debugging of this to discover what could be going wrong. The general idea/approach here is:
To clarify, Disable the workflow, send an email, then run the smletsExchangeConnector.ps1 script as the WF/Run As account?
Yes
Exiting without any red text
And no warnings/errors in either the SMLets Exchange Connector or Operations Manager Event Log?
None in ops manager, looks like it didn't pull any of the values set by the connector setup inside of scsm
This is from the smlets event logs
After working with Patrick from the Cireson team and reinstalling the connector with the latest installation the issue quit occurring with just the base connector running and no custom events. It did stop properly moving items to deleted again once we attempted to add in Custom events. Removing the custom events file path in the settings resolved the issue, but we plan to use that feature for some automated ticket routing. Thoughts?
We had the same situation, but I don't remember what solved it for us. - Maybe this is solved with the new version where the customevents are no longer tied to the logginglevel.
Maybe try to set up the exchange connector in a test environment and start by setting the logging level to highest. Then everything gets logged and you should be able to see, what has been the last step before the script stopped.
We are currently on the latest version. It has the same standard logs up to the point where it would normally go to Processed, then Processed in. Both of those logs never occur and then it will cycle back to the standard logs for intake.
Do these errors still occur? If yes, what is inside this log errors?
No errors are logged. And the logs are on the highest setting.
When you add the path to the customevents, do you get a log info that it was loaded successfully?
Yes