From Domain-Joined to Microsoft Entra Joined: A Low-Disruption Migration Framework
How the right in-place migration approach can preserve eligible user profiles, establish Intune management, and accelerate the move away from on-premises Active Directory. Cloud-native endpoint management is relatively straightforward when a Windows device is new. The harder problem is the installed base: hundreds or thousands of working laptops and desktops that already contain user profiles, local files, applications, certificates, security controls, and years of configuration. Resetting and re-provisioning those devices is a valid route, but it can introduce significant coordination, user downtime, application rebuilding, and service-desk demand. This often creates a practical gap between an organisation's cloud strategy and its ability to move the existing fleet. Can an existing domain-joined or hybrid Microsoft Entra joined Windows device move to Microsoft Entra join without being wiped or re-imaged? For eligible devices, the technical answer can be yes, when specialized migration tooling, careful preparation, and a controlled recovery model are used. However, an important support distinction must be made at the outset. The Microsoft support boundary matters Microsoft recommends Microsoft Entra joined, cloud-managed endpoints as the strategic direction for organisations that are ready to reduce their reliance on on-premises infrastructure. Microsoft also states that its supported path for converting an existing Active Directory-joined or hybrid Microsoft Entra joined device to Microsoft Entra join requires a Windows reset; it does not provide a Microsoft-supported, no-reset conversion path for that scenario. See Microsoft's guidance on Microsoft Entra join and hybrid join. A no-reset migration is therefore not a hidden Microsoft feature. It is a vendor-supported, tool-assisted workflow that orchestrates Windows, Microsoft Entra ID, Microsoft Intune, and Microsoft Graph capabilities and adds the missing profile-continuity and recovery layers. Microsoft may support the underlying platform components, but not the end-to-end no-reset conversion. That distinction does not put the approach in conflict with Microsoft's direction. The destination, Microsoft Entra joined devices managed by Intune, is aligned with Microsoft's cloud-native endpoint strategy. The bridge used to move the existing fleet is specialized and must be validated through a representative proof of concept, with clear ownership for support and recovery. The strategic destination can be Microsoft-native even when the migration bridge is specialized. What “seamless” should mean in practice “Seamless” should not mean that nothing changes. A credible low-disruption migration may still require a user sign-out, controlled restarts, a first sign-in with Microsoft Entra credentials, Windows Hello re-provisioning, and re-authentication to some applications. Instead, a successful in-place migration should aim to achieve the following: Retain the same physical device and Windows installation. Keep the eligible local Windows profile, local files, installed applications, and compatible settings in place. Re-associate that profile with the correct Microsoft Entra identity. Establish or re-establish Intune management in a controlled manner. Restore the intended application and policy targeting. Protect BitLocker and local-administrator recovery throughout the transition. Limit the interactive cutover to a predictable maintenance window. Produce verifiable evidence that identity, management, security, and user productivity are working after the change. The join operation is a milestone; it is not the entire migration. A device is truly migrated only when the user can work and the required security controls are demonstrably active. A step-by-step framework for an in-place migration Step 1: Define the complete target state Do not define success simply as “Microsoft Entra joined.” The target state should cover four connected layers: Device trust The endpoint is Microsoft Entra joined in the correct tenant and is no longer joined to the on-premises domain where that is the intended outcome. Management The endpoint is enrolled in Intune, has the correct corporate/personal ownership classification and primary user, has the required Microsoft Entra registered owner where applicable, and receives the required applications and configurations. User continuity The correct user can sign in to the existing eligible profile and access the files, applications, and services needed for work. Security and recovery Compliance is evaluated, Conditional Access behaves as designed, and BitLocker, Windows LAPS, Defender, certificates, and recovery access are validated. For new designs, a supported Windows 11 edition capable of Microsoft Entra join should be the forward-looking baseline; Windows Home editions cannot be Microsoft Entra joined. Windows 10 reached end of support on 14 October 2025; ESU, LTSC, or other exceptional servicing scenarios should be assessed separately against Microsoft's lifecycle information. Step 2: Discover dependencies and segment the estate An accurate inventory determines which devices are suitable for an in-place path. At a minimum, collect: Current join and management state. Windows version, edition, servicing status, disk health, free space, and pending restarts. Primary and additional local profiles, including profile health and size. Source account, target user principal name, and any identity-mapping exceptions. BitLocker status, recovery-key location, and local-administrator or LAPS recovery route. Applications that use AD computer authentication, legacy protocols, device certificates, or domain service accounts. GPO-delivered settings, mapped drives, printers, folder redirection, logon scripts, Wi-Fi, VPN, and certificate delivery. Windows Hello, Credential Manager, EFS, private keys, and other identity-bound data. Network location, proxy behavior, endpoint security controls, and remote-worker constraints. Use the findings to classify devices into practical groups: Ready for a tool-assisted in-place migration. Ready after remediation. Better suited to reset and Windows Autopilot. Better suited to hardware replacement. Temporarily retained as a managed hybrid exception because a dependency remains. This segmentation prevents a small number of unsuitable devices from setting the risk profile for the entire project. Step 3: Replace the policy dependencies—not merely the join state Once a device leaves Active Directory, Group Policy no longer refreshes. Existing registry-based settings may remain on the device, while mapped drives, printers, folder redirection, scripts, certificates, Wi-Fi, and VPN configuration may require a cloud-management replacement. Microsoft's Group Policy analytics in Intune can help identify which GPO settings have a cloud-management equivalent. The goal should not be to copy every historical setting. It should be to rebuild the controls the organisation still requires through Intune, rationalizing old policies along the way. Applications that rely on an AD computer account or machine authentication deserve particular attention. Device migration cannot make an application cloud-ready; application and infrastructure modernization remain separate work streams. Step 4: Prepare Microsoft Entra ID and Intune before touching a device The destination must be ready before the source trust is removed. Confirm: Target user identities exist, are enabled, and use the intended sign-in names. Required Microsoft Entra ID and Intune licences are active. Device-join permissions, device limits, MDM authority, enrollment restrictions, and ownership rules are correct. The correct users are included in the Intune MDM user scope. Required applications, configuration profiles, security baselines, certificates, Wi-Fi, VPN, and update policies are assigned. Compliance policies and Conditional Access rules include a safe enrollment and bootstrap path. Access to required on-premises resources has been tested from a Microsoft Entra joined device. Microsoft documents that eligible corporate devices can automatically enroll in Intune when they join Microsoft Entra ID, provided licensing and MDM scope are configured correctly. Conditional Access deserves careful sequencing. A device may need time to enroll, receive policy, and report compliance. Temporary exceptions, if required, should be narrow, documented, monitored, time-bound, and removed as soon as the migration wave is complete. Compliance does not migrate from the old device record; it must be evaluated again in the target state. Step 5: Secure the migration control plane A mature migration design should use a customer-controlled Microsoft Entra application with only the Microsoft Graph permissions required for the enabled functions. Application credentials should be protected, rotated, audited, and revoked when no longer required. Microsoft recommends applying the principle of least privilege to Microsoft Graph permissions. Where the selected workflow requires credentials to update, disable, or delete source AD computer objects, use a dedicated identity with narrowly delegated permissions rather than broad domain administration. If the workflow uses a Windows Configuration Designer provisioning package, treat it as a privileged credential. Microsoft's bulk enrollment documentation notes that the embedded bulk token can be valid for up to 180 days and that MFA is not supported in that particular token flow. Microsoft documents bulk provisioning for new devices, not as a native in-place profile-migration method, so any orchestration around it remains part of the specialized workflow. Protect the package, scope any necessary policy exception tightly, test it on a non-production device, and revoke it after use. Endpoint security controls also need advance preparation. Any approved migration executable and the system actions it performs must be tested against EDR, antivirus, WDAC, AppLocker, hardening policies, and proxy controls. A good architecture should not require a persistent endpoint agent after the migration is complete. Step 6: Build recovery into the design Changing device trust crosses several systems and is not one atomic transaction. A credible plan therefore starts with recovery, not optimism. Before migration: Confirm that critical user data is backed up or successfully synchronized to an approved location. Keeping files on the same disk is not a substitute for backup. Confirm that a working BitLocker recovery password is available through an approved location. Confirm a tested local-administrator or Windows LAPS break-glass route. Keep source recovery information available until target escrow is verified. Record the source join state, device identifiers, user-to-profile mapping, primary user, group assignments, and management state. Define stop points and avoid irreversible source cleanup until the target state has been validated, where the workflow permits. Document who owns endpoint recovery, identity recovery, and user support. Microsoft recommends storing BitLocker recovery information for Microsoft Entra joined devices in Microsoft Entra ID; see the BitLocker recovery overview. Windows LAPS can back up managed local-administrator passwords to Microsoft Entra ID on Microsoft Entra joined devices. Do not accept a vague “rollback” promise. Look for phase-aware, checkpoint-based recovery that can identify the failure stage, preserve administrative access, and safely resume or repair the workflow. Reset or re-image should remain the documented last-resort recovery path. Step 7: Run a representative proof of concept A pilot built only from clean IT laptops proves very little. Include representative devices and users, such as: AD-joined and hybrid Microsoft Entra joined endpoints. Office-based and fully remote users. Different hardware models and supported Windows builds. BitLocker-protected devices. Large or multiple eligible local profiles. Certificate-based Wi-Fi or VPN. Business-critical and internally developed applications. Users who still require on-premises file, print, or application access. Define success before the pilot begins. Measure device join, Intune enrollment, policy receipt, compliance evaluation, BitLocker escrow, pre-cutover local-administrator or LAPS recovery, post-migration Windows LAPS policy and backup operation, application access, profile continuity, user downtime, failure rate, and recovery effort. The purpose of the pilot is not merely to prove that a device can join Microsoft Entra ID. It is to prove that a real user can remain productive afterward. Step 8: Apply a strict per-device readiness gate Immediately before cutover, an automated preflight should verify: Supported source and target states. A healthy, supported Windows installation and local profile. A valid source-user-to-target-user mapping. Intune enrollment eligibility and available device capacity. Stable power, internet, DNS, and non-interactive system connectivity. Sufficient privileges for the required system operations. Accessible BitLocker and local-administrator recovery. No blocking restart, disk, encryption, proxy, or security-software condition. An unloaded profile during the identity-re association stage. Valid target-join material and required API access. Unsafe devices should be blocked and routed to remediation rather than allowed to fail halfway through the trust transition. Step 9: Capture the state that must be reconstructed Before changing identity, a capable workflow should record the data required to rebuild the intended management relationship, including: Source user, target user, profile path, and security identifiers used for correlation. Existing Microsoft Entra, Intune, and Autopilot device identifiers where relevant. Intune primary user and ownership information where applicable. Assigned device-group memberships and any groups that must not be recreated. Device attributes or tags used for policy and application targeting. BitLocker recovery-key identifiers and administrative recovery status. Local execution logs and a central audit record. In a cross-tenant migration, group object IDs and device records are different. Memberships cannot simply be copied; source intent must be mapped to equivalent target groups, while dynamic membership must recalculate from target-tenant attributes. Step 10: Execute a protected identity transition The exact order varies by tool and environment. The following three phases are an illustrative orchestration model, not a universal sequence for every tool. Prepare and detach The workflow confirms readiness, protects the starting state, prevents sign-in during sensitive operations, and removes or transitions the former domain, registration, or management relationship in the planned sequence. Establish the target identity The selected tooling establishes the target Microsoft Entra join using Windows join or provisioning interfaces. Use of documented platform interfaces does not make the overall no-reset conversion a Microsoft-supported migration path. Controlled restarts and state checks confirm that the target trust was created before the workflow continues. Re-associate and finalize While the old user profile is fully unloaded, specialized tooling associates the existing eligible local profile with the correct target Microsoft Entra identity and aligns the necessary permissions. The local files do not need to be copied to an intermediate location simply to maintain the profile. After the protected stage, the user signs in with the Microsoft Entra account and final management, recovery, and cleanup tasks complete. This is the specialized part of the process. Microsoft does not provide a native supported AD-to-Entra profile-conversion utility, and its documentation states that, USMT does not support moving profiles from AD-joined devices to Microsoft Entra joined devices. The capability, support, and recovery obligations therefore belong to the chosen migration method. Profile continuity must also be described honestly. Windows Hello, passkeys, cached authentication tokens, Credential Manager entries, user-bound certificates and private keys, EFS-encrypted files, application licences, and some Outlook, OneDrive, or browser state may require re-authentication, re-provisioning, or separate recovery. Installed software can remain on the device without every identity-bound secret remaining usable. Endpoint migration does not migrate Exchange mailboxes, OneDrive or SharePoint content, Teams data, or other Microsoft 365 workloads; cross-tenant data migration requires a separate plan. Step 11: Re-establish management and policy intent Following the identity transition, the workflow should ensure that the endpoint: Enrolls in the correct Intune tenant and obtains valid management certificates. Has the correct primary user and ownership classification where applicable. Receives the intended device-group assignments, attributes, applications, and configuration. Re-onboards to Microsoft Defender for Endpoint where required. Escrows BitLocker recovery information to the intended target record. Receives the target Windows LAPS policy and proves administrative recoverability. Registers with Windows Autopilot for future reset, re-purpose, or replacement workflows where that is part of the lifecycle design. Removes obsolete source objects or management components only after the target state is proven. Be precise with the language: the same physical Windows installation may be retained, but new Microsoft Entra and Intune objects can be created. Intune enrollment is re-established, not magically “preserved,” and compliance must be recalculated after check-in. Step 12: Validate, observe, and scale in waves Validation should cover four dimensions. Identity Correct Microsoft Entra tenant and device record. AzureAdJoined : YES, DomainJoined : NO where intended, and successful device authentication in dsregcmd /status. A Primary Refresh Token for the signed-in user where expected. Microsoft documents these checks in its dsregcmd troubleshooting guidance. Management and security Intune check-in, correct primary user, policy delivery, Defender status, and compliance evaluation. Expected Conditional Access behaviour. Verified BitLocker recovery escrow and Windows LAPS operation. Required security baselines, certificates, updates, Wi-Fi, and VPN profiles. User continuity Desktop, documents, permitted local data, and compatible application settings. Microsoft 365, OneDrive, browser, Outlook, printers, mapped resources, and line-of-business applications. Expected reauthentication and Windows Hello provisioning. Business productivity SaaS access, required on-premises access, collaboration tools, and help-desk acceptance tests. Scale only after results are visible per device. A capable platform should provide central status, phase-level telemetry, error details, local Windows event logging, retry or recovery controls, and auditable outcomes. Migration can then proceed through technical validation, representative pilot, early adopters, departmental or location-based waves, broad rollout, and an exception queue. Depending on the operating model, deployment may use Intune, Group Policy, another endpoint-management platform, or a controlled manual process. Suitable endpoint-local architectures can also avoid a dedicated on-premises migration server. Define pause thresholds for first-pass failures, Intune enrollment delays, compliance delays, application incidents, and manual-recovery volume. Both centrally scheduled and guided self-service execution can be useful, depending on the user population and support model. Remote migration may be possible over the internet, but “no VPN required” should never be treated as universal. The answer depends on the domain-leave method, deployment channel, proxy, certificates, Wi-Fi, applications, and source-cleanup requirements. Remote scenarios need stable power, reliable connectivity, clear user communication, and a tested break-glass channel. What capable migration tooling should provide Automated readiness assessment Stops unsuitable devices before they enter a sensitive transition. Explicit identity mapping Connects the correct existing profile to the correct target user. In-place profile reassociation Preserves eligible local user state without rebuilding or copying the entire profile. Eligible multi-user profile handling Supports shared devices only when every profile and identity mapping is explicitly supported and proven in the pilot. Controlled sign-in and restart handling Prevents a user or background process from loading the profile during reassociation. Join and enrollment orchestration Coordinates domain departure, Microsoft Entra join, and Intune enrollment in the correct order. Primary-user, group, and attribute handling Reconstructs policy and application targeting without claiming that compliance state transfers. BitLocker and administrative recovery controls Maintains a usable recovery path throughout the identity gap. Source and target object hygiene Reduces duplicate, orphaned, or stale identity and management records. Remote and wave-based deployment Supports distributed workforces, schedules, rings, pauses, and exceptions. IT-driven and guided user modes Allows the operating model to match different user groups and support capacity. Central telemetry and local logs Gives IT evidence of each phase rather than relying on user reports. Checkpoint-based recovery Resumes or repairs partial transitions without promising an unrealistic one-click rollback. Least-privilege and transparent data handling Limits tenant access and makes it clear what device, identity, recovery, and diagnostic data is processed. No persistent endpoint agent after completion Avoids adding a permanent management dependency solely for a one-time transition. The right question is not, “Can the tool run a join command?” It is, “Can it safely coordinate identity, profile, management, recovery, and validation at enterprise scale?” How this complements Windows Autopilot Windows Autopilot and in-place migration solve different lifecycle problems. Microsoft describes Autopilot as a set of technologies for setting up and pre-configuring new devices and for resetting, re-purposing, and recovering existing devices. It should remain a core part of the future device lifecycle; see the Windows Autopilot overview. Device situation - Sensible approach New, replacement, or intentionally reset device - Use Microsoft Entra join through Windows Autopilot. Healthy existing device where eligible working state must remain substantially intact - Evaluate a vendor-supported, tool-assisted in-place migration through a representative proof of concept. Unhealthy, unsupported, or end-of-life device - Reset, rebuild, or replace it. Device with an unresolved legacy dependency - Remediate the dependency first or retain the device temporarily as a controlled hybrid exception. Windows Autopilot Reset should also be described accurately. On supported Microsoft Entra joined devices it removes personal files, apps, and settings while maintaining the Microsoft Entra and Intune connections; it does not support hybrid Microsoft Entra joined devices. Microsoft's Autopilot Reset documentation explains that use case. In-place migration does not replace Autopilot. It can help modernize the installed fleet, after which Autopilot can support the device's future reset, repurpose, recovery, and replacement lifecycle. When an in-place path may not be the right choice Reset or replacement may be safer when a device has: An unhealthy Windows installation, damaged disk, or corrupted profile. An unsupported edition or servicing state. A roaming, mandatory, temporary, VDI, FSLogix, or other containerized profile that the selected method does not explicitly support. EFS-encrypted content or critical private keys without a verified recovery plan. Business applications that require the AD computer account or cannot operate from a Microsoft Entra joined device. Kiosk, shared, laboratory, privileged-access, or other specialized configurations that require a separate design. So much historical configuration debt that a clean baseline is more valuable than preserving the current state. Low disruption is an eligibility-based design choice, not a guarantee for every endpoint. The practical way forward Reducing dependency on on-premises Active Directory does not have to be a big-bang rebuild of every Windows device. With the right discovery, target preparation, specialized migration tooling, security controls, and phased validation, eligible devices can move to a Microsoft Entra joined and Intune-managed state while keeping much of the user's familiar working environment in place. The most successful programs treat the change as more than a device join. They coordinate device trust, endpoint management, user continuity, and recovery as one controlled process. They use Windows Autopilot for new and reset devices, a vendor-supported in-place path where preserving the existing working state has clear business value and reset or replacement where it is technically safer. That is the practical path to faster endpoint modernization: align the destination with Microsoft's cloud-native strategy, choose the migration route according to device condition and business need, and declare success only after both security and user productivity have been verified. Microsoft Resources Cloud-native Windows endpoints overview Microsoft Entra joined versus hybrid Microsoft Entra joined endpoints High-level planning guide for cloud-native endpoints Plan a Microsoft Entra device deployment Set up automatic enrollment for Windows devices What USMT migrates—and does not migrate Windows Autopilot overview BitLocker recovery overview Windows LAPS overview
Intune 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-betaDuplicate subscriptions for a specific resource
Hello, Previously, we were not allowed to create duplicate subscriptions for the same resource. But now we can create duplicate subscriptions for a specific resource. Could you please confirm whether this functionality has been newly enabled or supported? Why duplicate subscriptions are now allowed for the same resource like (/users, /groups & communications/callRecords). Whether this is a change or a bug. We would appreciate clarification on the expected behavior and the supported use cases.
Intune App inventory Graph
Hi All, I've enabled the configuration profile to receive app inventory data in Intune. In the GUI the data I can view the data just fine, but I would like to use Graph to automate this data and create custom reports. When I use the following https://graph.microsoft.com/beta/deviceManagement/managedDevices/[device-id]/deviceInventories('ApplicationProperties') I get an error: "Forbidden - 403 - 199 ms Either the signed-in user does not have sufficient privileges, or you need to consent to one of the permissions on the Modify permissions tab" even though the docs I can find about permissions are OK.
What is the Microsoft Graph API replacement for deprecated Recent, SharedWithMe, and Insights APIs?
Hi Microsoft Graph community, I'm currently working on a Microsoft Graph integration that needs to retrieve: Files recently accessed/used by the current user Files shared with the current user Files from OneDrive and SharePoint I'm currently using the following APIs: GET /me/drive/recent GET /me/drive/sharedWithMe GET /me/insights/used However, these APIs are deprecated, and some of them will stop returning data after November 2026. (https://learn.microsoft.com/en-us/graph/api/drive-sharedwithme?view=graph-rest-1.0&utm_source=chatgpt.com) I'm stuck in development because I haven't been able to identify a Microsoft-supported replacement that provides the same functionality. Could someone please clarify: What is the official replacement for /me/drive/recent? What is the official replacement for /me/drive/sharedWithMe? What is the official replacement for /me/insights/used? Is there a single recommended Microsoft Graph API that can provide recently used and shared files across both OneDrive and SharePoint? I'm specifically looking for the officially supported API/recommended approach, rather than a workaround that may also become deprecated. Any guidance from Microsoft Graph experts or Microsoft employees would be greatly appreciated. Thanks!
Graph /users query with mailboxSettings filters/expands excludes unlicensed users
Hello Microsoft Graph team, I would like to report what appears to be a bug in Microsoft Graph user queries involving mailboxSettings. Issue summary: When mailboxSettings is used in a filter or expand clause on /users, unlicensed users are not returned, even when they should match the filter. Example scenario: Filter used: mailboxSettings/userPurpose ne 'room' Observed behavior: Users without Exchange license/mailbox are excluded from results (or result set appears truncated to mailbox-enabled users). Expected behavior: All users should be considered in /users query evaluation. If a user has no mailbox settings, behavior should be consistent and documented (for example null handling), but those users should not be silently dropped from /users results unless explicitly filtered out by query semantics. Reproduction steps: In a tenant with mixed users: Licensed mailbox users Unlicensed users without mailbox Run a /users query that includes mailboxSettings in filter and/or expand. Compare returned users with a baseline /users query without mailboxSettings conditions. Notice unlicensed users disappear when mailboxSettings is involved. Sample request patterns: GET https://graph.microsoft.com/v1.0/users?$filter=mailboxSettings/userPurpose ne 'room' GET https://graph.microsoft.com/v1.0/users?$expand=mailboxSettings&$filter=mailboxSettings/userPurpose ne 'room'
Virtual Event Legal Terms
Hello all - I'm currently in the process of attempting to integrate Team webinar registration into my Drupal site, but we discovered an issue where if this Legal Terms field is added to the Event > Registration > Configuration: It doesn't show up when we GET predefined questions, but we can't create a registration without somehow returning a response for this field. We get this error: But we can't find anything in the graph API documentation about how to structure a POST to include an agreement to the terms of use. In the graph api metadata I do see an unknownFutureValue enum which is in the same place in the list as where Legal Terms is in the Teams UI. Is there any current way around this, or is this just a feature that will be added to the API eventually? We'd have no problem just never selecting Legal Terms and including our own checkbox that would have to be checked to submit the registration, but then users who register for the event outside of our Drupal site would not have to agree to our terms to register because the only way to see it here is to add the Legal Terms field to the configuration.Retrieve all Teams transcripts a bot has attended to using Graph API
Hi there, I've been struggling for a lot of time trying to get this done. Has anyone been able to achieve something like this ? I wanted to : 1- Get all the meetings and transcripts of the tenant 2- Filter on those where the bot was attending 3- Get the transcripts when available. 4- Add rules to restrict the bot's access Right now I am stuck with the OAuth : The application 'bot-transcript' asked for scope 'OnlineMeetings.Read.All' that doesn't exist on the resource '00000003-0000-0000-c000-000000000000'. But this permission was added, and really seems to exist. Right ? Thanks in advance for any kind of help you could give me.
Graph API 1.0 - Listing lists doesn't return all lists (todoTaskList)
Hi, first time posting here, please let me know if I should be doing something differently! I've searched throughout the internet and couldn't find a reason for this. I've got a couple of users running into a problem where the https://learn.microsoft.com/en-us/graph/api/todo-list-lists?view=graph-rest-1.0&tabs=http endpoint only returns one list (Flagged Emails), though these users have and see many other lists in the To Do desktop (macOS) app. I've confirmed in both cases it's the same user that's identified in my app/integration and in the desktop app. They can see the tasks in that list without a problem. There are no errors requesting that list, and asking via `/users/{id|userPrincipalName}/todo/lists` also returns the same response (with that one list). Is there any known situation where this could be happening? Am I missing something obvious? Is there something else I should be trying? I've got many other customers using the To Do integration without a problem. I'm aware "My Day" and a few other special lists aren't returned. Thank you so much!Retrieving the “Device inventory” of iOS devices via the Graph API
We use Microsoft Intune to manage our iOS mobile devices. To achieve the highest possible level of efficiency, we use PowerShell as a supplementary tool for administration. Since our devices may contain two SIM cards, it is important for us to be able to read this information in order to perform relevant processes (e.g., adding phone numbers to address books). In general, it would be desirable to be able to read the information from the “Device Inventory” of iOS devices. For the reasons mentioned above, we would like this information to be made available via the Graph API. Alternatively, there should be a way to provide this information for all devices in a single report.
