Windows Office Hours: January 16, 2025

We constantly strive to improve Intune to meet the needs and requirements of our customers and are always happy to consider feedback and criticism. We fully acknowledge that Intune has evolved and will continue to evolve; i.e., it's still a work in progress and pretty much always will be. Windows and on-prem Windows management products like ConfigMgr grew up together so had the ability to change and grow together, however, there were still many growing pains that most folks don't remember.

We have many (many, many, many) organizations (from the very small to the extremely large) that have successfully adopted Intune for all of their device management needs but again, we are constantly striving to improve. That improvement is a long-term effort though and while we release significant  new features every month, we can't do everything as quickly as we would like let alone or awesome customers.

The best suggestion I have to help here is for admins, implementers, IT Pros, etc. to stop comparing what they used to do and how they used to do it when it comes to device management. The world of management has changed as have most (if not all) organizations and thus Intune was/is built to reflect this change. It's not meant to be a one-for-one replacement for ConfigMgr (or any other on-prem management tools). This makes trying to directly translate anything used to do to Intune difficult if not impossible because Intune is itself different. The end result is often the same, but how you get there is different for these reasons.

Thus, I suggest taking a step back to define your actual requirements and work from those instead of trying to translate existing settings, switches, knobs etc. as this will never work. Additionally, the existing configuration in a tool is rarely a reflection of your actual requirements. It's often the subjective interpretation of a lot of undocumented, unknown, temporary, questionable, or confusing requirements by individuals in the past. Until you actually document your requirements though, you'll never truly know. 

Yes, this 100% involves effort and change, but it is ultimately the best path IMO to embrace where our focus and investment is at as nearly everything we do and intend to do is cloud-centric or cloud-native. If your organization has other priorities and goals, then you can certainly choose to delay your adoption (or never adopt at all) and we're happy for you to continue to use our existing toolsets that are on-prem centric.

Last comment here on my long-winded reply is specific to the "instant gratification" desire you've called out. We generally recognize this as something we can and should improve on. In general though, this is not required for on-going operations but is instead only impactful during one-off troubleshooting or testing. On-going operations calls for consistency and reliability in general and that's what we've traditionally focused on. Instant gratification expectations can often be managed with users though -- that's not to discount the desire here at all, just to call out the level of emphasis that we have. We're happy to hear feedback on this including specific business impact and examples where your business was impacted by not having this instant realization of configuration.