One of the banes of many SCCM admins existence is reporting. Some SCCM people are SQL guns, others, like me, know what they need to to get by, but a strong SQL understanding – that just isn’t me (and i know i’m not alone!).
One of the key things with SCCM reports, and something that some consultancies we deal with ignore is the requirement to use views for your reports, not directly talk to the tables.
The official SCCM doco dances around this and doesn’t explicitly state it (even though it does reference views constantly, it does not specifically state that using tables is unsupported – and it should)
These posts are far better at laying it out as it is
The TL;DR version of the ehansoft articles is:
- The SCCM reporting services account is specified during setup and is granted access to all the views – but not the tables etc
- The 2nd enhansoft article lays out why views are utilised instead of tables – and the associated benefits
- You can grant datareader access to accounts over the SCCM database to get around this – but its officially (MS) unsupported, and can cause a range of issues (again, laid out in the 2nd article)
- There are people out on the web that recommend just allocating permissions – even some MVPs – which doesn’t help
- My recommendation is to remain in “supported” territory and update the report to use views rather than tables directly (knowing full well that we have all referenced tables directly at some point in our careers!)
A couple of things i have found handy with this are:
When you know the table you wish to reference, but aren’t sure which views you can use (and you want to do the right thing and use a view)
SELECT * FROM INFORMATION_SCHEMA.VIEWS WHERE VIEW_DEFINITION like ‘%tablename%’ OR VIEW_DEFINITION like ‘%tablename%’ OR VIEW_DEFINITION like ‘%tablename%’
When you can find what your looking for in the database