User(s) transfer from 7.2 to 8.3

[Craig A]

Are you moving the users to new tin?

If so, I wouldn't ship anything but provide new.

Use it as an opportunity to rationalise and strip out all the crud that will have gathered on the system over the years.

Use new physical device names, logical names, usernames (possibly a new VMS username standard), etc..

Craig

[Hoff]

Given that there's no f$getuai DCL lexical function, here's the GETUAI tool, a tool that extracts the specified UAF record contents into DCL symbols, and which could be the basis for a locally-written migration procedure:

http://labs.hoffmanlabs.com/node/1205

if you'd prefer to get out of the business of adding and maintaining this stuff and allow folks to enroll themselves and allows them to reset their own passwords, here's the NEWUSER tool:

http://labs.hoffmanlabs.com/node/1260

If you do decide to port over the contents of the core authorization files in bulk, do expect to have to resolve the inevitable UIC and binary identifier values collisions; these tend to collide. (This wouldn't be my preferred approach, but I've used it.)

Here are the list of files that are shared, and that can have either host or usernames or UICs or identities embedded:

http://labs.hoffmanlabs.com/node/169

That's likely a few more files than you will have to deal with here, but it's a start, and it describes the files that are shared in a cluster.

As for cleaning off stale identifiers in file ACLs and such, here's an ACL_SCRUB tool:

http://labs.hoffmanlabs.com/node/426

Here's a general write-up on creating OpenVMS users:

http://labs.hoffmanlabs.com/node/856

And as Craig A comments, I'd start over again and haul over as little as possible, if that's at all feasible. VMS systems tend to build up huge accretions over the years, odd defaults and settings, weird logical names and all that dreck makes the management more complex, and can lead to higher direct and indirect support costs. (You can end up paying for the support for products and licenses that you aren't using anymore, for instance.)

[Jeremy Begg]

Hi Niall,

I've also had to deal with the problem of moving a batch of users from one system to another. Copying SYSUAF and RIGHTSLIST is one method but I prefer to merge the old and new instead.

First you need to confirm that the users to be moved don't have UICs which conflict with any existing users on the destination server. (In your case it sounds like you're building a new server so this shouldn't be a problem.)

Secondly you need to get a list of all the Rights Identifiers on the existing system using

$ MCR AUTHORIZE LIST/ID/FULL *

which will create RIGHTSLIST.LIS. Armed with this information, create the Identifiers on the new system. It's best if you can preserve the identifier values otherwise you risk breaking any ACLs which might be present in your filesystem.

Then to move the users I use EDIT/TPU to edit the SYSUAF.DAT file from the old system, removing the users which aren't going to be moved, then saving the file to (say) USERS.TXT. I copy USERS.TXT to the new system then merge it into the UAF there using

$ CONVERT/MERGE USERS.TXT SYS$SYSTEM:SYSUAF.DAT

The next step is to create rights identifiers for all the moved users. The ADD/IDENT/USER= command within AUTHORIZE is the easiest way, in my experience.

Once the user Rights Identifiers are created you need to grant any other Identifiers to each user. Use the RIGHTSLIST.LIS file to guide you. (If you're good at TPU it's not hard to turn this into a list of GRANT/IDENT commands.)

Other steps might include moving the users' directories using BACKUP (unless the disks are being moved from the old machine to the new) and possibly changing the users' default device and directory in SYSUAF.

Regards,
Jeremy Begg