Windows Office Hours: January 16, 2025

In the ESP profile, make sure the "Only show page to devices provisioned by out-of-boxy experience (OOBE)" setting is set to No, since you're doing a Workplace Join and not an Entra join/MDM enrollment in OOBE.  Setting it to Yes should make the ESP display only when Entra join/MDM enrollment occurs during OOBE.  Hope this helps.

The ESP consists of the "device" ESP, which is displayed during OOBE proper (i.e., before Windows logon), and "user" ESP, which is displayed after Windows logon.  OOBE itself prevents the device from going to sleep.  For the user ESP, there's no built-in sleep prevention, and so you'd have to go with work-arounds, like targeting a script to the device to configure sleep/lock (and have it run during the ESP), and undo that when the user reaches the desktop via another scheduled task.

Hi Dom, we had to create a firewall rule that allowed the executable that Miracast uses to make this work for us. We have miracast working on Win11 AADJ devices managed by Intune. 

Without knowing exactly which policies got set and what was blocked, my suggestion would be to look at your policies that would block any of the protocols used and ensure the firewall settings are not blocking or dropping communication between devices.  The Miracast spec here details the protocols used: https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-mice/9598ca72-d937-466c-95f6-70401bb10bdb . The driver requirements are also here, if you've had any driver updates, may be related to that as well. https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/wireless-projection-pc-manufacturers Hope that helps.

Confirming and building on Jason_Sandys comment:
You should seriously consider disconnecting all PCs from their local ADs and JOIN them to Entra/Intune/M365 only. Whether by manually disconnecting each PC and then re-joining (I doubt this is a good method for you) or re-deploying them fresh from the cloud remains to be seen.

Hybrid management does not simplify things in our experience, it makes it worse. You have TWO environments to deal with now: AD + Entra/Intune. While ensuring they play nice with each other.

These days, MSFT recommends Entra/Intune joined PCs only - not hybrid joined, if any way possible.
Even with Entra join only, you will still have access to AD-based resources, but management will be fully centralized.

As an MSP, I would strongly advise against a hybrid configuration.

I believe you'll be very pleasantly surprised at the new abilities you gain with cloud-only endpoint management.

It kind of depends on your goals and purpose of these 20 distinct domains as well as your current management state. Assuming a lot of things not in evidence here, you can sync your multiple on-prem AD domains successfully to a single Entra tenant which Intune will be linked to. The devices from these domains can then be either hybrid joined to this tenant or reprovisioned to be Entra joined to this tenant. In both cases, this will enable the devices to be managed by Intune.

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. 

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.

Good one! 👍 Did you speak to Cisco about this yet? Seems they need to make their updates less disruptive.

+1 on this