| Author |
Message |
Bob Trouchet
Guest
|
Posted:
Tue Jan 18, 2005 9:11 pm Post subject:
Using ADMT2 to migrate SIDhistory |
|
|
I am trying to transfer my users and groups from a Server 2000 domain
to a Server 2003 domain. I want to keep the process as transparent to
my users as possible ie include passwords etc.
ADMT is very happy to transfer my user groups and shows no errors. If
I try to run a test transfer with SID history enabled then I get an
error.
I have followed the instructions as per Mark Minasi's book Mastering
Server 2003.
After choosing enable SID history in ADMT I am asked for a username
and password in the originating (Win 2000) domain. I then receive an
error that the originating PDC cannot be contacted or that the
original PDC has not been restarted after setting TcpipClientSupport
to 1.
The original PDC has been restarted a number of times and I have
verified that TcpipClientSupport is set to 1 (also a number of times).
I can happily connect to the originating PDC from the new domain
server either through explorer or even via Regedt32 (to recheck the
status of TCPIP.)
Can anyone please give me any ideas what else could be wrong?
Regards
Bob Trouchet |
|
| Back to top |
|
 |
Frances [MSFT]
Guest
|
Posted:
Wed Jan 19, 2005 2:00 pm Post subject:
RE: Using ADMT2 to migrate SIDhistory |
|
|
Hello Bob,
Thanks for your email.
I would like to confirm my understanding of your problem. Do you mean
that you can successfully migrate your users and groups from win 2k domain
to win 2k3 domain with the SID history disabled, however, the migration
ends with an error message when you transfer with SID history?
To isolate the problem, perform the steps below:
Step 1. Set the TcpipClientSupport registry key to 1 on all DCs.
Restart the DC after the key has been changed, the key will take effect
after the restart.
Step 2. Verify that there is no other server with the same name on the
network.
Step 3. Try the User/Group Migration wizard again.
If the same error occurs, please take a screen shot of the error message
and send it to v-franhe@microsoft.com for research. Please also compress
the folder located in \Program Files\Active Directory Migration Tool\Logs
and send it to me.
In addition, I believe you may find the following article helpful to you:
How to Troubleshoot Inter-Forest sIDHistory Migration with ADMTv2
http://support.microsoft.com/default.aspx?scid=kb;en-us;322970
I am looking forward to your reply!
Best regards,
Frances He
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. |
|
| Back to top |
|
 |
Frances [MSFT]
Guest
|
Posted:
Mon Jan 24, 2005 5:17 pm Post subject:
RE: Using ADMT2 to migrate SIDhistory |
|
|
Hello Bob,
I am happy to talk to you again.
From your logs, I notice that the target domain may not trust the account's
domain. Please make sure the trust is established.
In addition, please verify the following:
Groups:
---------
1. Add the Domain Admins global group from the source domain to the
Administrators local group in the target domain.
2. Add the Domain Admins global group from the target domain to the
Administrators local group in the source domain.
3. Create a new local group in the source domain called <Source
Domain>$$$ (this group should have no members).
Auditing:
----------
1. Enable auditing for the success and failure of user and group management
on the source domain.
2. Enable auditing for the success and failure of Audit account management
on the target domain in the Default Domain Controllers policy.
Registry
-----------
On the PDC in the source domain, add the TcpipClientSupport:REG_DWORD:0x1
value under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA.
Administrative Shares:
---------------------------
Administrative shares must exist on the domain controller (DC) in the
target domain on which you run ADMT, as well as on any computers on which
an agent will be dispatched.
User Rights:
---------------
- You must log on to the computer on which you run ADMT with an account
that has the following rights:
- Domain Administrator rights in the target domain
- Is a member of the Administrators group in the source domain
- Administrator rights on each computer you migrate
- Administrator rights on each computer on which you translate security
Therefore, logging into the PDC that is the FSMO role holder in the target
domain with the source domain\Administrator account suffices, assuming that
the source domain\Domain Administrators group belongs to each computer's
Administrators group.
After you verify that all of these steps are in place, attempt the
migration again. If it is still failing, please don't hesitate to let me
know.
I am looking forward to you reply!
Best regards,
Frances He
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. |
|
| Back to top |
|
 |
Frances [MSFT]
Guest
|
Posted:
Tue Jan 25, 2005 6:08 pm Post subject:
RE: Using ADMT2 to migrate SIDhistory |
|
|
Hello Bob,
According to your message, I think the trust is probably the main cause of
your problem. Migration will not function correctly if the trusts are not
set up properly.
Please send to v-franhe@microsoft.com the screen shot of the error you
mentioned when you validate the trust. I will have further research
regarding the trusts.
At the same time, I suggest that you recreate the trusts between the win2k
domain and the win2k3 domain according to the following KB. Although the
source domain is NT in the KB, the process is almost the same.
How To Establish Trusts with a Windows NT-Based Domain in Windows Server
2003
http://support.microsoft.com/default.aspx?scid=kb;en-us;325874
In addition, please send your reply in our newsgroups in the original
thread titled "Using ADMT2 to migrate SIDhistory", and thus more people
will either share their knowledge on the same issue or learn from your
interaction with us. Thank you for your understanding.
Best regards,
Frances He
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. |
|
| Back to top |
|
 |
Frances [MSFT]
Guest
|
Posted:
Wed Jan 26, 2005 3:29 pm Post subject:
RE: Using ADMT2 to migrate SIDhistory |
|
|
Hello Bob,
What is the result after recreating the trusts?
I have found the following articles to create trust between the win2k
domain and the win2k3 domain for your reference.
Planning Distributed Security
http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/
en-us/Default.asp?url=/resources/documentation/windows/2000/server/reskit/en
-us/deploy/dgbe_sec_bkhy.asp
To create a forest trust
http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/p
roddocs/en-us/Default.asp?url=/resources/documentation/windowsserv/2003/stan
dard/proddocs/en-us/x_createtrust.asp
In addition, please send your reply in our newsgroups in the original
thread titled "Using ADMT2 to migrate SIDhistory", and thus more people
will either share their knowledge on the same issue or learn from your
interaction with us. Thank you for your understanding.
Any update, let us get in touch!
Best regards,
Frances He
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. |
|
| Back to top |
|
 |
