An SMlets based Exchange Connector

Adam_Dzyacky

To say the least @Taras_Kirillov, forcing a specific time zone for the connector is an untested scenario and not one I can shed much light on as it's not part of the normal setup. If you get this working, there is no way of guaranteeing what happens after that and what functionality (if any) is disrupted by said change. The only suggestion I can provide here is searching for and reading up on other PowerShell examples that connect to Exchange, Microsoft Docs, and experimenting. Here's one such blog - https://devblogs.microsoft.com/scripting/learn-to-use-the-exchange-web-services-with-powershell/

Simon_Zeinhofer

@Adam_Dzyacky two additional questions (Sorry) :

1) When I define e.g. one keyword "Declined" for reactivating a work item and one keyword "Closed" for closing it, and an Email has both of them in the body - What will happen? We have some users who are not able to klick on a link and then they answer to the Resolved Mail. Then both keywords are inside the mail. Has one keyword priority over the other? or do I have to define that in the script myself?

2) The connector offers the possibility to create a new Incident, when the Incident, which this should be applied to, is already closed. Will this happen with all comments? Because we have users who write a "Thank you" email, after the Incident has been closed. Or will this just be applied when the mail body contains the reactivate Keyword? Right now we have this logic inside an SCO Monitor runbook which monitors every new Action Log Entry and it would be awesome if I could replace that with the connector in built function :)

Taras_Kirillov

To say the least @Taras_Kirillov, forcing a specific time zone for the connector is an untested scenario and not one I can shed much light on as it's not part of the normal setup. If you get this working, there is no way of guaranteeing what happens after that and what functionality (if any) is disrupted by said change. The only suggestion I can provide here is searching for and reading up on other PowerShell examples that connect to Exchange, Microsoft Docs, and experimenting. Here's one such blog - https://devblogs.microsoft.com/scripting/learn-to-use-the-exchange-web-services-with-powershell/

@Adam_Dzyacky Thank you for your replay. Changing this to "English (US)" is resolved my issue.

Adam_Dzyacky

All good @Simon_Zeinhofer!

1. I might have to message you to make sure I get the full picture
2. A few things at play here depending on whether or not the [keyword] is used:
   1. If IR123 is isn't Closed, then it gets updated in that the Action log is appended to
   2. If IR123 is Closed then a New, Related Work Item gets created
   3. If the [reactivate] keyword is used on IR123 which is Resolved, it moves back to Active. If it was Closed, a New, Related Work Item gets created

Their is only one general point I wanted to clear up. You said:

or do I have to define that in the script myself?

It depends what you mean here, but nowadays I'd like to think there is very little reason to modify the core connector's logic. It could exist! But there are a healthy amount of Custom Events sprinkled throughout the connector that allow you to inject your own PowerShell Before/After a majority of key events and no less is preserved throughout upgrades without you having to manage your own copy/paste maintenance 😁

Simon_Zeinhofer

@Adam_Dzyacky with point 1 I meant the following:

In our company when a ticket gets resolved, the affected user receives an email with 2 "buttons" inside an email:

1) mailto:OURHELPDESKMAIL?subject=[IRNUMBER]&body=[declined] if he/she wants to reopen it.

2) mailto:OURHELPDESKMAIL?subject=[IRNUMBER]&body=[closed] if it shall be closed.

Some just see the mail subject "Your ticket has been resolved", and immediately respond that that's not the case. As we append the whole mail to the action log, the body of the mail contains both keywords, the close and reactivate. So my question here is, what will happen? ;) This is even a known issue in the ootb connector and Microsoft just states as workaround "Don't use both keywords in one email". So we rebuilt the whole mail with only the declined button and a link to the incident, in case the user wants to close it, what does not work so fine, as sometimes affected users see their incidents as archived. So I'd like to include both keywords again, with the reactivate keyword having priority over the closed keyword.

Point 2 was meant if the incident is closed and the mail sent to this incident does NOT contain the reactivate keyword - Is a new incident created? If yes we cannot go with that option, as users tend to send a "thank you" 2 weeks after the ticket got closed :D EDIT: After we switch to the new connector I tested it and with deactivating the "create new work item when closed..." in the settings the behaviour is exactly as we want it to be. When the reactivate keyword is present, a new workitem gets created, if not, the action log will be appended to the closed ticket and our SCO monitoring runbook fires. Don't know if that's intended but for us it is perfect :)

Today we did the step to switch our standard Helpdesk address to the smlet connector and after some try and error it works like a charm. :) Next week we will start activating the forwarding + multi mailbox processing. It's really amazing! :)

Maybe you could help me with the customevents. I use this script to change an incident if the affecteduser has the custom boolean VIP set to True. Unfortunately it just does nothing:

