Change Your MDM Authority without re-enrollment... WAIT!

First off, I want to promise you that this article is not clickbait. In short, I'm here to say that what the current documentation as of 8.1.2017 states is factually correct but it is omitting something rather large for those performing a switchover. And again - I know this is a Service Manager blog so why am I bothering to talk about SCCM/InTune? As always, I'll get there.

Per the opening lines of Microsoft's document you can change your MDM Authority without having to re-enroll devices. GAME ON! If you are standalone or hybrid and looking to switch to the other, this is some pretty fantastic news. But if you're a SCSM Mercenary in your own right, you're probably (hopefully) switching to hybrid because you want all of that awesome mobile device data to get pulled into SCCM, and in turn SCSM. I can't say I blame you. So here's the two biggest gotchas and entire point of this post that could introduce some unease you when converting from Intune standalone, to SCCM/InTune hybrid. You can jump to point #2 if you want to get straight to the landmine and point of this article.

1. Apple Push Notification Certificates (APN)
This process is not necessarily difficult, but when you read Microsoft's documentation closely it may startle you a bit if you think on it. In short - when the switchover is performed you need get the same APN that was used on InTune standalone. Because until you do this, you can't enroll new devices/potentially manage your current devices.

Again - it sounds a little terrifying. So you may think...

Well I'll just request the APN before performing the switchover. That way the APN is already in place and there isn't a single second of non-managed iOS devices.

There is only one problem, SCCM will not let you and doesn't provide any warnings/popups to tell you otherwise. If you attempt to perform the APN request before switching from standalone to hybrid, you'll get the InTune sign-in prompt to log into your tenant. However the second you sign in, this new dialogue box goes solid white and nothing happens. It will just hang out at this white screen indefinitely.

It's with this said, you may get cold feet thinking...

If it doesn't work now, how do I know it will work after the switchover? I suddenly feel very uneasy about this. I can't risk losing management of my iOS devices!

Fret not because the directions per Microsoft's documentation should absolutely be followed in order. So yes, I am in fact telling you to read the manual.

Lesson Learned: You have to perform the switchover from standalone to hybrid, then request the APN per the instructions. If you attempt to grab the APN first, you get a solid white screen after the login. Doing it in the correct order takes less than 4 and half minutes (unless you can click faster than me) with no impact to the management of your iOS devices.


2. Device Groups and Collections (the real "gotcha")
As Microsoft documentation explicitly states on several occasions, you should re-create policies as soon as possible after the conversion. But here we go again. Order of operations. Does it matter? The good news here is that no it does not!

Create new SCCM Device Collections with names that mirror the Group names you've setup on InTune. Create Configuration Items/Baselines and point them at your new collections mirroring the way you've configured your policies within the InTune portal. This way when devices get thrown into those groups they immediately receive their new policy from SCCM and drop the one from InTune. You're in the home stretch! Time to make that switchover - 

Wait a second...how do I get devices from their InTune Groups to their new Device Collections in SCCM?

BOOM! Well as long you don't step on this landmine everything will be fine. During the conversion process, there is absolutely nothing that InTune nor SCCM do to ensure that devices move from an InTune group to a SCCM Device Collection. Everything will in fact get dropped into the out of box "All Mobile Devices" Device Collection. This said, the onus falls on you the customer to shuffle the devices into their new device categories/collections so as to minimize lax policy coverage.

But what about Device Categories? I had to re-create those before the switchover. Can't I leverage that somehow to get out of this situation?

Unfortunatley, no. You created the Device Categories. So any Device Categories currently on InTune and/or associated with devices unfortunately mean absolutely nothing in this conversion! You probably even found this article from System Center Dudes that tells you how to configure new Device Categories within SCCM and while it is 100% correct it is only addressing new devices going forward post switchover. Which means once they come down, you'll have to re-categorize them!

So how can we right this? You've spent all this time meticulously recreating all of your InTune rules in SCCM. How can we ensure that we continue to deliver policy as soon as we can post-switchover? Hopefully the answer won't surprise you - PowerShell.

Lesson Learned: Handling InTune Groups and SCCM Device Collections is a bit disjointed
So now having realized that we still have to do some shuffling of devices once they arrive in SCCM, first we'll export a list of devices from an InTune group. Just head over to the InTune portal, go to a Device Group, view its members, and export to CSV. Repeat this process for all the groups you have.

After the switchover occurs, it will take several hours before all of your InTune devices are registered within SCCM. But as they arrive, we can keep sorting them with PowerShell. The script below will read the Name column of the CSV, find the corresponding device in SCCM, and then add it to the Collection of your choosing where Configuration Items/Baselines are being applied. What we're taking advantage of here, is that the InTune portal uses the identical Name property that we'll eventually see within SCCM. You'll want to probably get this script running on some kind of regular interval if any lax policy enforcement concerns you. Otherwise, per Microsoft document you'll have 7 days to get everything setup correctly before the InTune rules get dropped and SCCM truly takes over.

# skip the column header 

$devices = get-content "path to intune csv export" | select -skip 1 | ConvertFrom-Csv
$sccmCollection = Get-CMDeviceCollection -name "collection name" 

