MOVETREE issue

[Jay Duff]

Hello all,

I am using my network's Forest root machine to move an OU
from one child domain to another. I have ensured that the
administrator passwords on all three servers are
identical. movetree /check works perfectly. When I try
to actually do the movetree, however, I get the following
output:

movetree /start /s source.d83.org /d
destination.d83.org /sdn
OU=SourceOU,DC=source,DC=d83,DC=org /ddn
OU=Faculty,DC=destination,DC=d83,DC=org

MOVETREE PRE-CHECK FINISHED.
MOVETREE IS READY TO START THE MOVE OPERATION.

MOVETREE FAILED. 0x574
READ movetree.err FOR DETAILS.

The movetree.err reads:

ERROR: 0x574 Logon Failure: The target account name is
incorrect. MoveTree cross domain move failed. The
extended error is 00000574: SvcErr: DSID-031B0600, problem
5002 (UNAVAILABLE), data 0

ERROR: 0x574 Logon Failure: The target account name is
incorrect. MoveTree cross domain move failed to move
object OU=SourceOU,cn=89e74fe7-2b47-44d3-883a-
2b907320d8f2,CN=LostAndFound,DC=source,DC=d83,DC=org to
container DC=destination,DC=d83,DC=org

I'm trying to move about 100 accounts, and I'd hate to do
it by hand and lose all the passwords. All servers on the
LAN side of a SonicWall (which has been physically
bypassed anyway).

I tried looking up the error numbers on MS support website
and in Google, both to no avail.

What is the name of the account that MOVETREE is trying to
use? Anybody had this type of trouble before? Anyone know
how to fix it?

Thanks in advance!

Jay Duff
Network Administrator,
Mannheim School District 83
Franklin Park, IL USA

Take out the nospam@nospam to get email address.

[Dmitri Gavrilov [MSFT]]

0x574 is ERROR_WRONG_TARGET_NAME. The most likely cause of this error is
that the two DCs can not mutually authenticate. Please check that the SPNs
for the two computer accounts are properly registered.

There is a way to fall back to one-way authentication. Set
Services\NTDS\Parameters\"Replicator Allow SPN Fallback"=DWORD:0x01.

--
Dmitri Gavrilov
SDE, Active Directory Core

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Jay Duff" <duffja...@nospam.d83.org> wrote in message
news:02d901c2ad2b$6222c500$d2f82ecf@TK2MSFTNGXA09...

[Jay Duff]

