Software Metering of application not working with Recently Used Applications..
Hi, we're metering a product, and the canned report 120 Software Metering - Computers that have a metered program installed, but have not run the program since a specified date. is not concurring with the Recently Used Applications class found in resource explorer. We are using software metering to remove unused software, but some people are questioning this as they claim to be using the software. When i look at Recently Used Applications in resource explorer for their machine, it would suggest that they are indeed using the application. In the mtrmgr.log i can see the monitoring of the .exe when it is started. but in the SWMTRReportGen.log it is just endless lines of No usage data found to generate software metering report Any suggestions here on what could be causing this?
October 3rd, 2011 12:35pm

Can you also see that the process ended in the mtmgr.log file?Kent Agerlund | My blogs: http://blog.coretech.dk/author/kea/ and http://scug.dk/ | Twitter @Agerlund | Linkedin: /kentagerlund
Free Windows Admin Tool Kit Click here and download it now
October 3rd, 2011 12:45pm

yes i can. but i think perhaps the client is not finding the software metering rule as a match now that i look at it, based on the 3rd line below....is that what it would suggest? The rule was created at the central site, with the version being * Creation event received for process 2560 Process ID 2560 is for process C:\Program Files\app.exe No matching rule found for process 2560 Termination event received for process 2560
October 3rd, 2011 12:50pm

correct, it hasn't downloaded the rule. Can you doublecheck the rule, language settings and version.Kent Agerlund | My blogs: http://blog.coretech.dk/author/kea/ and http://scug.dk/ | Twitter @Agerlund | Linkedin: /kentagerlund
Free Windows Admin Tool Kit Click here and download it now
October 3rd, 2011 12:52pm

Ok, i verifed that we're monitoring: File Name = Acrobat.exe Version = * Language = English (united states) On one of the the suspect machines i verifed that the .exe meets these requirements. It's acrobat.exe settings are: File Name = Acrobat.exe version = 8.3 Language = English (united states) Everything looks ok, not sure why the client would not pick up this rule. Anything else to look at?
October 3rd, 2011 2:27pm

I always select Any in the language when testing.Kent Agerlund | My blogs: http://blog.coretech.dk/author/kea/ and http://scug.dk/ | Twitter @Agerlund | Linkedin: /kentagerlund
Free Windows Admin Tool Kit Click here and download it now
October 3rd, 2011 2:36pm

None of the machines are reporting back with the data for this particular rule or the issue is for only some machines ? Have you already seen this? http://technet.microsoft.com/en-us/library/bb932167.aspx (Troubleshooting Software Metering Issues)Anoop C Nair - Twitter @anoopmannur MY BLOG: http://anoopmannur.wordpress.com SCCM Professionals This posting is provided AS-IS with no warranties/guarantees and confers no rights.
October 3rd, 2011 2:37pm

yes, the language settings could be an issue, not sure why i never went with Any. Only a small number of clients are affected by this, say %5 What if i modify the rule to Any for the language settings? Would we lose any of the data collected or anything else like that?
Free Windows Admin Tool Kit Click here and download it now
October 3rd, 2011 2:40pm

Not, it should not loose any data. The rule ID is still the same.Kent Agerlund | My blogs: http://blog.coretech.dk/author/kea/ and http://scug.dk/ | Twitter @Agerlund | Linkedin: /kentagerlund
October 3rd, 2011 2:48pm

Thanks, i will make this change, montior the client and post back the results.
Free Windows Admin Tool Kit Click here and download it now
October 3rd, 2011 2:49pm

I'm confused on one final thing. The reports all list these affected systems as not having used the product in X number of days. To me that means the SCCM agent has picked up the rule and submitted the summeraization...that's how we know it has not been used in X days. If the clients are not picking up this particular rule, as in the example i detailed above, then i would expect them not to appear any of the software metering reports for that rule. Does this sound correct?
October 3rd, 2011 3:12pm

Yes,it should be in that way. How about the other reports?Anoop C Nair - Twitter @anoopmannur MY BLOG: http://anoopmannur.wordpress.com SCCM Professionals This posting is provided AS-IS with no warranties/guarantees and confers no rights.
Free Windows Admin Tool Kit Click here and download it now
October 3rd, 2011 3:16pm

I have resolved this issue. As it turns out all the clients were not metering any rules, not just the one in this example. I found a similar post on here regarding locked files in policypv inbox I noticed 2 files that had not changed since the date the server was built 1. RULECHG.RTA 2. _POLICY_.RTA I moved them to a temp folder, pulled for policy on the clients, and everything started to work. All the metering rules came down. I do not know what those files are, but one/both were certainly the problem. If anyone knows the purpose these files i would like to know.
October 4th, 2011 10:52am

Hi, You may refer to the following explanation: SMS in the past has used "lock files" to prevent related processes from operating on the same files at the same time (to avoid conflict). SCCM appears to use _POLICY_.RTA in the same manner that "lock files" were used by SMS (this file is created and deleted during normal operation). The drawback of using lock files in this way is: If for any reason the lock file is not deleted, a problem can occur which is extremely difficult to track down. Regards, Sabrina This posting is provided "AS IS" with no warranties or guarantees, and confers no rights. |Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Free Windows Admin Tool Kit Click here and download it now
October 7th, 2011 5:02am

Hi, You may refer to the following explanation: SMS in the past has used "lock files" to prevent related processes from operating on the same files at the same time (to avoid conflict). SCCM appears to use _POLICY_.RTA in the same manner that "lock files" were used by SMS (this file is created and deleted during normal operation). The drawback of using lock files in this way is: If for any reason the lock file is not deleted, a problem can occur which is extremely difficult to track down. Regards, Sabrina This posting is provided "AS IS" with no warranties or guarantees, and confers no rights. |Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
October 7th, 2011 11:50am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics