+31(0)850160550 info@appixoft.com

Where workspace orchestration fits in hybrid Windows environments

31 Mar 2026 | Deep Dive

…next to Intune, ConfigMgr and GPO

Hybrid Windows environments often end up with user workspace settings spread across GPO, ConfigMgr, and Intune, which makes change control and troubleshooting harder than it needs to be. This article explains where a workspace orchestration layer such as worXpace fits, and how to use it to centralize user-facing workspace behavior without replacing your existing device management stack.

 

Why hybrid Windows management needs clearer workspace ownership

In a hybrid Active Directory and Microsoft Entra ID environment, you do not need to choose a single tool for everything. Running more than one management platform can increase complexity, overlapping policies, and governance overhead. If you add a workspace orchestration layer such as worXpace, treat that as a deliberate design decision, with a clearly defined user workspace scope and boundaries between tools.

You can keep Microsoft Intune and Configuration Manager (ConfigMgr) as your primary tools for device configuration, security, compliance, and most application lifecycle management. You then add worXpace as a workspace orchestration platform for Windows that focuses on selected user workspace elements across AD joined, Entra joined, and hybrid devices, such as managed shortcuts, drive mappings, app entry points, and context based automation. Instead of recreating similar mappings and scripts in GPO, ConfigMgr, and Intune, worXpace uses one targeting model to decide which applications, drive mappings, shortcuts, and workspace Actions a user gets in each session. For example, it can keep a project workspace consistent for a user who moves between an AD joined office desktop and an Entra joined laptop. In most environments, Intune and ConfigMgr still install the underlying apps and enforce baselines, while worXpace owns the user facing workspace behavior. As that model proves itself, a natural next step is to let worXpace also decide which selected applications should be delivered across your AD joined, Entra joined, and hybrid devices, while Intune and ConfigMgr continue to handle the actual installation and update mechanisms. worXpace runs on top of your existing Intune, ConfigMgr, and Group Policy configurations, and the exact implementation can differ per join type.

 

The real problem: three tools, one Windows user experience

In some larger or hybrid Windows environments, especially while they move from traditional to cloud management, three different engines can end up touching the same users and devices: Group Policy Objects (GPO), Configuration Manager (ConfigMgr), and Intune. Other estates may still run only GPO with ConfigMgr, or may have gone Intune first, so this three way overlap is a common pattern during long migration phases rather than a universal default.

GPO often still maps drives and printers for Active Directory joined devices. ConfigMgr may push scripts and application installs. Intune brings device profiles, compliance policies, and sometimes more scripts. Co‑managed devices can talk to both ConfigMgr and Intune at the same time.

In real world hybrid estates where legacy GPO and ConfigMgr items stay in place while new Intune assignments roll out, the result can be confusing. One drive mapping comes from an old logon script. Another comes from an Intune PowerShell script. A Start menu shortcut is in a ConfigMgr package. A new Entra joined laptop gets some of these items, but not all, because it only sees a subset of the legacy configuration. These are not inherent flaws in the tools. They show up when older configuration is left running next to newer assignments. Careful cleanup and migration planning can reduce these clashes, but many environments carry overlapping settings for years.

When you run pilots or move workloads between ConfigMgr and Intune, you do have models that define ownership. Examples are co‑management workload sliders and documented precedence rules between Group Policy and MDM policies on hybrid devices. But even with those controls, it is still hard in day to day support to see the full picture for one user on one device. Support teams often have to piece together which combination of GPO, ConfigMgr, and Intune items is shaping that Windows workspace. They must look across drives, printers, shortcuts, and scripts.

 

What Intune and ConfigMgr are already good at (and where they collide)

ConfigMgr and Intune are strong device management platforms. Together they handle Windows enrollment, device configuration profiles, security baselines, compliance, software distribution, and update management. In a co-management model, you can even choose per workload whether ConfigMgr or Intune is the authority.

Where things often get fuzzy in real environments is the user workspace layer: drive mappings, printer mappings, shortcuts, Start menu layout, and complex app stacks with add ons and prerequisites. In many historically grown or partially migrated environments, these items can end up spread across:

  • GPO preferences and logon scripts.
  • ConfigMgr packages and task sequences.
  • Intune device profiles, app assignments, and PowerShell scripts.

Each tool can do the job on its own. In hybrid or transition scenarios where two or three of them touch the same item and ownership is not enforced, you increase the risk of overlap, conflicting results, and change processes that are slow and hard to reason about. These problems are mainly about how organizations use the tools over time, not about hard limits in ConfigMgr or Intune.

 

Introducing workspace orchestration as a separate layer

