
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.
DISCLAIMER
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.
Comments
I think this would require two separate changes @Gabriel_Lences. But only one of them really falls into the connector's scope -
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:
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!
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.
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!
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.
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?
Thanks!
@Filip_Theyssens - hrm...
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.
(https://social.technet.microsoft.com/Forums/systemcenter/en-US/5d3f1767-6d72-48a0-af4b-5f80b2d6f7cf/scsm-2019-notifications-arent-send-for-tickets-created-by-exchange-connector?forum=administration)
could it be that the above errors create the IR but in an 'incomplete' way, causing the workflows to not pickup these IR's?
Thanks!
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.
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!
Congrats man! I'm definitely going to give this a spin in my dev environment.
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
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.
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.