Thursday, February 25, 2016

Exchange Connector, Our Analysts Hate Employee Signature Graphics in Work Items!

10:36 PM Posted by Adam Dzak , No comments

My email signature doesn't look like this, but I needed a graphic to illustrate a point...

So you have the Exchange Connector running in your SCSM deployment to convert emails to either an Incident or Service Request. What holds true in both scenarios is that the Exchange Connector will take the email's attachments and add them as Attachments in the Related Items sections of the Work Item. This is great and of course super awesome - but if your company has a corporate signature or your users decide to spice things up with their own graphics, the Exchange Connector just goes about it's job of...

I FOUND PICTURES, THOSE ARE ATTACHMENTS TOO! YOU'RE WELCOME! G'BAI!

But it'd be great if we had a bit more logic around this to remove email signature photos or perhaps more to the point - let's remove attachments less than X File Size from New Work Items (Incidents/Service Requests).

And believe it or not, the solution we're going to build doesn't exist in Service Manager at all. Well, I guess we could do it in Service Manager via a custom PowerShell workflow saved into a sealed management pack but I'm writing post this with the intent of 0 lines of code and a focus of all your automation/process existing in, well the automation wing of System Center (Orchestrator)! To be clear, even going the pure SCSM route means anytime you want to change this particular file size value, you're going to have to reseal and constantly update the associated DLL file on your workflow server. Now you could go build a custom GUI for your Settings pane in SCSM but...well it's just one more thing to admin/do/build and if you're not a developer quite an undertaking. That and I'm somewhat counting on you not having that kind of time on your hands with the need to just get it done and move onto the next thing.

Get excited and make things, let's do this!


To Orchestrator...
For the purposes of this post, I'm going to write this runbook against Incidents. But I'm sure you'll quickly see how you could alter this to Service Requests.

Alright, so first things first. Here's the runbook we're going to build:


1. Monitor New Email Incidents
2. Get Incidents
3. Get Relationship (Incidents to Attachments)
4. Get All Attachments
5. Get Signature Attachments
6. Delete Relationship (Remove Signature Photos)

1. Monitor New Email Incidents

Here I grab a "Monitor Object" from the SCSM activities for Orchestrator and configure as such. Notice the shape of the data we're defining here -
  • New Incidents
  • Source = Email
It goes without saying, if you've done something really complex with your Email Incidents (or SRs) you'll want to modify this appropriately so the scope of this runbook meets your other configurations.

2. Get Incidents
This step grabs all the incidents discovered in step 1

This is achieved by setting the SC Object Guid equal to the Published Data from Step 1

3. Get Relationship (Incidents to Attachments)

Here we're defining the relationship to obtain all attachments from those New Email Incidents. In this case, the related class is File Attachment (System.FileAttachment)

4. Get All Attachments
With the Get Relationship producing the related objects, we need a Get Object to grab the individual file attachments.

Again, we're going to use the File Attachment (System.FileAttachment) class to match the objects received the get "Get Relationship" step previously. The SC Object Guid equals the Related Object Guid

5. Get All Signature Attachments
This is going to look repetitive, but fret not the final payoff is at the end...



Again - I'm doing almost the same thing. The difference is now the filter is SC Object Guid equals the SC Object Guid from Step 4 (aka all of the attachments). Again, I know this is the same thing and I still don't have the photo attachments. I in fact still have all the same attachments in this step as I did in step 4...but read on, we will fix this!

6. Delete Relationship (Remove Signature Photos)
This one is really straightforward, delete the relationship between the Incident and the Attachment which effectively removes the attachment from the Incident!


Here the Object Guid to delete is the Relationship Object Guid from Get Relationship in Step 3.

Alright, I think I see what you did here. But this still deletes all attachments in it's current iteration. You said we were going to do less than some file size!

Link Condition...
The link between Get All Attachments and Get All Signature photos is where we're going to define the filter of our "less than" condition.



Whoa whoa whoa...hold on a second. Matches Pattern? Wait. Equals? There isn't less than! WHAT?! THIS CAN'T BE DONE!

Yeah...I painfully discovered the same thing. The Published Data property of "Size" from the Get All Attachments is text. That's right. Text. If it was an number, we could easily do this. To be honest, I wish I knew why this was the case but you know what, we can do this with matches pattern and building a regular expression

Ugh...I hate regular expressions. I immediately regret building this runbook.

Well. No use making you hit your head against the desk, here's the regular expressions to match the following ranges to insert into the value property of this link condition. By using these, your runbook will then remove attachments from new Incidents that are 1-X bytes:


1-1000
\b(?:1000|[1-9][0-9]{1,2}|[1-9])\b

1-2000
\b(?:2000|1[0-9]{3}|[1-9][0-9]{1,2}|[1-9])\b

1-3000
\b(?:3000|[12][0-9]{3}|[1-9][0-9]{1,2}|[1-9])\b

1-4000
\b(?:4000|[1-3][0-9]{3}|[1-9][0-9]{1,2}|[1-9])\b

1-5000
\b(?:5000|[1-4][0-9]{3}|[1-9][0-9]{1,2}|[1-9])\b

