Building the perfect CMDB with System Centre Part 3

So this next part will focus on the enrichment of the toolsets which will allow you to obtain the best information and the cleanest in terms of integrity when it comes to your CMDB.

The default toolsets being focused around;

• System Centre Configuration Manager
• System Centre Operations Manager
• Active Directory

The backbone of your infrastructure most certainly has to be clean as it being the foundation for your orphaned objects if you are not careful of its up keep so will go through a few scenarios to consider in more finer detail.

Though this section does have an SCCM/MEMCM influence, we have to remember that computer objects at the end are always going to end up here. Depending on your environment it may go directory to the "Computers" OU or it will go perhaps to a designated OU of your choosing whether this is done by a selection within the AD tree or a variable to decide.

We find that we have template builds which can cover various technologies such as building tools (MDT, SCCM) but also templates which derive from hypervisor platforms (VMWare, Hyper-V, SCVMM). These can create AD objects but we also have a process in which we may rebuild multiple machines which either use the same computer object or perhaps a different name afterwards leaving the older AD object orphaned.

Be very mindful on the up keep of AD. Though these can be excluded through various options which we will cover later, they still need to be removed from AD at some point or another.

A child section perhaps of the section above. Once new AD objects come in they would need a clean up to placed into the correct corresponding OUs which apply to the AD Objects whether they are computer or user objects.

When it comes to finer discovery methods which can come from many tools, some organisations may find that just having a discovery across the entire domain or forest to be more intrusive and discover objects which they don't want to be found, or in the case of which specific objects they would expect to be in certain OUs, simply are not.

This does sound like a very minor action, but it really does make all of the difference when it comes to the overall integrity of the CMDB in general. Because anything not covered here, will eventually deteriorate once it reaches up to the CMDB level where you would have to develop more filtering enrichment than necessary to correct these things.

Perhaps the most overlooked and maybe the most important of all in fact!

When we think of the attributes in AD you may think of base ones such as

• Name
• Description
• OS
• Pre Windows 2000 (Netbios Name)

• Department
• Manager
• Owner
• Office
• City
• Address

The more information in your AD Objects the better information you will be able to extract overall from your CMDB. You will find once it does reach to the CMDB level these values would be empty. And as you don't have an asynchronous level between your tools and the CMDB the gap becomes bigger in terms of maintaining integrity on both sides.

Below is an idea on how your AD would look when enriched. So you would have your specific object classes which would all have fully or relevant populated attributes which would then feed into your CMDB

Your hardware and software inventory information all resides here. Also not to mention its also another pit stop for which your Active Directory will know doubt connect to, so its also a very important piece to have refined.

This is a tricky one, as we can't always account for how many devices within MEMCM will actually be online as such but good scheduling is also very important when it comes to these particular scans.

Another key element of the CMDB information is the Hardware and Software information which relates to each CI that gets pulled into it, so it is absolutely worth investigating your client settings (whether you use default or a custom device one) that you have the schedules done at one which is realistic as well as balances out the times in which it can get accurate scans.

By default these are set 7 days, most recommended or should I say popular tend to be between 1-3 days with 1 day perhaps being too frequent whilst 2 days gives a more appropriate amount of time to catch others which may have been off the network.

It would be a recommended idea to have the scans and the connectors for MEMCM to be somewhat in line with each other to ensure you are pulling a greater amount of successfully scanned machines to ensure your data is definitely up-to-date.

With orphaned objects of course being in AD, there is also the bigger one of them being in MEMCM which can not only destroy the integrity of the CMDB but can eventually cause issues within MEMCM as well.

Repeated builds on objects in MEMCM can indeed create duplicates, especially when identical information is shared on both records such as Mac Addresses and SMBIOSGUIDs. But this can also be caused if you have an object in AD which may not necessarily be active and this gets pulled in from your discovery methods and can leave greyed out records and can cause ambiguity when managing devices for other reasons.

There are a couple of ways in which you can avoid this. First lets look at how we bring objects into SCCM via the discovery methods. If we look at the settings below.

Here we can zone more into specifics of which OUs we want to bring in which is a filter on areas we dont want to include. But then we also have the additions of more advanced filtering which allows us to bring in objects which have either been active or not had password issues within a certain amount of time. Though we would expect to have a lean Active Directory, we still have to factor in the real-life scenarios of that there could still be some objects which would be troublesome.

Once that is sorted, how do we maintain the same cleanliness in MEMCM. We would look more into the Site maintenance tasks which would focus on clearing orphaned objects.

Another point to factor in is how we build machines in MEMCM if using All Unknown Computers. It is indeed convenient but it can sometimes make issues like these more tricky, where as pre-staging machines and with appropriate collection designations can make this a lot easier to manage otherwise.

Important to have very precise and to the point collections, ones that would be able to identify what the collection is for and the type of members which are in the collections.

Where Service Managers CMDB is concerned it focuses on the devices by collections, and if we are using a strategy in which the collections are query based and are specific to group membership or particular OU membership this can indeed help in terms of the enrichment of your CMDB structure.

You have the option of wanting to bring in devices using default collections such as;

• All Systems
• All Users
• All Desktop and Server Clients

• Test Accounts
• Service Accounts (Optional)
• Known Temporary machines/users

For those who perhaps manage devices in MEMCM which are other than WIndows such as;

• Linux/Unix
• Mac OS

So we can see the devices and users organised within the collection containers. We can also see the hardware and software inventory which would run on schedule for those devices and they would in turn be pulled into the CMDB from the SCCM connector within Service Manager.

This is where things are going to get very interesting here! This tool has such as wallop of importance to your CMDB. As this is where you will obtain all of your attributes for every single kind of class which your CI fits. But to get it there takes a substantial amount of work, but we will explain how to enrich this side.

The Management Packs in SCOM are truly king in this scenario, especially the ones which are marked Discovery and Library. Most management packs contain this kind of structure where the Library Management Packs contain the classes of all of the objects which make up the overall technology, and then the discovery management pack is then used to discover those attributes on the machines which have a SCOM agent installed.

By default Service Manager will have some base ones it will start to pull in from, but in order for you to truly unlock its power you have to import the rest of the management packs you have in order to really obtain all of the attributes for all of your classes.

Versions are also quite important, as any old versions can complicate the type of references you would require in order to get your objects discovered correctly. Save all management packs that you download either in a repository or at least make sure that they are within the default C:\Program Files (x86)\System Center Operations Manager Management Packs folder.

I wouldn't say this section has much of a focus on an enrichment perspective, but more of a note to say ensure your management packs are up to date and you have the original files for them.

Sadly enough when it comes to the connections from SCOM to your CMDB, there are no default attributes pulled in which actually indicate if a server is indeed managed by SCOM or not as well as its current health state.

Luckily this is covered in the next section of this series.

This section requires the most enrichment in every sense, though this is slightly off topic as this is more of the SCOM alerting connector for those who are using Service Manager as the basis to route alerts into.

Any configuration churns which impact very negatively on your SCOM estate such as;

• Thousands of alerts
• Performance Counters high
• Too many state changes
• Agents health and connectivity going up and down

So the SCOM Agents and classes all relate to the management packs which perform all of the discovery methods and they then feed into the Service Manager connector. So having the correct management packs imported into Service Manager is very important.

The next part will go into detail on how we create the custom connections to all of our other toolsets as well as developing a way to capture all of the attributes which relate to those same toolsets.