Moving objects in Active Directory is a routine part of keeping the directory organized: Relocating a user when they change departments, gathering decommissioned machines into a quarantine OU, or restructuring containers after a reorganization. Every move changes which OU holds the object, and with it, which Group Policy applies.

The Move-ADObject cmdlet in the PowerShell Active Directory module handles this for any object type, like users, computers, groups, and OUs, by pointing the object's distinguished name at a new target container. This guide covers three methods on how to move objects in Active Directory: Using the Move-ADObject cmdlet, the Active Directory Users and Computers (ADUC) console, and ADManager Plus, along with common error fixes you may face.

Understanding objects and OUs in Active Directory

An Active Directory object is any entity the directory tracks, such as a user, computer, group, contact, or the OU, that contains them. OUs are the containers that hold those objects and give the directory its structure, typically arranged by department, location, or object type. Because Group Policy and delegated permissions are applied at the OU level, an object's OU determines both the policies it receives and who can control it.

Moving an object relocates it from one OU (the source) to another (the target). The object keeps its SID, group memberships, and attributes, but leaves behind the source OU's linked Group Policy and delegation, and picks up whatever applies at the destination. That policy shift, covered below, is the part worth thinking through before any move.

Prerequisites

Before making any moves, make sure the following are in place:

Tools: The Active Directory PowerShell module must be available—it's installed with the Active Directory Domain Services (AD DS) role on a domain controller, or with the Remote Server Administration Tools (RSAT) on a Windows 10/11 Workstation.

Permissions: The account running the command needs delegated Write and Create/Delete rights on both the source and destination OUs. Being a member of the Domain Admins group provides these permissions.

Object identity: You'll need each object's distinguished name (DN) to reference it in the move command. You can retrieve the DN by querying the object in PowerShell or by viewing its properties in ADUC.

For the PowerShell method, import the Active Directory module and confirm that it is loaded:

How to move Active Directory objects using PowerShell

Finding the object's current location and DN

Every move needs the object's DN—its full LDAP path, such as CN=Jane Smith,OU=Sales,DC=corp,DC=com. The DN identifies the object and shows its current location in the directory. You can retrieve it using ADUC or PowerShell:

1. Using ADUC (GUI): Enable View > Advanced Features, right-click the object, choose Properties, and open the Object tab. The Distinguished Name field shows the DN you need for the move command.
2. Using PowerShell: Query the object and read its DistinguishedName property. For a user, run:

To move a computer object, use Get-ADComputer, optionally narrowing the search with -Filter and -SearchBase:

Moving objects using the Move-ADObject PowerShell cmdlet

With the source DN and the destination OU in hand, the move is a single command. Move-ADObject takes the object to move (-Identity) and the destination container (-TargetPath), both expressed as DNs.

Always preview first. The -WhatIf parameter reports what the command would do without changing anything. It's a cheap safety check that catches a mistyped DN before it moves the wrong object:

When the preview looks right, run it for real by removing -WhatIf:

Bulk-moving stale computer objects

A common hygiene task is cleaning up stale computer accounts that haven't logged in for an extended period and moving them to a quarantine OU for review before deletion. Get-ADComputer finds them by lastLogonDate, and the results are piped to Move-ADObject, which moves every returned account to the target OU in the same command. This example quarantines every computer inactive for more than 90 days:

Review the -WhatIf output, then remove the flag to execute. For a safer sequence, disable each stale computer account before moving it. A moved account keeps working but loses the Group Policy linked to its original OU, so a device still in use can slip out of management unnoticed. A disabled account can't authenticate to the domain, so if the machine is still needed, failed sign-ins surface it quickly, and you can re-enable it and move it back.

Supported parameters

The parameters below can be used with the Move-ADObject cmdlet.

Limitations of using PowerShell to move objects

• Move-ADObject needs the exact DN of both the object and the target OU, so bulk and stale-object moves depend on PowerShell fluency and careful filtering to avoid relocating the wrong objects.
• There's no built-in approval step, so a mistaken or oversized bulk move runs with nothing to catch errors first.
• Changes aren't logged to a reviewable history without adding your own transcription or logging.
• Running moves at scale safely requires expertise, since one bad DN or filter can move objects you didn't intend to move.

How to move an Active Directory object using ADUC

For a single move through the GUI, ADUC has a built-in Move command:

1. Open Active Directory Users and Computers: Press Win + R, type dsa.msc, and press Enter.
2. Locate the object in its current OU, or use Action > Find to search for it.
3. Right-click the object and select Move (you can also drag and drop it into the target OU).
4. In the Move dialog, select the destination OU and click OK.

ADUC moves one object (or a multi-selected set) at a time, with no preview or logging. For large or repeatable moves, PowerShell or ADManager Plus is the better fit.

Limitations of using ADUC to move objects

• ADUC moves one object, or a manually selected set, at a time. There's no way to move objects in bulk across many OUs in a single action.
• The console gives no preview of what a move will change and keeps no record of what was moved, by whom, or when.
• Selecting the right objects is manual and visual, so large or recurring moves are slow and easy to get wrong.
• Group Policy shifts the moment an object lands in a new OU, and ADUC gives no warning about the policies it will gain or lose.

Group Policy inheritance impact when moving objects between OUs

The moment an object lands in a new OU, the Group Policy it receives changes. It stops inheriting the GPOs linked to its old OU and immediately picks up those linked to the new OU and every parent above it in the hierarchy. Group Policy in Active Directory flows down the OU tree, so an object in a deeply nested OU inherits policy from that OU plus all its ancestors up to the domain root.

That has real consequences worth checking before a move: the object may gain stricter security settings, different software deployments, or drive mappings it didn't have. A workstation moved into a locked-down OU can suddenly enforce policies that block software the user needs; a user moved out of a department OU can lose mapped drives. Before moving objects in bulk, review which GPOs are linked to the destination OU and its parents, and confirm the resulting policy set is what you intend. Changes take effect at the next Group Policy refresh, or immediately with gpupdate /force on the affected machine.

Troubleshooting common errors

Most move failures come down to permissions or protected objects. The common ones and their fixes:

1. Windows cannot move object <name> because: Access is denied.

The account running the move lacks rights on the source OU, the destination OU, or both. Moving requires Write and Create/Delete permissions on both containers. Verify the delegation-of-control settings on each OU, or run the command as a Domain Admin. Note that a per-object setting, Protect object from accidental deletion, also blocks moves. Clear it on the Object tab (with Advanced Features enabled) before retrying.

2. The move fails for a domain controller account.

Domain controller computer accounts are meant to stay in the Domain Controllers OU. Moving them is strongly discouraged because it changes the security policy applied to the domain controller; if you must reorganize, use Group Policy linking rather than relocating the account.

3. Directory object not found or invalid DN.

The -Identity or -TargetPath DN is mistyped or the OU doesn't exist. Recheck the exact DN with Get-ADObject or Get-ADUser, and confirm the target OU's path. Running with -WhatIf first surfaces this before any change.

4. The requested operation could not be performed on a protected object.

System or built-in objects and objects with accidental-deletion protection, resist moves. Confirm the object is a normal, movable object and that protection is cleared.

FAQ