Best approach to detect multiple user accounts signing in from the same physical device
Hi Everyone, Working on environment: D365 Finance & Operations (cloud). Goal: I need to detect when more than one Dynamics user account is being used from the same physical device, and ideally count how many distinct users are active on that device. The business reason is this is not permissible to login with more than one account in the same device. For example: User X has device D1, User Y has device D2. User X logged in with his account using Device D2 (which is user's Y device). I want to know if this happened, cause it's not permissible behavior in the organization. For more illustration some users have blank devices id when I see Microsoft Entra. Or if I could find out when a user logs in and integrate it with D365 F&O to store the device the user logged into in a custom log table or anything that tells me that this user account is opened on more than one device or this device has more than one logged-in user account. .
Why “Data in Switzerland” Is Not Enough
Moving from Residency to Control in Microsoft 365 Every conversation about data sovereignty in regulated industries tends to start the same way: “We use Multi-Geo. The data stays in Switzerland.” It’s the right starting point. Microsoft 365 Multi-Geo allows organizations to place selected workloads - SharePoint sites, OneDrive accounts, Teams data, or Exchange mailboxes - into specific regions, including Switzerland, while maintaining a single global tenant. This makes it possible to align sensitive data with regulatory or customer requirements without fragmenting the overall environment. But it only answers one question: Where is the data stored? It does not answer who accessed the data, from where, under which conditions, or what happened after access. That is where the real problem begins. A scenario that happens every day A Swiss engineering firm stores sensitive project documentation in Switzerland using Multi-Geo. An external contractor - working from an unmanaged device outside Switzerland - is granted access to review a file. The document opens. The data is now on a screen in an unknown location, on a device with no compliance posture, in a session with no restrictions. From the platform’s perspective, residency was enforced. From a sovereignty perspective, control was lost the moment access was granted without conditions. The file never left Switzerland. But sovereignty did. Residency is static. Control is not. The moment a document is opened, storage location stops being the relevant boundary. The file is no longer just “in Switzerland.” It moves instantly across endpoints and browsers, collaboration tools like Teams, external users and partners, and increasingly AI-driven contexts. The infrastructure remains unchanged. The data does not. From the platform’s perspective, everything is working as designed - access was granted, residency was enforced - and control was lost. Most “data in Switzerland” strategies fail at exactly this moment: when the data is used. The shift: from location to conditions If data sovereignty is the goal, the question must change. Not “Where is the data stored?” but: Under which conditions can data be accessed and used? This shift fundamentally changes the architecture. Control must be applied across three distinct layers - and all three must be connected. Layer 1: Access is conditional, not static Conditional Access extends control beyond authentication and turns it into continuous evaluation. Access decisions can depend on: Device compliance Location (geo-restriction) Identity and risk signals Multi-Geo ensures data is placed correctly. Conditional Access ensures it is reachable only under defined conditions. The two must work together - residency without access governance is an incomplete control. Layer 2: The session is the real risk surface Even with strict access controls, risk remains. A session is an exposure surface by design. During an active session, data is viewed, copied, shared, processed by applications, and connected to AI prompts. The gap does not appear at storage or authentication. It appears during active usage - inside the session. This is the layer most architectures do not explicitly address. Controls must extend into the session itself: limiting data transfer and replication, restricting interaction patterns, and enforcing policies in real time. Access is no longer a one-time event. It becomes continuously governed. This becomes even more critical as AI assistants consume content across SharePoint, Teams, Exchange, and other Microsoft 365 services. The question is no longer only where the source document resides - but whether the AI interaction itself is governed by the same access and protection controls as direct access. Layer 3: The document becomes the control point The most durable control does not sit in the network or in the session. It sits in the data itself. In regulated industries, organizations often arrive at this architecture having first evaluated sovereign or national encryption solutions. The decision to rely on native Microsoft 365 Purview encryption rather than a separate layer comes down to integration: AES-256 protection operating natively at file, user, and SharePoint level - including geo-based access restrictions - without an additional system to maintain. When protection is applied directly to the document through Microsoft Purview: Sensitivity labels define classification - automatically assigned based on content Encryption enforces access - AES-256, bound to the file itself IRM controls usage - view, copy, print, share, and presentation rights DLP governs movement across services - preventing data from leaving defined boundaries Dynamic watermarking tracks exposure - applied on open, view, or print At that point, access is enforced by the file, usage restrictions travel with it, and control persists regardless of location. The document becomes the perimeter. Platform control: limiting provider access One dimension often overlooked in sovereignty discussions is platform access itself. Even a perfectly configured tenant is only as sovereign as the controls placed on the operator. Customer Lockbox ensures that even Microsoft support cannot access customer data without explicit, logged, time-bound approval. Every access request is visible, auditable, and subject to customer veto. Data control applies not only to users - but also to the platform operating the service. Enforcement requires an integrated architecture Most organizations already have the required capabilities: Multi-Geo, Conditional Access, session control, Purview (labels, encryption, DLP, IRM), and monitoring. The issue is not capability. It is fragmentation. In practice, fragmentation looks like this: residency is configured in one project, Conditional Access policies are managed by a different team, and Purview labels were applied during a compliance initiative that never connected to the access layer. The tools exist. The signals do not flow between them. When designed as a single architecture: Data is placed intentionally - residency aligned to regulatory requirements Access is governed by context - device, location, and identity evaluated continuously Usage is controlled dynamically - session-level restrictions enforced in real time Protection is embedded in the document - encryption and IRM travel with the file Signals are connected across the platform - monitoring feeds access policy, not just audit logs “Data in Switzerland” becomes not just a statement - but an enforceable system property. Closing thought Placing data in Switzerland is the right first step. Multi-Geo makes it possible, even in global environments. But residency alone is not control. Data residency answers where information is stored. Data sovereignty requires proving who can access it, under which conditions, and what controls remain in place after access is granted. In Microsoft 365, sovereignty is no longer defined by geography alone. It is defined by the ability to enforce control wherever the data travels.
MacOS platform SSO deployment issues
Hello, We tried to deploy MacOS platform SSO but the devices are having problems with their authentication. The devices are connected through company portal but keep asking for logins and authentication, especially on reboot. Some users are prompted to sign-in to their entra account several times per hour. To Deploy it we used the configuration setting template: Authentication > Extensible Single Sign On (SSO) Settings: Extension Identifier: com.microsoft.CompanyPortalMac.ssoextension Authentication Method: Password Token To User Mapping: Account Name: preferred_username Full Name: name Use Shared Device Keys: Disabled Team Identifier: UBXXXXXX Type: Redirect Has anyone here experienced similar issues or found a fix for these constant re-authentication prompts? Thanks!Windows App Management in Microsoft Intune
Audit every managed and unmanaged app per device with more metadata, including publisher, architecture, estimated size on disk, install location, uninstall commands, to help troubleshoot PCs and expose shadow IT before it spreads. Pull curated Win32 apps straight from the Enterprise App Catalog or upload PowerShell scripts to control exactly how each app installs. Stage rollouts in rings with Intune deployments, to gradually deploy, pause or cancel any deployment in flight; and auto-trust every app you push using App Control for Business with Managed Installer, which also works with Autopilot as you provision new devices, now with up to 25 apps. Keep your fleet of apps up-to-date automatically as vendors publish new versions through the Enterprise App Catalog, or trigger updates on demand from the Guided Upgrade Supersedence report. Nicole Zhao, Microsoft Intune Product Manager, shares how to put these built-in enhancements to work across every managed device. *Intune Deployments is currently in private preview. Capabilities shown are subject to change and not yet generally available. Identify shadow apps across your managed devices. Microsoft Intune’s app inventory now surfaces publisher, architecture, size on disk, install location, & uninstall command per device. See how it works. Auto-trust every app you deploy through Intune. App Control for Business with Managed Installer tags your deployments as safe and scopes trust to specific user groups. Check it out. One toggle, continuous app updates. The Enterprise App Catalog in Intune pushes vendor releases to managed devices automatically, or surfaces them in a Guided Supersedence report for manual review. Try it now. QUICK LINKS: 00:00 — Built-in app management 00:51 — App Inventory Visibility 01:42 — Enterprise Application Management (EAM) 02:28 — PowerShell Script Installer GA 03:09 — Ring-Based Deployment Plans 04:44 — Managed Installer Auto-Trust 05:39 — Enterprise App Catalog Auto-Update 06:12 — Guided supersedence 06:50 — Wrap up Link References Go to https://aka.ms/IntuneAppManagement Check out https://aka.ms/RSAC26-Intune-Blog from the RSA Conference for additional security context and guidance when managing apps with Microsoft Intune. Unfamiliar with Microsoft Mechanics? As Microsoft’s official video series for IT, you can watch and share valuable content and demos of current and upcoming tech from the people who build it at Microsoft. Subscribe to our YouTube: https://www.youtube.com/c/MicrosoftMechanicsSeries Talk with other IT Pros, join us on the Microsoft Tech Community: https://techcommunity.microsoft.com/t5/microsoft-mechanics-blog/bg-p/MicrosoftMechanicsBlog Watch or listen from anywhere, subscribe to our podcast: https://microsoftmechanics.libsyn.com/podcast Keep getting this insider knowledge, join us on social: Follow us on Twitter: https://twitter.com/MSFTMechanics Share knowledge on LinkedIn: https://www.linkedin.com/company/microsoft-mechanics/ Enjoy us on Instagram: https://www.instagram.com/msftmechanics/ Loosen up with us on TikTok: https://www.tiktok.com/@msftmechanics Video Transcript: -Controlling the application layer on devices, delivering the right apps, keeping them secure, up to date, and protected has always been one of the toughest challenges as you manage IT environments. This is nothing new, but what is new is how much easier Microsoft Intune now makes it. With the latest built‑in app management enhancements, you can more easily discover apps across your environment with clearer visibility into your full app inventory per device, simplify app preparation and deployment through pre-packaged apps or with scripted installs, as well as safer, gradual app roll-outs using ring-based deployments. -Ensure only trusted apps run by automatically trusting deployed apps through App Control for Business with Managed Installer, and keep devices automatically on the latest versions as vendors release updates, using the new auto-update capability with your Enterprise App Catalog. It all starts with knowing what apps people have running on their managed devices. And that’s where the latest improvements to app inventory in Intune give you the full up-to-date picture with minimal latency. -Here, for each device, you can see a comprehensive list of inventoried applications, including both managed and unmanaged apps. Importantly, we’ve added more app metadata to help you make better decisions about your apps or start troubleshooting. For each app, you can see the publisher name, architecture, and now even estimated size on disk, as well as installed location, uninstall command, and languages, as long as that information was registered in Windows. For shared devices, we’ve also improved the per user app information to include all users on the device. This gives you clear visibility into which applications exist in your environment, to help you identify unknown or shadow applications that may be running against your policy and governance controls. Next, for getting the right apps deployed, let me show you how we’ve made it easier to bring apps into your managed catalog. -Here, Enterprise App Management, or EAM, is designed to simplify app lifecycle management. I’m going to start by creating an app. Unlike the consumer-focused Microsoft Store, which uses community-driven WinGet app types for app discovery, EAM provides a curated list of enterprise-ready Win32 apps. You can find these apps by choosing the Enterprise App Catalog app type and Confirm. From there, you just need to search for the apps you want. In this case, I’ll look for Blender, and then under Configuration, you’ll find available architectures and versions. You’ll see that it pre-populates the app information. And in the Program tab, the install and uninstall command lines are pre-populated, as well as the exit codes. -Now, this used a command line installer type, but something new to give you even more control is the script installer, which is now generally available. This lets you use PowerShell script to control the installation of your Win32 apps. So, I’ll change the installer type to be a PowerShell script, and that will expose a control to upload a custom script as a PS1 file. Next, I’ll choose the Blenderinstaller script from File Explorer. It conveniently enters the name field for me and then mounts the script to give a preview of the pre-installation commands it runs. This gives you precise control over the install behavior of your apps using script-based installation. And as we progress, the rest of the steps for getting this app deployed to your managed devices should be pretty familiar. -Next, for app roll-outs, Intune’s policy-driven deployment lets you introduce application changes gradually using Deployment Plans. This helps avoid issues from misconfigured, compromised, or unintended app updates, giving you more control over the roll-out process. Let me show you how to create a deployment. You’ll start in Deployments, which you’ll find under Managed Devices. At the top, you’ll see two tabs: Deployments, which lists the app payloads targeted for existing roll-outs; and Deployment Plans, which are reusable deployment schedules that you create with ring timing, as well as assigned groups. I’ll move to the Deployments tab and select Create. Then I’ll give it a name, Global Secure Access Client, and description, East Coast rollout, Next, I’ll select a payload. I’ll choose Win32 and Add Payload, and select Global Secure Access Client. -Now I’ll configure the deployment schedule, which is the key step when setting up this deployment. Here I can either build rings manually, where you’ll add time offsets per ring, or I can load an existing deployment plan. In this case, I’ll load a plan. From here, I can choose the plan I want. I’ll pick the East Coast retail store rollout plan. I’ll choose a start date and add a time. Once the plan loads, all the rings are added with their timelines and associated groups or exclusions. For example, this one has a one-week offset between each ring. When I move to the last Review step, this dialog on top tells me that, once created, I can pause, resume, or cancel the deployment at any time. -From there, I can review my deployment and confirm by hitting Create. Now my app will roll out based on this defined schedule. Let’s look at the latest capabilities for keeping your apps trusted. First, App Control for Business with Managed Installer in Intune means that apps you deploy using this method are automatically tagged as safe apps, without manual allow-listing. It lets you upload your app control policies as XML files or leverage built-in controls to automatically trust apps from the managed installer. -There’s also a new option to target the Managed Installer to specific groups where you enable Intune Managed Extension as Managed Installer and scope the managed installer to specific users with inclusion and exclusion policies. Additionally, with Managed Installer enabled during Autopilot device preparation, you can ensure apps are trusted right from the start as you provision new devices. And using device preparation policies, Autopilot also supports an increased app limit of up to 25 apps. Of course, you can combine these capabilities with Windows Defender Application Control together with Intune to allow only trusted and approved apps to run on your managed devices. Now let’s look at new ways to keep apps on the latest version. -First, with the new auto-update capability using the Enterprise App Catalog, you can have Intune automatically keep apps up-to-date on your managed devices. When you add a new app using the Enterprise App Catalog, as part of the initial configuration in the Updates tab, you can choose between Automatically Update and Update with Supersedence. This is a one-time setting that allows Intune to automatically install updates as they are published. From there, once you confirm, you’ll see that, by design, many of the subsequent settings have been streamlined to just Scope tags, Assignments and Review + Create. -And if you want more control over app updates, our second option, Guided Upgrade Supersedence, automatically surfaces available updates of your deployed apps without you having to go look for new versions of each app manually. You’ll see that, under Apps in the Monitor blade, you’ll find a new report called Enterprise App Catalog apps with updates. By clicking into one of these apps, you’ll see that there is an update button in the upper left corner. This lets you supersede existing app versions for that app on managed devices in just a few clicks. You’ll see that all of the necessary information is pre-populated. And this is the same with the program tab and subsequent tabs in the app deployment workflow, including the supersedence relationship. -Everything you’ve seen today is about simplifying control of your application layer, making apps easier to discover, deploy, trust from day one, and keep automatically up to date, so you can deliver the right apps securely and consistently across your environment. To find out more, check out aka.ms/IntuneAppManagement Keep watching Microsoft Mechanics for the latest tech updates, and thanks for watching!
Best approach for migrating AD joined devices to Entra ID without wiping user profiles?
We’ve seen many organizations struggle with device migration when moving from traditional Active Directory (AD) or hybrid environments to Microsoft Entra ID. The biggest challenge is avoiding user disruption especially when wiping devices causes profile loss, app reconfiguration, and downtime. In large environments, wipe-and-reload becomes difficult to scale and impacts productivity significantly. Curious to know how others are handling this: Are you still using wipe/reimage methods, or are you using alternative approaches that preserve user profiles, applications, and settings? Would love to hear practical experiences from the community.
