GarthMJ

Does it make it to IIS?

So you are going to have to create a share on each DP in order to capture this data. you can parse the DP name from the HTTP address. Also keep in mind that you based on xcopy command above you will only ever has 1 set of logs on each DP.

Are you sure that you are not getting an access denied? I would think that you would be. Again, how do you plan to prevent each computer over writing the next OSD's logs?

How is one place any different that user going to the software center or application catalog? Deploying to *nix and MAC new to CM12 but the feature has been there since the beginning. (if I remember right)

What is not working? What error do you get? Have you checked the permission on the share and files? Are you sure? Why would you want to do this? How can you tell which OSD deployment the logs are for.

#1 how is it multiple place? aka how exact would it be different than DFS with respect to multiple places? #1 Yes there is a reason, it is less secure to use a domain account that using the local system account, Plus it will not allow you to manage workgroup PC, *nix, mac, and mobile phone and increase your support cost.

#1, yes I think you are missing the whole point of CM12. DP should always be "near" client, they use BITS to download content or use branch cache to reduce network traffic. #2, I'm sure you can make it work but you will be compromising security to do it. Again you are not using the benefits of CM12, branch cache, etc.

1. Why would you use DFS, instead of a DP? This complete defeats the purpose of what CM12 does. 2. This is going to be a permission issue. Why because the local system account does NOT have access to the DFS server and therefore get accessed denied to the MSI.

So your query will only show you x64 PCs as written. Try this. (watch out for typo and I write this freehand.) select distinct SMS_R_System.ResourceId, SMS_R_System.NetbiosName, SMS_R_System.OperatingSystemNameandVersion from SMS_R_System where SMS_R_System.ResourceId not in ( select SMS_G_System_ADD_REMOVE_PROGRAMS.ResourceID from SMS_G_System_ADD_REMOVE_PROGRAMS where SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName = "Microsoft Forefront Endpoint Protection 2010" or SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName = "Microsoft Forefront Endpoint Protection" ) and SMS_R_System.ResourceId not in ( select SMS_G_System_ADD_REMOVE_PROGRAMS_64.ResourceID from SMS_G_System_ADD_REMOVE_PROGRAMS_64 where SMS_G_System_ADD_REMOVE_PROGRAMS_64.DisplayName = "Microsoft Forefront Endpoint Protection 2010" or SMS_G_System_ADD_REMOVE_PROGRAMS_64.DisplayName = "Microsoft Forefront Endpoint Protection" )

Your subselect has too many columns, you can only have 1 column with a subselect query.

So what was added / changed 3 weeks ago?

This is so not supported and will likely cause problem the next time you try to upgrade you site. Why wouldn't you take an (IMO) easier and support method and setup Status filter rule to execute a SSRS report or something like that?

Yes, it is best practice (in general) to have SQL and CM12 on the same server.

Does the site server computer account have full admin to both the SQL server and SQL itself? BTW it is generally not best practice to have SQL remote from CM12

Does the Reg key exist?

I re-read this post and it look like I need more coffee.. :-) I still "hate" SW inventory and think no one should use it but...

I would love to hear what the business requirement is to have SW inv enable and even more so why it needs to be less than 5 minutes.

No it is not mandatory but it is recommended. BTW, you should go for Windows 2012 for your server not Win2k8R2.

Is your CM07 site server computer account an SA within SQL?

I would suggest re-installing SSRS, reboot between the uninstall and the install if you can.

So what does the Web service URL node look like now? Until you can connect the webservice url via IE or firefox there isn't much that you can do. If you can I would re-install SSRS.

Ok, then why not remove the HTTPS? It adding complexity for what seem like no reason.

Why setup SSRS to use a certificate? What is listed on the report manager node?

As Jorgen stated above you need to give Domain Computers access to the share and files. No CM12 does not need a users logon for the script to work correctly.

So the easiest way to test this is using PsExec, Then from there you can track down exactly what is happening. if it works for PsExec running as local system then it will work for CM12. This video will get you started. Instead of using wbemtest, execute your vbs. Best of luck. http://www.youtube.com/watch?v=d9UqSSQ3kBE