SID history trouble in Win2k3 to Win2k3 migration

[rfgrau@eos.ncsu.edu]

Hello-

I'm having trouble with the Active Directory Migration Tool v3 and a
Win2k3 to Win2k3 migration. I'm trying to migrate global groups with
SID history, and I'm running into an unusual error.

When I attempt to use the Group Account Migration Wizard in ADMT, I'm
able to successfully step through it until I reach the Group Options
dialog, where I check the box for "Migrate group SIDs to target
domain". Then when I try to continue, I got an error pop-up with the
following text: "Could not verify auditing and TcpipClientSupport on
domains. Will not be able to migrate Sids. The specified domain
either does not exist or could not be contacted". The wizard then
unchecks the "Migrate group SIDs..." box.

If I continue without the SID history, the group is successfully
created in the target domain. To me, if the specified domain did not
exist or could not be contacted, then it wouldn't matter whether or
not I was trying to do the migration with SID history. I've also
run Wireshark and done a packet capture to verify that the two domains
are in fact talking with each other.

When I ran the ADMT on the source domain PDC, I got had slightly
different experience, albeit the same ultimate result. On the source
domain controller, I was allowed to step all the way through the Group
Account Migration Wizard. However, when the wizard was completed, and
the migration task ran, it failed to create the object in the target
domain with the SID history. I've pasted part of the migration log
below:

[Object Migration Section]
2007-05-10 09:51:48 Starting Account Replicator.
2007-05-10 09:51:48 CN=Global Group - Created
2007-05-10 09:51:48 ERR2:7449 SID History cannot be updated for Global
Group. The tool could not locate a domain controller for the source
domain.
2007-05-10 09:51:48 WRN1:7392 SIDHistory could not be updated due to a
configuration or permissions problem. The Active Directory Migration
Tool will not attempt to migrate the remaining objects.
2007-05-10 09:51:48 Operation Aborted.
2007-05-10 09:51:48 Operation completed.

As you see, it still has the same 'could not locate a domain
controller' error, and it was even running on said source domain
controller. It's enough to make you pull you hair out.

Sincerely,

Rob Grau

[Mike Luo [MSFT]]

Hello,

Thank you for using newsgroup!

This error typically indicates that a user or a global or universal group
with the {SourceNetBIOSDom}$$$ name already exists. ADMT typically creates
the local group of that name, but it cannot do so if a security principal
already exists with the name. Please check the source domain, delete the
user or a global or universal group with the {SourceNetBIOSDom}$$$ name,
and then create the {SOURCEDOMAIN}$$$ local group.

More information:
How to troubleshoot inter-forest sIDHistory migration with ADMTv2
http://support.microsoft.com/kb/322970/en-us

Thanks & Regards,

Mike Luo

Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security

=====================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=====================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

[rfgrau@eos.ncsu.edu]

Mike--

I deleted the source_domain$$$ local group and allowed the ADMT to
recreate the group when I stepped through the wizard.

At the end of the process, I still had the same error messages. Is
there any additional information I can provide to assist with
troubleshooting?

Sincerely,

Rob Grau

On May 11, 5:07 am, v-mi...@online.microsoft.com (Mike Luo [MSFT])
wrote:
> Hello,
>
> Thank you for using newsgroup!
>
> This error typically indicates that a user or a global or universal group
> with the {SourceNetBIOSDom}$$$ name already exists. ADMT typically creates
> the local group of that name, but it cannot do so if a security principal
> already exists with the name. Please check the source domain, delete the
> user or a global or universal group with the {SourceNetBIOSDom}$$$ name,
> and then create the {SOURCEDOMAIN}$$$ local group.
>
> More information:
> How to troubleshoot inter-forest sIDHistory migration with ADMTv2http://support.microsoft.com/kb/322970/en-us
>
> Thanks & Regards,
>
> Mike Luo
>

[Mike Luo [MSFT]]

Hello,

I have the following suggestions:
1. Verify the trust between on the two domains.
2. The user account that is running ADMT is included in Administrators
group in the source domain.
3. Auditing in both domains is turned on.
4. Try again.

Mike Luo

Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security

=====================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=====================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

[rfgrau@eos.ncsu.edu]

Hi, Mike--

> I have the following suggestions:
> 1. Verify the trust between on the two domains.

Here are the results of the netdom command:
C:\>netdom trust /d:source target /verify /twoway
The trust between target and source has been successfully verified

The command completed successfully.

> 2. The user account that is running ADMT is included in Administrators
> group in the source domain.

I've done this and also made sure that the Administrators group on the
target domain has the extended permission to migrate SID history.

> 3. Auditing in both domains is turned on.

Auditing is on in both domains. I used the step by step instructions
from page 125 of the ADMT v3 Migration Guide.

