Best practice for migrating a file server?

We currently have a 2008R2 Server Core VM with all data on D: and E:.  We'd like to migrate (not upgrade) to a 2012R2 file server.  There's 2 ways I see this going:

1.  Take a snapshot of VM; clean install 2012R2 and import shares as in https://support.microsoft.com/kb/125996 ; remove snapshot if successful.

2.  Make a new VM and copy all data.

We have about 200 users, so obviously all file level permissions also need to be retained.  Can anyone recommend a guide or some firsthand tips?  I see MS has a File Server Migration Toolkit, but it doesn't appear to be updated for 2012R2.  We are NOT using DFS, and I don't see much reason to start now given our environment is so small.
sbumpasAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Sean FitzpatrickSr Lab Systems EngineerCommented:
have you looked at 2012 Migration tools?
0
Cliff GaliherCommented:
Just Robocop the data and recreate the shares. The process is painless unless you have something funky.
0
sbumpasAuthor Commented:
Wouldn't a clean install achieve the same thing as robocopy to a new server?

I have looked at the 2012 Tools, but they seem incomplete.  for example, there's the guide states it does not supply info for "Migrating Roaming User Profiles (for additional information see Upgrading or Migrating a Roaming User Profiles Environment to Windows 8.1 or Windows Server 2012 R2)".  But, there is no section on migrating profiles to 2012R2 (that I can find).
0
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

Sean FitzpatrickSr Lab Systems EngineerCommented:
you could always script the ad profile update for every user.

I'm assuming that the path is going to be the same for all users?
0
sbumpasAuthor Commented:
Right - it would be something like \\server\share$\profiles\%username%

So you're saying create a script that copies individual user data at login?
0
Sean FitzpatrickSr Lab Systems EngineerCommented:
I had to do this for a previous employer, and I just used xcopy to move all the data, other option is to take a complete backup of the data and just restore it on it's new location
0
Cliff GaliherCommented:
You would install the OS clean, yes. I wasn't saying otherwise. But robocopy will, with the right flags, copy all ACLs. So you *only* have to recreate the shares. You won't have to reset all of the other ACLs, which when it comes to NTFS permissions and inheritance, could be a right pain to do manually.

So you get the benefit of a clean OS, but the time-savings of a copy. Not sure what else you were looking for...
0
sbumpasAuthor Commented:
So formatting C: and installing 2012R2 would cause NTFS perms to be lost on D: and E:?
0
Cliff GaliherCommented:
Most people interpret the term "migration" as moving from one machine to another, vs "upgrade" which is installing overtop. Based on your original question terminology and mention of VMs, I assumed that you were indeed migrating from one platform to another. If you have the option of mounting the disks/partitions from the old install into the new, sure, that is an option and would save you the copy step for those partitions. But depending on disk configuration, RAID controllers, etc, that usually isn't an option. Hence I didn't mention it.
0
sbumpasAuthor Commented:
I see your point.  So if I were to take the following approach:

shutdown VM
take snapshot
power on, format C: and install 2012R2
Import D: and E: volumes
Recreate shares

that should hold my NTFS-level ACLs, yes?  then I would remove the snapshot after (a lot) of testing
0
Sean FitzpatrickSr Lab Systems EngineerCommented:
Just wondering are your D: and E: Volumes on separate VMDK's from your C: volume?
0
sbumpasAuthor Commented:
yes
0
Sean FitzpatrickSr Lab Systems EngineerCommented:
Ok, easy enough. Dismount your D: and E: volumes; leaving the C: Volume VMDK attached.
Update your system to 2012, reattach the D: and E: volume VMDK's; update permissions, you should have all your data available to you.
0
sbumpasAuthor Commented:
Fantastic - 1 question:  what do you mean "update permissions"?
0
Sean FitzpatrickSr Lab Systems EngineerCommented:
So, your D: and E: drive's are going to have 'System' permissions, which are permissions from the old OS installation, you will need to update those permissions (ie. take ownership) with the new system.
0
Cliff GaliherCommented:
In theory that could work as it will preserve all ACLs, yes. However, keep in mind that if you set any ACLs based on local users or groups, those local users and groups are *not* being preserved so the related ACLs are, in effect, orphaned. In many higher security environments, file ACLs are never set to domain groups or users directly. Local groups are instead created and used, ACLs are set to local groups, and domain groups are made members of those local groups. That is where migration tools can help. At the very least, auditing your ACLs would be a good idea.
0
sbumpasAuthor Commented:
Good point - fortunately we're a very simple environment, no ACLs are (intentionally) tied to local groups.  In fact, there are no local users other than those OOB.
0
Sean FitzpatrickSr Lab Systems EngineerCommented:
+1 to Cliff, I was more getting him an easy update to his data, then worry about the shares. That can be dealt with after.
0
sbumpasAuthor Commented:
I understand now - would I take ownership at the volume/root level, or the folder level?
0
Sean FitzpatrickSr Lab Systems EngineerCommented:
0
sbumpasAuthor Commented:
Sorry but now I'm confused - all these procedures look like they'd completely wipe existing ACLs?  Or is it that i'd run only the 1st line:

TAKEOWN /f "X:\" /r /d y
0
Cliff GaliherCommented:
Unless I'm mistaken (and that is possible, it has been a long day), "system" is a well-known ID, which basically means that it has the same SID on every installation. And since ACLs are granted by SID, you usually don't have to take ownership to fix system permissions. As long as the original owner was a domain account (which goes back to what I said above about auditing ACLs.)  "Creator Owner" and similar are also well-known SIDs so they shouldn't break either.

-Cliff
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Server 2012

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.