1-6000
\b(?:6000|[1-5][0-9]{3}|[1-9][0-9]{1,2}|[1-9])\b

1-7000
\b(?:7000|[1-6][0-9]{3}|[1-9][0-9]{1,2}|[1-9])\b

1-8000
\b(?:8000|[1-7][0-9]{3}|[1-9][0-9]{1,2}|[1-9])\b

1-9000
\b(?:9000|[1-8][0-9]{3}|[1-9][0-9]{1,2}|[1-9])\b

1-10000
\b(?:10000|[1-9][0-9]{1,3}|[1-9])\b

1-11000
\b(?:11000|10[0-9]{3}|[1-9][0-9]{1,3}|[1-9])\b

1-12000
\b(?:12000|1[01][0-9]{3}|[1-9][0-9]{1,3}|[1-9])\b

1-13000
\b(?:13000|1[0-2][0-9]{3}|[1-9][0-9]{1,3}|[1-9])\b

1-14000
\b(?:14000|1[0-3][0-9]{3}|[1-9][0-9]{1,3}|[1-9])\b

1-15000
\b(?:15000|1[0-4][0-9]{3}|[1-9][0-9]{1,3}|[1-9])\b


Once you've got your filesize requirements, check your runbook back in and click Run to get it started.


Done!
Hope this helped curb a common complaint against SCSM and potentially within your own deployment.

Sooo...uhhh...I have another file size for a regular expression you didn't list. I know you can't list every conceivable pattern, so....little help?

There are a few tools that can help you match a range of numbers with a regular expression. Bear in mind, matching numbers with a regex is inherently a bit more challenging because regex's aren't really meant to match numbers (integers). The fact this works, well is sort of hacking a regex to do it. Regardless, it works, so how can you build your own if this beast seems beyond your current scope of knowledge? Here's my two recommendations:

1. A lot of sites mention this one - utilitymill.com/utility/Regex_For_Range - I've used it once or twice before but a recent visit is asking for a login. No Bueno.

2. Regex Magic is something you will invariably come across in your searching for how to quickly build a regex with no experience building regular expressions. It's either a 14 day trial or $40 to purchase but I can certainly attest to it getting the job done. Make no mistake, learning that tool is a bit like learning Dreamweaver and not understanding HTML - you're teaching yourself how to use a tool, not understand the language.

Wednesday, February 10, 2016

In Defense of Class Extension vs. Inheritance

10:18 PM Posted by Adam Dzak , 2 comments
Hrmmm...


As I've shared on the About Me page, I'm just someone who loves Service Manager/System Center. I'm just another IT guy out there managing and helping SCSM deployments. So, in the time since my last post (which looking at it has been awhile...holy crap) and no less the deployment I provide advice on when asked/invited to my opinion has really started to change around the concept of Extending classes and Inheriting them. I would argue that I've taken a violent, 180 degree swing in the other direction. But I'll let you be the judge of what is best for you and your environment. But first, let's pretend for a bit and fast forward your SCSM deployment a few years into the future...


When you're doing authoring with the SCSM Authoring Tool (and by now, I think we all know that means Notepad++) and modifying SCSM functionality you almost always have to start your development with the fundamental question of...

Inherit this class or Extend this class?

In a previous post of mine, we walked through building an employee onboarding process (and really building something to suit the idea of a host of HR related scenarios), we chose to Inherit the Service Request class. If you're new to SCSM reading that/similar posts may seem to make a great deal of sense...


Pros of Class Inheritance:
  • Inherited classes are unique and do not "disrupt" or change stock SCSM functionality that Microsoft ships SCSM with.
  • You can have really specific fields/concepts since they pertain to the new class instead of affecting the "core" class, in this way a derivative class has been created
    • This is great for things like Employee Management or Create Virtual Machine as we have a lot of fields that don't exist out of box and need to call them into existence
  • You can have a custom form exist in the same management pack as the inherited class
    • Makes the management of this "thing" easier since it's now grouped together into a single management pack

Cons of Class Inheritance:
  • You almost always are going to have to manually edit the XML before sealing
    • This isn't fun/it's tedious work
      • If you keep doing different inherited classes off of the same classes, this can get unruly quickly. This may be manageable as a single SCSM Admin but can quickly become rough as the SCSM Admin numbers grow.
    • It may go without saying, but it's the kind of thing that almost necessitates the position of a full time job to understand this XML, etc. Not a con persae, but really trying to draw attention to the care and feeding of a specific thing within any SCSM deployment
  • Reporting becomes a bit more challenging if you are not the one writing reports or are a SQL/System Center veteran as now your SQL team has to start understanding how the DW changes based on these Inherited Classes.
    • A bit more challenging if your SQL team are not one with SCSM
    • A bit more challenging because you have to custom build out your DW to support these new classes that technically are not the stock ones
      • It's not like this can't be done, but it a classic "just one more thing to do"

So with the above said, generally speaking as a newcomer to SCSM it seems to just make sense that...

Of course I have two or more different classes based on the core one Microsoft ships. I mean, it doesn't make sense to have things like "New Laptop" share things with the base Service Request class. That's why I'm not Extending classes...because I don't want these things jumbled up. It makes sense to keep them separated. I want to have unique classes for each of these requests.