> 4. Try again.

Please note that I didn't make any configuration changes to either
domain. They were already configured in the recommended manner. I
did try the group account migration wizard again and had the same
result:

[Object Migration Section]
2007-05-14 16:00:40 Starting Account Replicator.
2007-05-14 16:00:40 CN=Global Group - Created
2007-05-14 16:00:40 ERR2:7449 SID History cannot be updated for Global
Group. The tool could not locate a domain controller for the source
domain.
2007-05-14 16:00:40 WRN1:7392 SIDHistory could not be updated due to a
configuration or permissions problem. The Active Directory Migration
Tool will not attempt to migrate the remaining objects.
2007-05-14 16:00:40 Operation Aborted.
2007-05-14 16:00:40 Operation completed.

Sincerely,

Rob Grau

[Mike Luo [MSFT]]

Hello,

I suggest you perform some tests to narrow down the problem:

1. Ping the PDC emulator role holder in source domain from the computer
that is running ADMT. Make sure you are successful in Ping FQDN and NetBIOS
name.
2. Ping the PDC emulator role holder in target domain from the PDC in
source domain. Ensure that you are successful in Ping FQDN and NetBIOS name.
3. Try to migrate user account with SID history to see if the error appears.
4. Migrate all users that are inluded in the global group before migrating
the global group, and then migrate global group.

Update me with the result and I look forward to your reply.

Mike Luo

Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security

=====================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=====================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

[rfgrau@eos.ncsu.edu]

Hi, Mike--

On May 15, 11:04 pm, v-mi...@online.microsoft.com (Mike Luo [MSFT])
wrote:

> 1. Ping the PDC emulator role holder in source domain from the computer
> that is running ADMT. Make sure you are successful in Ping FQDN and NetBIOS
> name.
> 2. Ping the PDC emulator role holder in target domain from the PDC in
> source domain. Ensure that you are successful in Ping FQDN and NetBIOS name.

I was successfully able to ping the PDC emulator domain controller on
both the source and target domains using both the FQDN and NetBIOS
name from all of the computers on which I have installed the ADMT.

> 3. Try to migrate user account with SID history to see if the error appears.

Unfortunately, I received the same error attempting to migrate a user
account. On the target domain, I got the pop-up when I was stepping
through the User Account Migration Wizard telling me, "Could not
verify auditing and TcpipClientSupport .... The specified domain
either does not exist or could not be contacted" From running ADMT
on the source domain I was able step through the wizard, but had the
(same) following error:


[Object Migration Section]
2007-05-16 09:56:33 Starting Account Replicator.
2007-05-16 09:56:34 CN=First Lastname - Created
2007-05-16 09:56:34 ERR2:7449 SID History cannot be updated for
userid. The tool could not locate a domain controller for the source
domain.
2007-05-16 09:56:34 WRN1:7392 SIDHistory could not be updated due to a
configuration or permissions problem. The Active Directory Migration
Tool will not attempt to migrate the remaining objects.
2007-05-16 09:56:34 Operation Aborted.
2007-05-16 09:56:34 Operation completed.

[Mike Luo [MSFT]]

Hello,

Can you migrate the user without SID histroy?

I have the folloing suggestions:
1. First, check the user account that is running ADMT has Administrator
rights on the computer where ADMT installed.
2. Inspect the source domain DNS server. If there is A and SRV record for
the deleted DC, please delete it.
3. I recommend you create a second DNS zone for source zone on the target
DNS server(if the second zone has existed on the server, please delete and
re-create it).
4. Run ipconfig /flushdns command on the computer where ADMT installed, try
again.

Thanks & Regards,

Mike Luo

Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security

=====================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=====================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

[rfgrau@eos.ncsu.edu]

Mike--

> 2. Inspect the source domain DNS server. If there is A and SRV record for
> the deleted DC, please delete it.
> 3. I recommend you create a second DNS zone for source zone on the target
> DNS server(if the second zone has existed on the server, please delete and
> re-create it).
> 4. Run ipconfig /flushdns command on the computer where ADMT installed, try
> again.

There's something "funky" related to DNS happening. All of the DNS
records appear correct and up to date-- such as dcdiag shows no
problems --, but yet on Friday when we were forced to remove the
backup domain controller from the source domain, it then became
possible to run the ADMT on the source domain PDC and migrate the SID
history.

I'm actually having new problems communicating from the target domain
with the source domain, so there's still a DNS issue, but since we can
connect to individual servers in the source domain, this may be "good
enough" for my purposes.

Sincerely,

Rob Grau

[rfgrau@eos.ncsu.edu]

