• State Verified Answer
  • Locked Locked
  • Replies 14 replies
  • Subscribers 20 subscribers
  • Views 11449 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Process Permissions on FIle Servers

ianclarke
over 5 years ago

Hi All

I have not been involved in a migration for the past 3 years.  Now we are migrating between forests for users/groups, workstations and email. Which is all good.

We have a question around the File Server Migration process and whether it can be streamlined?  I am looking to find out

1. Can we run an initial Vmover command and start to process permissions. Even if all users and groups are not migrated? And then run a delta to permission new folders and also add missing users and groups?

2. On data this is dedupe'd - Does this have any effect when running VMover?

Thanks 

Parents
  • 0 over 5 years ago

    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. 

  • 0 over 5 years ago in reply to Jeff Shahan

    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.

Reply
  • 0 over 5 years ago in reply to Jeff Shahan

    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.

Children
  • 0 over 5 years ago in reply to Chris.Holley

    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.