RE: Remigrating users to update .mdb file
From: Jeff Qiu [MSFT] (jefffqiu_at_online.microsoft.com)
Date: 06/24/04
- Next message: Gux: "Adding Windows 2003 to replace 2000 server"
- Previous message: Alex: "Post Migration Question"
- In reply to: Erik: "Remigrating users to update .mdb file"
- Next in thread: Erik Ableson: "Re: Remigrating users to update .mdb file"
- Reply: Erik Ableson: "Re: Remigrating users to update .mdb file"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 24 Jun 2004 16:10:53 GMT
Hi Erik,
Thanks for posting!
Based on my research, the following KB contains the information that should
be pretty helpful to explain this "undocumented" Protar.mdb database:
835991 How to use a SID mapping file with the ADMT tool to perform a
resource
http://support.microsoft.com/?id=835991
For your convenience, I have included the part related to this file:
When you perform a resource domain migration to Windows Server 2003, you
must run the Security Translation Wizard to translate the security
information about resources from the source domain to the target domain. If
you must perform the migration from workstations other than the master
workstation to correctly translate the security principals on various
resources, you must either copy the Protar.mdb database from the master
workstation to the alternative workstations or use a SID mapping file.
MORE INFORMATION
================
The Protar.mdb database resides in the installation folder of the ADMT
tool. By default, this is the following folder:
C:\Program Files\Active Directory Migration Tool
This database contains a complete list of the migrated objects, including
the source and the target SIDs of objects.
During the security translation process, the ADMT references the database
to determine the security principals that must be modified. It is a best
practice to perform the migration from a single workstation where the
Active Directory Migration Tool (ADMT) is installed so that the program can
access the Protar.mdb database.
However, if you must perform the migration from alternative workstations,
make sure that you copy the Protar.mdb database from the master migration
workstation to the alternative workstations.
Additionally, if you copy the Protar.mdb database from the master
workstation to the alternative workstations, make sure that you first
follow these steps:
1. Make sure that both the source and the target computers are running
ADMT version 2.
2. Back up the existing Protar.mdb database on the target workstations
before you copy the master database.
3. Copy the Protar.mdb database from the installation folder of the
ADMT tool on the master workstation to the installation folder of the
ADMT tool on the target workstations.
If WAN bandwidth limitations make it inconvenient to copy the database,
you must generate a SID mapping file on the master migration workstation
and then copy this to the alternative workstations. This SID mapping file
is used by the Security Translation Wizard.
The SID mapping file is a comma separated values (CSV)-formatted file. In
the SID mapping file, specify first the source SID and then the target
SID, separating each SID value by a comma. If the account domains are
accessible, you can specify the source and the target account names and
then separate them by a comma instead of specifying the source and the
target SIDs. To specify the account names, use the following format:
domain\account
For example, to generate a SID mapping file on the master migration
workstation by using Microsoft Visual Basic Scripting Edition (VBScript),
follow these steps:
1. Connect to the Protar.mdb database, and then retrieve the recordset:
Set objConnection = CreateObject("ADODB.Connection")
objConnection.Open "Provider=Microsoft.Jet.OLEDB.4.0;Data
Source=C:\Program Files\Active Directory Migration Tool\Protar.mdb"
Set rs= CreateObject("ADODB.RecordSet")
Set rs = objConnection.Execute ("Select * FROM [MigratedObjects]")
Note "C:\Program Files\Active Directory Migration Tool\Protar.mdb"
represents the default path of the Protar database, and ?rs? is the
recordset. Also, the ADMT installation path can be determined by querying
the HKEY_LOCAL_MACHINE\Software\Microsoft\ADMT\Directory registry subkey.
2. Create a new SID mapping file to write the contents of the recordset to:
Set fso = CreateObject("Scripting.FileSystemObject")
Set fo = fso.OpenTextFile("sidMapping.txt", ForWriting, True)Note
"Sidmapping.txt" is the file where the SID records will be written.
3. Move through the recordset, and then write the source SID and the
target SID to the SID mapping file:
Do while not rs.EOF
fo.write rs("SourceDomainSid") & "-" & rs("SourceRid") & "," &
rs("TargetDomain") & "\" & rs("TargetSamName") & vbcrlf
rs.MoveNext
loop
Now you can copy the SID mapping file, SidMapping.txt, to the alternative
workstations and use it in the security translation process.
REFERENCES
==========
For additional information about the ADMT utility, click the following
article numbers to view the articles in the Microsoft Knowledge Base:
HOW TO: Set up ADMT for Windows NT 4.0 to Windows 2000 migration
http://support.microsoft.com/?id=260871
HOW TO: Set up ADMT for a Windows NT 4.0-to-Windows Server 2003 migration
http://support.microsoft.com/?id=325851
How to use Active Directory Migration Tool Version 2 to migrate from
Windows 2000 to Windows Server 2003
http://support.microsoft.com/?id=326480
Hope it helps!
Best Regards,
Jeff Qiu
Microsoft Online Partner Support
MCSE 2k/2k3, MCSA 2k/2k3, MCDBA
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
--------------------
>From: Erik <eableson@ozitem.com>
>Subject: Remigrating users to update .mdb file
>Date: Wed, 23 Jun 2004 20:50:06 +0200
>Newsgroups: microsoft.public.windows.server.migration
>microsoft.public.windows.server.migration
>
>Problem here that I think is resolvable by a few actions in ADMT but
>looking for a little confirmation. Situation is an interforest
>migration 2000 to 2003. The user accounts were originally migrated
>using ADMT from a DC in the source domain while logged into an account
>in the destination domain. This was (at the time) the only way to get
>the password migration to work properly.
>
>Since then (reading up in here) I've noticed that the User Profiles
>migration will not work unless the actions are done from the same
>machine with the same copy of ADMT since it needs the references in the
>little (very much undocumented) local .mdb file with the other
>requirement being that these actions should be performed on ADMT on a DC
>in the destination domain. Without resorting to exotic copy rename
>actions on the mdb file can I simply remigrate the accounts on the copy
>of ADMT on the destination DC in order to get those accounts referenced
>in the mdb file?
>
>Once the accounts are in this copy of ADMT I can proceed with the
>profile and workstation migrations as per normal (or as normal as an
>inter forest migration ever gets)
>
>Hints and tips appreciated.
>
>Erik
>
- Next message: Gux: "Adding Windows 2003 to replace 2000 server"
- Previous message: Alex: "Post Migration Question"
- In reply to: Erik: "Remigrating users to update .mdb file"
- Next in thread: Erik Ableson: "Re: Remigrating users to update .mdb file"
- Reply: Erik Ableson: "Re: Remigrating users to update .mdb file"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
