4.6 Domain Migration Scenarios

Sites for which a domain upgrade is impossible can use a domain migration process. This process uses Microsoft tools to populate a native-mode Active Directory domain with user, group, and resource accounts that have been cloned from existing accounts in a Windows NT domain. Both types of domain can operate in parallel and, if the appropriate trust relationships exist between the Windows NT and Active Directory domains, users and groups in either type of domain have equivalent ClearCase access rights.

Migration can take place over an extended period, if necessary. When all user and group accounts have been migrated to the Active Directory domain, the migration process can be completed and the Windows NT domains decommissioned. After a migration, all users, groups, and hosts have new SIDs. This has several implications for ClearCase LT:

Detailed instructions for performing these procedures are included in the remainder of this section.

Migrating Multiple Domains

All migration scenarios are essentially the same, differing only in their level of complexity as measured by the number of domains being migrated and the trust relationships among them. The procedure defined in this section can be used whether you are migrating a single domain or multiple master and resource domains.

NOTE: Before you begin any migration process, prepare all ClearCase LT hosts as described in Preparing ClearCase Hosts. Even though the hosts may not be migrating right away, they will not be accessible by migrated users and groups until you have taken this step.

Migrating Users and Groups

We recommend that you begin any domain migration by migrating users and groups from the Windows NT domains in which they were created to new Active Directory domains. Follow these steps to migrate ClearCase users and groups:

  1. Use the procedures defined by Microsoft to migrate users and groups from the Windows NT domains to the Active Directory domains.

  2. In many migration scenarios, there will be a period when users logged in to the Active Directory domain will share a VOB with users logged in to a Windows NT domain. To ensure access to VOBs by users in either type of domain, do one of the following:

  3. Because migrated accounts include SID history, user accounts in the Active Directory domain include twice as many group memberships as they had in the Windows NT domain. (Each user's group list includes groups from both domains.) Users who are members of multiple groups in a Windows NT domain may find that their group list includes more than 32 groups after migration. Because ClearCase only recognizes 32 groups, these users should set their CLEARCASE_GROUPS environment variable to include the SID string that represents the ClearCase users group in the Windows NT domain, as well as the name of the ClearCase users group in the Active Directory domain. See Step #2 of this procedure for information on how to use creds to obtain the SID string.

  4. If the user environment variable CLEARCASE_GROUPS exists for any user, ClearCase will consider the semicolon-separated list of groups specified in the value of this variable first when determining (or displaying) which groups a user belongs to. This example includes the name of the ClearCase users group from the Active Directory domain and the SID of the ClearCase users group from the Windows NT domain.

    CLEARCASE_GROUPS=AD-DOMAIN\clearusers;NT:S-1-5-21-103034363-981818062-1465874335-1064

If You Must Add a New User While Migration Is In Progress

If a new ClearCase user must be created while a domain migration is in progress, use either of the following methods:

These users may also need to change their CLEARCASE_PRIMARY_GROUP and CLEARCASE_GROUPS environment variables as described in Migrating Users and Groups.

Migrating Individual ClearCase LT Hosts

When all users and groups have been migrated and no users are required to log in to the Windows NT domain, take the following steps to migrate ClearCase LT hosts to the Active Directory domain. If you cannot migrate all your ClearCase LT hosts at the same time, we recommend migrating VOB servers first. (Registry and license servers can migrate at any time, because they do not store SIDs in their databases.)

NOTE: The procedures in this section require you to use the vob_sidwalk utility. Before executing any of these procedures, review the vob_sidwalk reference page to get a better understanding of the capabilities of vob_sidwalk.

To migrate an individual ClearCase LT host:

  1. Stop ClearCase on the ClearCase LT server.

  2. Use the procedures defined by Microsoft to migrate the host to the Active Directory domain.

  3. Restart ClearCase on the ClearCase LT server.

  4. Reprotect any VOB and view storage on the host by running the ClearCase fix_prot utility on each VOB or view storage directory as shown in this example:

  5. ccase-home-dir\etc\utils\fix_prot -replace storage-dir-pname

    where storage-dir-pname is the pathname to the VOB or view storage directory.

  6. Use the following procedure to update VOB databases with the new SIDs representing the cloned user and group accounts.

    1. Log on to the VOB server host as the VOB owner or privileged user

    2. Lock the VOB for all users but yourself (-nusers your-user-name).

    3. Replace the old SIDs with the new ones. Use the vob_sidwalk utility as shown in the following example, where vob-tag is the VOB-tag of the VOB you are updating and SIDfile-path is the name of a file where vob_sidwalk will log the changes it makes:

    4. ccase-home-dir\etc\utils\vob_sidwalk -s -execute vob-tag SIDfile-path

      For additional details on how vob_sidwalk remaps SIDs, see Remapping Historical SIDs After Domain Migration.

    5. Unlock the VOB.

NOTE: If you had been using proxy groups to enable users from multiple domains to access a common set of ClearCase artifacts, we recommend using an Active Directory universal group to eliminate the need for proxy groups and domain mapping. Follow the procedure described in Converting Proxy Groups

If VOB Servers Cannot Migrate When Clients Do

If any VOB server cannot migrate when its clients do and you need to preserve the clients' ability to access VOBs on that server, you must use vob_siddump to establish the mapping between new SIDs and old ones. After the mapping has been established, you can use vob_sidwalk to update the VOB database with the new SIDs.

  1. Log on to a client that has been migrated to the Active Directory domain.

  2. Lock the VOB for all users but yourself (-nusers your-user-name).

  3. Run vob_siddump to generate a map file. (You must use vob_siddump because you cannot run vob_sidwalk from a remote host.) In the following example, vob-tag is the VOB-tag of a VOB on a server that is still in the Windows NT resource domain, and SIDfile-path is the pathname to the map file that vob_siddump will generate. (If SIDfile_path cannot be created on a drive that is accessible to the VOB server host, you must copy it to the VOB server host before you perform Step #4 of this procedure.)

  4. vob_siddump -sidhistory vob-tag SIDfile-path

  5. Log on to the VOB server that hosts the VOB whose tag you used in Step #3 of this procedure. With the VOB still locked for all users but yourself, run vob_sidwalk to update the SID information stored in the VOB

  6. vob_sidwalk -execute -map mapfile-path vob-tag SIDfile-path

    In this example, mapfile-path is the map file you generated in Step #3 of this procedure and SIDfile-path is the name of a file in which vob_sidwalk will log the changes it makes. For more information, see Using vob_sidwalk to Change or Update VOB Users and Groups.

  7. Unlock the VOB.

NOTE: Unless the VOB remains locked from the time you begin Step #3 until the time you complete Step #4, users may create new objects in the VOB between the steps. If they do, you will have to perform both steps again.