TERMS OF USE
AGREEMENT BETWEEN USER AND CIRESON
The Cireson Community Web Site is comprised of various web pages operated by Cireson, LLC (collectively, the web pages are referred to herein as the “Cireson Community Web Site”).
The Cireson Community Web Site is offered to you conditioned on your acceptance of the terms, conditions, and notices contained herein without modification or exception. Your use of the Cireson Community Web Site constitutes your agreement to all such terms, conditions, and notices contained in these Terms of Use.
MODIFICATION OF THESE TERMS OF USE
Cireson reserves the right to change the terms, conditions, and notices under which the Cireson Community Web Site is offered, including but not limited to the charges associated with the use of the Cireson Community Web Site upon written notice.
LINKS TO THIRD PARTY SITES
The Cireson Community Web Site may contain links to other Web Sites (“Linked Sites”). The Linked Sites are not under the control of Cireson and therefore Cireson is not responsible for the contents of any Linked Site, including, without limitation, any link contained in a Linked Site, or any changes or updates to a Linked Site. Cireson is not responsible for webcasting or any other form of transmission received from any Linked Site. Cireson is providing these links to you only as a convenience, and the inclusion of any link does not imply endorsement by Cireson of the site or any association with its operators.
NO UNLAWFUL OR PROHIBITED USE
As a condition of your use of the Cireson Community Web Site, you warrant to Cireson that you will not use the Cireson Community Web Site for any purpose that is prohibited by law, rule regulation or by any of these terms, conditions, and notices, including, without limitation the export of any Software or technical data to any country prohibited by law. You may not use the Cireson Community Web Site in any manner which could damage, disable, overburden, or impair the Cireson Community Web Site or interfere with any other party’s use and enjoyment of the Cireson Community Web Site. You may not obtain or attempt to obtain any materials or information through any means not intentionally made available or provided for through the Cireson Community Web Site.
USE OF COMMUNICATION SERVICES
The Cireson Community Web Site may contain bulletin board services, chat areas, news groups, forums, communities, personal web pages, calendars, and/or other message or communication facilities designed to enable you to communicate with the public at large or with a group (each a “Communication Service,” and collectively, “Communication Services”). You agree to use the Communication Services only to post, send and receive messages and material that are appropriate, proper and related to the particular Communication Service. By way of example, and not as a limitation, you agree that when using a Communication Service, you will not:
Cireson has no obligation to monitor the Communication Services. However, Cireson reserves the right to review materials posted to a Communication Service and to remove any materials in its sole discretion. Cireson reserves the right to suspend or terminate your access to any or all of the Communication Services at any time without notice for any reason whatsoever.
Cireson reserves the right at all times to disclose any information as necessary to satisfy any applicable law, rule, regulation, legal process or governmental request, or to edit, refuse to post or to remove any information or materials, in whole or in part, in Cireson’s sole discretion.
Always use caution when giving out any personally identifying information about yourself or your children in any Communication Service. Always use caution when giving out any information concerning your employer or customers, if any. Cireson does not control or endorse the content, messages or information found in any Communication Service and, therefore, Cireson specifically disclaims any liability with regard to the Communication Services and any actions resulting from your participation in any Communication Service. Managers and hosts are not authorized Cireson spokespersons, and their views do not necessarily reflect those of Cireson.
Materials uploaded to a Communication Service may be subject to posted limitations on usage, reproduction and/or dissemination. You are responsible for adhering to such limitations if you download the materials.
MATERIALS PROVIDED TO CIRESON OR POSTED ON THE CIRESON COMMUNITY WEB SITE
Cireson does not claim ownership of the materials you provide to Cireson via the Cireson Community Web Site (including feedback and suggestions) or post, upload, input or submit to the Cireson Community Web Site or its associated services (collectively “Submissions”). However, by posting, uploading, inputting, providing or submitting your Submission you are granting Cireson, its affiliated companies and sublicensees permission to use your Submission in connection with the operation of their Internet businesses including, without limitation, the rights to: copy, distribute, transmit, publicly display, publicly perform, reproduce, edit, translate and reformat your Submission; and to publish your name in connection with your Submission.
No compensation will be paid with respect to the use of your Submission, as provided herein. Cireson is under no obligation to post or use any Submission you may provide and may remove any Submission at any time in Cireson’s sole discretion.
By posting, uploading, inputting, providing or submitting your Submission you warrant and represent that you own or otherwise control all of the rights to your Submission as described in this section including, without limitation, all the rights necessary for you to provide, post, upload, input or submit the Submissions.
LIABILITY DISCLAIMER
THE INFORMATION, SOFTWARE, PRODUCTS, AND SERVICES INCLUDED IN OR AVAILABLE THROUGH THE CIRESON COMMUNITY WEB SITE MAY INCLUDE INACCURACIES OR TYPOGRAPHICAL ERRORS. CHANGES ARE PERIODICALLY ADDED TO THE INFORMATION HEREIN. CIRESON (OR ITS SUPPLIERS) MAY MAKE IMPROVEMENTS AND/OR CHANGES IN THE CIRESON COMMUNITY WEB SITE AT ANY TIME. ADVICE RECEIVED VIA THE CIRESON COMMUNITY WEB SITE SHOULD NOT BE RELIED UPON FOR PERSONAL, MEDICAL, LEGAL OR FINANCIAL DECISIONS AND YOU SHOULD CONSULT AN APPROPRIATE PROFESSIONAL FOR SPECIFIC ADVICE TAILORED TO YOUR SITUATION.
NEITHER CIRESON NOR ANY OF ITS SUPPLIERS MAKE ANY REPRESENTATIONS ABOUT THE SUITABILITY, RELIABILITY, AVAILABILITY, TIMELINESS, AND ACCURACY OF THE INFORMATION, SOFTWARE, PRODUCTS, SERVICES AND RELATED GRAPHICS CONTAINED ON THE CIRESON COMMUNITY WEB SITE FOR ANY PURPOSE. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, ALL SUCH INFORMATION, SOFTWARE, PRODUCTS, SERVICES AND RELATED GRAPHICS ARE PROVIDED “AS IS” WITHOUT WARRANTY OR CONDITION OF ANY KIND. CIRESON AND/OR ITS SUPPLIERS HEREBY DISCLAIMS ALL WARRANTIES AND CONDITIONS WITH REGARD TO THIS INFORMATION, SOFTWARE, PRODUCTS, SERVICES AND RELATED GRAPHICS, INCLUDING ALL IMPLIED WARRANTIES OR CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT.
TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT SHALL CIRESON AND/OR ITS SUPPLIERS BE LIABLE FOR ANY DIRECT, INDIRECT, PUNITIVE, INCIDENTAL, SPECIAL, CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF USE, DATA OR PROFITS, ARISING OUT OF OR IN ANY WAY CONNECTED WITH THE USE OR PERFORMANCE OF THE CIRESON COMMUNITY WEB SITE, WITH THE DELAY OR INABILITY TO USE THE CIRESON COMMUNITY WEB SITE OR RELATED SERVICES, THE PROVISION OF OR FAILURE TO PROVIDE SERVICES, OR FOR ANY INFORMATION, SOFTWARE, PRODUCTS, SERVICES AND RELATED GRAPHICS OBTAINED THROUGH THE CIRESON COMMUNITY WEB SITE, OR OTHERWISE ARISING OUT OF THE USE OF THE CIRESON COMMUNITY WEB SITE, WHETHER BASED ON CONTRACT, TORT, NEGLIGENCE, STRICT LIABILITY OR OTHERWISE, EVEN IF CIRESON OR ANY OF ITS SUPPLIERS HAS BEEN ADVISED OF THE POSSIBILITY OF DAMAGES. BECAUSE SOME STATES/JURISDICTIONS DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES, THE ABOVE LIMITATION MAY NOT APPLY TO YOU. IF YOU ARE DISSATISFIED WITH ANY PORTION OF CIRESON COMMUNITY WEB SITE, OR WITH ANY OF THESE TERMS OF USE, YOUR SOLE AND EXCLUSIVE REMEDY IS TO DISCONTINUE USING THE CIRESON COMMUNITY WEB SITE.
SERVICE CONTACT: team@cireson.com
TERMINATION/ACCESS RESTRICTION
Cireson reserves the right, in its sole discretion, to terminate your access to the Cireson Community Web Site and the related services or any portion thereof at any time, without notice.
GENERAL
To the maximum extent permitted by law, this agreement is governed by the laws of the State of California, U.S.A. and you hereby consent to the exclusive jurisdiction and venue of courts in San Diego County, California, U.S.A. in all disputes arising out of or relating to the use of the Cireson Community Web Site. Use of the Cireson Community Web Site is unauthorized in any jurisdiction that does not give effect to all provisions of these terms and conditions, including without limitation this paragraph. You agree that no joint venture, partnership, employment, or agency relationship exists between you and Cireson as a result of this agreement or use of the Cireson Community Web Site. Cireson’s performance of this agreement is subject to existing laws and legal process, and nothing contained in this agreement is in derogation of Cireson’s right to comply with governmental, court and law enforcement requests or requirements relating to your use of the Cireson Community Web Site or information provided to or gathered by Cireson with respect to such use. If any part of this agreement is determined to be invalid or unenforceable pursuant to applicable law including, but not limited to, the warranty disclaimers and liability limitations set forth above, then the invalid or unenforceable provision will be deemed superseded by a valid, enforceable provision that most closely matches the intent of the original provision and the remainder of the agreement shall continue in effect. Unless otherwise specified herein, this agreement constitutes the entire agreement between the user and Cireson with respect to the Cireson Community Web Site and it supersedes all prior or contemporaneous communications and proposals, whether electronic, oral or written, between the user and Cireson with respect to the Cireson Community Web Site. A printed version of this agreement and of any notice given in electronic form shall be admissible in judicial or administrative proceedings based upon or relating to this agreement to the same extent and subject to the same conditions as other business documents and records originally generated and maintained in printed form. It is the express wish to the parties that this agreement and all related documents be drawn up in English.
COPYRIGHT AND TRADEMARK NOTICES:
All contents of the Cireson Community Web Site are: Copyright 2016 by Cireson, LLC and/or its suppliers. All rights reserved.
TRADEMARKS
The names of actual companies and products mentioned herein and on the Cireson Community Web Site may be the trademarks of their respective owners.
The example companies, organizations, products, people and events depicted herein are fictitious. No association with any real company, organization, product, person, or event is intended or should be inferred.
Any rights not expressly granted herein are reserved.
NOTICES AND PROCEDURE FOR MAKING CLAIMS OF COPYRIGHT INFRINGEMENT
Cireson respects the intellectual property of others and asks that users of the Cireson Community Web Site do the same. In connection with the Cireson Community Web Site, we have adopted and implemented a policy respecting copyright law that provides for the removal of any infringing materials and for the termination, in appropriate circumstances, of users of the Cireson Community Web Site who are repeat infringers of intellectual property rights, including copyrights. If you believe that one of the Cireson Community Web Site users is, through the use of the Cireson Community Web Site, unlawfully infringing the copyright(s) in a work, and wish to have the allegedly infringing material removed, the following information in the form of a written notification (pursuant to 17 U.S.C. § 512(c)) must be provided to our designated Copyright Agent:
Please note that, pursuant to 17 U.S.C. § 512(f), any misrepresentation of material fact (falsities) in a written notification automatically subjects the complaining party to liability for any damages, costs and attorney’s fees incurred by us in connection with the written notification and allegation of copyright infringement.
Designated Agent: Matthew W. Deen, Esq.
Address of Agent: 1620 Fifth Avenue, Suite 875, San Diego, CA 92101
Telephone: 619-993-8873
Fax: 888-244-8458
Email: matt.deen@cireson.com
Comments
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 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 :)
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.
All good @Simon_Zeinhofer!
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 😁
@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 } } }@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.
@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:
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.
Alright. Just a few things going on here :)
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.
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.
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!!
@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:
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?
I'll take both of those -
But I have to ask, why the entire email?
@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
@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.
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 :)
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
A couple of things on this front:
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.
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.
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
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