I strongly agree with this suggestion.
Yes having similar super flows for all aspects of current branch would literally be the best thing Microsoft could do for SCCM beyond bringing new features to the product. If they could maintain and extend them alongside the introduction of new features would be even better and should be a standard part of the process for introduction of new features. new stuff comes frequently, but almost no information on how to troubleshoot the new stuff comes along with it.
This is a very interesting scenario
This VERY MUCH. We have to make strong distinction between what kinds of policies can be applied on BYOD vs Corporate supplied devices. While there are ways to do it and we can manage it, this would make it a lot simpler to achieve.
I support this idea, it has been awkward in the past at times to script this with Wusa. It works but it is a bit clunky and relies on you having someone with more than basic admin experience to ensure success in a scenario that almost invariably happens with an incident outside of normal business hours and availability of the ideal administrator to action this may be limited and where you may need to work quickly to un-***** the situation before it deploys too far.
Check out the new uninstall behavior in 1804 tp.
You do have to be careful with these kinds of features. I have seen some pretty horrible incidents where people use exclusion collections as a dead mans switch style approach to avoiding having something install or trigger uninstalls (even worse they use direct memberships for exclusion collections....). I am not arguing against the feature at all and would support its inclusion as an option however I would suggest, 1) ensure it is never the default setting to uninstall when out of scope. 2). perhaps have a tooltip and/or popup "are you sure?" type dialogue when someone chooses to switch this on.
1,294 votesplanned · AdminMark Silvey - ConfigMgr Product Team (Admin, System Center Configuration Manager) responded
Saw a working demo of this recently so updating to planned.
Tempted to mark this completed, now that we’ve released full blown powerBI integration:
Building reports & dashboards doesn’t get much easier than that.
PowerBI is NOT the solution. you can't just assume all organisations will use a cloud based reporting solution for their on premises enterprise management systems, additional licensing or cloud data charges alone will basically blow it out of consideration, not to mention privacy concerns. But the real issue is that in the mean-time if the MS response is "use PowerBI" then that means they have no incentive to enhance one of the fundamental features of SCCM, that frankly is given inadequate development already. SSRS is okay, but it has a steep learning curve and arguably is harder to use in some ways than classic SCCM 2007 reporting. So while it is more capable if you really know what you are doing with the SQL schema and reportbuilder (arguably one of the least user friendly design tools I have ever encountered). SQL management studio create views functionality shows some good capability with graphically allowing you to join tables\views and have it then generate the SQL code for you. something like that perhaps simplified would be a great addition to an on-premises reporting tool either built into the SCCM console or (more likely) as a companion tool launched from the console.