Preserving Customizations through Upgrades
If you’ve joined myself and others on this open source Exchange Connector journey, something that may have come up is “Inserting custom logic on this thing is doable, but I could easily see myself forgetting to do it on an upgrade” or “Can’t there be someway to preserve my own organization logic between upgrades?”
It’s a great question and one whose answer deserves its own post.
Upgrading the Connector
So let’s say the latest version of the SMLets Exchange Connector is out OR you prefer to live dangerously using an in development branch. What’s true in both cases is you want it deployed. But upgrading this script could potentially lead to some sweaty palms as you cross check what settings you’ve enabled from what are otherwise set to a default of $false on the download. Wouldn’t it be great if there was some way quick and easy way to compare your customized connector to the latest vanilla one you’ve just downloaded? If you are thinking we’re just going to diff these files you’re right, but what program are we going to use to do it? The same one the SMLets Exchange Connector is currently maintained in - Visual Studio Code.
I want to contribute, but I have no idea how to use GitHub
This is something I’ve heard in passing. People are interested in contributing to the connector, but they are worried they’ll make a mistake OR GitHub feels foreign if you’ve only ever been PowerShell scripting for yourself. Let’s use this blogpost as the opportunity to address both of those things and how you can comfortably get started.
What WOULD HAVE Suggested Knowledge Articles/Request Offerings suggested?
You have the Cireson portal. You have the SMLets Exchange Connector and you are looking to put your SCSM deployment to the test by enabling the connector’s ability to automatically Suggest Knowledge Articles and/or Request Offerings based on the content of the email. How useful will this feature actually be to your deployment if enabled? How much time do you stand to shave off per day? Not to mention you may even further be venturing down the Azure Cognitive Services route to see if you can improve the accuracy of the suggestions through picking out keywords instead of submitting the entire Subject/Body to the Cireson Web API. Just one problem - short of a stage environment that 100% mirrors your production environment, there isn’t a good way to test this feature without just turning it on.
Building a Custom Settings UI for Service Manager (part 2)
I hope you’ve had time to digest Part 1 because it’s time for Part 2 which will wrap this management pack of ours up by including a custom UI that can surface our MP’s respective properties. At the time of this exact original publish date, I still HAVE NOT published the Visual Studio solution onto a new Settings branch within the SMLets Exchange Connector repo. Links on this post will be updated to the repo accordingly once this has been done.
Building a Custom Settings UI for Service Manager (part 1)
While dedicated developers of SCSM already know what’s what when it comes to developing for Service Manager - many an onlooker have no doubt stumbled across Travis Wright’s blogpost “Creating a Custom Administration Setting” on TechNet. In it, a primer on creating your very own truly custom management pack not only with some properties you could define, but a walkthrough of building a new Settings pane within the console, and then surfacing those properties in a way that can be edited through the SCSM Console with a custom UI. Truly the icing on any management pack cake for SCSM.
The SMlets Exchange Connector at its core
If you’re entering PowerShell, SMLets, or no less this connector for the first time a question you may have is simply “Where’s the part that processes the mail?” In short - it’s at the bottom of the script. But even still it’s filled with a lot of conditional processing to handle the different Work Item types as well as different email types. The following are all of the same variables and logic from the original SMLets Exchange Connector just condensed down into this version again for readability and examining the whole premise of said connector. So let’s dive in and see how this works without talking about Service Manager.
How much time can you save when you enable Merge Replies?
Here’s something you may have been wondering - if you enable the connector’s Merge Replies feature, that is, when emails come in that are a Reply to another email that do not have a Work Item in the subject how much time are you really saving your analysts? Because once you turn it on, you’ll never know it is happening. Emails are simply appended to the correct Work Item from that point forward and everyone benefits as there are no more duplicates to micro-manage. But maybe you’re the curious type and/or looking to impress your boss with some time savings statistics on the SMLets Exchange connector you recently implemented. Look no further than the following PowerShell.