in a service provider environment (ie. share infrastructure between companies), having the software metering enabled by site as opposite per collection can cause an extra network flow (ie. company 1 needs to monitor outlook.exe while company 2 mozilla.exe).

current software will force all clients to look for outlook.exe as well as mozilla.exe and this could cause performance issue, this also could be a security issue as the information of the monitoring software is stored on the client computer and if the client is monitoring the execution of a software that will be launched, this info will also be available to all machines.

with this approach, this could also increase the limit of rules as not all will be applied to all machines

Since ConfigMgr is now more user centric, it would be nice if user specific settings(registry) are discoverable via Hardware Inventory ( or a new inventory function. I would not consider this a DCM as we are looking to query and report on the data that is on the users profile vs a DCM which checks for compliance. Example would be something like if a user has a proxy set, what is it. Another example would be discovering all the trusted sites a user has configured. This would help us identify sites that we may need to include in a GPO trusted sites deployment or if there are unwanted sites that people are trusting.

I've dabbled with the deployment of Cloud management gateways, and Cloud DP's and one thing that I observed is that when you create the CMG or CDP you are specifying a region to deploy where you want the resource to be located (east US, West Europe, etc)..
As someone who manages SCCM endpoints at a global level, trying to deploy resources to handle staff to operate across multiple geographic locations (US, Canada, Europe, Australia, New Zealand) you can imagine that I need a lot of Cloud resources to keep traffic local to the endpoints.
It would be fantastic if there was a means to utilize Azure Traffic manager, so that I could point my SCCM endpoints at a single traffic manager location, rather than having the overhead of trying to figure out where in the world the endpoint/employee is working .. it would be a huge reduction in the management overhead currently done.

Currently, changes to configuration.mof appear to be read in based on the timestamp of the file.

This means that if you restore configuration.mof from a backup, it will not be re-read into the database because the timestamp is older.

Recently I had to force a re-read of a backup of configuration.mof by making a trivial change to a comment in the file so that the timestamp was changed and thus hardware inventory would again run on my clients.

It would seem that perhaps a checksum of the file compared to a file that was read in previously would resolve this issue.

There is a hard limit of 50 MBs for Hardware inventory set within the data loader for MIF file. If you enabled AI classes to collect more data by SCCM, it is not unusual for these computers to hit this hard-coded limit. This causes an endless loop of resyncs being performed by SCCM clients. the resync then consumes network bandwidth and processing time on the client/MP/etc. It is not until it hit the Data loader that these MIF files are rejected and ultimately a resync occurs to start the whole process over. The hard code limes should be increased to 200MB (for now), this will stop this issue and allow the computers to only send delata after the full inventory.

The "Automatically create disabled metering rules" in Software Metering Properties should be "Specify the percentage of computers WITHOUT the software" rather than "Specify the percentage of computers that have the software".

Because of the way corporations license software we don't care about metering the items that 70% or more of the company has on their machines (the way the rules are currently set up to be created) we care about the software that is used on 60% or less of the computers.

The current calculation method for automatically creating software metering rules just clutters it up with rules for things like explorer.exe, notepad.exe, and acroread.exe. What we want to see is things that are expensive licenses used by just a few users like acrobat.exe. Current method gives us exactly what we don't care about and never gives us what we do care about. It is backward.