Secure Enterprise Onboarding and Domain Join Method - Concept
Hey Microsoft Hub community — Rodrigo here. After nearly two decades working in enterprise Windows environments, I’ve seen the same onboarding problem repeat everywhere: trust is granted too early, too inconsistently, and across too many disconnected systems. To address this, I created APilot — a Microsoft‑aligned concept for secure Windows onboarding and domain join. We’ve modernized identity. We’ve modernized device management. We’ve modernized compliance. But onboarding — the moment trust is established — remains fragmented. APilot — A Unified, Microsoft‑Aligned Trust Orchestration Lifecycle APilot reframes onboarding as a governed trust event, not just a technical step. It brings together Microsoft Entra ID, AD DS, Intune, Windows Autopilot, Conditional Access, PKI, and CMDB governance into a single zero‑trust onboarding lifecycle. The core principle: A device should not be considered trusted or productive until identity, asset ownership, posture, and certificate state are validated together. Why This Matters Enterprise onboarding is often split across identity, device management, compliance, PKI, and asset lifecycle systems. This fragmentation leads to: failed joins and poor first‑time success rates partially trusted devices entering production stale or orphaned device records certificate drift and expired trust artifacts inconsistent onboarding experiences across teams increased helpdesk and support burden higher risk from lost, stolen, or decommissioned devices APilot addresses these issues through a governed lifecycle that includes: identity validation device identity collection CMDB verification compliance gating temporary trust windowing join authorization quarantine and rollback wipe and decommission controls Microsoft Ecosystem Alignment APilot aligns directly with: Entra ID identity governance Intune compliance & Autopilot provisioning AD DS domain join PKI certificate trust Conditional Access CMDB / ITSM asset governance ZTNA segmentation The result: a device becomes trusted only when identity, posture, certificate state, and asset ownership converge. Who This Concept Is For APilot is intended for: Microsoft ecosystem stakeholders identity & endpoint engineering teams Zero Trust and security architects enterprise IT operations leaders CMDB / ITSM governance teams If this resonates with Microsoft PMs or architects, I’d be happy to collaborate on deeper exploration or refinement. Full technical concept: https://github.com/RodrigoACriscuolo/criscra/blob/main/Domain-Join_Knowledge.is.Power.md?utm_source=copilot.com This is my first contribution, and I invite fellow engineers and architects to contribute their perspectives. Today, many enterprises still rely on custom scripts or adopt tools like NinjaOne simply because they lack a unified Microsoft‑aligned approach. My hope is that APilot helps us elevate our Microsoft environment and improve the operational reality we face every day.
New MD-102 : Weird departure from course traditional design
The first slide deck is tremendously long. It takes me 5 hours of lecture to get students into the first lab. The slide decks are very repetitive and could often be replaced with Instructor Demonstration slides. The topics are far-ranging: it mixes identity administration, Intune RBAC, Android enrollment, LAPS, Windows enrollment, and Autopilot before students have a stable mental model of the fundamentals of: Device enrollment > Policy/app creation > Targeting assignment. The first lab is disjointed, with many configurations, such as Creating Administrative units, Assigning Scope tags, and Custom Intune Roles, not implemented until later in the week in Exercise 5. The delegation model, administrative-unit work, and Android restrictions obscure the basics students should understand first. The course design seems to be a big departure from most, if not all, Microsoft courses I have ever taught. No Entra Connect Lab and no real Autopilot lab are a disappointment to some students as wellIntune On-Demand Proactive Remediation API Reliability for Large-Scale Usage
Hi Team, We are testing the Intune On-Demand Proactive Remediation API: POST /deviceManagement/managedDevices/{managedDeviceId}/initiateOnDemandProactiveRemediation In our environment, the remediation package works correctly, and the API generally triggers the remediation as expected. However, during repeated testing, we noticed that a small percentage of requests do not seem to reach the endpoint. For example: 20 remediation requests sent 18-19 execute successfully 1-2 never trigger on the target device Devices are online and managed by Intune Added a 30-second delay between requests, but the behavior still occurs intermittently Before adopting this in production for a large client base, we'd like to understand: Has anyone observed similar behavior? Is this API reliable for triggering remediation across multiple devices in parallel? Are there any known limitations, queueing mechanisms, throttling considerations, or best practices? Is there a recommended way to verify that a remediation request was actually delivered to the device? Since this API is still in the beta/preview stage, is there any information on its roadmap or GA timeline? Note: For additional context, detailed test results, observations, and environment information, a PDF containing the complete analysis has been attached. Any guidance or real-world experience would be greatly appreciated. Thank you. https://learn-attachment.microsoft.com/api/attachments/1ad5bea4-9038-4b25-9a2a-a9e66a870f6a?platform=QnA https://learn.microsoft.com/en-us/graph/api/intune-devices-manageddevice-initiateondemandproactiveremediation?view=graph-rest-betaEntra Shared Mode - Force App Stop
Hi All I hope you are well. Anyway, I was asked this yesterday and think I already might know the answer, but here goes. We had an instance of Microsoft Excel stuck in "getting things ready" on an Android Entra Shared Mode Device. Technical Support wondered if there was a way to Force Stop Excel or clear the app data. We had a look in Exit Kiosk Mode, Android Settings, and the Force Stop of Excel said "Action not allowed" and the clear the app data said "Unable to delete data for app" So, my question(s) would be, is going into Exit Kiosk Mode and even trying to force stop / clear data on apps even a valid option, or is this by design? Would adding Excel to this setting help? Any help or confirmation would be greatly appreciated. Stuart
enrolling in Intune MacBook Pro with an M5 Pro
Hi everyone We have tested the Wi-Fi and ethernet profile without success with Apple businesses manager. The Wi-Fi and the ethernet connection itself works, but the enrollment process into Intune does not complete successfully. At this stage, we cannot sign in, and neither the Wi-Fi nor the Ethernet connection appears to be working. The device is a 14-inch MacBook Pro with an M5 Pro chip, running macOS 26.5.1 the device connects to the server, the settings begin to apply, but the process suddenly stops, and we are then unable to log in. These are steps followed : Synchronize the device from Apple Business Manager to Intune. Assign the enrollment profile to the device. Perform a device wipe/reset. Start Automated Device Enrollment (ADE). Complete the device setup and user sign-in. The device successfully enrolls into Intune. Intune begins deploying configuration profiles, compliance policies, security policies, and applications. During the policy application process, Wi-Fi connectivity stops responding. The device loses network connectivity and cannot continue synchronizing policies. We are unable to sign in because the enrolment process has not been finalized. As a result, we have to wipe the Mac and start the process again each time. We have disabled some policies, but we are still experiencing the same issue. Have anyone experienced any issues like that ? Regards,
Android Enterprise System update expected behavior
What would be the expected behaviour when we set the System update to Automatic in the Android Enterprise Device restriction profile? We have several devices rebooting "randomly" and without notification and when we check the dumpstate logs, these reboots were triggered by an update: Canonical boot reason: reboot,enterprise,mainline_updbug. According to the Android documentation this could be correct: https://source.android.com/devices/tech/admin/ota-updates Since we don't see the same behaviour on all devices, while they share the same Update policy, I'm not sure what to expect from this setting?
Fully Managed Android Devices Constantly Restarting
Hi all, We have had users with our Fully Managed Android devices regularly rebooting without warning, sometimes multiple times a day. These devices are already fully updated when these restarts are happening. It's been hard to catch it as it's random and sometimes when it does, it will reboot multiple times. When the device turns back on, the phone says it is 'Optimising apps'. We also have the 'Auto Optimisation' function disabled in device care within settings. I know that's not much info to give but does anyone have any idea why this is happening or how to resolve it? As you can imagine it's causing a lot of issues within our business. This is occurring on both Samsung A32 devices and Samsung Tab Active 3 devices, both Fully Managed with the device firmware update setting in our configuration profile set to default.
