Cireson AM, whose dealing with Azure constructs?

Adam_Dzyacky

I'm still surprised there isn't a dedicated Azure ARM style MP for SCSM because it feels like I'd want to be syncing all sorts of Azure specific constructs (tags, vm size, etc.)

But with the advent of Cireson Asset Management, it feels like this may just be an SMA runbook away of syncing things you care about in Azure to items within your CMDB. Specifically, sync the VM Size as the Model number to a Hardware Asset, etc. etc.


I'm curious to know who has or at least started going down any Azure/SCSM style path with respect to building their CMDB out? And if so, what has your logic been behind those decisions of what you'll map where vs. extending the HW Asset class to deal with new Azure specific constructs?

John_Long

Hi @Adam_Dzyacky ! This is something I've been thinking of doing for our AWS resources. Renewing internal PO's as well as reservations is a frequently ran task for our AWS resources. I was thinking about extending out a new CI class for AWS Computer which would track the AWS attributes and then I'd relate the HA record to it a lá the existing SCCM synchronized content. Hadn't started to build out the CMDB classes yet, just gather the AWS data in scripts.

Certainly easier to just map the AWS attributes into the existing Hardware Asset class though!

Haven't looked at the Azure side as yet we we're mainly in AWS for now.

Adam_Dzyacky

I wrote this post before I even tried anything, but now after performing it I'm so far loving the results. What I did is pretty much exactly what I typed out - SMA job that pulls VMs (names, size, location), and sync them into SCSM.

Catalog Item Model = VM Size (i.e. Standard_DS3)
Catalog Item Manufacturer = (i.e. Microsoft, Amazon, etc. This sort of just falls in line with anything you already have configured I'd have to guess)
Location = This didn't require too much extra work, but because Location in SCSM isn't a plain text/string, I created wholly new location objects in SCSM with SMLets and new-scsmobject. (i.e.  Azure West, Azure East US, etc).

In fact, I actually just populated the Azure locations as a single PowerShell script, then used SMA to pull vNet/Subnet configurations for VMs and then create those subnets. Leveraging native AM functionality, I let the workflow start mapping machines to location based on Subnet. Now I have an unbelievably clear distinction of where resources are moreso than any portal could ever provide!


Really hoping this doesn't backfire in some unforeseen way, but it so far feels to make a great deal of sense. I think in the case of Azure or AWS - specific concepts (like tags/things you could have an unknown number of) may be best left to a concatenated string as the description/notes of the asset perhaps?

John_Long

@Adam_Dzyacky Tags are the exception alright and in my case, it's the tags I'd like to get at! I'll have a play around in my DEV system and see what translates for AWS best!

Adam_Dzyacky

Well @John_Long, I actually wrapped up the other day with the whole tag thing haunting me a bit and so far I can only think of two possible outcomes of this that work in Azure, AWS, or any other cloud provider:

1. Write key/value pairs as a hash table or some kind of format you decide into the current "Asset Tag" on the Hardware Asset

• The tags are certainly there then (albeit, one giant string)
• The class doesn't have to be extended and you can leverage the truly native Cireson solution
• The tags now require some custom parsing to view this intelligently in a SQL report

2. Extend the HW Asset Class to include new, vague tag titles (i.e. "Asset Cloud Tag 01, Asset Cloud Tag 02, etc.) And then store single key/value pairs in those items

• The tags are certainly there, but now a bit more digestible (at least from a PowerShell perspective) format
• The class gets extended in such a way that it would work for probably a bunch of other scenarios
• The tags still require custom parsing to view this intelligently in a SQL report

But the thing that holds true in both of these scenarios is that these are just strings, rendering them impossible to use as drop down values within a SQL report within the SCSM console. So my next workaround for this limitation is to front-end the report with a Service Request, that kicks off an SMA job that executes the raw sql against your DW.

Adam_Dzyacky

Hey @John_Long and any onlookers - I realized I had overlooked something potentially crazily obvious with respect to tags, Azure/Amazon constructs in SCSM that effectively negates my original post on this topic...

Take the same MP(s) and import them into SCSM. Configure the SCOM CI Connector to sync said assets. In doing so (at least with Azure, not sure what AWS MP's will provide) I managed to automatically pull the resource groups, tags, and pretty much anything else you'd care about with respect to Azure all consumable within SCSM.


It's with this said, I'd argue this provides a dramatically different take on doing (Cireson) Asset Management in SCSM because now you may not need to run to Azure/AWS with PowerShell/SMA to perform your "gets" - instead just shift the data how you see fit without ever leaving SCSM. What's more this means a "Build a VM" type of request can now use Query Results on things against Resource Groups, etc.