When trying to move and AD User using the following command:

move-adobject 'CN=John Doe,OU=_Users,OU=ABC,DC=xyz,DC=com' -targetpath 'OU=Disabled Accounts,OU=_Users,OU=ABC,DC=xyz,DC=com' -targetserver someDC.xyz.com

I'm receiving an error:

Move-ADObject : Source and destination for the cross-domain move operation are identical. Caller should use local move operation instead of cross-domain move operation.

The Object and it's target both reside in the same domain. In fact there is only one domain. I've verified the DN is correct on both ends. I've also looked up the GUID's and used them with the exact same results. I have several user's and OU's I'm attempting to run this on and am getting the same error regardless of OU and user. If I do ont specify a -targerserver parameter, I receive the error: 

Move-ADObject : The operation could not be performed because the object's parent is either uninstantiated or deleted

Is there something wrong with my AD structure?

Update : After trying it on nearly every OU I could, I've found the command does work right on some. The one's it does NOT work on were from an old company Novel migration ages ago. Coincidence? What would the Novel to AD migration have possibly left on the OU to cause this not to work?

Update2: Turns out it doesn't work on some OU that were newly created also.

Update3:No results yet; however, the result does seem to be related to the user object and not the OU. Newly created object can me moved regardless of OU.

• Edited by Breaker1253 Wednesday, April 02, 2014 1:03 PM Update

Hi,

Try this instead

Move-ADObject  "CN=John Doe,OU=Live,OU=_Users,DC=labdomain,DC=int" -TargetPath "OU=Disabled,OU=_Users,DC=labdomain,DC=int" -Server "server1.labdomain.int"

Change from your -targetserver to just -server

Thanks

Specifying -server in place of -targetserver results in error:

Move-ADObject : The operation could not be performed because the object's parent is either uninstantiated or deleted

I would drop specifiying server at all and try again.

Just tried it again. Not specifying -server or -targetserver results in the usual:

Move-ADObject : The operation could not be performed because the object's parent is either uninstantiated or deleted

This looks like a lab system.  Can you create a root OU (Test) and try sending it there.  Don't use any special characters in the name.

ou=test,DC=labdomain,DC=int

Hi Paul - did you manage to test this in your environment?

I tested on standalone 2012 R2 (single DC test environment) and got the same error as the OP using his first command. It worked okay when I used -server rather than -targetserver.

targetserver I got same issue as the OP did with the parent is uninstantiated....

wondered if you had managed to replicate either?

thanks

Specifying -server in place of -targetserver results in error:

Move-ADObject : The operation could not be performed because the object's parent is either uninstantiated or deleted

Did you try replacing the single quote ' with a double quote " to surround your OU paths?

I've tried it both ways, single and double.

Since it's a pretty large domain I'll have to get approval to make an OU that I can test with. I'll reply soon as I can try this

Update: After trying it on nearly every OU I could, I've found the command does work right on some. The one's it does NOT work on were from an old company Novel migration ages ago. Coincidence? What would the Novel to to AD migration have possibly left on the OU to cause this not to work?

Update: After trying it on nearly every OU I could, I've found the command does work right on some. The one's it does NOT work on were from an old company Novel migration ages ago. Coincidence? What would the Novel to to AD migration have possibly left on the OU to cause this not to work?

I presume it can be the permission issue on particular OU which is causing the trouble. I would use DSACL or other scripting method to compare the security permission on particular OU over other.

http://blogs.technet.com/b/ashleymcglone/archive/2013/03/25/active-directory-ou-permissions-report-free-powershell-script-download.aspx

-targetserver is used to do cross domain moves.  Even if you were doing a cross domain move, the -targetserver needs to be the RID master of the target domain. If you don't specify the RID master, you'll get the uninstantiated error.

-server just specifies a specific server to execute the command.  It's not required unless you have some crazy reason to target a server (usually outside your AD Site)

- if you don't specify -server, it will be a local DC, just like logging in.  You will resolve a local DC to the AD site in which the command is being run from.

As to some OUs working and others not, sounds like permissions to me.  What error are you getting when it doesn't work?  I'm sure it's not the same error.

What are your group memberships in correlation to permissions on the OUs? 

Agree with Chris on the options, however it doesn't explain why it works on some systems and not others.

I setup a quick lab the other day with single 2012 DC and could replicate your issue if I didn't specify any -server path when running from the DC.

But just tested here on another domain, and I can't break it, either with specifying or not specifying the server option.

I can't test again on the other domain I used until later today so will get back to you later.

You can dump the ACL's from different OU's.  I have a script in the Script Center that can help you with this.
http://gallery.technet.microsoft.com/scriptcenter/DUMP-ACLs-From-an-OU-8e2da85c

Ok I'll have a look. I've got a few co-workers involved on this too. I'll see what discrepancies I can find and report back.

No results yet; however, the result does seem to be related to the user object and not the OU. Newly created object can me moved regardless of OU.

Did you check the duet account security permissions on the user account and check they are inheriting perms

I might be missing something on this one. Isn't Duet related to SharePoint? I've never worked with it so I might need clarification. Sorry.

Hi - I am having the exact same issues when attempting to move computer objects from one OU to another OU on the same domain. We did, in fact, use the Quest Migration tools some years ago when going from a Novell environment to Windows AD. I'm not sure if the computers involved in this operation were alive back when the migration took place.

Anyway, did you arrive at a solution? You did conclude that is related to the actual objects and not the OU's, correct? How do we get those objects over to a "moveable" state?