GarthMJ

So what have you done to troubleshoot this? What error message are you getting? do the reports work outside of CM console?

I'm always around to answer questions but I'm a bit busy with MS Ignite stuff... If you are at Ignite, feel free to stop by the booth 1246 or if you are going to IT/Dev in Oct, say stop me and say Hi.

ok, I will bite, if the exe updates every 14 days, why don't you force it to upgrade any week? Why jump thur the extra hoops? I would not set the policies to check every 10 minutes, you are begging for trouble.

why don't you post the solution for other to find? Either here or on your own blog with a link here.

BTW, after re-reading the above, It is unclear to me if you uninstall IIS and rebooted. then Re-installed IIS.

What CM services account at you talking? CM uses the computer account for just about everything. Does the CM site server computer account have full admin and SA rights to SQL?

First off nothing within the CM database or WMI can every be used for forensics investigations and have it hold up in any court. On a side note, there are assumption within the first blog that are incorrect. CCM_RecentlyUsedApps will not tell you about deleted files. It will only tell you what was executed only. But by doing a comparison you can determine what executables have bene deleted or rename but nothing else. More than just SW metering needs to be enable the AI class also needs to be enabled too. AI data is collected based on the Hardware Inventory cycle default is 7 days BUT most senior SCCM admins will recommend daily. Not all apps are tracked by CCM_RecentlyUsedApps, you can see this from the log file. In my quick tests, the execution user is incorrectly identified, only the logon user (I assume console user) is shown as show executed the app.

Who found this? Where exactly are you seeing this? Why do you care about it?

a quick internet search revealed lots of blogs on the subject for example this one https://blogs.technet.microsoft.com/servicemanager/2009/12/17/service-manager-connectors/

Unless your lab is an EXECT clone of you production environment, the restore will not work. When I say exact clone, I mean you need to clone your DC too! It can't be a forest/domain with the same name, it has to be exactly that domain/forest.

Can clients at the secondary site talk to the primary site? are your boundaries correct?

OU, is not always populated by AD discovery, it is also populated by heartbeat discovery. Similarly, Security groups are populated by Heartbeat discovery too. As such I never recommend using that query style instead, use a direct membership for the Sec group. This allow computers to install the SW (assuming that is what the collection is for) without having to wait for heartbeat discovery to run.

No, CMCB is NOT a CMDB, However SCSM (Service Manager) is a CMDB and you can do that with it.

BTW, I hope you have a plan to upgrade to CMCB. CM07 is really old now.

No don't change it to slow, keep the site setup for fast. Once your MP, AD extension and the boundaries are right, client will automatically start reporting to the site.

So Subnet are evil, and I never recommend them. Instead use IP ranges fro everything.

Exactly how have you setup your boundaries. AKA what type of boundaries do you have?

Your Boundaries are going to be an issue. This is most likely why things are not working for you.

If it is manually entered then you should enter it directly into the CMCB. There is no point in "shoe horning" into CM.

Just to be clean CM is NOT a CMDB. CM is not intended to store the data that you are looking for that is the job of a CMDB. The company that I work for does have product for some of the items you are looking for.

CM is not a CMCB, as such it is not the right place to store this data. However CM is a great tool to collect data. You will need to look at 3rd party tools to collection some of this data. However not all of it can be collected for example IP Phones.

Remember a lot of the console data is cached. Reports will always show you live data. Personally I would never setup an ADR for SU, only Virus defs. Also remember that depending on how to setup your ADR, it can take time before it is seen and deployed.

ok, but that still mean the issue is with your CI detection methods.

if you are going to create a PowerShell script to collect, I would take this one step farther and Tattoo the image version in either WMI or registry. This way you can inventory it was Hardware Inventory. I would also make sure that you update your TS to do this as well.

ok, so there is nothing wrong with CM12 as it is reporting exactly what the cleitn detects. There is nothing wrong between CM12 and the end client as the results on the client are exactly what is on the client. There is nothing wrong with the Client itself as the CI is executing and giving results. So this mean there is a problem with the CI itself. First off I would avoid using a "/" in anything as it is a special character in C. Instead try 247, does that work? Secondly I would change the detection time to 1 days. I personally find that anything less that 4 hours seems to have problems.