function Invoke-AfterCreateIR {
  # This function occurs after a new incident work item is created.
  if($affectedUser)
  {
    


    if($affectedUser.VIP -eq $true)
    {
        $newlyCreatedIR = Get-scsmobject -id $newWorkItem.__InternalId
        [string]$newDisplay = $newlyCreatedIR.DisplayName + " - VIP TICKET!!"
        [string]$newTitle = $newlyCreatedIR.Title + " - VIP TICKET!!"


        $vipProperties = @{


            Urgency = "VIP";
            Title = $newTitle;
            DisplayName = $newDisplay;
            IsVIPTicket = $true;


        }


        Set-SCSMObject -SMObject $newlyCreatedIR -PropertyHashtable $vipProperties -PassThru


    }
  
  }
}

Brad_Zima

@Simon_Zeinhofer To reply to your point #1, I've run into the same issue and the end result is that any response will trigger one of those two if the response body contains the original notification email.

You can work around this by disabling the "Include Whole Email on Action Log" which prevents the script from processing the entire message body in a reply. This change may have other implications for your organization though, so it is worth testing in a Dev environment and communicating with your users about as well.

Simon_Zeinhofer

@Brad_Zima thanks for the answer :) But if I do that and users reply, nothing will happen, as neither the declined, nor the closed keyword are present. Not that much of an issue though, I will just let it be that way :)

@Adam_Dzyacky I added some logging to every step of my invoke function and now I finally see that receiving the workitem via $newWorkItem.__internalId did not work. Now I receive it via the $irClass and a filter and everything works like a charm :)

Additionally I changed the regex in the main script for the processing of response mails, where no ticket number is present. As we are in Austria and most of our users have german language settings, I changed the regex at the beginning to " (([R][E][:])|([A][W][:])) " - with that it works with english and german settings ;) Still a question remains on my side: when the AW: or RE: is not at the beginning of the title, will it also work, or is this regex like a starts with?

Today I also tried the multiple inbox processing. I have some strange behaviour here. When I set an SR as standard workitem type (what I want to do with that one mailbox) it creates the SR, but never applies the template. I tried the functions (set-scsmtemplate and update-scsmpropertycollection) inside a script and everytime the following error occurs:

Set-SCSMObjectTemplate : The provided path ($Context/Property[Type='!System.WorkItem']/Id$) was not valid: Property reference 'Property[Type='!System.WorkItem']/Id$' could not be resolved.
Parameter name: pathReference
At line:149 char:5
+     Set-SCSMObjectTemplate -Projection $Projection -Template $Templat ...
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (Template.083d95...82ca2b3c48a82ac:ManagementPackObjectTemplate) [Set-SCSMObjectTemplate], ArgumentException
    + FullyQualifiedErrorId : ApplyTemplate,SMLets.SetSCSMObjectTemplateCommand

As I use this script from the webpage you noted in an SCO runbook as well I had a look at how we use it, and there we don't use the $Alias parameter. So for testing I deleted it from the function parameters and changed the function call in the set-scsmtemplate function, all inside the smletconnector.ps1, as well and voila, the template gets applied - It also works for the default IR template. I guess I did something, which is not wanted, but for me it works. So I ask myself if I misconfigured my system, so that the function inside the script is not working if I am not changing it.

Adam_Dzyacky

Alright. Just a few things going on here :)

1. Just a heads up @Simon_Zeinhofer that I opened this issue in regards to Custom Events
2. It's a regex that starts with. A quick sanity check is just open up any email in Outlook, and click Reply. As long as the formatting of the subject matches you should be good.
3. In regards to Multi-Inbox processing, make sure you're using Templates you've created and not one that are not provided out of the box. But I'm looking at the functions again, and something isn't right here between the parameters on v5 and v5.0.1 on Update-SCSMPropertyCollection. Might update this with a link depending on how things progress.

Simon_Zeinhofer

https://community.cireson.com/discussion/comment/24567#Comment_24567

Hello @Adam_Dzyacky ,

I think I just edited the post the moment you replied :D I guess my problem was, that the workitem was not passed, as __internalid did not work. Now I tested and it works ;)

What do you mean with point 3 exactly? "Not one that are not provided out of the box" - so you mean I shall not combine custom and ootb ones or shall I not use ootb templates in general? The templates which define the default workitem type I only used templates I created. But for the other workitem types I chose e.g. the default SR one - but it is not used anyway.

Anyway, by deleting the $Alias everything works now.

Adam_Dzyacky

You should not use any OOTB templates anywhere in the connector - Config Examples.

When choosing your Incident, Service Request, Change Request, or Problem Request templates for either the primary or secondary mailboxes - do not use any Templates that come out of box with SCSM. Instead make sure you use or create your own custom Templates (e.g. Library -> Create Template). If you previously created your own custom Templates for use with the original Exchange Connector those are acceptable to use here.

Simon_Zeinhofer

