Event details
35 Comments
follow up on the Dynamic groups.. For a single tenant shared by two regions (US + EU), what's the recommended way to keep Autopilot deployment profiles, the Enrollment Status Page, and device-naming templates cleanly separated per region? Autopilot profiles assign to groups but there's no scope-tag enforcement on profile assignment — so is the answer group tags + dynamic user groups, Administrative Units, or something else, and how do you keep it from colliding when both regions share one tenant?
I might be reading this question wrong but I think what you'll want to do is create two different autopilot deployment profiles - one for EU, and one for US.
Next you'll create 2 separate dynamic groups - one for Intune Device EU, and one for Intune Device US.
You need to determine how you can programmatically detect the difference between your EU & US devices. You might already have something like this in place.
Then assign your dynamic groups to the matching autopilot deployment profile.
The behavior you'll see is that devices that have the EU identifier will use the EU Autopilot Deployment Profile, and ones with the US identifier will use the US one.
For this specific use case, I don't think you need to worry about group tags or anything else. As long as you can identify which device belongs to which region, Autopilot will apply the correct profile.- Hung_Dang
Microsoft
It's not clear if this is a question about dynamic groups usage or scope tags -- two very different concepts.
We are currently preparing to deploy a Virtual Machine Scale Set (VMSS) utilizing marketplace Ubuntu images to collect and forward rsyslog and CEF data to a Log Analytics workspace.
Regarding the Azure Monitor Agent (AMA) running on these Ubuntu instances, could you please clarify how updates are managed? Specifically, are these agents patched automatically and on a regular schedule, or do they require manual maintenance from our end?
As organizations move from traditional Active Directory domain joined devices to Microsoft Entra joined devices managed through Intune, many desktop support and system administration teams are facing significant changes in how endpoints are managed and supported.
While the benefits of cloud native management are clear, many day to day administrative tasks that previously relied on domain connectivity, administrative shares, Group Policy, remote management tools, and direct access to the endpoint are changing or no longer function the same way.
Examples include:
- Driver installation and updates during troubleshooting.
• Manual application installations for urgent support situations.
• Remote administrative access for advanced troubleshooting.
• Running scripts and tools interactively on endpoints.
• Accessing administrative shares and traditional management utilities.
• Supporting devices that are off network or operating in a hybrid state.
• Delegating endpoint administration to desktop support staff without granting broad Intune administrative permissions.
My question for the Intune product team is:
What is Microsoft's long term vision for desktop support and endpoint administration in fully Entra joined environments? Specifically, what tools, workflows, and administrative models are expected to replace the traditional domain based methods that desktop and system administrators have relied upon for decades?
Additionally, are there plans to provide more granular operational support capabilities that allow help desk and desktop support teams to perform troubleshooting, software installation, driver management, and remediation tasks without requiring full Intune administrative privileges or complex custom role configurations?
Many organizations understand the strategic direction toward cloud native management, but practical day to day support workflows remain a significant challenge during this transition.
"Are there specific support workflows that Microsoft considers obsolete in an Entra joined world, and if so, what are the recommended replacements?"
- Hung_Dang
Intune does provide many of these capabilities. e.g., there's remote log collection, Tunnel, scope tags, etc. Best to search the community for each specific need to see how Intune customers have achieved each. And of course, our Intune documentation can help.
- Driver installation and updates during troubleshooting.
What's the best way to keep apps deployed by Autopilot (Intune) up to date? We're an MSP so look after multiple clients and it's a bit of a challenge.
So is it recommended to use User Dynamic groups for Application Deployment for AutoPilot? Seeing as Dynamic Device groups are slow and can be missed.
In what scenarios does Autopilot struggle to fully replace traditional imaging, and what best practices can help overcome these limitations?
Additionally, what common misconceptions exist around achieving minimal IT touch or true zero-touch deployment, and how can these be corrected in real-world enterprise implementations?
Good morning. We are looking to use Windows 365 virtual desktops. If we implement this, how are those virtual systems put into Autopilot? Thanks!
What is best practice way to prevent device enrollment on none company purchased devices? Enrollment allowed only devices purchased form partner vendors, or (if device is purchased outside of our vendors) enroll using a specific azure account only.
What are the key signals and troubleshooting approaches used to distinguish service-side outages from tenant-side issues
When you are using Autopilot v1 in a hybrid environment, at what point do you recommend installing the security tools?
I have seen when you require some security tools during the ESP as a required app, they cause hiccups. Thank you for the advice to install it afterwards at the desktop so it doesn't get installed and start applying policies which might be impacting other required apps in the ESP.