foreach ($device in $devices)
{
    Add-CMDeviceCollectionDirectMembershipRule -CollectionID $sccmCollection -resourceid $(Get-CMDevice -Name $device.name).ResourceID
}

Once you've got the current devices setup the way you want, you're good to go! Then going forward, device management will be handled by the Device Categories you created in SCCM and dynamically associated with Device Collections. Thus addressing all new device enrollments.

Note: The alternative option at the time of this writing is manually assigning (one by one) the Device Category to each device as it appears. The downside of this approach is you constantly have to revisit the All Mobile Devices collection for new devices as they appear and categorize. Not to mention, that you do in fact have to do it one by one! There is currently no supported method in the GUI or PowerShell to mass set/foreach loop the Device Category. However, I suspect there is probably someway to address this on the SQL backend. You can read more about there on the TechNet discussion here.


Endgame - Service Manager
So once you've righted these wrongs and you've made the switchover, what does this have to do with SCSM? Well if you're syncing SCCM data into SCSM, you'll be happy to know that a Mobile Device class exists within SCSM and will become populated with this new wealth of data. Which means you can attach mobile devices to Incidents, Changes, Service Requests, etc. What's the even slightly larger payoff? Devices will sync their Primary User relationship! So now when navigating within SCSM, you can view not only the computers a user access, but you can see the relationship to their mobile devices as well.

With this new integration point, a new wealth of possibilities are unlocked for SCSM. Here's just a few examples:

