Need advice for shifting rational server to new domain

yes, but ... read https://publib.boulder.ibm.com/infocenter/cchelp/v7r1m0/topic/com.ibm.ra...

and be aware that you need to uninstall 7.1.1 before you can install 7.1.2 (big sigh)

I haven't done an upgrade since migrating from 6.13 to 7.0, but if it helps, here's what we did. Maybe it's changed since, and if so, feel free to disregard:

On Windows, VOBs formatted with schema version 54 store Windows security identifiers (SIDs) to represent users, groups, and resources (hosts). When you move a VOB to a different domain, these SIDs become incorrect and must be changed (mapped) to SIDs that are valid in the new domain. Rational ClearCase includes a utility program, vob_sidwalk, that provides a flexible means of mapping SIDs after you move a VOB to a different domain. Review the vob_sidwalk reference page before continuing with this procedure.

The following procedure moves the VOB \<VOB name> from storage directory E:\ClearCase_Storage\VOBs\<VOB name>.vbs on VOB server host \<old host>, which is in the OLD domain, to a storage directory shared as <VOB storage path>\VOBs on VOB server host \<new host>, which is in the NEW domain. To run this procedure, you must be able to log in to both the OLD and NEW domains as the VOB owner of \<VOB name> or as a privileged user.

1. Verify that the VOB is formatted with at least schema version 54. Lower-numbered schema versions do not support moving a VOB to a different domain. You can use the Rational ClearCase Administration Console or the cleartool describe command to determine a VOB’s schema version. For more information about VOB schema versions and how to change them, see “VOB schema versions” on page 72 of the ClearCase 7.0 Administrator’s Guide.

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

3. Lock the VOB. for all users. This ensures that no new VOB objects are created while you complete Step 4 on page 117 of the ClearCase 7.0 Administrator’s Guide.

4. Generate a SID file from the Source domain that lists the names of users and groups associated with objects in \<VOB name>. Run vob_siddump to generate a SID file in comma-separated-value (csv) format:
c:\Program Files\Rational\ClearCase\etc\utils>vob_siddump \<VOB name> E:\ClearCase_Storage\VOBs\<VOB name>.vbs \<VOB name>.csv

It is best to do the SID Dump at the same time as the backup is done so that the SIDs match the backed up data as closely as possible.

Create the SID file in the VOB storage directory so that it is available on the new VOB host after the storage directory has been moved. (You will need it in Step 11 on page 118 of the ClearCase 7.0 Administrator’s Guide.)

5. Stop Rational ClearCase on the VOB server host.

6. Rename the old VOB storage directory before you restart Rational ClearCase on the source host. If you omit this step, the VOB will become available in its old location as soon as the VOB server starts on the source host, which can cause a variety of problems for users trying to access the VOB.

7. Copy the VOB storage directory to the new location.
E:\ClearCase_Storage\VOBs> net use E: \<new host>\<VOB storage path>\VOBs E:\ClearCase_Storage\VOBs> xcopy <VOBName>.vbs E:\<VOB name>.vbs /E

Note: Because the existing VOB storage directory ACLs are not valid in the new domain, you may use xcopy or another copy utility that does not preserve ACLs for this step.

8. Fix the VOB storage directory protections. Log on to the VOB server host in the new domain (\<new host> in our example) as the VOB owner of \<VOB name> or as a privileged user. Run the fix_prot utility. In this example, <AdminUserID> is the name of the new VOB owner, <DomainID>\<CC Users Groupname> is the name of the VOB’s new principal group, and E:\<VOB storage path>\VOBs\<VOB name>.vbs is the host-local pathname of the VOB storage directory on \<new host>:

c:\Program Files\Rational\ClearCase\etc\utils>fix_prot –root –chown <AdminUserID> –chgrp <DomainID>\<CC Users Groupname> \<new host>2\<VOB storage path>\VOBs\<VOB name>.vbs

c:\Program Files\Rational\ClearCase\etc\utils>fix_prot –r –chown <AdminUserID> –chgrp <DomainID>\<CC Users Groupname> -chmod 775 \<new host>2\<VOB storage path>\VOBs\<VOB name>.vbs

Note: The users group <CC Users Groupname> is used, not the admin group.

