Process Permissions on FIle Servers

Unfortunately, there is no delta.  You would have to run vmover/Resource updating manager over and over if new people are migrated.

data that is duplicated doesn't matter, Rum will look at all files and folders and update them appropriately 

With large servers we find that processing with the Vmover.exe (Command line) instead of RUM  is rather faster than the UI, Resource Updating Manager.  You can run multiple instances of vmover with the exported INI against individual volumes etc.

https://support.quest.com/migration-manager-for-ad/kb/20808/processing-resources-and-moving-computers-from-command-line

There is no notion of delta-permissions update within the product.  

I suppose you could try to optimize the VMover INI file (via Custom Map) to include only "new" users etc. but this is probably more work than it's worth.

Not sure what you mean by "de-duped".  Repeated re-ACL'ing of servers doesn't cause any duplication.

There's nothing technically wrong with the approach you suggest.  Though, depending on the size of the environment, babysitting the success/failure of a repeated re-ACL'ing process on many servers can get human resource intensive.

Thanks for the quick response.  

Was just hoping to run a first pass for now then once all migrated run a second pass on setting permissions.  

Thanks

Thanks for the response.  I think we will just wait until the end of the migration and then target the file servers.

I think the term "migrated" is causing confusion. I assume you mean that the source users is now a migrated target user. However in the terms of the tool. Migrated mean the target object has been created and there is a mapping between the source and target users/group,etc...  This is normally done very early in the migration project. Once it is done, the directory sync keeps the objects up to date. So from this point, you can have two work streams, server processing and workstation processing/migration. Normally the users are migrated with their workstation. I.E They start to use their target user account when their workstation is a member of the target domain. 

Now you only have to process the file server once. 

I have to agree here as I was typing up a similar response when he replied.   We have to look at what a migration is from the application perspective which is what Jeff mentions.  So one the users/groups are migrated with a "Migration" session or synchronized via "Directory Synchronization" you can then move forward with processing the file servers, even if the users aren't logging onto the new domain.

This allows you to process the resources (file servers) so that as the users are migrated (from a human perspective) and logging onto the new domain, they can access all the resources in the source.   Even if they have not yet been physically moved to the new domain.

Thanks for the replies.  So more stats around the file servers - in prep for the Vmover taks.  Is there any loose formula or ball park figure that can be used to say, re-permission around 100,000 files?

 I guess that there are many factors, but a ball park figure would be ideal.

Is it all on the item count or does file sizes become a factor?

Thanks

For that many files you can open up multiple command line boxes and run vmover against individual shares/volumes to help speed things up.  

Yes, migrated is a very ambiguous term.

FWIW, what Chris calls "migrated (from a human perspective)" to avoid I confusion I refer to as cutover [to logging into the "new" domain.]

To amplify Jeff's point:

However in the terms of the tool, Migrated mean the target object has been created and there is a mapping between the source and target users/group,etc...  This is normally done very early in the migration project.

Practically speaking this means that you initially re-create all existing users & groups up front "in bulk" using a couple of migration sessions.  You then have to engineer into your process some "delta" or "catch up" migration sessions for net-new users and groups that get created as the project rolls out. 

That, or you decide that from a certain date forward, all net-new creates will take place in the target.  This is not as crazy(?) as it seems because if you used SIDHistory with the migration of your groups, then the new users placed in the target groups will have access to the legacy resources whether you have re-ACL'd or not.

File sizes don't matter - whether a file is big or small, it only has one ACL.  It's all about the number of files and folders.