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.
Cireson does not and will not support or maintain these enhancements, extensions, and scripts.
For Team Cireson uploads click here.
@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.
Can you verify you're running Windows PowerShell 5.1 and the latest version of SMLets which should be v1.x.x.x?
Is PowerShell 5.1 required for v3? That could my issue. We're on PowerShell 4.something.
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.
I've checked and PS is version 5.1.xxx and SMLets is (Don't know where to look...):
The version shows 0.1.0.0
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?
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.
@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?
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.
It's time for SMLets Exchange Connector v3.4!
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.
New System Center on the horizon.
New SMLets Exchange Connector with the arrival of the next major release that is v4.0!
Let's talk about this in practice:
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:
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.
I almost let April wrap without acknowledging the 5th anniversary of the SMLets Exchange Connector and mentioning that v4.1 is now available!
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.
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/
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:
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?
@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.
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
@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.
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.
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...
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.
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.
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:
I have installed the latest version (220.127.116.11) 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.
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.
Cannot get SMLetExchange v18.104.22.168 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=22.214.171.124, 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.
@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).
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:
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.
@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?
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.