1 of 1 people found this helpful
Everything you need you can find here, also the download link for the sccm AI Jobs
Good Luck and a Happy New Year
2 of 2 people found this helpful
Not quite everything.
I thought there was documentation detailing a bug in the transformation for some component classes like operating system (mentioned by Andrius Seirys in the comments on that documentation page) but I could not find any link to that.
Out of the box, if you open the transformation which imports Operating System CIs, you will see that there is a hop from Filter Rows to CMDBLookup.
That hop should not be there (there should only be 2 hops coming from a Filter Rows step). Instead, there should be a hop from the previous step, CMDBOutput OperatingSystem going to CMDBLookup.
Unless this is fixed (also for other classes like NetworkPort and Monitor - and possibly others), then the component will be imported but there will be no relationship between the computer and that component.
Something else to be aware of is that the number of CIs from the SoftwareProduct transformation can be very large. When I discussed this in another thread, I was told that some customers disable it altogether. We customised the SQL in the table lookup step to only bring in certain useful BMC_Product CIs and exclude other types. On the other hand, we did remove the transformation creating BMC_Memory CIs since there was a value for memory already being written to an attribute on the ComputerSystem CI and we did not feel that we needed both.
We installed the 9.1 integration and later upgraded ARS and CMDB to 18.5. There do not seem to be any issues specifically relating to that upgrade even though Pentaho changes version from 4 to 6 in that time. Good thing too because when I tried to look up BMC documentation for the SCCM adaptor 9.1.04+, I ended up at a PDF which was a repeat of the 9.1 doc. Perhaps I just missed something there.
We made a couple of other customisations as well so it does not hurt to consider the integration that BMC supply as a starting point, study it well and adapt it.
Also, in the documentation, you will notice that there is a reconciliation job...
...which is nice, but it uses the standard rules which are better optimised for ADDM data than for SCCM data, and if you are using both (particularly if there is overlap) then you may need to consider things like ensuring the timing of the jobs is configured so that the ADDM reconciliation job runs first (because the standard rules use token Id a lot and SCCM data does not have this). If you do it in that order, it should be OK, but if a computer from SCCM is identified before the same computer in ADDM, then you may end up with two instances in the production dataset rather than a merged instance.
Oh, and talking about identification, we found some examples of computers in the SCCM source having generic values for Serial number such as
"Chassis Serial Number"
The fact that they are there at all is a Microsoft issue and not a BMC issue but if you also have similar, then you may want to customise the SCCM integration such that if it encounters values like this, it replaces them with a NULL serial number, otherwise some computers will not be identified because the identification rule which refers to serial number will think they are duplicate
If we go into the details, I would recommend a partner product for the integration - seamless datapump.
We had no problems with it and we‘re online very quickly with a good quality.
I've heard good things about Seamless - witnessed a demo once, but if that's not an option for any reason then the BMC integration (despite having room for improvement - part of which is in the details) can be made to work
Absolutely, only a little more expensive.
Happy New Year
In other words, we don't have a budget for anything and work mostly with duct tape and bubble gum to MacGyver fixes.