Home Community Uploads

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



  • VikVik Member IT Monkey ✭
    edited September 2021

    @Adam_Dzyacky , i was using the version 1.8 when i got that error and the script is set to "localhost" out of the box. Version 1.9 is giving me similar error (see below).

    It seems to be complaining from line number 2762

    Many thanks in advance.

  • Adam_DzyackyAdam_Dzyacky Product Owner Contributor Monkey ✭✭✭✭✭

    Can you verify you're running Windows PowerShell 5.1 and the latest version of SMLets which should be v1.x.x.x?

  • Nick_FlintNick_Flint Customer Advanced IT Monkey ✭✭✭

    Is PowerShell 5.1 required for v3? That could my issue. We're on PowerShell 4.something.

  • Adam_DzyackyAdam_Dzyacky Product Owner Contributor Monkey ✭✭✭✭✭
    edited September 2021

    It's possible their could be a pwsh versioning issue here, but I can't say this with certainty.

    The current notes on the connector cite PowerShell 4+ and were written at a time when that was the norm/there was the transitionary period into 5/5.1.

    ...but v1.x of the connector in a 2012x environment I feel like had no problems running it, however it's been awhile since I've worked on that version.

  • VikVik Member IT Monkey ✭

    I've checked and PS is version 5.1.xxx and SMLets is (Don't know where to look...):

  • Adam_DzyackyAdam_Dzyacky Product Owner Contributor Monkey ✭✭✭✭✭
    edited September 2021

    get-module smlets

  • VikVik Member IT Monkey ✭

    Thanks @Adam_Dzyacky

    The version shows

  • Joakim_NormannJoakim_Normann Customer Adept IT Monkey ✭✭

    I have a strange issue with the Exchange Connector. As far as I know, I only have this issue with one of our end users.

    When he replies to an email that we have sent from the portal or the Service Manager client, the email is getting processed in the mailbox and moved to the processfolder. On the workitem the email is attached, but his reply is not being added to the actionlog.

    I have looked at the emails he has sent and they look like they should and the subject of the email has not been edited. This issue is frustrating for the end-user, since he has replied to the email we've sent him, but we can't see his reply and the analyst is not being notified of his reply, since the response hasn't been added to the actionlog.

    Has anyone else experienced this issue or have a clue on what could be causing this?

  • Adam_DzyackyAdam_Dzyacky Product Owner Contributor Monkey ✭✭✭✭✭

    The first suggestion I'd have here is if you're on v3.x of the connector to turn up logging all the way, have him send a message, and then check the logs to see if the message is processing or if an error is thrown.

  • Joakim_NormannJoakim_Normann Customer Adept IT Monkey ✭✭

    @Adam_Dzyacky we are currently only on version 1.5, since it covers our needs at the moment, but when I have time in the future I will upgrade it to a newer version in order to get all the new functionality that has been added. Are there any logs for v1.5 or somewhere in the eventlog that I can look for clues?

  • Adam_DzyackyAdam_Dzyacky Product Owner Contributor Monkey ✭✭✭✭✭

    Are there any logs for v1.5 or somewhere in the eventlog that I can look for clues?

    Unfortunately there aren't in v1.x @Joakim_Normann. If you wanted to troubleshoot in the v1.x series of releases, you'd need to manually run the connector in ISE/Code as the mailbox account in question to see if PowerShell throws any errors.

    v3.x offers extensive logging out of the box along with the opportunity to introduce your own custom logging events as well.

  • Adam_DzyackyAdam_Dzyacky Product Owner Contributor Monkey ✭✭✭✭✭

    It's time for SMLets Exchange Connector v3.4!

    • Activity File Management: What if you could provide supporting evidence as the basis for Completing, Failing, Approving, Rejecting or Skipping an Activity? Just like any other Work Item in SCSM, File Attachments on emails for an Activity now make their way to the parent Work Item for easy reference. Not to mention continuing to respect the File Attachment settings that have been in the connector since day 1. My thanks go out to @Brad_Zima for the idea and executing on this!

    This release also introduces a few enhancements and fixes as they pertain to those using SCSM workflows to run the connector as well as improvements to how suggestions for Knowledge Articles and/or Request Offerings are made from your respective portals.

    And for those wondering, I have been working towards the next major release of the connector (aka v4) with plans to introduce wholly new ways to control email flows to and from SCSM.

  • Adam_DzyackyAdam_Dzyacky Product Owner Contributor Monkey ✭✭✭✭✭
    edited March 2022

    New year.

    New System Center on the horizon.

    New SMLets Exchange Connector with the arrival of the next major release that is v4.0!

    • Match any pattern and sync every external system: Do you have one or many vendors emailing you about their maintenance windows? their outages? How about a Microsoft invoice? What about other ticketing, project management, or other applications within your environment that can only send email notifications and you only wished could be synced with SCSM? Now you can control Work Items and Configuration Items, entirely through email!

    Let's talk about this in practice:

    • A Vendor you work with emails you about maintenance they'll be performing. They have their own Work Item ID like [MAIN#1234] they put in the Subject of the email. The SMLets Exchange Connector processes and creates CR87493. Further replies from the vendor about [MAIN#1234] will continue to update Change Request CR87493.
    • Your CRM sends alerts like [de77079f-0a41] in the Body of an Email. Create an Incident and continue to update it.
    • You receive emails in a non-standard Message Type such as IPM.Note.VoicemailMessage. Despite this difference, it shares almost everything in common with a normal email (IPM.Note). Process it like any other email and create a Service Request with its related attachments.
    • Your Hardware Supplier emails you about a purchase order or invoice such as #G84769243 that they put in the Body of the email. Creating a Work Item doesn't make much sense. But creating and updating a Cireson Asset Management Purchase Order/Invoice does! With Custom Actions you can now create and update any Configuration Item! Plus, keep all of your communications and attachments logged to it!

    But I know what you could be thinking. "This sounds awesome, but I'm not great at regular expressions." FRET NOT! Because as always, I have updated the Wiki to include a primer on building regular expressions for any combination of patterns you may want to match against regardless of your skill level. Plus I've also written extensive documentation with examples of Custom Events you may want to use with this feature, making your own particular customizations a copy and paste away.

    Best Practice: This release also features several changes that align the the connector's PowerShell to now fall in line with universally accepted PowerShell standards per PSScriptAnalyzer. A code checker that verifies the quality of work being presented is to PowerShell specification. As such - aliases has been removed, several functions/event logs have been renamed, and even $null comparison operations have been updated to meet PowerShell quality standards.

    Functions that have been renamed:

    • Attach-EmailToWorkItem = Add-EmailToSCSMObject
    • Attach-FileToWorkItem = Add-FileToSCSMObject
      • New functionality: Support for adding files to Configuration Items
    • Verify-WorkItem = Confirm-WorkItem
    • Schedule-WorkItem = Set-WorkItemScheduledTime
    • Create-UserInCMDB = New-CMDBUser
    • Apply-SCSMTemplate = Set-SCSMTemplate

    Boost Me: Finally, a subtle but noteworthy change in the connector is the utilization of [PSCustomObject] instead of New-Object that results in a performance gain of about 30%-40% which means the connector processes messages faster than ever before. Thanks go out to the newest contributor @Daniel_Polivka1 for this improvement and righting my wrongs!

    As has been the case since it's inception, the SMLets Exchange Connector continues to push the boundaries of what is possible with email all the while continuing to be free, open source, and granting administrators everywhere the ability to control everything not just in Service Manager - but their entire environment through email and PowerShell.

  • Adam_DzyackyAdam_Dzyacky Product Owner Contributor Monkey ✭✭✭✭✭
    edited April 2022

    I almost let April wrap without acknowledging the 5th anniversary of the SMLets Exchange Connector and mentioning that v4.1 is now available!

    • Azure Cloud Instance: If there is one thing that's been important to me with respect to the connector, it's been ensuring feature parity with the out of box connector. That's why just like the out of box connector, it now talks to Azure Public or Government clouds with a list picker as seen conditionally in the General, A.I., Translation, Vision, and Transcription UIs.
    • Form Updates: If you've been using Multi-Mailbox or Custom Rules, the horizontal scrolling involved on these UIs has been less than ideal to deal with. Which is why select screens now adjust with the overall resize of the Settings UI. Changes are also visible across the DLL, History, and About pages as well.

    This release also addresses a bug that pertains to suggesting Knowledge Articles and/or Request Offerings to users when they don't exist in SCSM.

  • Adam_DzyackyAdam_Dzyacky Product Owner Contributor Monkey ✭✭✭✭✭

    In case you missed Innovate 2022, there was a session that focused on a few different ways to integrate with Service Manager and specifically how SolarWinds Alerting was integrated entirely through the SMLets Exchange Connector!

    Check out the recording of "Can You Integrate It...? Yes You Can!" over at https://innovate.cireson.com/

  • Gerhard_GoossensGerhard_Goossens Customer Advanced IT Monkey ✭✭✭
    edited June 2022


    Our script stopped working (on 10 June) and I can't figure out what is the issue.

    Nothing has changed in our env or the script. I can manually log into the mailbox (and see 800+ unread emails) from the server hosting the script, so it's not credentials or connection issues

    I get the following error:

    PS C:\Windows\system32> C:\SCSM\ExchangeEmail\smletsExchangeConnector.ps1
    Exception calling "Bind" with "2" argument(s): "The request failed. The underlying connection was closed: An unexpected error occurred on a send."
    At C:\SCSM\ExchangeEmail\smletsExchangeConnector.ps1:3557 char:1
    + $inboxFolder = [Microsoft.Exchange.WebServices.Data.Folder]::Bind($ex ...
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
        + FullyQualifiedErrorId : ServiceRequestException
    Exception calling "FindItems" with "3" argument(s): "The element at position 0 is invalid
    Parameter name: parentFolderIds"
    At C:\SCSM\ExchangeEmail\smletsExchangeConnector.ps1:3600 char:1
    + $inbox = $exchangeService.FindItems($inboxFolder.Id,$searchFilter,$it ...
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
        + FullyQualifiedErrorId : ArgumentException

    This is the code lines from the error.

    35557 - $inboxFolder = [Microsoft.Exchange.WebServices.Data.Folder]::Bind($exchangeService,$inboxFolderName)

    36000 - $inbox = $exchangeService.FindItems($inboxFolder.Id,$searchFilter,$itemView) | where-object $inboxFilterString | Sort-Object DateTimeReceived

    We use impersonation to authenticate to https://outlook.office365.com/EWS/Exchange.asmx

    We use v1.9 and I have done a diff with v1.6 to check if a unwanted character sneaked into the code, but I cant see anything different in the area of the error.

    Do you perhaps have any suggestions that I can try, this is our production system and I really don't understand how the analysts only picked up the error now?



  • Brad_ZimaBrad_Zima Member Adept IT Monkey ✭✭

    @Gerhard_Goossens We had a similar experience about a year ago, suddenly the script stopped processing emails correctly, though I think our error message was different. We were on 1.6 I believe at the time and could only resolve the issue by turning off impersonation and using the account credentials to log in directly to the mailbox. This also helped prompt us to update to the 3.x branch of the script so we could store the credentials for the mailbox in the SM credential store for better password security.

    We were never able to successfully determine what happened but our best guess is that something changed during an update for Exchange 2016 that broke the way impersonation works with the script. Our errors were very intermittent, so it would process only a single email at a time before failing again. Took us the better part of a week to figure it out.

  • Gerhard_GoossensGerhard_Goossens Customer Advanced IT Monkey ✭✭✭

    I also suspect a Microsoft change that broke the impersonation option.

    The problem is that our SM env and the exchange runs on different domains, so not sure how to do cross-domain Windows authentication from PowerShell.

    I have heavily customized the script, so moving to the new 3.x branch is not an option, I think I have discussed it with Adam last year.

    I will poke around further on the intertubes.

    Thanks for the feedback


  • Adam_DzyackyAdam_Dzyacky Product Owner Contributor Monkey ✭✭✭✭✭
    edited June 2022

    @Gerhard_Goossens I've actually seen this come up several times (this year specifically). It's either a patch or an internal policy change that changes TLS to v1.2. Fortunately, forcing it in the connector is pretty easy. Just throw this at the top/first line of the connector.

    [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

    It's worth adding this was brought up on this discussion over on GitHub. It has relevant links for better managing TLS 1.2 within your SCSM environment as opposed to explicitly within the connector.

  • Gerhard_GoossensGerhard_Goossens Customer Advanced IT Monkey ✭✭✭
    edited July 2022

    Hi @Adam_Dzyacky , I missed your message, but just came to the same solution.

    I was busy re-writing the exchange connector to use OAuth instead of basic/impersonation and had issues installing the "MSAL.PS" module when I found this blog and the solution...


  • Tim_VottaTim_Votta Customer Adept IT Monkey ✭✭
    edited July 2022

    I am seeing warnings when attempting to setup the connector. I am using a bunch of mailboxes with redirects which seems to be working fine. If it hits an e-mail from anything that is not a known user I see events in the log saying "[email protected]" could not be matched to a user in SCSM. I have the checkbox enabled to "create users not found in CMDB."

    With the old SCSM Exchange Connector it would make the user in the CMDB and create the ticket for them automatically. I added another e-mail address to my user CI to match one of these and now it is properly creating the work item.

    It wouldn't be too bad but it is stopping processing of e-mails. Once an item comes in that is from a user not in the CMDB it won't process any items in the mailbox after that. I feel like there has to just be a setting somewhere that I am missing.

    Edit: I got it sorted like right after submitting this. Apparently checking "create users not found in the CMDB" was causing my issue. I don't really understand why I don't want that enabled though. I don't really care if they are in the CMDB or not, I just don't understand why trying to have it create the users was causing the problem.

  • Matt_OvertonMatt_Overton Customer Adept IT Monkey ✭✭

    Had a scare today as Microsoft disabled basic auth for our M365 tenant, breaking v.1.5.x of the connector we've been happily using for a long time now. Tried my best with the latest version of the connector, went down the route of installing the management pack and doing things via the UI, followed steps to set up an app in Azure and link it all up, but ultimately couldn't figure it out. Couldn't even get proper logging to work! All I could get was this repeatedly in the Ops Manager event logs:

    Tried digging through the wiki as much as I could, but all I could find was a reference to changing the username of the RunAs account in SCSM to use an email format - but that's impossible! As soon as I set it and enter the account password, it deletes the @ and everything following it! Then, naturally, fails to verify the account.

  • Adam_DzyackyAdam_Dzyacky Product Owner Contributor Monkey ✭✭✭✭✭

    I can only go off of so much given the error message above, but I'm led to believe there is a misconfiguration here. Please closely read the following walkthrough on the Wiki. Noteworthy items worth calling out:

    • You must be using EWS 2.2/latest. You cannot use EWS 1.2 as it doesn't support OAuth.
    • I'm fairly certain that error message is saying that the tenant ID is not a valid tenant ID as they are GUIDs (please do not post that GUID in the forum).
    • Make sure that the MP is not pointing at your v1.5 of the connector as OAuth doesn't even exist in that version.
  • Joakim_NormannJoakim_Normann Customer Adept IT Monkey ✭✭

    I have installed the latest version ( of the Connector. However when I run it, I get the following error message in the event viewer.

    Exception Message: The term 'Invoke-BeforeConnect' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. 

    I have setup the connector to run as the Workflow account.

  • Adam_DzyackyAdam_Dzyacky Product Owner Contributor Monkey ✭✭✭✭✭

    Do you have a file path defined for "Custom Events Path" in the DLL pane? Second, assuming you have something defined for the file path, does your Custom Events file actually contain (it should) the function Invoke-BeforeConnect? If you don't want to use Custom Events, just remove anything in that field and then save the Settings.

  • Sandra_ColeSandra_Cole Customer IT Monkey ✭

    Cannot get SMLetExchange v4.1.1.5 to process emails. Operation event log indicate file or assembly load failure.

    Description:A Windows Workflow Foundation workflow failed during execution.

    Workflow Type: SMLets.Exchange.Connector.Resources.RunScript 

    Workflow Identifier: 7bdb4c11-31b8-bf66-e2ef-54de5d109462 

    Exception Type: System.Management.Automation.MethodInvocationException 

    Exception Message: Exception calling "Verify" with "1" argument(s): "Could not load file or assembly 'BouncyCastle.Crypto, Version=, Culture=neutral, PublicKeyToken=0e99375e54769942' or one of its dependencies. The system cannot find the file specified." 

    I installed SMLetsexchange on our primary SCSM server.

    Disable the MS Exchange connectors

    This works in our test environment without an issue.

  • Joakim_NormannJoakim_Normann Customer Adept IT Monkey ✭✭

    @Adam_Dzyacky the function Invoke-BeforeConnect was present in the Custom_Events file, however we don't use it at the moment, so I removed the file path in the settings menu and I didn't receive the error again.

    However a new error message appeared when running the connector afterwards.

    Error: The address/SCSM Run As Account used to sign into 365 is not a valid email address.

    The setup we have is that the portal mailbox is connected to a separate mailbox account. The workflow account doesn't have an own mailbox, but we have given the workflow account access to that mailbox. Is it possible to run the connector with the workflow account to access another mailbox in order to process the emails in that mailbox?

    The RunAs logon credentials for the workflow account is specified with the User logon name (pre-Windows 2000).

  • Adam_DzyackyAdam_Dzyacky Product Owner Contributor Monkey ✭✭✭✭✭


    The workflow account doesn't have an own mailbox, but we have given the workflow account access to that mailbox.

    A couple things here. First, if the mailbox is on 365 I would recommend just configuring a Run As account with that accounts credentials and using that in the Settings. When the connector runs, it simply just uses those creds to authenticate.

    Second, it depends on how you are defining the word "access" here as it's an Exchange concept I see many (myself included) get confused with from time to time. The misunderstanding usually arises between the difference of:

    • Exchange Full Access permission
    • Exchange Impersonation Role

    In order for the Workflow account to control another mailbox as though it were its own. It must have the Impersonation role assigned to it. This is controlled via the Exchange Admin Center underneath Permissions or via PowerShell as seen here in Microsoft Docs. Then upon doing this, select the checkbox for "Use Impersonation" on the General tab of Settings.

    Finally, Run As Accounts attempting to authenticate to 365 per the error message must be stored in SCSM as their full domain (e.g. .com, .net. org, etc.). Typically shown in Run As Accounts in the form of domain.tld\user. If you enter the username as the email address SCSM will automatically save it in the right format as outlined here.


    Sounds like you're trying to read digitally signed/encrypted messages. That said, make sure that Mimekit.dll and BouncyCastle.Crypto.dll are placed in the same directory with one another.

  • Joakim_NormannJoakim_Normann Customer Adept IT Monkey ✭✭

    @Adam_Dzyacky How do I configure a Run As account for the email account? I don't have the option to create a new Run As account as an administrator in the Service Manager console. Is there any powershellscript to run in order to create a Run As account and if so, which MP should the account be created in?

  • Matt_OvertonMatt_Overton Customer Adept IT Monkey ✭✭

    Just thought I'd update to let you know with a little time to breathe and look at everything properly, I managed to get it working!

    The walkthrough is helpful to a point... I'd assumed that everything was now configured through the settings GUI in Service Manager and I no longer needed to even look at the .ps1 file. So it didn't work because I hadn't filled in any of the necessary configuration info within the Powershell script. I think something for dummies like me just to point people in the right direction could be a helpful inclusion within the wiki.

Sign In or Register to comment.