A workspace orchestration platform for Windows environments focuses on who gets what workspace, and when. It gives you a way to describe user facing behavior once, then apply it consistently across different join types and management stacks.

With worXpace, the core objects look like this:

  • Tasks for general configuration and automation.
  • Applications and Compositions for single apps and app stacks.
  • Scopes and Criteria to describe who should get them, including checks on Active Directory and Microsoft Entra ID (Azure AD) group or OU membership.
  • Event Contexts (for example User Logon, Workspace Refresh, Computer Startup, Network Connect) to control when Actions run.

Actions then do the actual work: Network (drives and shares), Printer, Shortcut, Install, Start, Uninstall, Script, Notification, TaskDialog, and more.

Here is what that looks like in a mixed Active Directory and Microsoft Entra ID setup. You can create one Task that maps a project share and deploys an app stack to a user who signs in on an AD joined office PC and on an Entra ID joined laptop. A single Scope with AD and Entra group Criteria decides who gets it, and a User Logon Event Context decides when it runs. Another Task can show a Notification and add a Shortcut only when a device is in a specific AD OU or Entra device group and connects from a trusted network, instead of repeating that logic in separate Group Policy and Intune assignments. In both cases, the user workspace rules live in worXpace, while the underlying network access and app deployment remain in your existing tools.

At first glance this can look like adding a fourth tool on top of GPO, ConfigMgr, and Intune, after already calling out overlap between the first three. The intent is different: worXpace takes a narrow, explicit scope around user workspace behavior and pulls that logic out of the other tools over time. You accept one extra component so that drive mappings, shortcuts, and app entry points move into a single orchestration layer, instead of being scattered across several policy engines. The result is fewer places to change workspace rules and a clearer view of what each user should see across AD and Entra joined devices.

In this model, Microsoft Intune and Configuration Manager still handle device enrollment, app deployment, scripts, and most configuration and compliance policies. worXpace complements these capabilities by providing a dedicated, event driven way to orchestrate selected workspace elements across AD and Entra ID devices and users. It runs its Tasks and Actions alongside Intune and Configuration Manager so you can centralize workspace behavior and reduce duplicate or conflicting policy logic in hybrid environments, without replacing native Intune or ConfigMgr features.

 

How worXpace understands hybrid AD and Entra ID devices

Most workspace decisions in worXpace start with the user. You usually target Tasks, Applications, and Compositions by role, group, or location, using Active Directory or Microsoft Entra ID groups as Criteria.

When device state also matters, worXpace can look at the device and tenant it is running on. It does this through built in Device and Tenant variables that are available at runtime. These values come from the local Windows join state, management configuration, and Entra ID metadata. They refresh whenever the runtime starts for a user session or workspace refresh. In a steady state environment they are close to the real device and tenant state and work well for targeting. During migrations or broken joins some values can be missing or still changing, so Scopes should handle those cases safely.

On the Device side, examples include:

  • how the device enrolled
  • how it is managed, for example by Intune, ConfigMgr, or both
  • the trust model
  • the on premises domain name and related Windows AD sync fields
  • the identifier of the Entra device object

On the Tenant side, examples include:

  • whether the device is Entra joined, domain joined, or hybrid joined
  • identifiers for the Entra tenant, such as tenant id and display name

Scopes in worXpace group Criteria that test these user, device, and tenant signals. At runtime, a Scope decides if a Task, Application, or individual Action applies for the current user and device. In larger or multi tenant environments, complex hybrid rules still need careful design, testing, and maintenance. Scopes keep that logic in one place instead of across several tools and scripts.

In practice, this lets you do things like:

  • Use one Composition for an app stack that is assigned to a project group, and add Criteria so some Actions only run on devices that are joined to your on premises domain.
  • Target a different set of Actions when the same user signs in on an Entra joined, Intune only laptop, by adding Criteria for the management type and join state.
  • Split behavior for co managed devices by testing the management and join information, so you often avoid cloning the Task per platform, while still keeping separate Tasks when packaging or governance is different.

In many hybrid scenarios, the same worXpace object can adapt to AD joined, Entra joined, and hybrid devices, although some deployments still use separate objects when platforms, packaging, or rollout strategies are very different. The main logic stays user and role based, and you add device and tenant checks only where they affect what the user should see.

 

Layering worXpace on top of Intune and ConfigMgr: three concrete patterns

Across these patterns, worXpace starts from the user. You mainly target roles, groups, and locations. Device and management state are signals that the runtime can use when needed, but they are usually secondary.

1. One workspace for users who move between AD joined and Entra joined devices

