GarthMJ

Yes it is fully supported to do that, one of my lab is step that way. Did you configures SSRS after installing it? BTW, it is generally recommend that SQL be install with CM and it is also generally recommend that SSRS be installed with SQL.

You shouldn't be accessing the reports from the console, you should be accessing them from the web interface. The first report you are rung to run use SW inventory , which is useless and shouldn't be turn on anyways. Therefore the error is normal.

Remove your boundaries from CMCB 1606, then when you are ready move each role one at a time. Push out the client from CMCB 1702.

BTW What the SSRS error is telling you, is that the there is no SQL view called that within the CM database.

Just to be clear the MOF edit will give you no results when you don't have WMI provided installed for SQL, one of the SU removed it and it never gets put back. Or you will get duplicated results if you have two or more different version of SQL installed on the same computer. Now as for others there is product that will give you this and a lot more. PM me if you want more details.

Have you looked at the Builtin ARP reports? They should give you what you want.

I can tell you that the MOF edit listed within your first will product wildly inaccurate results. I can tell you that this blog post will help with showing you the true error within your SSRS RDL. https://www.enhansoft.com/blog/turn-on-remote-error-reporting

There are several things you can try, Uninstall and reinstall the CM client. maybe even deleted the computer form CM console first. Confirm that the results within WMI are correct Check the health of WMI; Don't destroy WMI just because.

Did you refresh the WMI on those computers to ensure that everything is correct? Have you force a full HW inventory on them?

You need to solve you SSRS timeout issues. Once that is fixed, you can come back to this issue.

Which reports are failing? Is it the Data warehouse reports?

Ok I will bite, why are you change the MS DS at all? Are you trying to share one SSRS server for two different CM environments? (BTW that isn't supported)

If they can't see the computer it is because the permissions are wrong for the collection. How exactly did you grant them access to the collection? Entering the IP address and getting an error, has nothing to do with boundaries that would most likely be a firewall issue or maybe a local to the PC permissions issue.

What exactly does the above mean? A collection has no link to a boundary therefore if you grant someone RC access to the collection they can RC every computer in that collection, not matter where that computer exists on your network.

Boundaries are not a security scope so.. what exactly do you mean by this?

You the like option within your query that you create for the collation. It like this. Where SMS_R_System.name like "EH-%"

I just imported the RCM.mof and it imports without issues and I'm seeing data in my test lab using these mof edits.

This query will in no way, shape or form, show you when the last SU was installed. For that matter, when the last SU was applied is completely useless info. Why? Because what happen when 1st SU fails but the 2nd SU is successful. You will have a false believe that you server it update. Instead you should look at what SU are outstand for that server. This query will get you started. http://sccmug.ca/2009/02/25/patch-compliance-progression-report/

What does the console say? does it should have it has been deployed to your DPs?

Also keep in mind there is no version call SCCM 2016, The latest version is CMCB 1702..

You shouldn't have a CAS and two primary unless you have over 150,000 computers. Yes all site server require permissions.

Yes, I would create a different schedule for server vs client. Most of my clients do this.

Go back to Basic. Did you deploy the package to your DP? Does the Package show up within the CM cache folder? Does the program run as Local system account?

First what didn't work when you created the package the first time? Secondly, your problem is you are trying to run a PowerShell script from a UNC path. The Computer account will NOT have access to that path. Therefore it will fail. Why don't you include the posh script within the package source?

I will turn this question around on you. Where do you see the dongles in Resource Explorer? Once you find a reliable way to determine that, reporting part is easy.