Hi there.
I'm about to undertake a massive file migration from a legacy 2003 Server to a newer 2012 Server.
OldFileServer has 561,498 files on it - a mixture of EV Placeholders and unarchived files.
Reading whitepapers the common method is :
1. Migrate placeholders using fsautility -pm
2. Follow behind with Robocopy
Problem here is time to do it - it's a two stage process, with each process quite lengthy. I would need to kill the drive letter, do the 2-step migration to new file server, then once complete (and checked) map drive letter to new server. During this time, access to file server is unavailble.
Done a bit more reading - and stumbled across article TECH144810 which talks about renaming a file server that is archived by Enterprise Vault System Archiving. I then had a thought of a quicker completely different way we could do this, and conducted a test outwith the live environment which appears to work perfect.
Without knowing the intricate ins and outs of how EV works at a deeper level, i'd like to run this by the experts in case i have overlooked something which may come back and bite me afterwards...
File servers in question are virtualised by VMWare and backed up with Veeam which i'm hoping can dramtically speed up the migration process instead of using fsautility -pm and robocopy.
1. Using Veeam, Backup The Data Drive (vmdk) of the old file server
2. Using Veeam, Restore The vmdk of the old file server into the folder on the LUN for the new file server
3. Add the vmdk to the new file server using VMWare so the drive from old files erver now appears as drive letter on new.
4. Recreate the shares on the new file server for the data from the old server which is now part of the new file server.
5. Add the new file server into EV as a File Server and add Shares via EV admin console.
5. Stop all EV Services on Enterprise Vault Server
6. Backup EnterpriseVaultDirectory Database on SQL Server
7. On the SQL Server issue the following query (as per TECH144810):
USE EnterpriseVaultDirectory
UPDATE FileServerEntry
SET DnsName = 'newfileserver'
WHERE DnsName = oldfileserver'
8. On the SQL Server issue the following query (as per TECH144810):
USE EnterpriseVaultDirectory
UPDATE FileServerEntry
SET UncName = '\\newfileservernetbiosname'
WHERE UncName = '\\oldfileservernetbiosname'
9. On the SQL Server issue the following query (as per TECH144810):
USE EnterpriseVaultDirectory
UPDATE ArchiveFolder
SET FolderPath = replace(cast (FolderPath as nvarchar (1000)),
'\\oldservername\', '\\newservername\')
WHERE FolderPath like '\\oldservername%'
10. On the SQL Server issue the following query (as per TECH144810):
USE EnterpriseVaultDirectory
UPDATE FSAArchivePointFolderPathChecksum
SET FolderPathChecksum = CHECKSUM(CAST(ArchiveFolder.FolderPath AS NVARCHAR(MAX)))
FROM FSAArchivePointFolderPathChecksum
INNER JOIN ArchiveFolder ON ArchiveFolder.RootIdentity = FSAArchivePointFolderPathChecksum.RootIdentity
11 Start EV Services on EV Server
12. Goto File System Archiving Task -> Properties -> Synchronise (as per TECH144810)
Job done. Takes a fraction of time that doing the two stages of fsautility -pm and robocopy - and all entries in database point to new server due to the SQL amendments above (i think? hence purpose of this post - to double check)
On testing - i can double click a Placeholder and it brings the file back fine.
Alternatively, on the EV server, i can use the fsautility -t - s \\newfileserver\path - f to force the restore of files from EV into folders which works fine.
All looks good - and my test worked a treat - but before i move this theory to a production environment, is there anything i need to be aware of?
Best Regards,
