Occasionally the Enterprise Vault databases need to be moved to another SQL server whether thats a decommissioning exercise or as apart of an upgrade, for instance EV 11 doesnt support SQL 2005 whereas previous versions did. Symantec have some great support when it comes to EV, I havent came across any fault that isnt covered either by a KB or their support team cant answer.

The KB to move the databases can be found here

Before any migration check compatibility here

Symantec offer a script to do the migration as long as you meet their criteria, the following blog will illustrate the manual steps to move the databases. I sometimes prefer to do the steps manually, hopefully these steps will help others

Prepare

First locate the database location for the Directory DB, Fingerprint DB and Vault Store DB

• Open SQL studio - Security - Logins - EV Services account - Properties - Server roles - confirm dbcreator is checked

Make sure TCP/IP and/or Names Pipes are enabled on the new SQL server

• Open SQL Server Config Manager - SQL Server Network Configuration - Protocols for instance - confirm Named Pipes / TCP/IP is enabled

Now on the old SQL server backup the EV databases, either run a configured maintenance plan or back them up manually. Run any backup of the server for good measure. Copy the backup files to the new SQL server. On the new SQL server restore these databases onto the configured instance. To restore a SQL database follow this

Update Fingerprint database

Now you need to configure EV to point to the new SQL server. Again the full process can be down by using Symantec’s script but I prefer to this manually. The first part to move is the Fingerprint database. Download the SQL script from Symantec from here. Open this script and edit the following and replace the details to match your environment.

SELECT @vaultStoreGroupName = N’VSG_NAME‘, — The name of the Vault Store Group to be moved. This can be found under “Display Name” in the VaultStoreGroup table.
@fingerprintDBName = N’FPCDB_NAME‘, — The name of the database that has been moved to a different SQL server
@newSQLServerName = N’NEW_SQL_SERVER_NAME‘ — The name of the new SQL Server

*Important* if you are not using the default instance name you must specify the server name and instance name next to @newSQLServerName*

Upload the changed script to the new SQL server and execute the script

To check the change run another SQL query, in this example I have changed the SQL name to SQL02\ENTERPRISEVAULT

select * from FingerprintCatalogueDatabase

Update the Monitoring database

While still in the SQL studio run the following query

USE EnterpriseVaultDirectory
UPDATE MonitoringSettings
SET SQLServer = ‘New_SQL_Server‘

Update the Directory database

This time on the EV server edit the registry to point to the new SQL server, reg keys are below

For 32bit systems, HKEY_LOCAL_MACHINE\Software\ KVS\Enterprise Vault\Directory\ DirectoryService.

For 64bit systems, HKEY_LOCAL_MACHINE\Software\ Wow6432Node\KVS\Enterprise Vault\ Directory\DirectoryService

Start the EV Admin Service and EV Directory Service

Update the Vault Store database

With the Admin Service and Directory Service up and running open the EV console. Expand Vault Store Groups - VaultStoreGroup - VaultStore - Properties - Database. Change this to the new SQL server and instance. Repeat this for each Vault Store

Now start all the EV services and monitor the event logs.

Update the Audit database

For 32bit systems, Open Data Sources (ODBC) from the Administrative Tools panel on the Enterprise Vault Server. For 64bit systems, browse to %systemroot%\syswow64\odbcad32.exe - Select the System DSN tab - Select the EVAudit entry - Click the Configure button - On the first page of the wizard, under Which SQL Server do you want to connect to?, enter the name of the new SQL server - Finish

Monitor

Now monitor all the event logs for any errors. I have done this a few times now and each time I have had the event ID 13397

The connect ‘database’ was lost and the system is waiting to reconnect (thread ID:#)

This is down to the Fingerprint database location, in my case I missed out the instance name as it wasnt the default. If you get this error check over the settings in puted under ‘Update Fingerprint database’ above and make sure they are correct.

Remember to create SQL maintenance plans for the new databases on the new SQL server and configure any relevant backup products to reflect the change.