Determining Domain Migration Strategies
|
|
ClonePrincipal
ClonePrincipal is a utility that consists of the following COM object and sample scripts. You can customize the scripts using Visual Basic.
- DSUtils.ClonePrincipal, a COM object supporting three methods:
- AddSidHistory — copies the SID of a source principal to the SIDhistory of an existing destination principal.
- CopyDownlevelUserProperties — copies the Windows NT properties of the source principal to the destination principal.
- Connect — establishes authenticated connections to the source and destination domain controllers.
ClonePrincipal allows you to migrate users incrementally to a Windows 2000 environment without impacting your existing Windows NT production environment. This is done by creating clones of the Windows NT users and groups in the Windows 2000 environment. The benefits achieved using ClonePrincipal in this manner are as follows:
- Users can log on to the destination account (clone) yet have emergency fallback to the source account during the trial period.
- Several users can be introduced to the destination Windows 2000 environment at the same time.
- The source production environment is not disrupted while users are being migrated to the destination Windows 2000 environment.
- It is not necessary to update ACLs to preserve group memberships and network access for the destination accounts.
- Multiple groups with the same name or purpose from different source domains can be "merged" into the same destination object.
In addition, you can consolidate large numbers of small resource domains into Windows 2000 OUs by using ClonePrincipal to clone local groups.
Note that the AddSidHistory method is a security-sensitive operation with the following constraints:
- AddSidHistory requires you to have or provide Domain Administrator credentials in the source and destination domains. The source and destination domains MUST NOT be in the same forest. Though an external trust can exist between the source and destination domains, such a trust is not required for this function.
- AddSidHistory events can be audited, which ensures that both source and destination domain administrators can detect when this function has been run. Auditing in the source domain is recommended, but is not required, whereas auditing MUST be enabled in the destination domain for AddSidHistory to succeed.
- ClonePrincipal sample scripts call the underlying AddSidHistory method; therefore the other ClonePrincipal utilities are subject to the same security sensitivity and constraints as AddSidHistory.
© 1985-2000 Microsoft Corporation. All rights reserved.