Event banner
Event details
Why does Intune seem like it's been in alpha release for a decade? There are so many functions that are poorly labelled or with poor documentation (policies), have major undisclosed caveats (policy sets, Baselines), or have little visibility/easily consumable statuses (Autopilot, application deployment in general) compared to every other platform. Why does it take 2, 8, 24+ hours for most changes to sync or install automatically when every other platform performs these same changes in under 30 minutes, if not instantly?
As a medium-sized org, we don't have resources to hire an entire team to build out and craft Intune into a fully-capable and effective device management platform when it's so much more efficient to pay for additional products (PDQ, chocolatey, etc) that 1 person can manage part-time.
I can understand your frustration. Truly.
We are an MSP working exclusively with SMB and provide cloud-only M365 on enterprise level for them.
While Intune surely can use more consistency - we use it very successfully. It works!
Here are a few "work arounds" we learned that might help you too.
1. Refresh times are not determined by Intune, it's the OMA-DM client in Windows. It polls Intune for policy changes - Intune doesn't really push anything to Windows. The polling frequency is hard coded in the client. During normal operation it is every 8 hours, correct. This reflects the desire to minimize user impact by diverting CPU cycles, memory consumption and disk access. Also, imagine a network with ~5000 devices behind an internet access point. Too frequent polling will strain internet access as all OMA-DM comms go to the cloud. During normal operation, policy changes are (hopefully) infrequent, so frequent polling doesn't really add value. Btw newly deployed devices will poll every 5 minutes and then slowly lengthen the polling interval once the device has picked up and deployed all policies.2. If you need an "instant" policy refresh for testing or because a user expects an instant fix, you can manually either trigger the poll/update from within Intune, or ask the user to manually do it from the Company Portal app - which I hope you deploy to all managed devices?
3. A new method of applying policies is currently in preview (AFAIK), where the MDM agent on the device applies policies to the device autonomously, near instantly. I forget what it is called and more details, but this new comm method may address your need for speed. 😁 Also, this new approach can remediate config drift even while offline, based on the last policy set they received. No idea what the status on this is, but stay tuned.
4. Baselines are really best for orgs that have NO or very little M365 capabilities. They set everything up "good enough", but not ideal. Being that: generalized baselines, they do not work for everyone with more specific needs and can even conflict with more specific needs, yes. We as an MSP therefore don't use MSFT Baselines but have our own.
5. Remote app deployment at scale on Windows is ALWAYS half good training, half luck, half experience and half black magic. 😉 There are sooo many different methods of installing apps from sooo many different sources with sooo many different licensing and activation methods and sooo many prerequisites that no single system can address them all. Some companies still use client-server apps leveraging AD that are 10-12 years old, others use modern cloud apps only. As an MSP, I can say that store apps are, by far, the least complicated to deploy. Even updating happens by itself with no interaction needed from us. So we steer customers to store apps whenever possible (for example Affinity vs. Adobe). Legacy AD-based apps are a nightmare in any MDM environment - which is why we don't support hybrid environments.
But I agree that deploying apps via Intune/Autopilot/ESP could use a lot more user-friendly insight.- Jason_Sandys
Microsoft
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.
