Apr 10, 2018 - 08:01 AM
I LOVE SCCM. ;)
Full disclosure: I'm a SAM vendor, our web-based SAM solution 'consumes' SCCM data, and portions of the SCCM inventory - the 'AI' stuff- came from Microsoft's acquisition of my previous company 'AssetMetrix'). That said, I have no commercial interest or dealings with Microsoft ( don't sell their products, nor own stock).
There *are* limitations to SCCM inventory, but they are - for the most part - non-sequitor to SLM & SAM.
1) Metering: Yes, metering *can* increase network loads based upon how it is configured ( i.e. granularity of time-scope, number of 'apps' to monitor, number of monitered apps out there.) .... but I would suggest that you consider metering as a post-license license 'resposne/remedy' tool rather than a license management 'determinator.
Here's the rub... actually 3 rubs:
a) Many of the widely distributed apps in your environment are part of a suite. It makes no sense to determine that powerpoint isn't being 'used' if it's removal has no SAM-consequence on the use of the 'suite' ( i.e. word, outlook, excel, etc.). More or less, exclude any suite offering from the application analysis.
b) It takes time to record time ( unless you can find a flux-capacitor and a spare 1.21GWatts) The longer you run metering, the better the view of usage is (changes in usage from day to day, week to week, over the quarters), but more robust data means a delay in analysis & response.
c) This one is critical: As you go down the pareto curve of software 'spectrum', the corellation between amount of use & 'value' falls apart very quickly. In other words, the less popular apps have 'punctuated' value in which the time used doesn't relate to value for the company.
Take Office Project for example; if Nancy only used it 1 hour a week, and Fred used it 15 hours a week, who is more 'worthy' of having Project? Nancy happens to be the manager, and is applying Freds efforts into a larger 'work-chain'. They both have value that can't be expressed in 'time used'.
SQL editions: You can blame Microsoft for the 'missing' edition names for SQLServer ( and Exchange!), but you can't blame SCCM. SCCM - most other network mgmt apps - use the entries in a specific section of the Windows registry of a device to grab the list of software titles ( same as for apps that use WMI method). The root issue is that the 'SQL edition' is found in a variable location in the registry, and these 'calls' do not necessarily have the conditional logic to go rummaging around the registry ( though MAP was built specifically for this).
The reason for why it may not matter is that the SQLServers you need to worry about are typically on Servers... and Server admins typically don't allow network admins to monitor/control their servers. Get out of the office if you ever hear that a network admin invoked a reboot-required patch on a mission critical server in the Datacenter! If SQL Server is on a desktop, it's likely that it's a non-production installation ( and thus typically exempt from licensing under your EA). If SQL Server is on a server, it's likely SCCM is not allowed to inventory it.
So, how does SCCM metering play as a SAM tool?
1) Sniper the applications based upon the danger over-deploys. If you have 20 installs of CorelDRAW, but 40 licenses.... what good is removing 2 from the herd of 20 when you're only at 50% entitlement capacity? Determine your current license position first, then target each app based upon likelyhood of over-deploy and unit cost
2) Take out the zombies first: Run SCCM to find the 'NEVER' run applications; at Zero usage, such application are an unwarranted drain on your license pool.
Metering should be considered as one of many tools to help drive down costs, but you may not be allowed to use it (Servers), some of the apps may not require pruning ( non-critical license pools) and some applications can't be valued where time is the X-Axis......
Apr 10, 2018 - 10:21 AM
Best advice is put it to the test. Pull your SCCM data into your SAM tool. Select a sample set of devices and install tool agents. Conmpare the hardware, installed software and software usage reports and decide whether SCCM meets your needs. I did just that recently, not for SCCM, but another similar tool. The results were very different, metering and software recognition through SWID tags were the main differentiators.
I would also argue that SCCM is used in many server environments I have come across. It makes absolutely no sense to meter server applications (unless they are desktop applications installedon a server and deliver via RDP/Citrix/etc, however, the ability for a tool to identify versions of SQL Server is critical. SAM tool agents generally do capture this. Even if it is on a desktop, it still needs to be licenced in one form or another (unless it is free to use Express or Developer edition)
Lastly, on the question of not metering applications that are overlicenced. Well, that depends on your notives for implenting SAM. If you wish to treat SAM as a function for identofying underlicencing only, then yes, leave out that products that are overlicenced. If you want to save some money at your next renewal, then these should be metered too so you can stop paying for software you aren't using.
Apr 11, 2018 - 12:07 AM
I would suggest you work out what/when you need to report (e.g. Desktop Apps monthly, Servers quaterly) and work out which pieces are important and relevent and which are not. SCCM should give you all the data you need, it might need a little bit of work on top, but once you have a baseline, the repeats are much quicker.
(Oh and use MAP for SQL)
Apr 11, 2018 - 12:34 AM
On the metering side, we typically do not use this data for 95% of apps; in most cases all we need to know is whether the application has been used in the last 90 days, and SCCM keeps a record of the last time each executable was used in the recently used apps table. It's pretty simple, just Executable details and last used time. We would recommend metering be used for high value applications, thus limiting the network traffic.
For SQL, you can set up custom collections to get the edition data, and if you use Service data you can match them to find Passive or unused servers by getting the not running/ manual start up and disabled servers, Custom collections using MOF files and scripts can also be run to gather most things we need; license keys and files being a good example.
despite supporting non-windows platforms, we still are not seeing much take up of use of this amongst our clients, largely down to most already having ADDM, UDI or similar already deployed.