There are two AD DCs at some levels (two at forest root
level (d83.org), two at source level (source.d83.org) and
one at destination level (destination.d83.org). Could you
please clarify and explain how to make sure everything is
registered properly (do you mean doing an
ipconfig /registerdns on each server)?

Also, where would I set that one-way authentication? On
one or both root server (where I'm executing the command
from) or on the child server(s)?

Thanks! Have a happy New Year!!!

- J.

>.
>

[Dmitri Gavrilov [MSFT]]

SPNs are registered for each DC account. Those can be found in CN=Domain
Controllers container. Check the values of servicePrincipalName attribute.
Those are used by Kerberos to do mutual auth. I am not sure which exact SPN
is used by movetree, most likely the
E3514235-4B06-11D1-AB04-00C04FC2DCD2/DCGUID/DDNS one.

The regkey should be set on the client (source), which opens the RPC
connection to the dest to move the account.

--
Dmitri Gavrilov
SDE, Active Directory Core

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Jay Duff" <duffja...@nospam.d83.org> wrote in message

news:070501c2b021$f2fe32f0$d5f82ecf@TK2MSFTNGXA12...

[Jay Duff]

I set the key on the Forest Root (which is also the GC) as
well as the source and destination DCs. No help.

The SPN issue is showing more promise, however. The child
domains do not show the GC/Forest Root as a domain
controller. Further, the Forest Root does not show the
child DCs as DCs. In fact, no servers have computer
accounts of any sort for computers outside their domain.
Is that normal? I thought it was, but maybe it's not. If
not, how do you recommend I fix it? I can't add the
missing accounts to the Domain Controllers OU, can I?

Just for giggles, I decided to try running movetree on the
GC from the source to the GC itself, hoping to alleviate
the authentication issue, I get the same error.

Could this have anything to do with the d83.org being
resolvable to 3 different IP addresses (2 are on one
machine)? Also source.d83.org resolves to 2 IPs (each of
the servers there).

Thanks again!

- J.

>.
>

[Dmitri Gavrilov [MSFT]]

Do not create any accounts manually. Each DC will have the account in its
own domain, and only there. Only GC machines will have the GC/ForestRoot
spn. Each DC must have the replication SPN (the one I mentioned below). Does
replication work ok? If it does, then the spn is likely alright. Replication
uses the same authentication mechanism as the one used in movetree.

One thing I forgot to mention: make sure you use the full dns names for the
DCs when you run movetree. This is because it uses this name to construct
the spn. And it must match the registered spn (which has the full dns name).

--
Dmitri Gavrilov
SDE, Active Directory Core

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Jay Duff" <duffja...@nospam.d83.org> wrote in message

news:087701c2b052$6db042b0$8df82ecf@TK2MSFTNGXA02...

[Jay Duff]

Good news and bad news....

Good news - using the full DNS names got movetree to
work!

Bad news - movetree gave an error about the source or
destination not agreeing on the version (error 0x208d). I
tried deleting the destination OU and running the command
again, but the source OU is now gone! I tried running a
movetree /continue, and it gives an error that the
destination OU is missing. So I made a new destination OU
and ran another /continue and now it says "ERROR: 0x208d
Directory object not found. MoveTree detected that the
Source DSA or Destination DSA Name is inconsistent with
parameter you entered previously."

I am guessing my original information is in the Lost and
Found somewhere. How can I get it back (preferably at the
destination)?!?

Thanks again!

- J.

>.
>

[Dmitri Gavrilov [MSFT]]

Movetree uses a rather complicated algorithm to transfer a tree, which
involves moving intermediate subtrees into the L&F container (while their
ancestors are being moved).

I presume not too many objects have actually made it to the other side as of
yet, right? You could move back the objects that did make it there, and then
you should be able to reconstruct the structure on the source by moving the
objects out of L&F container back to where they originally were. I am afraid
movetree does not restore the original tree structure if it fails part way
through. Sorry... You have to do it manually.

--
Dmitri Gavrilov
SDE, Active Directory Core

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Jay Duff" <duffja...@nospam.d83.org> wrote in message

news:08ff01c2b0d8$211ba6c0$d2f82ecf@TK2MSFTNGXA09...

[Jay Duff]

My problem: my original accounts and OU are gone. Not on
the source, the GC (where I issued the command from) nor
the destination.

I am unable to locate a Lost & Found container ANYWHERE in
the entire directory. Right now, I have NOTHING. I'm
screwed, aren't I?

Is there anything left that I can do to get those accounts
back?!? If there is, please explain in complete detail,
as I've tried everything intuitive that I can find.

Thanks.

- J.

>.
>

[Jay Duff]

A follow-up: I had a list of accounts and used it to
create an LDIF fileand used LDIFDE to create new accounts
on the destination server. When I went to the source
server to move the users' files, the securities were
intact! The user names were recognized! That means the
accounts still exist - or at least - the association of
the GUID with the account name exists, right? So how can
I do this right?!?

- J.

>.
>

[Jay Duff]

Follow up follow-up!

The OU is BACK! Not sure what happened, but it's back.

Could running the LDIFDE on the destination child domain
restore the original OU on the source domain?!?

OK - I'm going to delete the LDIFDE accounts and try
movetree again. I'll post results.

- J.

>.
>

[Jay Duff]

OK, here's the current situation:

There are two AD servers at the source site. One of them
has the original OU and all its accounts intact. The
other has none. At the root, if I switch domains to
source.d83.org, the OU is not there.

I've restarted the server at the source site that was
wrong, hoping it would update from the other one. It did
not. Further, when I try to check Group Policy on the OU
in question, it says the container does not exist on the
domain controller group policy is using....

So the question of the day is this - how do I get the OU
to replicate to the forest root so I can treee movetree
again?

- J.

>.
>

[Jay Duff]

OK, here's what I think happened....

The domain master has lost the OU and user accounts. The
backup still has them.

I tried using NTDS util on the server that has the
accoutns, to sieze the PDC, RID master and domain master
roles. For whatever reason, the Forest Root still doesn't
see the OU. I've given it about 30 minutes after
issuing "replicate now" commands in AD Sites & Services.

Movetree doesn't see the OU either - even if I point it to
the server that has the OU.

What can I try next?

- J.

>.
>

[Jay Duff]

I got it! Here's what I had to do:

I renamed the OU to something else, changed the GC to the
server that was good, used the AD Rplication Monitor and
ADSI Edit MMC Snap-in to get everything looking right.

I tried the movetree again and three wonderful words:
MOVETREE FINISHED SUCCESSFULLY.

Thanks for the help!!!

- J.

>.
>