• Service Requests on the self-service portal based on currently signed in user and their mobile devices
• Incident Requests on the self-service portal based on currently signed in user and their mobile devices
• Service Requests that initiate SCCM automation to lock, wipe, and reset devices
• Could be relevant to end users, analysts, or both
• Asset Management processes (if you're a Cireson customer, the possibilities here become even larger)
• Extend the SCCM Mobile Device class within SCSM and use SCO/SMA jobs to further populate more data from SCCM into SCSM

While getting all of these devices into SCSM stand to benefit your ITIL/Service Desk processes, it plays a much larger role in the name of Service Manager not just as a "ticketing tool" but a truly self-maintaining CMDB.

Go forth and automate!

Read More

Network Devices - In SCOM...uhh..SolarWinds...Service Manager?

IT Worker 1:

I'm an experienced network engineer. I've used SolarWinds tools because as far as I and my peers can remember, this is the standard when it comes to network monitoring. Our network. Our tools.

IT Worker 2:

I'm an experienced IT professional. I love all things System Center and I love their interconnectivity even more. Email notifications are so yesterday - SCO automates. SCOM alerts. SCSM triages Incidents. Our environment. Our tools.

Can you feel the tension in the air right now? I know I can!

No use running around in circles arguing, time to evaluate. But before we do, you may be asking yourself "SCOM? SolarWinds? I thought this was a Service Manager blog?" To which I say "OH BUT IT IS. JUST YOU WAIT!"


SCOM - A little late to the network monitoring game...
Operations Manager's biggest criticism is that it's a very Microsoft centric approach to monitoring. If you aren't a big Microsoft shop, you are going to struggle investing configuration/development efforts into SCOM. But it's not to say this is a Microsoft only tool. NetApp, Cisco, the former BlueStripe and even SolarWinds feature management packs to tie themselves into SCOM and help you centralize your monitoring/alerting solution. What's more, Microsoft builds network monitoring tools natively into SCOM. So really, what SCOM can't do these 3rd party integrations can extend their help with via management packs.
Enterprise tool. All of the things.

SolarWinds - The standard in network monitoring...
They run this game! You wanna do network monitoring right you gotta go through me! Well...you have to go through SolarWinds. But you get what I'm saying. These products feature intuitive, well thought out UIs, with a heavy emphasis on making you work as little as possible to get what you're after. If you're a SolarWinds user, viewing SCOM is probably a rather jarring experience to you. It's easy to see why this tool is chosen over the other as an experienced network professional.
Network tool. Network Devices.

Well this blog post is clearly over! SolarWinds is the victor here. If I want SCOM integration I'll just use the SolarWinds management pack.

Well, just wait a second...
The presentations and more importantly my own personal results I've seen on the SolarWinds SCOM management pack seem to gloss over almost all of the important details. In fact, I would argue that the information available seems squarely aimed at a single group of individuals - those who do not understand SCOM or the goal of System Center at large.

The flexibility of SCOM/SCSM is management packs...

SolarWinds in its three leading headers of their Orion platform (and integration with SCOM) would have you believe that Management Packs are unruly, difficult to use/upgrade, and it would seem that in the "worst case" - you need them!

All three of these points in my opinion pray on a single, rather common misconception - SCOM is difficult.

Management Packs as I've shared previously are the fundamental cornerstone of the houses that are SCSM and SCOM. One of the most awesome points of this architectural design is to allow the flexibility to only touch/modify select pieces of the SCOM/SCSM infrastructure without fear of disrupting ANY of the other parts of it. So let's break that down header by header...

Dependent on 3rd-party management packs: Monitoring business critical non-Microsoft applications requires expensive 3rd-party management packs and add-ons
Maybe I'm reading in to this too deeply, but this point feels like a criticism, even though it's nothing but a genuinely true statement. Although I am deeply curious what is considered "expensive" ?

• Citrix - Do you have Platinum Citrix licensing? You get the Citrix MPs for free with your purchase. Don't have platinum licensing? Good news, your Netscalers admin settings page feature a download link for at least Netscaler monitoring...free. They even have a freely available PowerShell module whether or not you use the SCOM MP
• Cisco UCS Chassis - Do you have these in your environment? You get these for free with your purchase
• NetApp SAN/Storage Controllers - Do you have these in your environment? You get these for free with your purchase along with an IP for Orchestrator, a PowerShell module, and SCVMM integration
• Linux/Unix/AIX systems - Microsoft makes these, I kid you not, and they ship with SCOM. Have a blast! Speaking of which, remember that time PowerShell went open source and now in very early builds works on Linux?
• Amazon AWS - Do you use AWS and not Azure? No problem, Amazon has you covered...for free. They too let you control their cloud with a PowerShell module in addition to the SCOM MP
• Network Devices - Do you have enterprise gear (i.e. Cisco and others) in your environment? No problem, Microsoft has you covered. Custom network gear in your environment? You won't get memory, cpu, or fan speed of the device but you will most certainly get up/down (availability).

And what makes all of the above listed things better? The ability to play with all of it through the SCOM PowerShell module.


No built-in support for VMWare monitoring: Monitoring VMWare requires the installation of management packs
Hey there Wyld Stallyns (and the uninformed), I suppose it's time for a history lesson - VMWare and Microsoft's Hyper-V aren't exactly the best of friends, as it turns out they are fierce. Fierce. Fierce competitors. This means you aren't going to find VMWare building integration points for SCOM nor Microsoft building them. Which means you must turn to a 3rd party company (Veaam runs that game for SCOM). So really, this boils down to a more fundamental question of - is SolarWinds going to be that 3rd party? or is it going to be any number of software companies that develop VMWare integration for SCOM?



Lacks built-in multi-vendor server monitoring: Discovering and monitoring multi-vendor server hardware requires multiple management packs.
Guys. Women. Folks! Come on! You're starting to sound like a broken MP3 here. Of course monitoring multiple solutions requires multiple management packs. You're describing EXACTLY how Operations Manager is architected and works!

Well, Management Packs aren't all that bad. We (SolarWinds) made one for SCOM! So the SCOM people can use this too! We won! SolarWinds for life!

Not so fast SolarWinds. While you most certainly provide a management pack that integrates your product with SCOM, as a long time user of SCOM I have to say it really feels like you cut corners here.

• The majority of the views are just web views that link you into your locally deployed SolarWinds Orion portal. It feels as though you've achieved SCOM integration on an incredibly superficial level here.
• Alerts that do cite specific items (switches, routers, etc.) do not feature relationships! You get an alert but no context associated with the actual device having the issue other than a single text name. Wondering exactly what I'm getting at here? Keep reading.
• Half of the alerts feature next to no context or value when pushed into SCOM. Orion Advanced Alert? The majority of the alerts feature the identical title with varying descriptions. Requiring a lot more investigation into the nature of the Alert than a glance. If anything, requiring someone just to go right back into Orion. I get that's what you want but...
• SquaredUp, an HTML5 web portal that rides on top of SCOM infrastructure is unable to visualize the data created by the SolarWinds SCOM MP as it fundamentally violates a core tenant of SCOM development - Never ever try to implement dynamic objects and counter names for performance collection rules!  But what does the tech babble translate to? It means the way the MP is written is crazily efficient at querying the SolarWinds database, but it falls on its face trying to insert that data into SCOM because that's not how SCOM is architected to accept data.

Truthfully this MP feels like more of a "view only" thing and less of a "things you could actionably work with"

Hey Adam! I'm a Service Manager admin. Can't I just take the SolarWinds MP, import it into SCSM, and then when SCSM runs its regular Discovery Inventory pull from SCOM I get all the devices anyway? Right? Everyone's happy!

While you are absolutely correct in your guess there SCSM admin, you're going to be really, really, really disappointed at the objects you get. You'll be even more disappointed to learn the single class of "SolarWinds Network Device" does not pass on any of that rich SNMP discovery data it obtained into SCSM.

Not only that - the SolarWinds MP does not feature any Relationship Classes! So your 24 port switch is a single device. The ports on it? Well those don't exist according to the SolarWinds MP once inside SCSM. So when it comes to data, we're unfortunately coming up terrifically short on it.

	SCOM	SolarWinds
Network Monitoring SNMPv1 and v2	x	X
Network Monitoring SNMPv3 (AES)	128*	128, 256, 512
Alerting via Email	x	X
Alerting via Text	x	X
Alerting with Automation	x
Deep network analysis/investigation		X
Work Item Integration with SCSM	x
Configuration Item Integration with SCSM	x

*Arguing AES256/512 are better because they are "harder" is a bit moot. AES128 at the time of this writing would take a billion plus years to crack via bruteforce attempts. If and when AES128 becomes trivial, 256/512 probably won't be that far behind.

I put this graph here, because I wanted to highlight some other points you may hear get made. But I also wanted to entertain a scenario in the world of System Center that genuinely cannot exist in SolarWinds (MP or not) - if I have a network switch go down, wouldn't it be neat to alert the network team, automatically create an Incident, and automatically alert all affected machines/users of this? This entire scenario is doable across the spaces of SCSM, SCOM, and SCO (I suppose SCCM if you wanted to get really fancy). Come to think of it, that's not a bad idea for another blog post.

All in all - the SolarWinds MP in my opinion is nothing more than a way to say they integrate with SCOM without truly doing it.



Let's talk about that whole "half of the alerts" point I just made...
And here's the part I've been waiting to get to on this post. If the information passed from SolarWinds to SCOM has almost next to no value, can you imagine what happens if you decided to get creative and forward said SCOM alerts into SCSM to create Incidents? You'll get:

• Incidents (a majority of the time) with the identical Title
• Incidents with similar/identical descriptions
• Incidents with maybe a related Configuration Item?

Configuration Items. The exact kind of thing in a CMDB that we care passionately about. The exact kind of thing that apart from relating to Incidents we'd want to relate to Problems, Service Requests, and Change Requests. Or maybe we just want it for Asset inventory for your companies respective ITAM processes? The kind of thing that we want as much information as possible about! The kind of thing we want to know about along with all of its relationships to ports, VLANs, and more! And it's the exact kind of thing that the SolarWinds MP does not provide whatsoever. What you get is a really distilled object (name, ip address, and a few more things) but not nearly as much information as you'd get with SCOM polling and monitoring these devices (i.e. SNMP version, Location, Primary Contact, and all other SNMP data available on the device).

However, let's be clear about this - this isn't the point of the SolarWinds MP. It was clearly designed for the express purpose of SCOM; to merely provide a view into SolarWinds data, to provide SCOM admins a means to do some overrides and email alerts on but providing almost nothing in the way of doing anything tangible with it via SCSM and SCO/SMA. All things considered, I actually can't blame SolarWinds here. After all, SCSM is a relative new player in the CMDB game so maybe SolarWinds genuinely hasn't gotten around to this? But equally plausible, maybe they won't get around to it. And really, either scenario is entirely ok! Because SolarWinds has never been a product focused around automation. It has never been a product focused around tickets. SolarWinds like so many other products in this space has its place and I don't believe there is any question that SolarWinds is still relevant and has a place in an IT organization but in the face of SCOM and SCSM I must admit - I quickly begin to hedge my bets.

Because when a network device goes down and you get an email about it, isn't it already too late? Wouldn't it be better if SCO/SMA tried several remediation steps first before alarming you? Before flooding your inbox? Before sending another email that you or members of your team are just used to deleting at this point?

Again, I want to be really incredibly clear with what I am saying because I feel like this post is destined to catch flak. I'm laying out counter points to the SolarWinds SCOM MP, these are not an attack or criticism of the SolarWinds platform in and of itself. The platform (as it stands by itself) is genuinely awesome, but when it comes to System Center integration there is certainly a ways to go.

So what's a better solution? Well hopefully you aren't surprised when I say it just might be a...


Better Together Solution
At the end of the day, I'm making my decisions in the name of Service Manager which is why it's best to look at SCOM and SolarWinds as complimentary solutions in your environment. Why?

• The shortcomings of one product are solved in the other
• The wants of one product exist in the other
• SolarWinds can shine as an amazing investigative tool for your Network Team
• SCOM can shine as this amazing monitoring/alerting tool for a host of things in your environment including network devices!

So this means you'll be performing dual SNMP monitoring of network devices in SCOM and SolarWinds. This is truly and I mean truly...the only way everyone gets exactly what they want. It's the only way you are going to make two different IT teams happy. To look at this as a "one or the other" is to do both products and your internal teams a potential disservice. If you have the means to both of these technologies, then by all means use both of these technologies to their fullest!

However if and I say if you have SCOM and are only evaluating SolarWinds I truly believe your expectation can be met for far less money in the way of SCOM, the future of SCSM, and letting your teams get a good night's sleep when SCO/SMA are fixing issues in the early morning hours.


Getting SCOM Network Devices into SCSM
Depending on where you are on your SCSM/SCOM journey you'll either already know exactly how to do this or need a pointer in the right direction. In short, importing the Network Management pack from SCOM into SCSM will automatically begin syncing those SCOM discovered devices over as SCSM Configuration Items to play with in your CMDB (i.e. SCSM). What's more, providing all of the crazily rich SNMP discovered data into SCSM.

There are lot blogs addressing this very topic, so I won't bore you with my own retelling of them:

• https://marcelzehner.ch/2013/06/22/network-device-management-in-the-service-manager-cmdb/
• http://blogs.catapultsystems.com/cfuller/archive/2012/07/13/how-do-i-integrate-operations-manager-2012-network-devices-into-service-manager-2012-as-configuration-items-scsm-scom-sysctr/

With your Network Devices pulled and updated from SCOM into SCSM, you continue to expand and open the possibilities of self-service and automation! Need some ideas?

• Got a Firewall that controls websites internally? Service Request!
• Need to shut down ports? Change Request!
• Switch go down? Incident!
• Unusual activity on a few ports? Shut em down with SCO/SMA
• Need to see all the models of a particular switch? Create a view!
• Want to report on all the Incidents, Changes, etc. about a Router? Glad you have Configuration Items because your Data Warehouse is spilling over with data now!

In conclusion...
I hope I've cleared a few things up. I hope I haven't too deeply offended anyone (again, not my intention for this post), but more than anything I hope I've helped someone out there quickly sift through some pros and cons of these platforms!

Read More

Just Enough (Temporary Remote) Administration - (Part 1)

Scenario/poll: Show of hands administrators - how many of you have an environment wherein individual user accounts are granted remote desktop access, to specific machines, and still have them even when they don't need those rights?

Keep your hands up - how many of you would like to know who those accounts are? When they got that permission? Who gave them the permission? etc.


The above scenario I'm sure is a common one that most departments will either deny or have no idea to the extent that it's happening. Even still, should the question be posed of "Well how bad is it in our environment?" who can answer this question quickly? I mean truly quickly. I mean in under 1 minute quickly!

Service Manager to the Rescue...
In the days before SCSM and SCO/SMA I found myself in this situation all too often. Whether it be places I was working full time or consulting at, there was always a degree of this one-off and non-auditable behavior. In the time since a lot (and I mean a lot) of single purpose tools have been created to address this incredibly specific situation. But with those tools come some rather high price tags.

I am a huge fan of less tools, more standards, and leveraging what I have before committing to something wholly new (and so wildly specific in this case). So with System Center in your environment, could we address this issue?

HELL YEAH!

To solve this, we're going to leverage native Service Manager and Orchestrator functionality. 1 Service Request and 2 really tiny runbooks. Depending on your experience with the ecosystem the following is either going to incredibly obvious making this post a waste of your time OR perhaps you're just getting started and looking for ideas to impress your colleagues. So if it's the second one...let's impress your colleagues!


So just what exactly are we going to build?

• Reduce privileged access in the environment through SCO
• Provide instant auditable and reportable data through SCSM
• Prevent members of your organization from "gaming" this request through SCO/SCSM

Enough teasing your respective IT security teams. Let's get to building.

It's not backwards, it's Orchestrator first...

We're going to create two runbooks within Orchestrator as our first steps. If you followed my "New Employee" and HR processes series of blogs OR you're just getting started with System Center this approach may seem entirely backwards but I assure you it'll work out.

As a preface to this, whatever SCO account you choose to accomplish this will absolutely need to be a Local Admin on the machine(s) you are going to perform this against. While I originally thought to myself "Ugh, I don't want to grant admin access to another account. That's the thing I'm trying to solve!" But again - we're adding a single automated account that no one controls (except Orchestrator) to invoke these actions on our behalf.

• UPDATE: I wanted to expand a bit more on the above paragraph with respect to "whatever SCO account you choose..." as it always seems to prompt the question "Well how could I chose?" By default the "Run .NET Script" activity will be run with the SCO service account. Since you probably don't want to distribute the Orchestrator service account to machines in your environment it would make much more sense to create a dedicated account to perform this function. Then save it's username and password as Global Variables in SCO. Then use an invoke-command with the scripts found below and leverage the credentials there. That way SCO is the thing spinning up the script, but it gets executed with an entirely different set of credentials on the remote machine. If you're unfamiliar with how to call credentials in PowerShell this is the most straightforward post on the matter. Just wanted to add this as I was writing this post in conjunction with deving this in a dev environment and as such not thinking this through as much as I should have for a post trying to be so security focused.

Runbook 1 - Grant x Permission on y Machine
High Level: We're going to obtain the Affected User of a Service Request, take the Windows Computer they selected on our request offering page, take the time they needed on this machine and then add them to some local security group on a machine. For the purpose of this post, I'm going to hardcode "Administrators" into the PowerShell script that grants permissions. However I'm confident that after walking through this, you could easily see how to alter this to either change the local group in the PowerShell script or allow the requesting user to select which group they would want to be in and then pass it into this runbook.

Finally, we'll have this (aforementioned) runbook execute a child runbook so they get removed from this group when the time they selected is up. To prevent the requesting person from keeping the permission, we're going to make sure this child runbook is not dependent on finishing based on the Parent Runbook's status (which will be "Complete"). By doing this it means once the first runbook finishes, the Service Request will be marked as Completed even though this second, non-dependent runbook is silently counting away to remove permissions at the selected time.

Initialize Data: We'll create one parameter and call it "ActivityGUID"

Get Relationship (RB to SR): We'll move from the SCO Runbook object and get the related (parent) Service Request

Get SR: We'll get the Service Request object

Get Relationship (SR to AU): We'll move from the Service Request and obtained the Affected User

Get Affected User: We'll get the related object from the previous Get Relationship step and obtain the Affected User object

Get Relationship (RB to Windows Computer): We'll get the Windows Computer that was selected on the request offering and mapped to the Runbook.

Get Computer: We'll get the Windows Computer object

Grant Access on Computer: We'll take all the objects we fetched from our previous steps and use it to drive a PowerShell script that adds the Affected User to the Local Administrators group on the selected Windows Computer. The good news is this PowerShell script will work with PowerShell 2.0 functionality, so you won't have to pull your hair out dealing with workarounds for getting PS 3+ working here. We'll use Ed Wilson's "The Scripting Guy's" two liner and just substitute the variables with our variables from the SCO databus. We'll also add a few lines for some simple datetime math. I've also put the script in here so you can quickly copy and past.

Don't forget that you'll have to head over to the "Published Data" tab on this Run .NET Script activity and make sure you publish the variable "timeToWaitInSeconds" so you can consume this data downstream in the second runbook. As far as datatype, a string will do.

[datetime]$currentTime = get-date
[datetime]$srScheduledEndTime = "srSCHEDULEDENDTIME"
$timeToWait = $srScheduledEndTime - $currentTime
$timeToWaitInSeconds = $timeToWait.TotalSeconds

$computer = "COMPUTERHERE"
$group = "Administrators"
$domain = "DOMAINNAME"
$user = "USERNAME"
$de = [ADSI]“WinNT://$computer/$Group,group”
$de.psbase.Invoke(“Add”,([ADSI]“WinNT://$domain/$user”).path)

So why the whole $currentTime thing? Why not just use the Service Request's created date, or the Runbook's Created Date?

The request process I'm showing only addressing the technical backend of this whole thing. That said, it would make sense that in your Service Request template to perhaps place a Review Activity before this activity or any other series of internal organization processes before this runbook invokes itself. But whether you do or do not when this runbook invokes it will grab the current datetime so that when the calculation runs to determine "how long to grant access" it will be the most accurate reflection of time that was requested.

02 - Revoke Permissions on Computer: Finally we'll pass all those previously obtained objects and the requested time into a non-dependent (i.e. "Wait for Completion" is unchecked on this Invoke Runbook activity) child runbook that start-sleeps for the selected period of time before removing the permissions. But before we can pass these variables from the SCO databus, we'll need to construct the 2nd runbook and create some parameters first. This one is super simple:

Runbook 2 - Remove x Permission on y Machine after z Period of Time (glad I only need three variables in this lead in)

High Level: We're going to take the Affected User, computer, and period of time in seconds from the parent runbook and pause this runbook until the timer expires.

Pause? How are we going to pause? Orchestrator and even SMA (PowerShell) don't really pause, they sort of just go and do their thing.

Quite simply we're just going to leverage the "start-sleep" cmd-let of PowerShell for the time the user selected on the Service Request.

Oh. Yeah...that. Nevermind.

We're also going to allow concurrent executions of this runbook so multiple people can make the request at the same time in addition to getting their rights revoked at the time selected as opposed to letting runbook jobs get queued up thus breaking the thing we're trying to setup here. But how are we going to remove the user that originally requested this? Good news, it's the almost identical script used in the adding of permissions, we're just going to change a few things. See if you can spot the differences.

Also the published data used in the screenshot here is the Parameters you'll have to create for your Initialize Data activity that proceeds this. To be perfectly clear those are:

• endTimeInSeconds
• computerName
• userDomain
• username

As for the script:

start-sleep -seconds "TIMEINSECONDS"
$computer = "COMPUTERHERE"
$group = "Administrators"
$domain = "DOMAINNAME"
$user = "USERNAME"

$de = [ADSI]“WinNT://$computer/$Group,group”
$de.psbase.Invoke(“Remove”,([ADSI]“WinNT://$domain/$user”).path)

This completes the Orchestrator part of this request. Next thing we'll do is head over to SCSM, sync these runbooks, create their respective activity templates, create the Service Request template, add the runbook activities into the SR template, then finally create the Request Offering.

If you made it this far then the "hard part" is over! I hope this provides a framework which you can build off.

• Maybe call a script to delete local user profiles after the timer expires?
• Maybe send the Affected User that their time is going to expire soon?

I'm sure there are any number of organizational processes you could incorporate into this! In the next post, we'll do all of the SCSM work.

Until next time. Make On!

Read More

But seriously...someone explain Management Packs to me

If you're new to the Microsoft System Center realm (and as I often joke) I have but two simple words for you:

Buckle up

When you're getting started in SCOM or SCSM you will very quickly run into the concept of management packs. Regardless of how little or much experience in you have in IT, if you've never used System Center then you've probably never had to come around to this concept of a management pack. As it was first explained to me...

Management packs store customizations that extend the core platform

And while it is most certainly a factual description, there isn't really anything tangible about that statement. I would argue that's the kind of statement that you come to understand with experience and less of a reasonable explanation to any newcomer of the platforms. Since there isn't any use in making you feel like an outsider, let's break down the roles of SCOM/SCSM first which may help you to come to understand what these things are and the architectural reasoning behind them.


SCOM/SCSM really can't do all that much out of the box...
The opening to this may come as a bit of a shock to some but like any new tool in an IT environment their is a degree of mandatory required configuration.

So let's start with possibly the most cliche of analogies - if you were building a house, you'd need to pour the foundation and get basic infrastructure up. After you have the core structure setup, you're free to add whatever you want onto it. Hardwood floors, solar panel roof, etc. The point here is that you probably intuitively understand their is a clear separation between the core house/infrastructure that was built and all of the amenities you choose to place inside of it.

It's with this said SCOM/SCSM are no different in that they are both core pieces of infrastructure and don't really provide much measureable value until you start customizing them to your particular needs. This is where the idea of Management Packs come in.


"Well the product doesn't do this natively. It could, but..."
So let's go through a brief exercise and we'll pretend you, the reader, are Microsoft. I mean, you are all of Microsoft. The all powerful Zoltar..err Microsoft. You need to create a piece of software that any customer could use and tailor to their needs but one that you could still upgrade, patch, etc. at whim without disrupting A SINGLE ONE of their customizations. How would you achieve this?

Again, returning to our house analogy - Microsoft has constructed the houses of SCOM and SCSM. But they've left it up to you to design, customize, and tailor what's inside of it. What's more, the only thing you can't do is touch the core infrastructure. You can build off of it, you can copy the work and built duplicates inside but you cannot touch the core infrastructure. You could even hire contractors (vendors) to do some of this improvement for you. Enough analogy, let's get practical with examples of two such customizations.


A Service Manager example...

Show me a view of all Incidents, that are in an Active status, created in the last 4 days.

While a perfectly reasonable view you may want to see of Incidents, is it a view that all customers who deploy SCSM want? Wouldn't it be easier to leave this kind of custom views to customers? Does it not make more sense to leave these kind of things to "organizational processes" and less "enterprise standards" ?

So if Microsoft won't roll this out of box for you, it makes sense to leave this kind of customization up to you. How could this be done? With a custom, unsealed, management pack.

Create an MP in SCSM, store all of your custom views per your needs inside of it. Problem solved.


An Operations Manager example...

I need to alert on a group of network devices, that are switches, whose location is data center 12

As it would stand to reason, no two customers are alike, and certainly their naming standards would vary dramatically. Your network engineers more than likely (or hopefully) have written the location attribute of network devices onto switches, routers, etc in your environment. You load all of these network devices into SCOM, but you want to alert now on a minority of them. How could this be done? WIth a custom, unsealed, management pack.

Create an MP in SCOM, create a Group in the Authoring pane, and create a dynamic membership rule that says something to the effect of All Network Devices, that are of class Switch, whose Location contains the words ''data center 12". Problem solved

Alright, I'm following you so far. Those are clearly customizations unique to me the customer. But those seem simple. What about MPs that change/alter/enhance functionality?

3rd parties, vendors, and the open source community...
In the above two examples I'm really addressing some very, very, very basic customizations to the platform. I would argue they are foundational configurations that everyone in the platforms will inevitably perform but do not address MPs of true function. So let's turn to SCOM for the next example.

Out of the box, SCOM comes with some management packs for monitoring basic Windows concepts. But if you want to monitor SQL specific concepts, you head over to SCOM, you request to download MPs from the catalog, search for SQL, and import those MPs. BOOM! You can monitor SQL.

Well I'd hope so! SQL is a Microsoft product. Exchange, IIS, these also seem all too obvious. What about my Cisco UCS chassis? What about monitoring Certificates in my environment that are about to expire?

While some of these MPs to monitor/discover things in your environment are a bit obvious and an assumed fact given they are Microsoft technologies what about the other stuff? This is where 3rd parties, vendors, and the open source community comes into play. So let's talk about those two aforementioned examples.

Want to monitor a Cisco UCS chassis? It isn't a Microsoft technology so the chances of Microsoft having an MP for this are highly non-existent. But Cisco, the manufacturer of said product does in fact provide an MP for SCOM to monitor their equipment. AWESOMETOWN!

Certificates expiring in your environment? The Certificate Authority MP provided by Microsoft really only tells you about health of your CAs. But it does almost nothing in the way of telling you about individual certificates. But with a little searching - clearly someone/a group of people were frustrated at this lack of functionality so they custom authored and made a management pack available to perform this very task. MOST EXCELLENT!

Turning back to Service Manager, wouldn't it be great as a CMDB to sync things like Projects into it? Fret not, because vendors have got you covered. What isn't made available by Microsoft, 3rd party products, or the open source community - vendors are ready to develop and extend the core functionality of the products to make them infinitely more flexible. But it goes without saying, for a price.

But what if no one in the community, 3rd party, or vendor makes something that is highly unique to organization? Good news - you can author your own MPs!

• Alter the SCSM Incident form so the Description field automatically expands
• Build a custom SCOM Windows Server class based off of the Microsoft one to monitor an application unique to your organization
• Extend the SCSM Service Request class to feature true/false values to use in all of your Request Offerings (bool01, bool02, bool03)
• Network engineer? Get friendly with XML and build a custom SCOM network monitoring MP to get even more data than what native SCOM provides.

And again - management packs are all done in the name of making both products highly modular, highly customizable, and allowing Microsoft to patch core infrastructure without disrupting your/3rd party customizations. Well ok, there was that one time with that UR9 for SCSM...

So what gives with this lock icon on some MPs but not others? Or rather, what is with this concept of sealed vs. unsealed management packs?

When we talk about the concept of sealed (lock icon) vs. unsealed (no lock icon), what we're talking about is along the lines of permissions with respect to that specific MP. Hrm...alright let me try again:

Unsealed Management Pack (no lock icon): An unsealed MP is one that customers create and modify somewhat regularly. They could contain things like SCSM Incident templates unique to the org, they contain custom alert groups for SCOM per devices in their environment. The point is they are custom, can be modified directly within the SCOM/SCSM console or via export and editing their XML.

Sealed Management Pack (lock icon): A sealed MP is one that authors (3rd parties or even customers) create to help further define and or extend the platform. Let's look at SCOM, there is a sealed Windows Server MP written by Microsoft. To prevent customers from intentionally or accidentally modifying it, the MP has been signed (sealed with a secret key generated and held unto Microsoft). This MP contains the matching/discovery criteria for finding Windows Server in an environment with respect to SCOM. It makes perfect sense they don't want customers to potentially modify this! Turn to SCSM, the Incident library contains all the element that define what an Incident is in SCSM - again, it makes perfect sense that Microsoft doesn't want customers modifying core pieces of infrastructure in these platforms. But what if you wanted to add a new Text Field to the Incident class/form? You can't touch their MP, but you can create your own sealed MP that extends the core class. Thus introducing the concept of MP dependency (i.e. for your MP to be imported, the core Incident class must exist first). This new MP you create would be signed/sealed with a secret key that you/your organization generates unique to your deployment.

Hrmm...I'm...I think I get the difference your making. But...well I'm just not sure.

So the stock Microsoft MP for Incidents contains all those fields/relationships and you want to introduce a new one like "Estimated Downtime". Per standard SCOM/SCSM MP architecture you are actively prevented from touching the Incident class because its in a sealed MP as defined by Microsoft. So how do you get this new thing? Using the SCSM Authoring tool you grab this MP that contains the stock Incident class and choose to Extend the Class. The Authoring tool stops you immediately and says "This is a sealed MP. I can't let you do this. Please pick a custom, unsealed MP to store you customization." So you create a brand new MP (*.xml). It now has a dependency on the core Incident class. In your new MP you say "Create Property" and name your new property something to the effect of "EstimatedDowntime."

You save the *.xml/MP file.
You seal this new MP (which converts the *.xml to *.mp)
You import this new sealed MP into SCSM

Wait a second. Why do I have to seal my new MP? I'm extending their core class with a custom thing of mine and you said I keep customizations in an unsealed MP...

Wait! Wait! Just think about this for a second! WAIT! Alright here's why - because YOU want to prevent unauthorized customizations from being made to YOUR new MP within YOUR organization/team of people. That and from a technical/Microsoft documentation perspective, class extensions should be stored in sealed MPs.

That...wow...So that means Microsoft plays by its own rules, 3rd parties play by those rules, and I in turn do as well. It's like this is some kind of standard!

So all of this means that every Incident in the entire SCSM system (new and old) gains this new text field of "EstimatedDowntime." Sooner or later when the MPSync job runs for SCSM and its Data Warehouse, you'll see your new field along side all the stock fields. Letting your customizations ride directly alongside Microsoft's but still fundamentally keeping them separate (from an MP perspective). This concept of extending the (Incident) class is fundamentally no different than extending your Active Directory schema.


In closing - this post isn't meant to be a "in defense of...", this isn't meant to be a "this is why these platforms are bad/good" - this is just simply the kind of plain English, non-technical thing that I wish existed when I was just getting started in System Center and it's one that I truly hope makes the whole concept behind management packs in SCOM and SCSM a bit more digestible.


So more confused? Less confused?
Leave a comment and I'll gladly expand or even update this post!

Read More

i3lets, an open source Interactive Intelligence PowerShell Module

Well if it isn't obvious, this really isn't a Service Manager focused post. Well ok it sort of is. You know what - little bit of column A little bit of column B. This is a PowerShell centric post with regards to Interactive Intelligence phone systems. While Interactive Intelligence seems to be making all sorts of waves with their phone system (leader in Gartner Magic Quadrant for Contact Center 8 times in a row per their website), the thing missing to me as a SCSM/SCO/SMA snob is the ability to control it with PowerShell. Fortunately they offer the IceLibSDK, a C# library that allows development for their phone system and in doing so...indirectly enable PowerShell control over it.

So after a few hours (it was about 5 hours) I discovered not only does the IceLibSDK ship with an example PowerShell module but it will never load/compile out of box. I've reworked it, recompiled, and most importantly extended the functionality of the OOB example of ConfigurationCmdlet and produced i3lets to work with PowerShell 4+

i3lets are an open source PowerShell library I created to enable administrative control of an Interactive Intelligence phone system. Using these, you can begin to automate all of the classic IT administrative duty of automating said phone system. Create users, modify users, license users, reset passwords (sounds like a great self-service request for Service Manager). This binary module has been tested and confirmed working against PowerShell 4, 5, and SMA.


This is a 100% first pass at a PowerShell module for said phone system that gets the job done but has tons of room for improvement. If you feel like you could contribute in anyway, please ping me and I can get you involved in the Codeplex GitHub project. Otherwise, get your download on and start automating!

Read More

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

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.

Read More

In Defense of Class Extension vs. Inheritance

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.)

Read More