none
Software monitoring not getting data RRS feed

  • Question

  • Hi,

    Last friday, I enabled Software monitoring

    And create some rules

    After 3 days the rules seems to not being detect in MTMGR.log

    Creation event received for process 2868	mtrmgr	2019-12-02 07:29:11	8340 (0x2094)
    Process ID 2868 is for process C:\Program Files (x86)\ConfigMgr Console\bin\Microsoft.ConfigurationManagement.exe	mtrmgr	2019-12-02 07:29:11	8340 (0x2094)
    No matching rule found for process 2868	mtrmgr	2019-12-02 07:29:11	6952 (0x1B28)
    

    So I got a look in WMI with WBEMTEST but it is empty.

    I am not sure to understand what is happening.

    Monday, December 2, 2019 3:49 PM

All replies

  • To validate, what are your custom client settings packages deployed to and do they have Software Metering disabled?

    Note that this is one of a handful of reasons you should never change anything in the default client settings package and should always use custom client settings packages to apply changes.


    Jason | https://home.configmgrftw.com | @jasonsandys

    Monday, December 2, 2019 4:22 PM
  • Hi,

    Software metering is enable on the clients.

    The other custom settings are not deployed.

    Thanks,


    • Edited by FRacine Monday, December 2, 2019 4:32 PM
    Monday, December 2, 2019 4:27 PM
  • For your screenshot above, you have a specific version defined for the ConfigMgr console, is that the version that is running?

    For your examination of the CCM_SoftwareMeteringRule class, did you run WBemTest as the local admin?


    Jason | https://home.configmgrftw.com | @jasonsandys

    Monday, December 2, 2019 4:36 PM
  • Hi,

    Yes, as a test purpose I browsed to the file directly. I ran wbemtest with a local admin account. Seems I have the same issue for all rules.

    Thanks,


    • Edited by FRacine Monday, December 2, 2019 4:43 PM
    Monday, December 2, 2019 4:38 PM
  • Hi,

    Software metering has these dependencies:

    1. To use software metering, the client setting Enable software metering on clients must be enabled and deployed to computers. You can deploy software metering settings to all computers in the hierarchy, or you can deploy custom settings to groups of computers.
    2. You must configure a reporting services point before you can view software metering reports. For more information, see Reporting in System Center Configuration Manager.

    If you have checked all the above dependencies, we can refer to this blog post for further troubleshooting:

    https://techcommunity.microsoft.com/t5/Configuration-Manager-Archive/Taking-a-look-at-the-Software-Metering-workflow-in-System-Center/ba-p/273590

    Best regards,
    Larry


    Please remember to mark the replies as answers if they help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, December 3, 2019 9:22 AM
  • HI,

    1. Already done

    2. We are already using reporting

    On the site server the Policy box is full...

    Tuesday, December 3, 2019 11:02 AM
  • Hi,

    This morning the rule are appearing in WMI. It tooks more than 3 days. Nothing to understand.

    Tuesday, December 3, 2019 3:42 PM
  • Are you sure the client was successfully receiving machine policy during this interval? Did you try to force it?

    Are there any backlogs on the site server?


    Jason | https://home.configmgrftw.com | @jasonsandys

    Tuesday, December 3, 2019 4:58 PM
  • Hi,

    Yes I did! Which log would show me if the software monitoring rules were received? In WMI they were not there but I did not found a log showing if the client was querying and receiving the rules.

    Thanks,

    Tuesday, December 3, 2019 5:25 PM
  • PolicAgent.log and PolicyEvaluator.log show all machine policy activity. You're not going to see anything specific to software metering though, just policy ids.

    Did the machine receive any other new policies in this period?

    Have you tried adding a new metering rule and updating the policy on the system to see if it gets it? Or any other new deployment for that matter?


    Jason | https://home.configmgrftw.com | @jasonsandys


    Tuesday, December 3, 2019 5:29 PM
  • Hi,

    I suggest you try to follow the blog post I posted above to check the corresponding log files for more clues.

    If you have checked all the above dependencies, we can refer to this blog post for further troubleshooting:

    https://techcommunity.microsoft.com/t5/Configuration-Manager-Archive/Taking-a-look-at-the-Software-Metering-workflow-in-System-Center/ba-p/273590

    Best regards,
    Larry


    Please remember to mark the replies as answers if they help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, December 4, 2019 8:22 AM
  • Hi,

    We found 3 files were stuck in policypv.box on the site server and removed them: _POLICY_.RT6, _POLICY_.RTA, RULECHG.RTA

    I don't know what are those files and why they were stuck there.

    Thanks,

    Wednesday, December 4, 2019 4:33 PM
  • So does deleting them correct the process of the metering policies being delivered?

    Jason | https://home.configmgrftw.com | @jasonsandys

    Wednesday, December 4, 2019 4:46 PM
  • Hi,

    Actually Yes. Immediately after deletion and ran the actions, again, in the client and got the rules.

    Thanks,

    Wednesday, December 4, 2019 4:58 PM
  • That's good. I don't know why those files got stuck. Perhaps your AV product locked the files; make sure these locations are properly excluded from whatever AV product you are using on the site server.

    Jason | https://home.configmgrftw.com | @jasonsandys

    Wednesday, December 4, 2019 5:12 PM
  • Hi,


    We're glad the problem is solved now. The policypv.box folder temporarily stores policy changes for the SMS components. Whenever the policy of SMS components change, a notification file appears in this inbox, causing the policy provider to regenerate the policies. A backlog of files in the policypv.box folder indicates that the policy provider component is not running. The policy provider component may not be able to read the site control file, or the component cannot write to the database. You can examine the Policypv.log in the \SMS\Logs folder on the site server for errors or additional information.

    Best regards,
    Larry


    Please remember to mark the replies as answers if they help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, December 5, 2019 7:46 AM