The most common source of inventory data used with 1E AppClarity, our Software Asset Optimization product, is from Microsoft System Center Config Manager (aka SCCM or ConfigMgr). AppClarity can take data from several sources, for simplicity sake, the specifics herein relate to ConfigMgr 2012.
When dealing with ConfigMgr, the inventory data is used to calculate software install count and usage for desktop environments, which is displayed in AppClarity console. This enables users to make intelligent decisions and save money by reclaiming software from machines which are not actively using it… However, there are a few occasions where the install count and usage information may change slightly between ConfigMgr and AppClarity, the number might lower than expected, after completing end-to-end syncs, using scout.exe and ActiveEfficiency sync.
It’s important to understand that a lower number of software install count and usage following a completed end-to-end sync might not necessarily indicate a problem with AppClarity. In this blog I will demonstrate how to identify possible cause of discrepancies in software install count and usage.
I am going to start by reminding you that in AppClarity “Machine Inactivity” is set to 7 days and “Hardware Inventory Threshold” is set to 8 days be default. What do these values actually mean and how do they impact software install count and usage?
In ConfigMgr Hardware Inventory is enabled in the Default Client settings. By default Hardware Inventory is scheduled to occur every 7 days. Also in ConfigMgr Heartbeat Discovery (used to maintain the ConfigMgr client active status in ConfigMgr database) is enabled and ConfigMgr client sends a heartbeat every week (7 days).
Based on this information we can conclude that if a ConfigMgr client has not sent Heartbeat Inventory data for more than a week and/or the ConfigMgr client Hardware Inventory was not processed successfully for more than 8 days, AppClarity scout.exe and ActiveEfficiency syncs will mark the device record as “inactive” in the AppClarity database. When the device record is marked as inactive in the AppClarity database the software install count and usage are not displayed in the AppClarity console.
Please note that AppClarity never deletes devices record information from the AppClarity database for reporting reasons.
Now we have clarified what may cause the software install count and usage information to lower in the AppClarity we can now identify if there is a genuine problem or if this is expected behaviour.
There are valid reasons why ConfigMgr clients may not sent Heartbeat information and or Hardware Inventory data. This could simply be because the device is shutdown (the user is on vacation) or the device has not connected back to the corporate network, for example if a laptop user is currently travelling with no remote access.
In both scenarios above, we expect the device to update its Heartbeat and Hardware Inventory information in the ConfigMgr database as soon as the device connect to the corporate network. AppClarity should then update the device record back to “active” at the next end-to-end sync.
What if the device is being used, connected to corporate network but still not showing the software install count and usage information? Don’t panic! I have below few tips to help identify if there is problem in ConfigMgr client, in AppClarity or in both.
In ConfigMgr the Reporting Service Point provides a few built in reports which very useful when trying to identify ConfigMgr clients that have not reported (sent Heartbeat data) and not inventoried recently (not has Hardware Inventory processed) in a specific number of days:
This report would help to find a number of ConfigMgr clients that have not sent Heartbeat data in the last 7 days.
This report would help to find a number of ConfigMgr clients that have not been inventoried in the last 8 days.
This report would help to find a number of ConfigMgr clients that might be duplicated in the ConfigMgr database.
Any machine returned on the reports can be potentially marked as “inactive” in the AppClarity database. It’s also possible to verify the machine Heartbeat DDR and Hardware Scan status in the ConfigMgr console, Assets and Compliance, Device node. By clicking on the device name the Summary tab will shows the Client Activity last Heartbeat DDR and Hardware Scan date and time. Please note that the Summary tab information might not be real time.
Finally, it’s possible to right click the device, click on Start and Resource Explorer. Under the device name, expand Hardware and click on Workstation Status. Verify the Last Hardware Scan (Client Local Time) for the last hardware inventory information inserted in the ConfigMgr database for the device.
If after verifying the information above you suspect the ConfigMgr client for a particular device (s) are not sending Heartbeat and Hardware inventory information to ConfigMgr, there are a few logs that can assist to identify the cause of the issues:
ConfigMgr client logs
InventoryAgent.log
Located under C:\Windows\CCM\Logs folder (default location) the InventoryAgent.log shows information for Hardware Inventory, Software Inventory and Heartbeat. Review this log for possible issues such as WMI corruption when the ConfigMgr client in processing Heartbeat and Hardware inventory data. It is possible to force a Heartbeat and Hardware inventory cycle in Control Panel, Configuration Manager “Properties and Actions” tab. Select Discovery Data Collection Cycle (Heartbeat) or Hardware Inventory Cycle (Hardware Inventory), click “Run Now” button and then “Ok”. Verify the InventoryAgent.log for possible errors.
ConfigMgr site server logs
There are a couple of logs in the ConfigMgr site server that could be useful for troubleshooting:
DDM.log
The ddm.log might show possible errors which processing discovery information and Heartbeat for existing ConfigMgr client.
Dataldr.log
The dataldr.log will show possible issues with Hardware Inventory processing received from ConfigMgr clients.
You have likely now verified possible issues with Heartbeat and Hardware Inventory in ConfigMgr and resolved possible issues. What if the issues still remains? i.e. software install count and usage are still lower than expected? What should you do next?
The next steps are to look at potential issues with the ActiveEfficiency scout.exe sync and the ActiveEfficiency sync from AppClarity.
The first step if to check the scout.log, webservice.log and AppClarity.ServiceHost.log. The following file locations are the default location for 1E AppClarity logs and 1E ActiveEfficiency scout.log and webservice.log:
C:\ProgramData\1E\ActiveEfficiency\scout.log
The scout.log shows information during the scout sync which connects to the data source, (in this case, the ConfigMgr database), and insert users and devices into ActiveEfficiency database. The important information in the scout logs is if and when the sync has started and when it has completed. Also the number of users and devices processed:
INFO : Configuring Scout. Modes=configmgr
Total Users processed=[1000]…
Total Devices processed=[1000]…
INFO : Scout scanning completed successfully.
C:\ProgramData\1E\ActiveEfficiency\webservice.log
The ActiveEfficiency webservice.log shows users and devices information during the scout.exe sync post via the web service via IIS. The important information in the webservice.log is potential duplicated records from the data source (ConfigMgr database).
C:\ProgramData\1E\AppClarity\AppClarity.ServiceHost.log
The AppClarity.ServiceHost.log shows information on when the ActiveEfficiency connector (created in the AppClarity console during the installation) connects to the ActiveEfficiency server, syncs the users and devices information and calculates the software install count and usage.
If no potential issues are identified in the AppClarity and ActiveEfficiency logs, close the AppClarity console, restart the AppClarity services (1E AppClarity and 1E AppClarity Catalog Update Service) and reopen the AppClarity console, to refresh the in memory views. This may help to bring back the missing software install count and usage information.
If none of the above has resolved the issues then it’s time to contact the 1E Support team.