We recently moved about 400GB of data from a NT4 file server to a Win2k file server using a tool from Fastlane. The tool also had a NetApp proxy, where you would install the software on a third system, independent of the first server and the filer. Not sure if it would work for two filers, but it might be worth a try. It would beat the backup and restore route, and then trying to hack the permissions with the cacls or subinacls tools. Ugh.
We had a ton of local groups, and a few local accounts, that were all migrated pretty painlessly. Drop an email back if you want more details on the product. The web page is http://www.quest.com/fastlane/consolidator/. The Fastlane product beat Aletia's in the last Windows 2000 magazine review.
-warren
-----Original Message----- From: Jeffrey Krueger [mailto:jkrueger@qualcomm.com] Sent: Tuesday, July 03, 2001 4:37 PM To: toasters@mathworks.com Subject: An idea on migrating NTFS data
We are about to migrate a bunch of data between different filers, among which is some NTFS security style data. The only non-slam-dunk about it is NTFS local groups.
Background: We use the Microsoft recommended method of assigning rights to filesystems, that is UGLR (phonetic == Uglier).
Users belong to ... Global groups, which belong to ... Local groups, which are assigned access to ... Resources.
The problem is that Local groups have a non-global SIDs between machines. That is, each filer assigns its own local SID's to local groups in its /etc/lclgroups.cfg on the root volume. That SID gets moved with the ACL data to the destination, but the destination machine can't resolve its membership with its local groups.
The traditional approach to fixing this is using a tool from Aelita or subinacl to traverse the entire destination filesystem (post-migration) and replacing any occurrence of the old SID with that of a new SID for a local group on the destination filer. This is all fine and good, but could take forever.
-------- THE IDEA --------
Here's my idea on a better way to do this. Simply shutdown CIFS on the destination machine pre-move and create analogous local group entries with SIDs that match the source. NetApp tech support might not like the idea too much, but it would mean that the same global groups would belong to that SID and thus no filesystem traversing or ACL modification! Ta Da!
Unfortunately, we are copying data from more source machines than there are destination machines and we are not copying data per filer - that is some data from filer1 will go to filerA, some to filerB, etc. This means that for my scheme to work, we'd need globally unique local group SID's. Since it appears that ONTAP starts assigning local group SID's at 65536 sequentially, we have lots of conflicting local groups with those lower numbered SID's.
To still use the original concept, I had the idea of copying the membership of all the groups on the source filers into new local groups with globally unique SID's. Then run one of the ACL tools to create analogous ACE's for the new group wherever it finds the old one. (This is all done pre-migration) After the migration we simply create local groups on the destination machine with SID's of the new, analogous rights granted group.
Has anyone tried something like this before?? Can anyone see any problems with this approach?? How about an alternative approach??
Again, the idea is to prevent the requirement of a filesystem traversal during migration.
Thanks in advance!!
-- Jeff
-- ---------------------------------------------------------------------------- Jeff Krueger, NetApp CA E-Mail: jeff@qualcomm.com Senior Engineer Phone: 858-651-6709 Storage Lead (NAS/SAN) Fax: 858-651-6627 QUALCOMM, Inc. IT Engineering Web: www.qualcomm.com