And I too shared this line of thinking for the longest time, because for one reason or another it just made more sense to me that I had dedicated classes. "Of COURSE I would!" I'd say to myself and it's the Employee Management scenario that really highlights this nicely. Because if I had done Class Extension, then all Service Requests in the system gain the properties of "First Name" and "Department" etc. etc...but now I'm here to ask the following...


Why is that such a bad thing? If you don't use the field, you just don't use it. Do you use the OOB Scheduled Start Time in every one of your request offerings? Do you use the OOB Actual Cost in every one of your request offerings?

So then I really started taking this scenario to it's logical extreme. If I'm making the case for "Oh well Employee Management" is different...why is it different? Do I just not like the idea of putting these things together? Sure, maybe that is it. But technically speaking is there a reason it's "bad" persae? Because the above quote is exactly the thought that struck me over the course of the last few months. Think of all of the options Microsoft ships out of the box with the SR class. Think of how many request offering you have published out on your portal. Do you map to ALL of those fields? Probably not. In fact, if you're playing the cautionary game (i.e. avoiding customizations) you may just be mapping things to things like...

  • Alternate Contact Method
  • Description
  • Notes
  • Scheduled Start/End Date (because you need some kind of date field for your request)
  • Boolean you are mapping to some Runbook inside of the SR

Pros of Class Extension:
  • Extended Classes effect all instances of that class, new and old in your system. If you add the "Random Date Field" parameter to a SR or IR, every single SR or IR in the system would get this new property
  • Multiple, disparate templates can feed off of a similar List should you utilize it
    • In the HR scenario the list for Departments is now bound to this new SR Class. Request Offerings based on the stock SR class cannot use this!
  • No XML hacking required, this works exactly like you expect it through the Authoring Tool
  • You can have multiple management packs Extend the same Class
    • So you can still group like extensions into similar management packs
    • But I'd argue that you probably don't want to get crazy with this and would advise sticking to a single management pack extending a single class
  • Reporting doesn't have a net loss as these new fields appear in the DW on the respective Class table. From a SQL perspective, nothing has changed. So if you extend the IR class, it appears on the IncidentDimVw table as though it were actually a part of the IncidentDimVw table out of the box. This is genuinely awesome as you can transform the schema of SCSM through management pack authoring.

    Cons of Class Extension:
    • Extended Classes effect all instances of that class, new and old in your system. If you add the "Random Date Field" parameter to a SR or IR, every single SR or IR in the system would get this new property
      • Again...is this actually such a bad thing technically speaking?

    If anything what you should see as someone in IT, is effectively the same as Extending your Active Directory schema. It's still the same thoughtful planning of "Alright, if we extend the schema what is something that can hold true for a host of scenarios or always serve one very specific one?" But the advantage you have is that you can extend the SCSM class schema's through MULTIPLE management packs which means you could if you so chose - blow away one management pack that extends a class and only lose that specific data. To be clear, the data that would be lost is the data in your warehouse as those items you extend would be pulled on the next sync.

    So what about the Employee Management thing we created? Does this mean I retreat on that? Well...I think it does unfortunatley. To be honest, this is the one scenario I struggle with a lot but I think I have to concede that I'd actually do that differently now. I'd probably change the names of fields to be more generic in some cases, but I would opt for extending the SR class to support this functionality. Because of all the fields in that example, there is one that I think holds a host of future scenarios for your environment and that is "Department" as I shared above. In my example, I stressed the need to create a Department list so you could have a single place to edit and change departments within the SCSM console. This said...when you get approached about "Hey, we need a new Request Offering based on the stock SR template where someone can pick a department" guess what you can't do now?

    Yup. That's right....Short of continuing to use the Employee Management pack for future non-specific HR requests, you can't reference the Department field since it exists and is exclusively bound too this new Service Request class. In the case of a class Extension, all SRs would have the field and all future request offerings/ideas could leverage this same list. Otherwise, you end up with the unruly situation of multiple Department lists within the SCSM console. A less than desirable scenario as now you have multiple lists that effectively serve the same function that you'd have to keep both up to date with. If you're into PowerShell or Orchestrator this scenario is an automation nightmare if you take it to it's logical extreme. Again, I have to concede that over the last several months my opinion on this topic has changed radically and that Class Inheritance and it's respective management has to potential get out of hand really fast.

    Apart from the above scenario of department, what are some actual practical and useful class extensions? What about giving Change Request's a much needed Support Group? And maybe doing the same thing for Manual Activities and Problems? Maybe throw something like "Email Notes 01" into Review Activities so when email notification goes out to review you map certain parts of the request into a dedicated email note area? All in all, I think I'm at the point now where I can think of more reasons and examples to extend vs. inherit a class.



    In conclusion...
    It's with the all of the above said, I argue for Extending Classes in SCSM vs. Inheriting them. I think it makes for cleaner future administration, you still get the granularity of grouping like extensions together and you can continue to build out your SCSM deployment to support larger organization wide initiatives (i.e. using the tool for non-IT based departments such as an HR help desk, etc.)