Cireson Partners, Customers and Community members share your customizations and examples here to help benefit the community as a whole to earn Kudos and badges.


All files and projects located here are provided and come "as-is" and without any warranty or support. Use at your own risk. Your use of Community Uploads is subject to our Terms of Use.

Cireson does not and will not support or maintain these enhancements, extensions, and scripts.

For Team Cireson uploads click here.

An SMlets based Exchange Connector



  • Adam_DzyackyAdam_Dzyacky Customer Contributor Monkey ✭✭✭✭✭
    edited October 2019

    I think this would require two separate changes @Gabriel_Lences. But only one of them really falls into the connector's scope -

    • Introduce logic on the connector's Update-WorkItem in turn, Analyst Comment sections to test if the First Response Date has been set
    • Create some kind of custom.js addition for the Cireson Portal that performs a similar check

    The Update-WorkItem function on the connector is really just a giant PowerShell switch. Identify the work item type, then identify who is leaving the comment, and finally perform the action. That logic starts here:

  • Filip_TheyssensFilip_Theyssens Partner IT Monkey ✭
    edited October 2019

    Hello All,

    We are setting up a new SCSM environment and was trying to get this running.

    So far, I deployed the Powershell AD Module, the EWS API 1.2 package.

    I was thinking of running this through a scheduled task, as we do not use Azure Automation.

    I'm seeing errors when running the script manually:

    Index operation failed; the array index evaluated to null.

    At C:\smletsexchangeconnector-master\smletsExchangeConnector.ps1:2451 char:24

    +                return $Mailboxes[$ScsmEmail]

    +                       ~~~~~~~~~~~~~~~~~~~~~~

       + CategoryInfo         : InvalidOperation: (:) [], RuntimeException

       + FullyQualifiedErrorId : NullArrayIndex

    Does anybody have an idea what this could be?

    I tried going through windows and impersonation options as well as autodiscover.

    the result Always ends up the same.

    The IR does get created in SCSM, but the script ends in error..

    Many thanks!

  • Adam_DzyackyAdam_Dzyacky Customer Contributor Monkey ✭✭✭✭✭
    edited October 2019

    Hey there @Filip_Theyssens - assuming you're running the script manually as the SCSM workflow account then I think I'm beginning to sense a theme here...

    This was originally brought to attention from @Brad_Zima on 141. Most recently with @Kenneth_McMichael on 151 as he's shared the error as part of a different issue being investigated, but he's NOT using the multi-mailbox feature. It sounds like you too also have this disabled given your new pristine environment.

    From what's being described here in that New Work Items are created successfully but this error shows up. It sounds like (haven't tested/confirmed) a lack of error handling on part of the connector that is invoked from New-WorkItem specifically on this line.

    The function is entered but then has an issue within Get-TemplatesByMailbox on/near the line you reference, the error is thrown, processing resumes back within New-WorkItem, the logic check is hit for "Mailbox Redirection" and since it's disabled isn't used. New-WorkItem then goes about it's business creating a New Work Item and the process repeats.

    I'm currently trying to wrap up the MP for v2, but I think you've helped me answer and understand what appears to be a visual annoyance.

  • Filip_TheyssensFilip_Theyssens Partner IT Monkey ✭

    hi @Adam_Dzyacky,

    thanks for your reply.

    actually I'm running it under my admin account which is full admin in SCSM.

    I'm also not using the Multi-Mailbox feature.

    Is this something I can safely ignore then?

    Do you intend on looking into this error condition?

    BEsides this error I shared here above, I also get an error where the script is trying to go and lookup the CiresonPortal.

    In the new SCSM the Cireson Portal will not be deployed, nor did I enable any lookup towards the portal in the script.

    Is the Ciresonportal a prerequisite for using the smlets exchange connector?

    Thanks again!

  • Adam_DzyackyAdam_Dzyacky Customer Contributor Monkey ✭✭✭✭✭
    edited October 2019

    Hey there again @Filip_Theyssens -

    actually I'm running it under my admin account which is full admin in SCSM. That will be a problem as it needs to run as the SCSM Workflow account that is attached to the inbox. Running it as your own account that isn't the mailbox generally produces errors.

    I'm also not using the Multi-Mailbox feature. Is this something I can safely ignore then? While I haven't tested to 100% confirm this, from what I'm seeing it looks that way.

    Do you intend on looking into this error condition? Yes. Right after I can wrap up the v2 management pack.

    Is the Ciresonportal a prerequisite for using the smlets exchange connector? No it isn't. I know you said you don't have it enabled, but it looks like you've do. I say that because the URL that's being shown in the error is the default one included with the connector. If it's truly disabled, then this would be a separate issue that needs to get looked at.

  • Filip_TheyssensFilip_Theyssens Partner IT Monkey ✭

    Hi @Adam_Dzyacky ,

    To clarify, I run the script with my admin account; but within the script I have the useraccount embedded for the mailbox:

    Here is how the Cireson bits are configured in the script (default settings):

    Where do I need to disable the Cireson integration from here?


  • Adam_DzyackyAdam_Dzyacky Customer Contributor Monkey ✭✭✭✭✭

    @Filip_Theyssens - hrm...

  • Filip_TheyssensFilip_Theyssens Partner IT Monkey ✭
    edited October 2019

    hello @Adam_Dzyacky

    I'm trying to create notifications using subscription or event configuration workflows.

    none of them seem to be running on the tickets created by the exchange connector.

    if I create an IR from the same IR template but manually, then these workflows trigger immediately and I receive an email notification.


    could it be that the above errors create the IR but in an 'incomplete' way, causing the workflows to not pickup these IR's?


  • Adam_DzyackyAdam_Dzyacky Customer Contributor Monkey ✭✭✭✭✭

    The subscription criteria we use @Filip_Theyssens is...

    When an Incident is Created with a Status of Active

    This handles an Incident created from the console, portal, and either Exchange connector.

  • Brad_ZimaBrad_Zima Member IT Monkey ✭

    Congrats man! I'm definitely going to give this a spin in my dev environment.

  • Filip_TheyssensFilip_Theyssens Partner IT Monkey ✭

    Hi all,

    I was wondering if following functionality is already in the connector:

    After a ticket gets created, a mail is sent to the user to notify him of his IR number and that we'll contact him etc. Unfortunately we have now hit a scenario where the mail we sent triggers an auto reply as well.

    This afternoon we had about 500 tickets created as the autoreply doesn't reply to our Original message containing the IR number in the title.

    Is there any logic in the Exchange connector to stop processing mails from a certain address if more then X mails have been received in X time?

    This could be considered a spam protection.

    Thanks !

    P.S.: sorry if I overlooked this feature in the documentation

  • Adam_DzyackyAdam_Dzyacky Customer Contributor Monkey ✭✭✭✭✭
    edited December 2019

    I suppose the question here is does that other email that is sending the auto-reply have any defining characteristics in its subject?

    I've actually dealt with something similar around 3rd party ticketing systems where the external system also drops the SCSM Work Item from the subject, but then uses its own proprietary identifier which can then be used for a match condition within SCSM. This requires introducing new regex matching patterns that you'd have to add after every upgrade and a class extension to the primary work item types. How to set this type of integration up is over here on the wiki.

    Another possible option is leveraging the Merge Replies feature that attempts to reconcile an email reply that does not have the [Work Item] in the subject to the correct work item via Exchange Conversation ID. This requires that emails are attached to Work Items and that the subject is something to the effect of "RE:" but doesn't have any Work Items contained in it.

  • Adam_DzyackyAdam_Dzyacky Customer Contributor Monkey ✭✭✭✭✭
    edited January 2

    Time to wrap the year up with v1.6.1 and v2.0.1.

    Take performance: The keyword has been refactored across all the Work Item types so that the optional Support Group membership is tested only when it's enabled. This results in ever so slightly faster processing.

    Manual Activity enhancements: Just like the stock connector, MAs can now be controlled by anyone while still preserving functionality introduced by the SMLets Exchange Connector. They've also joined the syntax of all other Work Item types nested inside Update-WorkItem so in the event you want to customize actions per User Relationship type (Implementer vs. Anyone) you can!

    These releases also addressed a few bugs raised here in the thread around browser compatibility with the Schedule Outlook Meeting Portal Task and Suggest KA/RO errors even when it's disabled. However there are currently 2 recently Pinned GitHub Issues looking for further discussion and solutioning -

    • Dynamic Analyst Assignment - Looking for anyone here who might be able to lend a hand in troubleshooting and/or could chime in with a "it works for me" or "it doesn't work for me" over on the GitHub issue.
    • Multi-Mailbox feature with Distro Groups - If any secondary mailbox received the message via a distribution group the respective template fails to apply. There is a lot of discussion going on and opportunity to innovate.

    2020 Road Map:

    Apart from the above, if there is one thing I hope this past year's releases demonstrated. It was a push to Azure Artificial Intelligence integrations to make the connector and in turn SCSM, smarter.

    Language translation between users to lower the communication barrier and Machine Learning to predict with increasing accuracy IR or SR as the Default Work Item. Even before than that, using Sentiment/Keyword Analysis to drive Work Item Priority or search results. All in the name of saving time where at all possible. Which is why the next item on the list, is the most relevant - predicting emails that are about a Configuration Item. Thereby enforcing or at the very least guiding your own internal processes around Incidents, Service Requests, Problems, and Changes.

    Of course there is more than just Azure AI functionality - more portal integration (watchlist) and providing direct PowerShell examples of how to take advantage of the Custom Events with your own logic if you're just getting started.

  • Brad_ZimaBrad_Zima Member IT Monkey ✭

    I'm currently working on setting up the RO suggestion feature and I have the connector able to connect to the portal and the test script is returning suggestions however the connector itself is returning an error about the "BodyType" property not being found. I'm assuming there may be some additional configuration needed to set up the response templates but I cannot seem to find any documentation, could you point me in the right direction?

  • Brad_ZimaBrad_Zima Member IT Monkey ✭

    Thanks for the link, unfortunately I'm still getting the BodyType error and I can't seem to figure out why. I've included the whole error message below if that helps.

    The property 'BodyType' cannot be found on this object. Verify that the property exists and can be set.

    At C:\smletsExchangeConnector\smletsExchangeConnector_modified.ps1:2197 char:5

    +    $emailToSendOut.Body.BodyType = $bodyType

    +    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

       + CategoryInfo         : InvalidOperation: (:) [], RuntimeException

       + FullyQualifiedErrorId : PropertyNotFound

  • Adam_DzyackyAdam_Dzyacky Customer Contributor Monkey ✭✭✭✭✭

    Yup! I know the exact section/flow you're referring to here. It's...

    1. New-WorkItem
    2. $ciresonSuggestionURLs = Get-CiresonSuggestionURL
    3. As long as there are suggestions to send, call Send-CiresonSuggestionEmail
    4. Send-EmailFromWorkflowAccount

    The error your citing is happening within Send-EmailFromWorkflowAccount function, suggesting that BodyType is not a valid property on the Exchange Message Class. And that isn't entirely clear to me how that's possible because the Exchange Web Services DLL that's loaded to process mail in the first place makes all of those things available. I have suggestions running...hrmm....what version of Web Services are you using? 1.2? 2?

    I won't call smletsExchangeConnector_modified.ps1 into question just yet. 😀

  • Brad_ZimaBrad_Zima Member IT Monkey ✭

    We are using EWS version 1.2 in an Exchange 2016 environment.

    Don't worry too much about the _modified, it just means I have the workaround for issue 141 installed ;-)

  • Brad_ZimaBrad_Zima Member IT Monkey ✭

    Just wondering if you had some additional thoughts on this? When I run the test script, I get some results from the Cireson portal, so there are suggestions to be had. I just can't figure out why BodyType is invalid. We are using EWS 1.2 on that server. I'm working on testing on our Dev server now to see if I have the same issue.

  • Jamie_JordanJamie_Jordan Customer IT Monkey ✭

    Has anyone been able to get this exchange connector to work with O365 when basic authentication is disabled? We recently moved to O365 and our exchange team has disabled basic authentication because of security concerns so I'm unable to get either the Microsoft exchange connector or this SMLets connector to work correctly anymore. They both return a 401 Unauthorized error. Microsoft plans on disabling basic authentication for O365 later this year so at some point I expect they will release an updated version of the connector. But I don't have the option of waiting as email is our primary way users contact IT.

  • Adam_DzyackyAdam_Dzyacky Customer Contributor Monkey ✭✭✭✭✭
    edited February 10

    Has anyone been able to get this exchange connector to work with O365 when basic authentication is disabled?

    I doubt it will work as this connector probably makes similar calls to the stock connector. I recently created an official GitHub issue for it to track progress. It is my plan to begin work on the OAuth for this within the next month. But I always welcome help if anyone can help expedite this along! This is a high priority for the SMLets Exchange Connector as the clock is ticking for October 13th, 2020 and I know a number of deployments have chosen this over the stock connector.

    Microsoft plans on disabling basic authentication for O365 later this year so at some point I expect they will release an updated version of the connector.

    I expect the same as well. But don't forget, it's not just the Microsoft SCSM Exchange Connector that has to get updated to sort this. It would also have to be the Microsoft SCO Exchange Integration Packs as well!

    Also - thanks for the back n forth PMs @Brad_Zima so we can work this out. Excelsior!

  • Brian_WinterBrian_Winter Customer Adept IT Monkey ✭✭

    @Adam_Dzyacky said:

    "Default Resolution Categories: A gap in the native Exchange Connector is that if an Incident gets [resolved] the Resolution Category is left blank. Now you can optionally set a default Resolution Category on Incidents/Problems and Default Implementation Results on Service/Change Requests"

    Any thought to provide a set of keywords to set the Resolution Category from the inbound Resolved email? I'm not happy with a single, generic resolution category.


  • Adam_DzyackyAdam_Dzyacky Customer Contributor Monkey ✭✭✭✭✭
    edited March 17

    I actually considered it at the time @Brian_Winter! The thing was maintaining the custom keyword list per Resolution Category entirely in PowerShell felt as though it had the potential to become cumbersome given everyone's lists could be the different. Again - at the time. But now that a management pack exists to store settings, I suppose it's something that could be back on the table. 😁

    Second for those wondering. OAuth token support is now currently working in a development capacity. While it's not part of the connector just yet, I feel confident the SMlets Exchange Connector will be well prepared for Microsoft's October 13th deadline.

Sign In or Register to comment.