Bob Trouchet
Guest
|
Posted:
Wed Jan 26, 2005 8:02 pm Post subject:
Re: Using ADMT2 to migrate SIDhistory (0/1) |
|
|
Subject: Re SIDHistory migration
Frances
Thank you for your reply via the newsgroup to my post about
difficulties transferring SID histories to a new domain.
I have enclosed the error message and the logs you requested.
Some further information which may or may not help.
Source Domain is Windows 2000 (kojonupdhs.cur.au).
Target Domain is Windows 2003 (curriculum.kojonupdhs.edu.a).
The ADMT tool appears to transfer groups when run in test mode (No SID
history).
The ADMT tool does not get to the actual transfer when SID history is
enabled. It stops at the ask for user name and password screen as
shown in the error message file. The user name and password is
immaterial as the message is given for wrong passwords or non existent
user accounts as well.
Regards
Bob Trouchet |
|
| Back to top |
|
 |
Bob Trouchet
Guest
|
Posted:
Wed Jan 26, 2005 8:05 pm Post subject:
Re: Using ADMT2 to migrate SIDhistory |
|
|
-----Original Message-----
From: Frances He (Smartek) [mailto:v-franhe@microsoft.com]
Sent: Monday, 24 January 2005 7:16 PM
To: Robert.Trouchet@eddept.wa.edu.au
Subject: RE: Re SIDHistory migration
Importance: High
Hello Bob,
I am happy to talk to you again.
From your logs, I notice that the target domain may not trust the
account's domain. Please make sure the trust is established.
In addition, please verify the following:
Groups:
---------
1. Add the Domain Admins global group from the source domain to the
Administrators local group in the target domain.
2. Add the Domain Admins global group from the target domain to the
Administrators local group in the source domain.
3. Create a new local group in the source domain called
<Source Domain>$$$ (this group should have no members).
Auditing:
----------
1. Enable auditing for the success and failure of user and group
managementon the source domain.
2. Enable auditing for the success and failure of Audit account
management on the target domain in the Default Domain
Controllers policy.
Registry
-----------
On the PDC in the source domain, add the
TcpipClientSupport:REG_DWORD:0x1 value
under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA.
Administrative Shares:
---------------------------
Administrative shares must exist on the domain controller (DC) in the
target domain on which you run ADMT, as well as on any computers on
which an agent will be dispatched.
User Rights:
---------------
- You must log on to the computer on which you run ADMT with an
account that has the following rights:
- Domain Administrator rights in the target domain
- Is a member of the Administrators group in the source domain
- Administrator rights on each computer you migrate
- Administrator rights on each computer on which you translate
security
Therefore, logging into the PDC that is the FSMO role holder in the
target domain with the source domain\Administrator account suffices,
assuming that the source domain\Domain Administrators group belongs to
each computer's Administrators group.
After you verify that all of these steps are in place, attempt the
migration again. If it is still failing, please don't hesitate to let
me know.
I am looking forward to you reply!
Frances HE
Online Partner Support Specialist
Partner Support Group
Microsoft Global Technical Support Center
Mailto: v-franhe@microsoft.com |
|
| Back to top |
|
 |
Bob Trouchet
Guest
|
Posted:
Wed Jan 26, 2005 8:15 pm Post subject:
Re: Using ADMT2 to migrate SIDhistory |
|
|
Thanks for that help Frances.
I rebuilt the two trusts and turned off SID filtering.
I have now successfully migrated my groups.
I am now trying to transfer some users but this does not seem to
happen.
I have set the migration to add "aa" to the front of users names if
they already exist (which they shouldn't).
The migration log includes the line
WRN1:7352 Failed to add *********** RC=80005008. One or more input
parameters are invalid.
Where the *** represent the LADP addressing.
I have enclosed a copy of the migration log.
Thanks for any more help which can be given.
Regards
Bob Trouchet |
|
| Back to top |
|
 |
Bob Trouchet
Guest
|
Posted:
Wed Jan 26, 2005 9:14 pm Post subject:
Using ADMT2 to migrate SIDhistory |
|
|
Thanks for that help Frances.
I rebuilt the two trusts and turned off SID filtering.
I have now successfully migrated my groups.
I am now trying to transfer some users but this does not seem to
happen.
I have set the migration to add "aa" to the front of users names if
they already exist (which they shouldn't).
The migration log includes the line
WRN1:7352 Failed to add *********** RC=80005008. One or more input
parameters are invalid.
Where the *** represent the LADP addressing.
I have enclosed a copy of the migration log.
Thanks for any more help which can be given.
Regards
Bob Trouchet |
|
| Back to top |
|
 |
Frances [MSFT]
Guest
|
Posted:
Thu Jan 27, 2005 2:50 pm Post subject:
RE: Using ADMT2 to migrate SIDhistory |
|
|
Hello Bob,
According to your message, you can migrate groups with SIDHistory after
rebuilding the trusts now. Is this correct? I am glad to hear the good news.
Since you have another problem regarding user migration, it is best to open
another thread and so we can deal with that separate issue attentively.
I am happy to find that you have opened "Re SIDHistory migration" thread to
deal with the new issue. I have seen the attached log and will answer you
in the new thread. Is this alright?
Thank you for your understanding.
Best regards,
Frances He
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. |
|
| Back to top |
|
 |
|
|
|
|