9. Replace the VOB object and tag with new ones that reference the new VOB storage directory. Use the following commands:

cleartool register –vob –replace \<new host>2\<VOB storage path>\VOBs\<VOB name>.vbs

cleartool mktag –vob –replace –tag \<VOB name> \<new host>2\<VOB storage path>\VOBs\<VOB name>.vbs

10. Lock the VOB. Although the VOB is now registered and has a tag, it will not be usable until you complete this procedure. If you are concerned that users may try to access the VOB before it is ready, lock it now.

11. Create a map file. Open the SID file generated in Step 4 on page 117 of the ClearCase 7.0 Administrator’s Guide. (\<new host>2\<VOB storage path>\VOBs\<VOB name>.vbs\<VOB name>.csv).

It may be easier to edit this file if you use a spreadsheet program that can read the comma-separated-value format. This example shows one line of such a file. It includes a header row for clarity. The SID string has been truncated to save space.

Old-name Type Old-SID New-name Type New-SID Count
<DomainID>\sampleue USER NT:S-1-2… IGNORE USER 137

For each line in the file, replace the string IGNORE in the New-name field with a string made up of the new domain name and the user name from the Old-name field; then delete the last three fields (Type, New-SID, and Count). In this example, old domain’s name is CA and the new domain’s name is <NEWDOMAINNAME>, so the line would change, as shown here:

Old-name Type Old-SID New-name Type New-SID Count
CA <DomainID>\<AdminUserID> USER NT:S-1-2… C <NEWDOMAINNAME>\<AdminUserID>

After you have edited all the rows of the SID file, save it as a comma-separated-value file and use it as the mapping file required when you run vob_sidwalk –map. Each line of the mapping file must have exactly four fields, separated by commas.

13. Unlock the VOB. If you are concerned that users may try to access the VOB before this procedure is complete, lock the VOB again for all users except yourself (cleartool lock –nusers you). You must have write access to the VOB to complete this procedure.

14. Update user and group identities stored in the VOB. When you are satisfied that the map file is correct, run vob_sidwalk. In this example, Sid-map.csv is the map file created in Step 11 on page 118 of the ClearCase 7.0 Administrator’s Guide:

Note: For the SidWalk, the ClearCase Admin group ClearCase_Users needs folder permissions for VOB and View storage locations

c:\Program Files\Rational\ClearCase\etc\utils\vob_sidwalk –execute –map \<new host>2\<VOB storage path>\VOBs\<VOB name>.vbs\<VOB name>-map.csv \<VOB name> <VobTag> -exec.csv

vob_sidwalk remaps ownership as specified in the map file and records the changes made in Sid-Map.csv.

15. Recover file system ACLs. While you are still logged on to \<new host> as the VOB owner or privileged user, use vob_sidwalk with the –recover_filesystem option to apply the correct ACLs to the VOB storage directory.

c:\Program Files\Rational\ClearCase\etc\utils>vob_sidwalk –recover_filesystem \<VOB name> Sid-Map_Recov.csv

vob_sidwalk logs changes made during this step to the file Sid-Map_Recov.csv

16. Verify that all clients in the new domain can access the VOB. Unlock the VOB if it is still locked.

17. Verify that all Rational ClearCase users in the new domain can access objects in the VOB. Users should be able to create new objects as well as change or remove objects that they own.

18. If problems occur, verify all ACLs
In ClearCase\etc\utils run the following command:

fix_prot –root -recover
If there are errors reported, consult page 207 of the Rational ClearCase administrator’s guide for remediation.

In addition, we did the following fix-prot and such commands and they worked great. Better than combining the two fixprots into one.

Do the following commands for each VOB: (might want to script these for speed and accuracy)

fix_prot –root –chown <admin user> –chgrp <domain>\<user_group> \<hostname>\<VOB storage dir path>\<VOBname.vbs>

fix_prot –r –chown <admin user> –chgrp <domain>\<user_group> -chmod 775 \<hostname>\<VOB storage dir path>\<VOBname.vbs>

cleartool register –vob –replace \<hostname>\<VOB storage dir path>\<VOBname.vbs>

cleartool mktag –vob –replace –tag \<VOBtag> \<hostname>\<VOB storage dir path>\<VOBname.vbs>