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
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. 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.
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 -
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.
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?
Consider it created @Brad_Zima. Over here -
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
Yup! I know the exact section/flow you're referring to here. It's...
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. 😀
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 ;-)
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.
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.
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!
@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!
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.
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.
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 :)
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..
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.
@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.
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?