Error migrating users/computers using ADMT

I currently have a lab environment with the following setup:

- One Windows 2000 Server as an Active Directory DC for the domain "SOURCE"
- Two Windows 2003 Servers as Active Directory DCs for the domain
"TARGET.local" (separate forest, netbios name TARGET)
- A two-way trust exists between the two domains.
- All machines in this lab environment are plugged into the same ethernet
switch.

I have a number of accounts in the SOURCE domain that I am attempting to
migrate to the TARGET domain while maintaining SID history. I am using ADMT
v2 from my Windows 2003 R2 CD-ROM to do this.

When migrating users, everything works fine (user is migrated w/ SID history
and group affiliations in the new domain), however the log reports the
following error:

==============================\
2006-10-20 09:00:58 ERR2:7600 Unable to query global catalog in target
forest to verify whether user principal name (UPN) 'stever@target.local' is
unique. UPN attribute will not be set. The specified domain either does not
exist or could not be contacted.
==============================/

Despite this (since we don't use UPN logins for anything) I can log onto a
computer in TARGET with the newly migrated account and access a shared
resource in SOURCE that had permissions assigned to the user account in the
SOURCE domain. Because of this, I didn't give much thought to this error.

However, when trying to migrate a computer account, everything completes
fine, but at the end I receive this error:

==============================\
2006-10-19 16:38:57 ERR3:7075 Failed to change domain affiliation,
hr=8007054b The specified domain either does not exist or could not be
contacted.
==============================/

This results in my being unable to run the wizard again (it will not
dispatch the agent to the computer). I can however go to the computer and
manually change the domain affiliation and it works fine.

Everything I've seen seems to point to a DNS-related issue. The following
is true in regards to my DNS setup:

- The domain controller for SOURCE is named DOZER. It has an IP address of
10.1.1.23 and a subnet of 255.255.0.0. Its primary DNS is set to 10.1.1.23.
- The domain controller (first server installed) for TARGET is LAN-DC1. It
has an IP address of 10.1.4.1 and a subnet of 255.255.0.0. Its primary DNS
is set to 10.1.4.1.
- The second domain controller for TARGET is LAN-DC2. It has an IP address
of 10.1.4.2 and a subnet of 255.2550.0. Its primary DNS is also set to
10.1.4.1.
- I feel it may be important to note that when originally running DCDIAG I
would receive errors that <string>._msdcs.target.local could not be
resolved, but lan-dc1 could be. I had to manually create zones for both
TARGET.local and _mscds.target.local on DOZER in order to resolve the
servers in the TARGET domain. The only records I created in the
_msdcs.target.local zone were the aliases for lan-dc1 and lan-dc2. I wanted
to create them as secondary zones, but LAN-DC1 would not allow the zone
transfer (though I configured it to allow transfers to any server).

- From DOZER in the SOURCE domain, I can ping TARGET.local, lan-dc1,
lan-dc2, lan-dc1.target.local and lan-dc2.target.local. I can run DCDIAG on
DOZER, running it against LAN-DC1 and all tests pass fine except the
following:

Starting test: Services
RPCLOCATOR Service is stopped on [LAN-DC1]
TrkWks Service is stopped on [LAN-DC1]
TrkSvr Service is stopped on [LAN-DC1]
......................... LAN-DC1 failed test Services
Starting test: ObjectsReplicated
......................... LAN-DC1 passed test ObjectsReplicated
Starting test: frssysvol
Error: No record of File Replication System, SYSVOL started.
The Active Directory may be prevented from starting.
......................... LAN-DC1 passed test frssysvol

SYSVOL is shared on LAN-DC1 however, as running a "net share" command on the
server shows it. Running DCDIAG against LAN-DC2 gives the same errors,
except for the SYSVOL error.

- Forwarders are not configured on any DNS.


I've been beating my head against this for a few days now, so if anyone has
any thoughts, I'd certainly welcome them.

Hi
> 2006-10-20 09:00:58 ERR2:7600 Unable to query global catalog in target
> forest to verify whether user principal name (UPN) 'stever@target.local'
> is unique. UPN attribute will not be set. The specified domain either
> does not exist or could not be contacted.

sounds like you need to create a Additional UPN on the destination domain to
mantain that UPN (USE DOMAINS AND TRUSTS MMC)

> Despite this (since we don't use UPN logins for anything) I can log onto a
> computer in TARGET with the newly migrated account and access a shared
> resource in SOURCE that had permissions assigned to the user account in
> the SOURCE domain. Because of this, I didn't give much thought to this
> error.

But it's defined on the account properties that's why is throwing away that
error.

> 2006-10-19 16:38:57 ERR3:7075 Failed to change domain affiliation,
> hr=8007054b The specified domain either does not exist or could not be
> contacted.

In this link for this error search for:ERR3:7075 Failed to change domain
affiliation
http://support.microsoft.com/kb/555040
also read the others (that's why I didn't provided the direct link), you can
check all recommended actions in this generall link.
--
I hope that the information above helps you

Good Luck
Jorge Silva
MCSA
Systems Administrator
"Joe Grover" <grover.joe@acd.net> wrote in message
news:OdoyQAF9GHA.4740@TK2MSFTNGP03.phx.gbl...
>I currently have a lab environment with the following setup:
>
> - One Windows 2000 Server as an Active Directory DC for the domain
> "SOURCE"
> - Two Windows 2003 Servers as Active Directory DCs for the domain
> "TARGET.local" (separate forest, netbios name TARGET)
> - A two-way trust exists between the two domains.
> - All machines in this lab environment are plugged into the same ethernet
> switch.
>
> I have a number of accounts in the SOURCE domain that I am attempting to
> migrate to the TARGET domain while maintaining SID history. I am using
> ADMT v2 from my Windows 2003 R2 CD-ROM to do this.
>
> When migrating users, everything works fine (user is migrated w/ SID
> history and group affiliations in the new domain), however the log reports
> the following error:
>
> ==============================\
> 2006-10-20 09:00:58 ERR2:7600 Unable to query global catalog in target
> forest to verify whether user principal name (UPN) 'stever@target.local'
> is unique. UPN attribute will not be set. The specified domain either
> does not exist or could not be contacted.
> ==============================/
>
> Despite this (since we don't use UPN logins for anything) I can log onto a
> computer in TARGET with the newly migrated account and access a shared
> resource in SOURCE that had permissions assigned to the user account in
> the SOURCE domain. Because of this, I didn't give much thought to this
> error.
>
> However, when trying to migrate a computer account, everything completes
> fine, but at the end I receive this error:
>
> ==============================\
> 2006-10-19 16:38:57 ERR3:7075 Failed to change domain affiliation,
> hr=8007054b The specified domain either does not exist or could not be
> contacted.
> ==============================/
>
> This results in my being unable to run the wizard again (it will not
> dispatch the agent to the computer). I can however go to the computer and
> manually change the domain affiliation and it works fine.
>
> Everything I've seen seems to point to a DNS-related issue. The following
> is true in regards to my DNS setup:
>
> - The domain controller for SOURCE is named DOZER. It has an IP address
> of 10.1.1.23 and a subnet of 255.255.0.0. Its primary DNS is set to
> 10.1.1.23.
> - The domain controller (first server installed) for TARGET is LAN-DC1.
> It has an IP address of 10.1.4.1 and a subnet of 255.255.0.0. Its primary
> DNS is set to 10.1.4.1.
> - The second domain controller for TARGET is LAN-DC2. It has an IP
> address of 10.1.4.2 and a subnet of 255.2550.0. Its primary DNS is also
> set to 10.1.4.1.
> - I feel it may be important to note that when originally running DCDIAG I
> would receive errors that <string>._msdcs.target.local could not be
> resolved, but lan-dc1 could be. I had to manually create zones for both
> TARGET.local and _mscds.target.local on DOZER in order to resolve the
> servers in the TARGET domain. The only records I created in the
> _msdcs.target.local zone were the aliases for lan-dc1 and lan-dc2. I
> wanted to create them as secondary zones, but LAN-DC1 would not allow the
> zone transfer (though I configured it to allow transfers to any server).
>
> - From DOZER in the SOURCE domain, I can ping TARGET.local, lan-dc1,
> lan-dc2, lan-dc1.target.local and lan-dc2.target.local. I can run DCDIAG
> on DOZER, running it against LAN-DC1 and all tests pass fine except the
> following:
>
> Starting test: Services
> RPCLOCATOR Service is stopped on [LAN-DC1]
> TrkWks Service is stopped on [LAN-DC1]
> TrkSvr Service is stopped on [LAN-DC1]
> ......................... LAN-DC1 failed test Services
> Starting test: ObjectsReplicated
> ......................... LAN-DC1 passed test ObjectsReplicated
> Starting test: frssysvol
> Error: No record of File Replication System, SYSVOL started.
> The Active Directory may be prevented from starting.
> ......................... LAN-DC1 passed test frssysvol
>
> SYSVOL is shared on LAN-DC1 however, as running a "net share" command on
> the server shows it. Running DCDIAG against LAN-DC2 gives the same
> errors, except for the SYSVOL error.
>
> - Forwarders are not configured on any DNS.
>
>
> I've been beating my head against this for a few days now, so if anyone
> has any thoughts, I'd certainly welcome them.
>

> sounds like you need to create a Additional UPN on the destination domain
> to mantain that UPN (USE DOMAINS AND TRUSTS MMC)
=================/

I don't want to maintain a UPN. The migration tool is reporting that it
can't connect to the global catalog in my target domain to determine if the
new UPN it wants to create (username@target.local) will be unique. The
target.local UPN already exists, as that's the name of the new 2003 AD (new
accounts created manually already have username@target.local as a UPN
username).

=================\
> In this link for this error search for:ERR3:7075 Failed to change domain
> affiliation
> http://support.microsoft.com/kb/555040
> also read the others (that's why I didn't provided the direct link), you
> can check all recommended actions in this generall link.
=================/

Yeah, I found this article as well. Unfortunately the particular one that
relates to my issue is only directed at people running the migration tool in
test mode--it is supposed to report that error in test mode since the actual
re-homing of the end-user PC is not actually taking place in a test. I am
however unable to find a document describing what to do when encountering
this error in an actual migration attempt. :/ Just about all of the other
articles at the above link are referring to upgrading existing 2000
directories to 2003.


Joe

I also didn't find anything related.
can you do:
nslookup -type=srv _ldap._tcp.pdc._msdcs.domain-name.com
nslookup -type=srv _ldap._tcp.dc._msdcs.domain-name.com
nltest /dsgetdc:domain-name.com
what results?

Do you have FW between the trusts?
How to configure a firewall for domains and trusts
http://support.microsoft.com/kb/179442
you can also download the portqry tool from
http://support.microsoft.com/kb/310456
and test the connection

at the moment I can't remember what can be the cause of this error, and I
don't recall having this error when using ADMT, but I'll check if I found
anything related, sorry not be more helpful


--
I hope that the information above helps you

Good Luck
Jorge Silva
MCSA
Systems Administrator
"Joe Grover" <grover.joe@acd.net> wrote in message
news:uCFdfgH9GHA.4708@TK2MSFTNGP05.phx.gbl...
>> sounds like you need to create a Additional UPN on the destination domain
>> to mantain that UPN (USE DOMAINS AND TRUSTS MMC)
> =================/
>
> I don't want to maintain a UPN. The migration tool is reporting that it
> can't connect to the global catalog in my target domain to determine if
> the new UPN it wants to create (username@target.local) will be unique.
> The target.local UPN already exists, as that's the name of the new 2003 AD
> (new accounts created manually already have username@target.local as a UPN
> username).
>
> =================\
>> In this link for this error search for:ERR3:7075 Failed to change domain
>> affiliation
>> http://support.microsoft.com/kb/555040
>> also read the others (that's why I didn't provided the direct link), you
>> can check all recommended actions in this generall link.
> =================/
>
> Yeah, I found this article as well. Unfortunately the particular one that
> relates to my issue is only directed at people running the migration tool
> in test mode--it is supposed to report that error in test mode since the
> actual re-homing of the end-user PC is not actually taking place in a
> test. I am however unable to find a document describing what to do when
> encountering this error in an actual migration attempt. :/ Just about all
> of the other articles at the above link are referring to upgrading
> existing 2000 directories to 2003.
>
>
> Joe
>

>I also didn't find anything related.
> can you do:
> nslookup -type=srv _ldap._tcp.pdc._msdcs.domain-name.com
> nslookup -type=srv _ldap._tcp.dc._msdcs.domain-name.com
> nltest /dsgetdc:domain-name.com
> what results?

The results are as follows:

========================\
C:\>nslookup -type=srv _ldap._tcp.pdc._msdcs.target.local
Server: dozer.source
Address: 10.1.1.23

_ldap._tcp.pdc._msdcs.target.local SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = lan-dc1.target.local
lan-dc1.target.local internet address = 10.1.4.1
========================/

========================\
C:\>nslookup -type=srv _ldap._tcp.dc._msdcs.target.local
Server: dozer.source
Address: 10.1.1.23

_ldap._tcp.dc._msdcs.target.local SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = lan-dc2.target.local
_ldap._tcp.dc._msdcs.target.local SRV service location:
priority = 0
weight = 100
port = 389
svr hostname = lan-dc1.target.local
lan-dc2.target.local internet address = 10.1.4.2
lan-dc1.target.local internet address = 10.1.4.1
========================/

========================\
C:\>nltest /dsgetdc:target.local
DC: \\lan-dc2.target.local
Address: \\10.1.4.2
Dom Guid: 0b927d5a-e4b6-41ed-96c3-497c48683b64
Dom Name: target.local
Forest Name: target.local
Dc Site Name: Default-First-Site-Name
Our Site Name: Default-First-Site-Name
Flags: DS LDAP KDC TIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST
CLOSE_SITE
The command completed successfully
========================/

========================\
> Do you have FW between the trusts?
> How to configure a firewall for domains and trusts
> http://support.microsoft.com/kb/179442
> you can also download the portqry tool from
> http://support.microsoft.com/kb/310456
> and test the connection
========================/

Nope, no firewall. Both controllers are plugged into a 16-port standard
ethernet switch. For kicks I even ran the nslookup utility looking for the
GC server in target.local and was able to do so without any problem.

Joe Grover

cnan you validate the trusts successfully?

--
I hope that the information above helps you

Good Luck
Jorge Silva
MCSA
Systems Administrator
"Joe Grover" <grover.joe@acd.net> wrote in message
news:e4vv3Ms9GHA.4376@TK2MSFTNGP03.phx.gbl...
> >I also didn't find anything related.
>> can you do:
>> nslookup -type=srv _ldap._tcp.pdc._msdcs.domain-name.com
>> nslookup -type=srv _ldap._tcp.dc._msdcs.domain-name.com
>> nltest /dsgetdc:domain-name.com
>> what results?
>
> The results are as follows:
>
> ========================\
> C:\>nslookup -type=srv _ldap._tcp.pdc._msdcs.target.local
> Server: dozer.source
> Address: 10.1.1.23
>
> _ldap._tcp.pdc._msdcs.target.local SRV service location:
> priority = 0
> weight = 100
> port = 389
> svr hostname = lan-dc1.target.local
> lan-dc1.target.local internet address = 10.1.4.1
> ========================/
>
> ========================\
> C:\>nslookup -type=srv _ldap._tcp.dc._msdcs.target.local
> Server: dozer.source
> Address: 10.1.1.23
>
> _ldap._tcp.dc._msdcs.target.local SRV service location:
> priority = 0
> weight = 100
> port = 389
> svr hostname = lan-dc2.target.local
> _ldap._tcp.dc._msdcs.target.local SRV service location:
> priority = 0
> weight = 100
> port = 389
> svr hostname = lan-dc1.target.local
> lan-dc2.target.local internet address = 10.1.4.2
> lan-dc1.target.local internet address = 10.1.4.1
> ========================/
>
> ========================\
> C:\>nltest /dsgetdc:target.local
> DC: \\lan-dc2.target.local
> Address: \\10.1.4.2
> Dom Guid: 0b927d5a-e4b6-41ed-96c3-497c48683b64
> Dom Name: target.local
> Forest Name: target.local
> Dc Site Name: Default-First-Site-Name
> Our Site Name: Default-First-Site-Name
> Flags: DS LDAP KDC TIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST
> CLOSE_SITE
> The command completed successfully
> ========================/
>
> ========================\
>> Do you have FW between the trusts?
>> How to configure a firewall for domains and trusts
>> http://support.microsoft.com/kb/179442
>> you can also download the portqry tool from
>> http://support.microsoft.com/kb/310456
>> and test the connection
> ========================/
>
> Nope, no firewall. Both controllers are plugged into a 16-port standard
> ethernet switch. For kicks I even ran the nslookup utility looking for
> the GC server in target.local and was able to do so without any problem.
>
> Joe Grover
>