Moving a VOB to a different domain

On Windows®, VOBs 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.

1. Log on to the VOB server host as the VOB owner or privileged user.
2. Lock the VOB for all users.
   This ensures that no new VOB objects are created while you complete Step 3.
3. Generate a SID file that lists the names of users and groups associated with objects in \libpub.
   Run vob_siddump to generate a SID file in comma-separated-value (CSV) format:

   ccase-home-dir\etc\utils\vob_siddump \libpub C:\ClearCaseStorage\VOBs\libpub.vbs\libpub.csv

   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 10.)
4. Stop DevOps Code ClearCase® on the VOB server host.
5. Rename the old VOB storage directory before you restart DevOps Code ClearCase on the source host.
   If you omit this step, the VOB is 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 who try to access the VOB.
6. Copy the VOB storage directory to the new location.

   C:\ClearCaseStorage\VOBs>net use E: \\vobsvr-new\vobstg
   C:\ClearCaseStorage\VOBs>xcopy libpub.vbs E:\libpub.vbs /E

   Note: If the existing VOB storage directory ACLs are not valid in the new domain, you can use a copy utility that does not preserve ACLs for this step. If you use xcopy, you may be able to use the /O to preserve ACLs if the new domain trusts the old domain. If the new domain does not trust the old domain, do not use /O.
7. Fix the VOB storage directory protections.
   Log on to the VOB server host in the new domain (\\vobsvr-new in our example) as the VOB owner of \libpub or as a privileged user. Run the fix_prot utility. In this example, vobadm is the name of the new VOB owner, ccusers is the name of the VOB's new principal group, and V:\vobstg\libpub.vbs is the host-local pathname of the VOB storage directory on \\vobsvr-new:

   ccase-home-dir\etc\utils\fix_prot –root –r –chown vobadm –chgrp ccusers V:\vobstg\libpub.vbs

8. Replace the VOB object and tag with new ones that reference the new VOB storage directory.
   Use the DevOps Code ClearCase Administration Console or the following commands:

   cleartool register –vob –replace \\vobsvr-new\vobstg\libpub.vbs
   
   cleartool mktag –vob –replace –tag \libpub \\vobsvr-new\vobstg\libpub.vbs

   If \\vobsvr-new is not in the same registry region as \\sol, you do not need to use the –replace option to cleartool register and cleartool mktag, but the old registration and tag for \libpub should be removed, because this data is not valid after the move.
9. Lock the VOB.
   Although the VOB is now registered and has a tag, it is not usable until you complete this procedure. If you are concerned that users might try to access the VOB before it is ready, lock it now.
10. Create a map file.
    Open the SID file generated in Step 3 (\\vobsvr-new\vobstg\libpub.vbs\libpub.csv). It might 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
    OLD\akp	USER	NT:S-1-2-21-532...	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 OLD and the new domain's name is NEW, so the line would change, as shown here:

    Old-name	Type	Old-SID	New-name	Type	New-SID	Count
    OLD\akp	USER	NT:S-1-2-21-532...	NEW\akp

    Although this example shows a user name that is the same in the old and new domains, the procedure can also be used to map a user or group name from the old domain to a different user or group name in the new domain. 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. The example row created in this step looks like this in CSV format:

    OLD\akp,USER,NT:S-1-2-21-532...,NEW\akp

    Note: You can reassign ownership of any object in a VOB to the VOB owner by placing the string DELETE in the New-name field. You can also reassign ownership of all objects in a VOB to the VOB owner without creating a mapping file. See Reassigning ownership to the VOB owner.
11. Test the map file.
    Run vob_sidwalk without the –execute option. The list of mappings in the map file libpub-map.csv is written to the SID file (libpub-test.csv in this example), but no changes are made to the VOB.

    ccase-home-dir\etc\utils\vob_sidwalk –map \\vobsvr-new\vobstg\libpub.vbs\libpub-map.csv \libpub libpub-test.csv

12. 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 your-username). You must have write access to the VOB to complete this procedure.
13. 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, libpub-map.csv is the map file created in Step 10:

    ccase-home-dir\etc\utils\vob_sidwalk –execute –map \\vobsvr-new\vobstg\libpub.vbs\libpub-map.csv \libpub libpub-exec.csv

    vob_sidwalk remaps ownership as specified in the map file and records the changes made in libpub-exec.csv.
14. Recover file system ACLs.
    While you are still logged on to \\vobsvr-new 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.

    ccase-home-dir\etc\utils\vob_sidwalk –recover_filesystem \libpub recov.csv

    vob_sidwalk logs changes made during this step to the file recov.csv
15. Verify that all clients in the new domain can access the VOB.
    Unlock the VOB if it is still locked.
16. Verify that all DevOps Code ClearCase users in the new domain have the same access rights to objects in the VOB as they did before the move.
    Users should be able to create new objects and to change or remove objects that they own.

    Note: If the user's name in the new domain is not the same as in the old domain, the user loses rights (for example, the right to remove a version that you created) associated with the creator of a version or a branch. These operations can still be run by a more privileged user (VOB owner, member of the DevOps Code ClearCase administrators group).