Why Are My Citrix VDA Machine Accounts Appearing in Microsoft Entra ID?

You've set up a Citrix DaaS environment with domain-joined Virtual Delivery Agents (VDAs). Your machine accounts reside in a dedicated Organizational Unit (OU) in your on-premises Active Directory. Users authenticate via SAML 2.0 with Microsoft Entra ID and everything works smoothly SSO is functioning and Microsoft 365 Apps with shared computer licensing are deployed on the VDAs.

Then you notice something unexpected: your VDA machine accounts are appearing as devices in the Microsoft Entra ID console, showing as "Microsoft Entra registered". You delete them, but they keep coming back with different registered owners each time.

Understanding the Problem

When VDA machine accounts mysteriously appear in Entra ID as "Microsoft Entra registered" devices, there are several potential causes:

1. Microsoft 365 Apps automatic device registration Office apps registering the device via WAM
2. Microsoft Entra Connect synchronization Your sync scope includes the VDA OU
3. Hybrid Entra ID Join GPO-configured automatic registration
4. Seamless SSO / Primary Refresh Token behavior PRT triggering device registration

In Citrix DaaS environments with Microsoft 365 Apps deployed, the most common cause is #1 the Web Account Manager (WAM) automatically registering devices when users sign into Office applications.

Identifying the Cause

Step 1: Check the Device Properties in Entra ID

Navigate to Microsoft Entra ID > Devices and locate one of your VDA machine accounts. Examine these properties:

Key indicator: If the Registered Owner is different for each device and corresponds to actual users in your organization, this confirms that Microsoft 365 Apps are triggering the registration.

Step 2: Run dsregcmd /status on a VDA

Open an elevated command prompt on one of your VDAs and run:

dsregcmd /status

Here's an example output from a real-world scenario:

+----------------------------------------------------------------------+
| Device State                                                         |
+----------------------------------------------------------------------+

             AzureAdJoined : NO
          EnterpriseJoined : NO
              DomainJoined : YES
                DomainName : YOURDOMAIN
               Device Name : VDA001.yourdomain.local

+----------------------------------------------------------------------+
| User State                                                           |
+----------------------------------------------------------------------+

                    NgcSet : NO
           WorkplaceJoined : NO
             WamDefaultSet : NO

+----------------------------------------------------------------------+
| Diagnostic Data                                                      |
+----------------------------------------------------------------------+

     Previous Registration : 2025-01-22 14:51:21.000 UTC
         Registration Type : sync
               Error Phase : join
          Client ErrorCode : 0x801c03f3
          Server ErrorCode : invalid_request
       Server ErrorSubCode : error_missing_device
          Server Message : The device object by the given id (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx) is not found.

Step 3: Interpret the Results

You might notice that Registration Type shows sync, which can be misleading. This doesn't necessarily mean Entra Connect is the cause. The registration type can show "sync" even when the actual trigger is an Office 365 application.

Key observations:

• WorkplaceJoined : NO at the device level
• But devices still appear in Entra ID
• Different registered owners for each device

This pattern indicates that users are triggering the registration through Microsoft 365 Apps, not a system-level sync process.

Step 4: Rule Out Other Causes

Before implementing the solution, verify these aren't contributing:

Check Entra Connect OU filtering:

• Open Entra Connect configuration
• Verify the VDA OU is NOT included in the sync scope

Check for Hybrid Join GPO:

gpresult /h c:\temp\gpo-report.html

Look for: Computer Configuration > Administrative Templates > Windows Components > Device Registration

Check registry for Workplace Join policies:

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin" /s

If these checks come back clean, the cause is confirmed: Microsoft 365 Apps via WAM.

Why Does This Happen?

When users sign into Microsoft 365 applications (Word, Excel, Outlook, Teams, OneDrive, etc.) on a Windows device, the Web Account Manager (WAM) handles the authentication. As part of this process, WAM can automatically register the device with Microsoft Entra ID.

This behavior is by design for personal devices and traditional workstations, where device registration enables:

• Single Sign-On across Microsoft 365 apps
• Conditional Access policy evaluation
• Device-based compliance checks

However, in a Citrix VDA environment, this creates problems:

• Multiple users share the same VDA
• Non-persistent VDAs may be recreated frequently
• You end up with numerous device entries cluttering your Entra ID tenant
• Deleting devices is futile the next user who logs in recreates them

The Solution