Consider a user who has an old AD joined desktop, a co‑managed laptop, and an Entra joined Autopilot device. Co‑management lets that laptop be managed by both Configuration Manager and Intune at the same time. With worXpace, you still define most of that user’s Applications, Compositions, and workspace Tasks once at the workspace level, scoped mainly to AD or Entra groups that match their role or project, not to each device or management tool.

At runtime, worXpace evaluates these user Scopes first. When it has to treat devices differently, it can also read deep device and management signals, such as join type, management stack, or network location, and branch Actions on those conditions. In many workspaces only a few Actions need that device detail; the main decisions still come from who the user is and where they work. Intune and Configuration Manager keep handling enrollment, app install, and security, while worXpace focuses on the user facing entry points and workspace logic. The user can see very similar managed shortcuts, app launchers, and mapped resources across sessions, as long as the app type and network location are available on that device. Packaging formats, identity context, and network reachability can still differ between devices, so the experience is not always identical everywhere, but the rules behind it live in one place.

2. Replacing GPO logon scripts with Context based Tasks

For common drive, printer, and shortcut mappings that you now handle with logon scripts or Group Policy preferences, you can move that logic into worXpace Tasks that use User Logon and Workspace Refresh Contexts. Network, Printer, and Shortcut Actions handle the details. Group Policy logon scripts and drive mapping GPOs are still widely used and can be a source of logon and troubleshooting issues.

You still let GPO, ConfigMgr, and Intune manage the operating system and security. The day to day workspace logic for these common mappings lives in one place, with clean Scopes and Criteria that usually point at user and group membership rather than long device lists. More complex or highly privileged scripts can stay as scripts or move into Script Actions, and you should plan migration and testing so that logon performance, sequencing with existing GPOs, and troubleshooting remain acceptable.

3. Separating BYOD from corporate, while still offering a workspace

Many organizations enroll user owned devices into Intune with light compliance. Intune already lets you classify devices as corporate or personal and target different policies and apps to each group, so it can support both BYOD and corporate owned devices in one tenant. You may still not want full device policies on BYOD, but you want to deliver a few apps and links.

In a worXpace approach, you first decide which workspace a person should get in each role, then scope Tasks, Applications, and Compositions to Entra or AD groups that reflect BYOD or corporate usage. The runtime can also read device ownership and enrollment type signals when you need to ensure that some Actions, such as AD backed drive mappings, only run on corporate or co‑managed devices. Corporate owned, co‑managed devices might receive rich Compositions with drive mappings and printers. These can include access to AD backed resources where that is appropriate. BYOD devices only get a small Task that deploys web app shortcuts or a self service launcher. Intune continues to enforce ownership based settings and compliance, while worXpace adds one workspace model and user experience across AD joined, hybrid joined, and Entra joined devices. The separation between BYOD and corporate is driven by clear workspace rules in one place, even when you use multiple underlying management tools.

 

Workflow comparison: changing a workspace rule vs changing device policy

Take a simple, common change: you need to update a departmental file share from \\filesrv1\projects to \\filesrv2\projects_new.

In a policy first world, especially if drive mappings have grown across several tools over time, you might:

  • Update or replace one or more GPO drive mappings for AD joined devices.
  • Change a ConfigMgr script or package that also maps the drive.
  • Adjust an Intune device configuration profile or PowerShell script for Entra joined and co managed devices.
  • Wait for GPO processing and Intune policy check ins before you know if the change is everywhere.

Many organizations already keep drive mappings in a single place, such as GPO only, but in mixed AD and Entra ID environments it is easy for mappings to end up split like this. It works, but there are several moving parts, and conflicts can creep in.

With worXpace as the workspace layer, you model the drive mapping once as a Network Action inside a Task. The Task has:

  • A Workspace Refresh Context, so changes apply when the user logs in or refreshes the workspace.
  • Scopes that mainly use Active Directory or Entra ID user and group membership to decide whether to map the drive. You can also include device join or management Criteria in more advanced cases, but for this example that is usually not needed.

This single Task and Scope logic can target both AD and Entra ID devices, instead of maintaining separate GPO and Intune rules with duplicated conditions. A shared set of Scope Criteria covers both login and workspace refresh events, so you do not have to coordinate timing and precedence between different policy engines.

After you consolidate drive mappings into worXpace and disable legacy drive mapping settings in GPO, ConfigMgr, or Intune, most future share changes are handled by editing that one Network Action and, if needed, adjusting its Scopes. In that steady state, Intune and ConfigMgr policies often stay unchanged, the risk of conflicting mappings between tools goes down, and pilots can usually run as simple Scope or group changes instead of cross platform policy projects.

 