https://community.cireson.com/discussion/comment/24569#Comment_24569

Thanks for the information ;) I thought I've read the wiki carefully 🙈

All in all we are processing 4 additional mailboxes now and I am really impressed how good it works! Amazing product!!

Simon_Zeinhofer

@Brad_Zima Concerning the "Both keywords inside an email":

Shouldn't it be possible to only do the reactivate, even when both keywords are present by doing the following:

1. Place both of the "\[$reactivateKeyword]" before the "\[$closedKeyword]" inside the update-workitem switch-case statement
2. At the end of both "\[$reactivateKeyword]" statements, but inside the if(...){ insert a break;

So $Matches[0] will always be the reactivate Keyword, no matter where the keyword is inside the mail. And as the break; in the end of the line prevents further processing inside the statement, the close keyword will never be handled.

@Adam_Dzyacky is that correct or am I missing something here?

Adam_Dzyacky

I'll take both of those -

1. It should be possible, but without any testing I'm reluctant to give a definitive yes/no
2. I think there is probably some work here that could be done to better curb this in the event you're adding the whole email

But I have to ask, why the entire email?

Simon_Zeinhofer

@Adam_Dzyacky I meant a combination of both, so 1 AND 2 ;)

The thing with the entire mail:

As in our company people often forward mails and just write "see below" we have to append the whole mail.

I even asked if we could change that someday and teach people how they should use it but I got a definite NO ;)

I will test it in our environment, and will come back with a conclusion :D

Brad_Zima

@Simon_Zeinhofer - I'd recommend giving top comment only a try. It should include the whole email on ticket creation even with top comment only turned on. This should allow it to meet most of the cases where a user will forward/CC the helpdesk mailbox on an existing email chain.

Simon_Zeinhofer

https://community.cireson.com/discussion/comment/24621#Comment_24621

Hm, let's say we have the reactivate keyword in the mail which is sent to the user and the user replies with , let's say, "Still not working" but does not include the keyword. If we append only the top comment, the reactivate keyword is not in it and the incident will stay on resolved. So the Analyst receives an email, that a new comment has been made - BUT lots of our IT employees have certain rules for mails from our helpdesk address and don't even read them. When we apply the whole mail as comment, the declined keyword is in it and the ticket will be reopened.

I tested the changes to the switch-case today and it works as expected. I will test further and if no problems occur, I will move it to production :)

Sean_Terry

I've been meaning to look at this connector for some time now (never enough time is there).

Our exchange team have highlighted this:

Retirement of RBAC Application Impersonation in Exchange Online - Microsoft Community Hub

We currently use impersonation and I was wondering if the PowerShell connector has/will have adjustments to cover this? I'd like to look at the PowerShell version and this might enable us to dedicate more time to it.

Any info you can provide may help. Thanks.

@Adam_Dzyacky FYI

Adam_Dzyacky

A couple of things on this front:

• I saw the announcement about the deprecation of EWS, and created the following issue for it on the repo to track progress
• I saw the announcement about deprecating Impersonation/suspected back in October it could happen as EWS was going to be deprecated and Graph does not have an explicit Impersonation permission

What I suspect is going to be the case here (from what I've read/the research I've done thus far) is the Azure App Registration is going to have to be modified to support interacting with multiple accounts. So it will functionally accomplish the same. Which means some of the project's documentation will have to get updated and testing will have to be done to ensure this works without using Impersonation in 365. But again, it's early in this for me so I can't comment with certainty just yet.

_ABIM_Support

Has anyone gotten multi mailbox to work without having a mailbox for each analyst? We have about 20 analysts and I am trying to figure out a cleaner way than making a dummy mailbox for each person and a 'redirect' rule inside each mailbox manually. I saw people mentioning aliases but the only email that comes through when you email a mailbox with a bunch of aliases is the primary, so the connector doesn't pick up on it. I have also tried every combination of transport rules I can think of but nothing works with BCC.

At the end of the day we just want a quick way to fwd or cc/bcc an email and have it quick assign to an analyst. If not possible through multi mailbox feature is there some way to do it based on subject line? I saw Adam mention "Custom Actions PowerShell script" in a previous reply but I wasn't able to find that documented or explained anywhere.

Justin_Workman

You should be able to use Custom Events to apply additional processing based on CC or BCC:
https://github.com/AdhocAdam/smletsexchangeconnector/wiki/Custom-Events-Examples

Brad_Zima

I should also add that if you are delivering to one mailbox, then using Exchange rules to forward to another mailbox, then there is a ReceivedBy property in the message header that should contain the original mailbox name. If you combine that with the custom events you should be able to pull out the original mailbox and perform some processing logic. The issue thread linked below has quite a bit of detail about this (though the issue listed there is different) and maps out the conditions where that field is used by the connector.

https://github.com/AdhocAdam/smletsexchangeconnector/issues/141