Block Workplace Join via Group Policy

Deploy a registry setting via GPO to prevent Microsoft 365 Apps from registering VDAs with Entra ID.

Registry Setting:

Path: HKLM\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin
Name: BlockAADWorkplaceJoin
Type: REG_DWORD
Value: 1

Steps to Create the GPO:

1. Open the Group Policy Management Console (GPMC)
2. Create a new GPO or edit an existing one linked to your VDA OU
3. Navigate to: Computer Configuration > Preferences > Windows Settings > Registry
4. Right-click > New > Registry Item
5. Configure the following:
   • Action: Create
   • Hive: HKEY_LOCAL_MACHINE
   • Key Path: SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin
   • Value name: BlockAADWorkplaceJoin
   • Value type: REG_DWORD
   • Value data: 1
6. Click OK
7. Ensure the GPO is linked to the OU containing your VDA machine accounts

Apply the policy immediately:

gpupdate /force

Verify the setting was applied:

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin" /v BlockAADWorkplaceJoin

Expected output:

BlockAADWorkplaceJoin    REG_DWORD    0x1

Clean Up Existing Devices

After implementing the GPO, clean up the existing VDA devices in Entra ID. They won't come back this time!

Using the Entra ID Portal

1. Navigate to Microsoft Entra ID > Devices > All devices
2. Filter by:
   • Device name (if you have a naming convention like "VDA*" or "CTX*")
   • Join type: "Microsoft Entra registered"
3. Select the VDA devices
4. Click Delete

Using Microsoft Graph PowerShell

For bulk cleanup:

# Install the module if needed
Install-Module Microsoft.Graph -Scope CurrentUser

# Connect with appropriate permissions
Connect-MgGraph -Scopes "Device.ReadWrite.All"

# List devices matching your VDA naming convention
$vdaDevices = Get-MgDevice -Filter "startswith(displayName,'VDA')" -All

# Review the list first!
$vdaDevices | Select-Object DisplayName, Id, ApproximateLastSignInDateTime, TrustType | Format-Table

# Delete the devices (uncomment when ready)
# foreach ($device in $vdaDevices) {
#     Write-Host "Deleting device: $($device.DisplayName)"
#     Remove-MgDevice -DeviceId $device.Id
# }

# Disconnect when done
Disconnect-MgGraph

Impact on Users

Will this break SSO or Microsoft 365 functionality?

No. The BlockAADWorkplaceJoin setting only prevents device registration in Entra ID. Users will still be able to:

• Sign into Microsoft 365 applications
• Use SSO if configured (via Citrix FAS or domain credentials)
• Access all Microsoft 365 services

The only difference is that the VDA device won't be registered in your Entra ID tenant.

Conditional Access Considerations:

If you have Conditional Access policies that require:

• Compliant devices
• Hybrid Entra ID joined devices
• Registered devices

These policies may need to be adjusted to exclude VDA sessions or use alternative controls (like requiring MFA instead of device compliance).

Best Practices for Citrix DaaS with Microsoft 365

1. Always Block Workplace Join on VDAs

Make BlockAADWorkplaceJoin a standard part of your VDA image or GPO baseline.

2. Use Shared Computer Licensing Correctly

Ensure this registry key is set:

HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configuration
"SharedComputerLicensing" = 1

This prevents Office from caching user licenses on the VDA.

3. Organize VDAs in Dedicated OUs

Keep VDA machine accounts separate from user workstations to:

• Apply VDA-specific GPOs easily
• Exclude from Entra Connect sync if needed
• Simplify management and cleanup

4. Review Entra Connect Scope

Even if it's not the current cause, verify your VDA OU is excluded from Entra Connect synchronization to prevent future issues.

5. Implement Regular Device Cleanup

Create an automated process to identify and remove stale devices from Entra ID, especially in non-persistent VDA environments.

6. Document Your Configuration

Maintain documentation of:

• Why BlockAADWorkplaceJoin is configured
• Which OUs have this setting
• Conditional Access policy exceptions for VDAs

VDA machine accounts appearing in Microsoft Entra ID is a common issue in Citrix DaaS environments with Microsoft 365 Apps. The cause is typically the Web Account Manager (WAM) automatically registering devices when users authenticate to Office applications.

The solution is straightforward: deploy a single registry setting via GPO to block Workplace Join on your VDAs. This prevents the automatic registration without impacting user experience or Microsoft 365 functionality.