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 1

    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 10

    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 10

    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 11

    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 22

    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.

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

    Version 2.0 of the SMlets Exchange Connector has arrived on GitHub!

    Settings Management Pack: Since the very first version of the SMLets Exchange Connector, one issue has always stood out against all others. "Every upgrade, I have to reset all of the configuration values to what I previously had." With an ever growing list of configuration possibilities (over 120!) the last couple years, this has become a bit of a trying experience that I am completely understanding of. So after research, republishing Travis Wright's original post on the topic so that ANYONE of ANY skill level can understand how to construct such a thing - we now have a management pack to store configuration settings required to make the SMLets Exchange Connector work that will preserve changes throughout upgrades of this PowerShell based connector.

    The plans right now are to run both v1 and v2 releases side by side. So in the event you're not ready to move forward just yet, that's okay. Both versions will continue to see releases for now.

    What started around 1000 lines/60kb and introduced things like the [Take] keyword, Minimum Attachment File Size, and a couple features over the stock connector has transformed over the last few years into 3500+ lines/250kb with integration to Azure Artificial Intelligence, the Cireson SCSM Portal, Multi-Mailbox handling with significant performance gains and 20+ features over the stock connector! I am truly grateful to everyone who has contributed code, shared their passerby thoughts, reported bugs, raised requests, forked/starred the repo, and of course - deployed this in their own environments.

    That about wraps it up for now. In which case, forward!

Sign In or Register to comment.