Fixing ERROR_DS_CANT_MOVE_APP_QUERY_GROUP (0x000021A1)

Cause 1: The group has existing members

This is the most common trigger. Query-based application groups (groupType containing ADS_GROUP_TYPE_APP_QUERY) can't be moved across domains if they're not empty. The system flat out refuses. You'll see this when running dsmove or ADMT on a group that's been used in production.

The fix is straightforward: remove all members from the group before moving it. Use AD Users and Computers or PowerShell:

Get-ADGroupMember "YourGroupName" | ForEach-Object { Remove-ADGroupMember -Identity "YourGroupName" -Members $_.DistinguishedName -Confirm:$false }

After that, run the move again. If the group's empty, the move should succeed. If it still fails, check for nested groups — those count too.

A common scenario: migrating a legacy LOB app's distribution group from a child domain to the root domain. The group had 200 users, and someone tried to move it directly. That's when you see 0x000021A1.

Cause 2: The group type itself blocks the move

Even an empty query-based group can sometimes fail. The underlying issue is that query groups rely on an LDAP query stored in the memberQuery attribute. That attribute references domain-specific objects. Move it to another domain, and the query breaks.

Don't bother trying to change the group type to a distribution group first — AD won't let you convert a query-based group to a basic security or distribution group directly. It's a one-way street once created.

The real fix is to recreate the group in the target domain. Export the group's attributes (especially the memberQuery and groupType), then create a fresh group in the new domain with the same query:

1. Export the group with PowerShell:

   Get-ADGroup "YourGroupName" -Properties * | Select-Object Name, GroupType, MemberQuery | Export-Csv group_backup.csv

2. Check the memberQuery value — it looks like (&(objectCategory=person)(department=sales)). Update any domain-specific paths in the query (like DC=olddomain,DC=com) to match the new domain.

3. Create the group in the target domain:

   New-ADGroup -Name "YourGroupName" -GroupCategory Security -GroupScope Global -DisplayName "YourGroupName" -Path "OU=Groups,DC=newdomain,DC=com"

4. Set the groupType to include the application query flag (value 0x80000000 = -2147483648) using Set-ADObject:

   Set-ADObject -Identity "CN=YourGroupName,OU=Groups,DC=newdomain,DC=com" -Replace @{groupType=-2147483648}

5. Set the memberQuery attribute with the updated query:

   Set-ADObject -Identity "CN=YourGroupName,OU=Groups,DC=newdomain,DC=com" -Add @{memberQuery='(&(objectCategory=person)(department=sales))'}

This recreates the group from scratch. It's more work, but it's the only reliable method when the group's query ties it to the source domain.

Cause 3: You're hitting a hard-coded framework restriction

Some Microsoft products (Exchange, SharePoint, Skype for Business) create query-based application groups automatically. Examples include Exchange Servers or Discovery Search Mailbox groups. These are system-managed. The framework prevents moving them across domains because they're tightly coupled to the product's configuration.

Don't try to move these groups. Period. If you need them in the target domain, install the product there and let it create new groups. Or use the product's management tools to migrate the configuration.

A real-world scenario: someone tried to move the Exchange Trusted Subsystem group from an old domain to a new one during a forest migration. That group is query-based and used by Exchange. The migration failed with 0x000021A1. The fix was to onboard the Exchange servers into the new forest and let the product recreate the group.

If you're not sure whether a group is system-managed, check its adminDescription or adminDisplayName attributes. If it says "Microsoft Exchange" or "SharePoint", leave it alone.

Quick-reference summary