On May 21, 9:04 am, rfg...@eos.ncsu.edu wrote:
>
> I'm actually having new problems communicating from the target domain
> with the source domain, so there's still a DNS issue, but since we can
> connect to individual servers in the source domain, this may be "good
> enough" for my purposes.

An update to the update--

We figured out the issue and the problem was that the FQDN of the
source domain PDC emulator only had a CNAME record in DNS. As a
result of some bereaucratic red tape, the A name record of the domain
used a different DNS suffix. We finally got it changed and everything
is now working perfectly. It took us a long time to troubleshoot
because for most things, the CNAME record worked just as well as the A
record.

Sincerely,

Rob Grau

[Mike Luo [MSFT]]

Thank you for the confirm. Glad to know that everyting is OK now.

If you need more help or have other concerns in the future, just post back
into the newsgroup. It is always our pleasure to be of help. Have a nice
day!

Mike Luo

Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security

=====================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=====================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

[Steve]

I am currently having the same problem that rfgrau was having back in May. I
can't fix my DNS problem but I was wondering what are the implications of not
being able to migrate SIDs to the target domain.
--
Steve


"Mike Luo [MSFT]" wrote:

> Thank you for the confirm. Glad to know that everyting is OK now.
>
> If you need more help or have other concerns in the future, just post back
> into the newsgroup. It is always our pleasure to be of help. Have a nice
> day!
>
> Mike Luo
>
> Microsoft Online Partner Support
> Get Secure! - www.microsoft.com/security
>
> =====================================================
> When responding to posts, please "Reply to Group" via your newsreader so
> that others may learn and benefit from your issue.
> =====================================================
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>

[Mike Luo [MSFT]]

Hello,

Generally, SID history is used to Preserve Resource Access. After migrating
an account and maintaining the SID history of the source domain account,
when a user logs on to the target domain, both the new SID and the original
SID from the SID history attribute are added to the access token of the
user. If the target domain users do not need to access the source domain
resource, you don't need to migrate SID.

In addition, during migration of Exchange mailboxes, the SID history is
used to determine to associate mailbox with user account.

Regarding the cause of failed migration SID history, please refer to the
previous post.

If you have any concern, please feel free to post back. Hope this helps.

Mike Luo

Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security

=====================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=====================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

[scha rique]

I am having same issue with using ADMT v3 to bring over the SIDHistory. I have read several articles here on this forum and on Experts-Exchange and can't seem to get to the bottom of it.

ERR2:7449 SID History cannot be updated for test-user1. The tool could not locate a domain controller for the source domain.
WRN1:7392 SIDHistory could not be updated due to a configuration or permissions problem. The Active Directory Migration Tool will not attempt to migrate the remaining objects.

-Both domains are Windows Server 2003 DFL/FFL level.
-The trust is in place and has been validated.
-SID Filtering is disabled.
-DNS resolution works and the SRV records of the source domains can be looked by (nslookup ->set type=srv -> _ldap._.......).
-The user account migration happens with the Password, and its only SID piece that is failing.
-On Source DC - The RPC over TCPip key was created via ADMT uner HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Lsa.
-The sourcedomain$$$ was created in source domain by ADMT.
-Account running ADMT is part of the Administrators group in source domain.
-Auditing is enabled in both domains.

Its a bit frustrating and some piece is still missing somewhere but I can't find where.

If someone has a recommendation, please share. Thanks much.

[Tesdall]

Some things you can try, Check your DNS make sure you can do from the Target
domain ping sourcedomainname. Secondly put your domain admin from your Target
and Source domains into the bulitin/admins group. For starters.

"scha rique" wrote:

> I am having same issue with using ADMT v3 to bring over the SIDHistory. I have read several articles here on this forum and on Experts-Exchange and can't seem to get to the bottom of it.
>
> ERR2:7449 SID History cannot be updated for test-user1. The tool could not locate a domain controller for the source domain.
> WRN1:7392 SIDHistory could not be updated due to a configuration or permissions problem. The Active Directory Migration Tool will not attempt to migrate the remaining objects.
>
> -Both domains are Windows Server 2003 DFL/FFL level.
> -The trust is in place and has been validated.
> -SID Filtering is disabled.
> -DNS resolution works and the SRV records of the source domains can be looked by (nslookup ->set type=srv -> _ldap._.......).
> -The user account migration happens with the Password, and its only SID piece that is failing.
> -On Source DC - The RPC over TCPip key was created via ADMT uner HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Lsa.
> -The sourcedomain$$$ was created in source domain by ADMT.
> -Account running ADMT is part of the Administrators group in source domain.
> -Auditing is enabled in both domains.
>
> Its a bit frustrating and some piece is still missing somewhere but I can't find where.
>
> If someone has a recommendation, please share. Thanks much.
>