Home Community Uploads
image

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.

An SMlets based Exchange Connector

124678

Comments

  • Adam_DzyackyAdam_Dzyacky Product Owner 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 Product Owner 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 Product Owner 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?

    Thanks!

  • Adam_DzyackyAdam_Dzyacky Product Owner 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.

    (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!

  • Adam_DzyackyAdam_Dzyacky Product Owner 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 Advanced 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 Product Owner 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 Product Owner Contributor Monkey ✭✭✭✭✭
    edited January 2020

    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 Advanced 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?

  • Adam_DzyackyAdam_Dzyacky Product Owner Contributor Monkey ✭✭✭✭✭
    edited January 2020
  • Brad_ZimaBrad_Zima Member Advanced 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 Product Owner 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 Advanced 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 Advanced 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 Product Owner Contributor Monkey ✭✭✭✭✭
    edited February 2020

    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 Advanced 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.

    Thanks!

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

    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.

  • Adam_DzyackyAdam_Dzyacky Product Owner Contributor Monkey ✭✭✭✭✭

    Well hey there 2020. I'd say it's about time for the next minor upgrade of SMLets Exchange Connector with v1.7 and v2.1!


    Watchlist Integration: Now Cireson customers can [watch] and [stopwatch] Incidents, Service, Problems, and Change Requests through the brand new configurable keywords. Don't forget you can create HTML mailto links to give users a one-click mail experience from any email client. Want this functionality for something outside of email? As always, the PowerShell functions are yours for the taking!


    These releases also patched a bug around suggestions that only occurred if you attempted to use Suggest KA or Suggest RO by themselves (you were not affected if you had them both turned on). As well as an environment based issue when the connector sends suggestions out through EWS. Both fixes deserve a thanks that go out to @Brad_Zima for his time, contributions, and being excellent this front. Thank you for righting my wrongs and making the connector better!

    Speaking of EWS, once again the highest priority right now for the connector is ensuring a smooth transition into OAuth tokens as the retirement of Basic Authentication for Office 365 approaches. While the most core of functionality appears to be functional, what currently remains is identifying the most appropriate place to store/reference credentials as depending on where you run the connector from these items will either be easy or slightly challenging to obtain.


    Finally - apart from preparing for the deprecation of Basic Authentication. A longer term goal presents itself in the form of the Microsoft Graph. Utilizing the Graph not only can the connector continue to retrieve email like it does today. But it opens the door to a host of brand new Office 365 experiences for Service Manager with access to things like SharePoint, Teams, OneNote, Intune, OneDrive, and completely removes the dependency on the Exchange Web Services DLL file. All in all, some very interesting possibilities lie ahead.

  • Ryan_Kennedy1Ryan_Kennedy1 Customer IT Monkey ✭

    Hi @Adam_Dzyacky

    Great work with this connector, it looks really cool!!

    I am in the process of setting it all up and reckon I have got there now :)

    Just a few things I noticed throughout setting it up which I'm not sure if it's just my lack of understanding of the script / my environment or if somethings have to be fixed up in your script.

    I have set it up to connect to EWS and use email impersonation. I have given it the credentials of our workflow account (without an email address attached to it) which has full access to the Service Manager mailbox. In order to get this to work I had to change a few lines (around line 3352) from :


    #define search parameters and search on the defined classes

    $inboxFolderName = [Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Inbox

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


    to :


    #define search parameters and search on the defined classes

    $inboxFolderName= new-object Microsoft.Exchange.WebServices.Data.FolderId([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Inbox,"EMAIL@DOMAIN.COM") 

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


    Perhaps there could be another variable within your script for if the impersonation is connecting to a different mailbox?


    Also, at the bottom of your 'Get-TemplatesByMailbox' function you have :

    "return $Mailboxes[$ScsmEmail]"

    However, $ScsmEmail is not defined anywhere within the script and gives the following error :


    Index operation failed; the array index evaluated to null.

    At E:\Scripts\IN PROGRESS\smletsexchangeconnector-master\smletsExchangeConnector.ps1:2579 char:17


    I changed $ScsmEmail to $workflowEmailAddress and this fixed the error. This is the var that should have been in there?


    Again, great work and look forward to further updates in the future :)

  • Ryan_Kennedy1Ryan_Kennedy1 Customer IT Monkey ✭

    Actually .. It is not working 100% .. Using impersonation with the credentials of my account there are no issues, trying it with our workflow account, running this line :


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


    I get 'Exception calling "Bind" with "2" argument(s): "Access is denied. Check credentials and try again."'

    Both my account and the workflow account do have access to the mailbox though.. The only difference I can see is that my account has an email attached to it, the workflow account doesn't ... Can anyone help with this?


    Also, one other thing I had to change in the script to get it to work was I had to replace all the "$message.To" and "$message.Cc" properties with "$message.ToRecipients" and "$message.CcRecipients" as To and Cc didn't appear as properties..

  • Adam_DzyackyAdam_Dzyacky Product Owner Contributor Monkey ✭✭✭✭✭

    Hey there @Ryan_Kennedy1. Alright so a bit to unpack here:

    I have set it up to connect to EWS and use email impersonation. I have given it the credentials of our workflow account (without an email address attached to it) which has full access to the Service Manager mailbox

    If you're using the workflow account and giving it credentials for impersonation - why not just use native windows auth? It's been awhile since I've used impersonation, so it's possible I'm missing something really obvious here so i'd have to defer to wider group of folks using it here.

    Also, at the bottom of your 'Get-TemplatesByMailbox' function you have :

    "return $Mailboxes[$ScsmEmail]"

    However, $ScsmEmail is not defined anywhere within the script

    I believe this is known. I suspect @Tom_Hendricks can keep me honest here though.

    I get 'Exception calling "Bind" with "2" argument(s): "Access is denied. Check credentials and try again."'

    I'd be curious if you start up ISE/Code as the workflow account and run the script with Windows Auth if you still get this.

    Also, one other thing I had to change in the script to get it to work was I had to replace all the "$message.To" and "$message.Cc" properties with "$message.ToRecipients" and "$message.CcRecipients" as To and Cc didn't appear as properties..

    Now that is beyond strange to me. At a high level the connector first connects to the Exchange Inbox, grabs all of the Exchange Messages, and then in the core processing loop essentially converts the Exchange Message object to a custom PS Object with significantly trimmed down properties and ones that have been renamed for use in the rest of the SCSM based functions. There should genuinely be no reason you have to do this.


    If you have more questions feel free to message me or raise a question on GitHub.

  • Tom_HendricksTom_Hendricks Customer Super IT Monkey ✭✭✭✭✭

    @Ryan_Kennedy1 and @Adam_Dzyacky

    Regarding EWS connection with impersonation, I am connecting the same way as you. Windows auth isn't a good option for me, unfortunately. This should work for you, though.

    Is it safe to assume that you are getting the access denied exception when making this connection to EWS? If so, I would start looking at how you are passing the username and the password over to it. i.e., are you expressing the user in the [DOMAIN]\[USERNAME] format? If you are using a PS credential, are you properly extracting the password from it?

    Regarding Get-TemplatesByMailbox, it looks like you discovered a typo. $scsmEmail should be $workflowEmailAddress. $scsmEmail is part of some custom work on my script and should not have entered into the main copy. $workflowEmailAddress gets set equal to $scsmEmail at the top of mine, so for me it would test successfully either way, but not so much on yours. Sorry about that!

    Regarding the TO/CC properties, I'm with Adam. While the object's properties are ToRecipients and CcRecipients internally, the resulting PS Object will have To and Cc as properties, populated from the longer ones. If we have a discrepancy here, then I think comparing EWS library versions might be the next step.

  • Ryan_Kennedy1Ryan_Kennedy1 Customer IT Monkey ✭

    Thanks for your response @Adam_Dzyacky / @Tom_Hendricks

    I get the access denied error on this line :

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

    Remembering that I had added that line in / changed this line in the original code :

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

    as it was erroring as the service account didn't have a mailbox attached to it ..

    Exception calling "Bind" with "2" argument(s): "When making a request as an account that does not have a mailbox, you must specify the mailbox primary SMTP address for any distinguished folder Ids."


    Pretty sure the password is getting passed through correctly, because if I change it to an incorrect password, instead of the Access Denied error I get

    Exception calling "Bind" with "2" argument(s): "The request failed. The remote server returned an error: (401) Unauthorized."


    I don't know why I am using impersonation instead of windows credentials ... lol, it's just how I set it up.. What issues did you have using windows credentials Tom? I ran powershell as the service account, changed the authentication type to windows and get the same Access is Denied error ...


    It really is looking like Access is just denied to the Inbox .... But that is the account we are currently using in the default Microsoft Exchange connector and I can also run outlook as the service account and connect to the mailbox and have full access to the inbox ..

    Any more ideas?

Sign In or Register to comment.