13 votesBob Panick shared this idea ·
That's a very cool idea. We created an Excel spread sheet with canned queries to do basically the same thing. Largely because a lot of the data was more readable that way.
coming to a TP build near you, soon
The two security mechanisms, collection scopes for users and machines, and security scopes for most everything else don't work.
In theory you can delegate who has access to different parts using collection scopes. The idea might work where you have nice clean separations in business. But the problem is that rarely seems to quite work out that way. There is also a huge problem with update frequency of those limiting collections. All Systems updates fairly quick, but each collection below that doesn't and incremental updates if enabled cause system resource issues. Further the incremental updates aren't smart enough to do the dependent collections first. Which then causes other collections dependent on picking up the changes fail to pick up a change. Maybe if SCCM were smart enough to look at the collection dependencies and evaluate them first, it might work.
Collection security also ends up being a nightmare trying to scope properly. About the only real use it seems to have is in reporting.
Security Scopes for everything else have to be set by an administrator. Our SCCM system has hundreds of items that we would have to set security scopes on. Further, we don't have an easy way of seeing that something new has been added that doesn't have scope set. Yeah, we could write a query or report, but that's a poor workaround.
What we need is to be able to set security on the folders themselves. If you don't have access to the folder, you can't see child folders, collections, etc... This would work with things that get created, it could be used to control application distribution, and a lot more without a lot of administrative work.
If I wanted to give a business unit access to collections that covered their unit, I could simply create a folder for the BU, and add the collections I want them to have access to. Lets go further and set that they can only use the collections for reporting/read only, or that they can target software distributions to them, etc...
Folder security for everything in the Software Library would be a lot simpler to manage. For instance read and distribution only access to centrally administered objects, and full control to a BU folder for that BU, and read and copy for everyone else.
Or Server and Workstation administration with folder level security to allow the two separate IT teams not to mess up each other's stuff.
Tempted to mark this completed, now that we’ve released full blown powerBI integration:
Building reports & dashboards doesn’t get much easier than that.
Reporting was one of those things where SCCM 2012 dropped something that worked and replaced it with something that doesn't. That's not just SRS, but also how complex many of the queries, particularly around applications and compliance have become. Creating a report on a package in SCCM 2007 took 15 minutes, doing the same thing in SRS with Applications can take hours, or longer.
The SRS reports look sort of pretty, but they are based on a template that the rest of us don't have access to. Making decent looking reports is a LOT of WORK, for little or no gain.
Also, maybe its time someone went through all the reports and got rid of about 90% of them. Seriously, do we really need a report on modems?
A better interactive tool for reporting for all of System Center is needed, one not based on SRS.