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

123457

Comments

  • Adam_DzyackyAdam_Dzyacky Product Owner Contributor Monkey ✭✭✭✭✭

    @Joakim_Normann - if you need to create a Run As Account, just open up any other connector you currently have configured and you'll see a "New" option within them. SCSM will automatically place it in a correct management pack. Once the account is created you can edit it afterwards from the "Run as Accounts" section and of course use it within the Settings UI for the connector.

    @Matt_Overton what configuration within the script? v2.x, v3.x, and v4.x should not require any editing of the PowerShell. But if I've missed something lets get it updated! Feel free to DM me or open a Pull Request 😁

  • Joakim_NormannJoakim_Normann Customer Adept IT Monkey ✭✭

    @Adam_Dzyacky creating a specific Run As account for the mailbox in the way you described worked perfectly. Using that account got the connector working. Thank you so much for the help.

  • Matt_Howard1Matt_Howard1 Customer Adept IT Monkey ✭✭

    Saw this article yesterday and was curious if the SMLets Exchange Connector is affected by this change to Remote PowerShell: https://office365itpros.com/2022/12/19/remote-powershell-deprecation/

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

    Remote PowerShell for Exchange is all about managing Exchange infrastructure, for example:

    • Creating/modifying Transport Rules
    • Creating/modifying Mailbox properties such as aliases, retention policies, etc.
    • Configuring mailflow

    etc. etc.

    Whereas the Exchange Connectors for SCSM are all about interacting with a user's mailbox via the Exchange Web API.


    So to answer your question. No, the SMLets Exchange Connector is not affected by this. 😁

  • Matt_Howard1Matt_Howard1 Customer Adept IT Monkey ✭✭

    Thanks Adam, I think the Web Services API was more the point I was concerned about. With all of the push to the Graph API, I wonder if the EWS API will go away or be reworked.

  • Adam_DzyackyAdam_Dzyacky Product Owner Contributor Monkey ✭✭✭✭✭
    edited January 2023

    Hope you're rested and ready to roll because SMLets Exchange Connector v5 is out! 😁


    • Multiple Keywords: You can now configure multiple keywords per keyword configuration. Now why would you do this if you've already templated responses? MAYBE you want to have multiple languages per keyword. MAYBE you want to have "secret" keywords only known to select individuals or MAYBE you want to update your templates to have multiple choices that lead to ever so slightly different outcomes. For example, [approved] may complete a Review Activity. But using [asap] the Review Activity would be completed and the subsequent Manual Activities priority is raised to Immediate. Check out the example here.


    This release also brings with it several bug fixes and optimizations such as:

    • refactoring of several functions used throughout the connector that improve their respective and overall performance
    • logging that is far more representative of the start, process and finish stages of the connector
    • continued adherence to PowerShell best practices per PSScriptAnalyzer and C# best practices per CodeFactor
    • addresses an incredibly specific bug wherein if a user's email address contains a PowerShell comparison operator (e.g. -le, -ge, -gt, etc.) then the user is failed to be identified by the connector

    And that incredibly specific bug above that I could not have found without those who made their voices heard on the GitHub repository. Like @Alexander_Axberg who introduced more logging functionality when connecting to M365 and improving Work Item creation so the native SCSM console search respects items created via the connector. 👍️


    As always, thanks to everyone for their contributions, continued support, and usage of the SMLets Exchange Connector.

  • Joakim_NormannJoakim_Normann Customer Adept IT Monkey ✭✭

    @Adam_Dzyacky I upgraded the Exchange connector from a very old version to version 5. I have followed all the instructions, but for some reason the connector won't start. I have created a Run As account with the credentials for our production mailbox and choosen that one in the settings.

    Do I need 2 separate Tenant and Application/Client ID? One for Test and another for production?

    It works fine in our test environment with the same version of the connector. I'm using the same Tenant and Application/Client ID's for production as I use for Test.

  • Konstantin_Slavin-BoKonstantin_Slavin-Bo Customer Ninja IT Monkey ✭✭✭✭

    @Joakim_Normann

    You only need separate IDs, if you have multiple tenants. If you just have a single Azure tenant, and you application has the correct access, then you can reuse that app across SCSM environments. If you use different service / mailbox accounts for the environments, you'll of course need to give permissions for the app to access the mailbox of the relevant accounts (as shown Step 7 in Scenario 3 here: https://github.com/AdhocAdam/smletsexchangeconnector/wiki/Configuration-Examples).

    Do you new mailbox account also have the correct permissions in SCSM?

  • Joakim_NormannJoakim_Normann Customer Adept IT Monkey ✭✭

    @Konstantin_Slavin-Bo

    Thanks for the response.

    We use the same Service Account for the WorkFlow account in both Test and Prod.

    Have I understood it correctly that the service account need to have access to both mailboxes in order for the connector to work in both enironments?

  • Konstantin_Slavin-BoKonstantin_Slavin-Bo Customer Ninja IT Monkey ✭✭✭✭

    Have I understood it correctly that the service account need to have access to both mailboxes in order for the connector to work in both enironments?

    Yes, the workflow account needs access to the mailbox, from which it's supposed to fetch mails. If the workflow account itself does not have a mailbox, but have FullAccess rights to another mailbox, I'm guessing that you'll need to use impersonation to access the mailbox, although I'm not awfully familiar with this configuration.

  • Adam_DzyackyAdam_Dzyacky Product Owner Contributor Monkey ✭✭✭✭✭

    ...the service account need to have access to both mailboxes...

    This comment has given me some pause, but @Konstantin_Slavin-Bo is already heading in the right direction. If the Run As Account is accessing the inbox of another account, then the Run As Account needs Exchange Impersonation rights to do so.

    This configuration isn't impossible and I know people out there do it, but it does require a little bit more thought to map out from an Exchange permissions perspective as it's not the kind of permission you want to accidentally overprovision. Because as the name implies, you're giving another account the ability to Impersonate another one entirely within your organization.


    You can read more about this permission on Microsoft Learn over here - Exchange ApplicationImpersonation Role.


  • Konstantin_Slavin-BoKonstantin_Slavin-Bo Customer Ninja IT Monkey ✭✭✭✭

    Now that you're here @Adam_Dzyacky, I'd like to say thanks for a great piece of work - we finally made the jump to your SMLets EC, because our org finally shut down basic auth last October, and I love it.

    I remember having some reservations regard error handling and logging, but a lot of work have been done on those fronts since then. Especially in v5, pretty much every step is logged, which really help troubleshooting and gives a peace of mind.

    I do have some ideas for improvement, primarily regarding modularization (and easier error handling), mainly born out of our needs for some specific functionality - but that's the beauty of OS; I can just start working on it and tweak it to our needs. If the quality ends up being acceptable, I can always submit a PR to your repo.

    Basically I'm just trying to say thanks to you and all the great contributers on this project 😎

  • Adam_DzyackyAdam_Dzyacky Product Owner Contributor Monkey ✭✭✭✭✭
    edited February 2023

    Appreciate the kind words @Konstantin_Slavin-Bo. Always great knowing this has helped someone out.

    I look forward to the Pull Requests


  • Joakim_NormannJoakim_Normann Customer Adept IT Monkey ✭✭

    @Adam_Dzyacky @Konstantin_Slavin-Bo Thanks for both your responses. The issue was resolved earlier this week. I had to uncheck Exchange Online in the settings, because the mailbox wasn't in the cloud. By doing that the connector worked perfectly afterwards.

  • Taras_KirillovTaras_Kirillov Member IT Monkey ✭

    @Adam_Dzyacky , Email does not attach to work item by using SMlets Exchange connector v5.0.0.29. Only attachment in email is attach to WI. Can you give me advice on how to fix this issue?

    Thank you in advance!

  • Joakim_NormannJoakim_Normann Customer Adept IT Monkey ✭✭

    @Taras_Kirillov Have you checked "Attach Email to Work Item" under Processing Logic in the Connector settings? I'm using v5.0.0.29 and for us the emails are attached properly to the work items.

  • Taras_KirillovTaras_Kirillov Member IT Monkey ✭

    @Joakim_Normann Of course yes. But olny attaches of on email are attach to work item. The email itself is not attached.

  • Adam_DzyackyAdam_Dzyacky Product Owner Contributor Monkey ✭✭✭✭✭

    As @Joakim_Normann has correctly stated, the only requirement here is to ensure that "Attach Email to Work Item" is enabled/checked off in the Settings UI. Beyond this, you would have to investigate event logs and/or debug runs of the connector yourself as to why you are experiencing this.

  • Sandra_ColeSandra_Cole Customer IT Monkey ✭

    Does anyone have a fix to only process emails from users in CMDB?

    Thanks in advance.

  • Daniel_Polivka1Daniel_Polivka1 Customer IT Monkey ✭

    @Sandra_Cole I chose to go the route of Exchange to handle inbound emails, instead of attempting to modify the connector, for two reasons. First, all the work is handled before it hits the SMLets connector, so you save it the effort of processing an additional unnecessary email. Second, Exchange is flexible, so you can easily add/remove processing logic like allow/deny domains and/or specific addresses. If I know a group of consultants will need to converse on work items, I'll go to Exchange and add @exampledomain.lcl to be allowed to send to my environment email. The same is true on the reverse, like the occasional Microsoft Digest email that is sent out. That was creating tickets for me, so I just blocked that particular Microsoft address from being able to email to my SCSM environment. If you do take this approach, try to close the gap as much as possible, and then add as needed, much like firewall best practices.

  • Sandra_ColeSandra_Cole Customer IT Monkey ✭

    @Daniel_Polivka1 Thank you for responding. We are currently using exchange rules to filter out known email addresses, but that means we are reactive weather then proactive. I was hoping to get a lead on a PowerShell script. My PowerShell scripting knowledge is very elementary.

  • Konstantin_Slavin-BoKonstantin_Slavin-Bo Customer Ninja IT Monkey ✭✭✭✭

    @Sandra_Cole

    I think @Daniel_Polivka1 is proposing to do it the other way around. You only allow internal addresses to reach the helpdesk inbox, thus creating a case. All others are relayed elsewhere. And if you then need to allow a specific external email address to be able to create a case, you can add that to an allow list.

    This will proactively stop all external emails from reaching the inbox, enabling you to allow other senders as needed.

  • Brad_ZimaBrad_Zima Member Advanced IT Monkey ✭✭✭
    edited February 2023

    I think the approach Konstantin outlined is a solid practice. It allows you to redirect the "rejected" emails to another mailbox for review so nothing gets missed, and allows for the flexibility of whitelisting addresses you do want to receive from. Consider that a lot of common names like "help", "support", "helpldesk" are probed by spam bots or the eventuality that your processing mailbox address gets onto a spam or marketing mail list.

    Adding code to the exchange connector to lookup a list of unknown length for each email received has the potential to add a lot of processing time to the script. Depending on the cost of the lookup for each CMDB object in the list this could become very expensive to efficiency.

  • Sandra_ColeSandra_Cole Customer IT Monkey ✭

    Thanks @Daniel_Polivka1 , @Konstantin_Slavin-Bo , and @Brad_Zima - you guys rock!

  • Taras_KirillovTaras_Kirillov Member IT Monkey ✭

    Email does not attached to work item because an error below:

    Does anyone can help me to fix this error? Thank you guys in advance!

    Email from xxx on IR22 could not be attached. System.Management.Automation.MethodInvocationException: Exception calling "Bind" with "3" argument(s): "The specified time zone isn't valid." ---> Microsoft.Exchange.WebServices.Data.ServiceResponseException: The specified time zone isn't valid.

      at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.ProcessWebException(WebException webException)

      at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.GetEwsHttpWebResponse(IEwsHttpWebRequest request)

      at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.ValidateAndEmitRequest(IEwsHttpWebRequest& request)

      at Microsoft.Exchange.WebServices.Data.MultiResponseServiceRequest`1.Execute()

      at Microsoft.Exchange.WebServices.Data.ExchangeService.BindToItem(ItemId itemId, PropertySet propertySet)

      at Microsoft.Exchange.WebServices.Data.ExchangeService.BindToItem[TItem](ItemId itemId, PropertySet propertySet)

      at CallSite.Target(Closure , CallSite , Type , Object , Object , Object )

      --- End of inner exception stack trace ---

      at System.Management.Automation.ExceptionHandlingOps.CheckActionPreference(FunctionContext funcContext, Exception exception)

      at System.Management.Automation.Interpreter.ActionCallInstruction`2.Run(InterpretedFrame frame)

      at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)

      at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)

  • Simon_ZeinhoferSimon_Zeinhofer Customer Advanced IT Monkey ✭✭✭
    edited March 2023

    Hello @Adam_Dzyacky ,

    after some considerations, digging into the wiki and reading the manuals, we are planning to finally switch to the SMLet Exchange Connector. Some things are not 100 % clear for me, so I thought I ask them here. Maybe you have the time to have a look =)

    1. In your manuals you state that the workflow should not be configured to run more often than every 5 minutes. In our environment, the main connector for the helpdesk runs every 2 minutes and I think reducing the cycle might be something my manager is not very happy about. We plan setting up the forwarding for at least 4 more mailboxes to the main malbox, so you think it would be possible to set the cycle to 2 or 3 minutes though?
    2. When configuring the main and additional mailboxes, it is required to set a template for IR,SR and PR and as well a work item type. Although we set the default templates for IR, SR and PR, will only the default work item type be created? Because we have mailboxes where strictly ONE SR type might be created out of it and I don't want it to create an Incident or Problem because of some logic in the script. Or are the additional templates only required in case of enabling cognitive service?
    3. We receive lots of "message could not be delivered" mails because of some external agents, which we are not able to send mails to via the internal subscriptions. With the OOTB connector these mails are not processed. How is the behaviour with the SMlet Connector? Will it skip these mails, and other "ootb mails sent from Outlook" too, or will it ceate work items from it?

    Thanks for the amazing work with the connector, I am looking forward activating it in our environment.

    EDIT: I had a look inside the script and point 2 is irrelevant now ;)

  • Taras_KirillovTaras_Kirillov Member IT Monkey ✭

    Hello @Adam_Dzyacky and all guys,

    I hope you are doing well :)

    After SCSM 2022 upgrade exchange connector v4.1 is stoped working. I found your greate tool made by you. All working perfect but emails does not attached to WorkItem. I found an error in Event log.


    I tried to use this instruction (https://community.cireson.com/home/leaving?allowTrusted=1&target=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F39467609%2Fthe-specified-time-zone-isnt-valid-using-ews-from-server) but I am newby to PowerShell :(

    Guys please give me an advice what exactly I should do to fix the error.

    I am stuck :(

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

    In your manuals you state that the workflow should not be configured to run more often than every 5 minutes. In our environment, the main connector for the helpdesk runs every 2 minutes and I think reducing the cycle might be something my manager is not very happy about. We plan setting up the forwarding for at least 4 more mailboxes to the main mailbox, so you think it would be possible to set the cycle to 2 or 3 minutes though?

    There are few reasons behind the "don't run this more than every 5 minutes"

    1. When the connector was originally created (v1), Task Scheduler only gave you the option to select every 5 minutes. Given all of the things you could configure/enable it just became more and more of a standard/safe bet
    2. Multi-Mailbox (v1/v2), is a fundamentally different approach to processing multiple inboxes. Rather than have multiple (stock) connectors, the SMLets Exchange Connector only has a single instance that combined with using Exchange Mailflow rules, allows you process multiple inboxes as a single inbox. This means that now a single inbox has more emails. In your case, it would have the volume of 5 total mailboxes. Maybe this is a lot more emails, maybe it isn't. In either case though, this results in significantly lower resource usage on the SCSM side, but it does mean processing time could grow based on the volume of emails to process. Somewhat related, this is why I've published Benchmarking with relevant versions
    3. When the connector transitioned to support SCSM Workflows (v3), there was not (and still not) any concept of the connector being "process aware" i.e. if a run is a occurring and a second run starts. The second run does not know the first one is running which could lead to duplicate Work Items. I've suspected (but I don't have anything concrete to prove) this is the same reason the stock connector has a generic warning in the configuration to only run the connector only so often. Related, it's the only connector that does not feature a "Sync Now" task.

    So with all of this said:

    • Could you set it to run faster than 5 minutes? Yes.
    • Could there be issues? Maybe.
    • The only way to get a definitive answer for your own environment is to test and evaluate.

    We receive lots of "message could not be delivered" mails because of some external agents, which we are not able to send mails to via the internal subscriptions. With the OOTB connector these mails are not processed. How is the behaviour with the SMlet Connector? Will it skip these mails, and other "ootb mails sent from Outlook" too, or will it ceate work items from it?

    They will not be processed and they have never been processed by any version of the connector

  • Simon_ZeinhoferSimon_Zeinhofer Customer Advanced IT Monkey ✭✭✭

    @Adam_Dzyacky Thanks for the answers :)

    I will have a look and will start with the config of 4 minutes.

    As for the 2nd part, good to know, so for me there are no arguments against the new connector :D

Sign In or Register to comment.