File Server Restore

[Viatcheslav75]

Hello All,

Here is a dilemma. My project to migrate our file server from Windows Server 2008 to Windows Server 2012. We are fully virtualized environment running VMware ESX, Veeam is our primary backup solution. We are considering the following to perform the migration:

- Deploy Windows 2012 R2
- Allocate a big chuck of space to the new file server
- Use Veeam to restore Guest files from old 2008 server to our new 2012 server
- Decommission 2008 server

Sounds like a simple plan. But, would Veeam retain NTFS and Windows Share permissions by restoring data to the new server? We threw idea of just reattaching vmdk files but we don't know how the new server would react when we enable dedupe functionality. Also knowing that attached vmdk would in the Windows server 2008 file system. If anybody see any issues what we are trying to do, please comment

[Dima P.]

Hello Viatcheslav,
Welcome to Veeam forums!

Please note, that Veeam B&R is never considered to be an OS migration tool. There are several best practices described by MS, mostly they involve native MS migration tools for Migrating Roles and Features in Windows server. Thank you.

[chjones]

We did the same migrations at my workplace. Since everything is virtualised we made a clone of the OS VMDK (without customization) so we would have a copy of it if something went wrong, also used Veeam to backup just the OS VMDK. Then, I expanded the OS disk from 40GB to 50GB (40GB was our standard OS disk for Windows 2008) and then created a VM snapshot (you can't expand a VMDK if a snapshot already exists).

Then, I attached the Windows Server 2012 R2 ISO to the VM and performed an inplace upgrade. If the source server was Windows 2008 then I had to go to Windows 2012 first, then upgrade again to 2012 R2, however if the source is 2008 R2 you can go straight to 2012 R2).

After the upgrades were complete, all tests passed and the system was running without issue for a fortnight we then enabled data deduplication. You can't shrink the size of the VMDK (unless you convert the VM to thin provisioned which we don't use as we use a HP 3PAR for storage and best practice is thick provisioned eager zeroed) but you will reclaim space inside the VMDK. We saw an average of 42% data reductions across 18 file servers around Australia just by migrating all file servers to 2012 R2 and enabling dedupe. It also then makes your VM Backups quicker as the data is not rehydrated, there is less for Veeam to backup.

If you are using Windows 2008 x86 then you have no choice and must deploy a new system as Windows 2012 is x64 only. But if you have to go that path there is an easier way to do it:

1. Create your new 2012 R2 Server
2. Remove the data drive VMDK from your 2008 File Server (I assume all user data is on a separate disk and not on the 2008's system drive)
3. Move the VMDK on the VM Datastore to the folder of the 2012 R2 VM
4. Attach the data drive VMDK to the 2012 R2 VM and assign the same drive letter it had on 2008
5. Export the registry keys from HKLM\System\CurrentControlSet\Services\LanmanServer\Shares from the 2008 server
6. Edit the exported file and remove any system shares you don't want to import (admin shares, prtprc, print$, etc)
7. Import the registery keys to the 2012 R2 and reboot (or just restart the server service)

This will restore all shares on the 2012 R2 and retain the share permissions. The NTFS permissions on the files is retained as that the security descriptior on the file and folders contains that information so it goes with the data no matter which Windows server you attach the VMDK to.

You can also then either remove the 2008 Server from the domain and rename the 2012 to the same name so user shares still connect (unless you use DFS in which case you just need to add the shares as targets to the DFS paths). Or, you can disable strict name checking (http://technet.microsoft.com/en-us/libr ... s.10).aspx) on the Server Service (we have done this for a few special cases) which allows you to create a DNS alias for the old file server that points to the new server. If the user browses to the old name they will be redirected and the server won't throw an error as the name the client requested doesn't match the name of the server.

We've used both methods and worked 100%.