Reference model: who owns what in a hybrid AD/Entra ID environment

As a simple reference model, you can think of the environment as two layers that sit side by side across all Windows devices, AD joined, Entra joined, and hybrid. Real ownership is more mixed, but this picture helps you reason about who does what:

At the device management layer, Intune and ConfigMgr handle Windows enrollment, device configuration profiles, security baselines, compliance policies, software distribution, and updates. They also deliver many user scoped policies and apps, and can hold workspace logic today, together with Group Policy Objects (GPO). Microsoft co management guidance explains how you can choose which workloads each tool owns.

At the workspace orchestration layer, worXpace is meant to be the main place where you orchestrate selected user level behaviors. These include which apps and Compositions appear, which managed shortcuts are present, which drives and printers are mapped, and what prompts or notifications the user sees at key events. Today, Intune and ConfigMgr usually still perform the actual installation and update of most applications. In this model you first move the user facing workspace elements for those apps into worXpace and then retire overlapping GPO, Intune, or ConfigMgr rules, so that one tool owns each workspace element. Later you can also let worXpace decide which selected applications should be delivered to which AD or Entra ID users and devices, while Intune, ConfigMgr, and related tools stay in place as the delivery engines.

This reference model is compatible with the co management idea of sharing workloads between ConfigMgr and Intune, but it is an extra, workspace centric choice rather than something Microsoft prescribes. By moving user workspace logic that is spread across GPO, Intune, and ConfigMgr into worXpace, you centralize who decides which user sees which apps and entry points. For some app sets, worXpace can also choose the delivery path across AD joined and Entra joined devices. That can make it easier to manage policies, troubleshoot issues, and keep the user experience more consistent.

 

Rolling out worXpace without disrupting existing management

You can introduce worXpace in small, low risk steps if you scope pilots carefully and avoid conflicting changes.

A common pattern is to start with a pilot group of co managed or Intune only devices and choose one narrow workspace area, such as drive mappings or a key line of business app’s shortcuts. You model that in worXpace, using the same AD or Entra groups you already rely on, and keep the pilot to a small, well defined user set. For items that are already managed by GPOs or logon scripts, use test drive letters or shortcut locations, or temporarily narrow the GPO or script scope for the pilot, so users do not see duplicate or conflicting entries.

During this phase, you do not switch any Intune or ConfigMgr workloads. You compare the worXpace result with what GPO or scripts used to do, and before you retire those old items you verify that worXpace covers the right groups, OUs and edge cases. You can then de link or disable the GPOs and scripts in stages, starting with the pilot scope and monitoring for any regressions.

Over time, you can move more user workspace rules into worXpace while keeping existing device configuration policies in place. In later phases, many teams also move selected application delivery into worXpace by publishing applications to the worXpace Service Point so users can add or remove them from their workspace. As your scope grows, you may need to coordinate worXpace changes with device side settings such as VPN profiles, network configuration or security baselines so that workspace behavior and application access stay consistent.

 

Next steps: test workspace orchestration alongside your Intune and ConfigMgr setup

If you already run Intune, ConfigMgr, and GPO, a practical next step is an architecture review that can sit before or alongside any larger migration or consolidation work.

As part of that review, map your current workloads against a simple split: baseline device management and compliance in Intune and ConfigMgr, and context aware workspace orchestration in worXpace, such as user logon actions, app access, drive mappings, and other user experience settings. Baseline device management typically includes items like operating system builds, security baselines, antivirus, and VPN or Wi Fi profiles. Identify one or two workspace areas where overlapping policies or scripts hurt you the most, and decide which of those should move into worXpace so you avoid double targeting and conflicts. Many organizations already use Intune, often together with Windows Autopilot, as their main device deployment path, and keep that model while letting worXpace take on more workspace specific tasks as they see how direct and fast it is to change mappings, shortcuts, and app entry points.

Then schedule a focused worXpace demo or workshop that uses those real scenarios. The goal is to design a small pilot that runs next to your current co management setup and proves the workspace orchestration model. In many environments this pilot can modernize the Windows user experience with only minor baseline or targeting adjustments, coordinated with your existing Intune, ConfigMgr, and GPO policies for the pilot group. If that approach fits well, some teams later choose to treat worXpace as their primary place to manage user experience settings, while Intune and ConfigMgr continue to handle device deployment and baseline posture.

 

 

Footnotes (sources you can look up)

Co-management and policy ownership:

Intune fundamentals, enrollment, and device management:

Device profiles and configuration:

Group Policy and legacy workspace mappings: