Saturday, August 26, 2017

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

11:49 AM Posted by A No comments

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 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 $

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!

Sunday, March 19, 2017

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

8:52 PM Posted by A No comments

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

Network Monitoring SNMPv1 and v2
Network Monitoring SNMPv3 (AES)
128, 256, 512
Alerting via Email
Alerting via Text
Alerting with Automation

Deep network analysis/investigation

Work Item Integration with SCSM

Configuration Item Integration with SCSM

*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:

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!