cancel
Showing results for 
Search instead for 
Did you mean: 

Reconfigure CA/DA after moving CA\DA database to new hardware.

Cdee
Level 6

Hi All,

Need your expert advice i am planning to move my CA\DA Journaling Database to new SQL server and i want to plan for re-configuration of the EV application side.

Below is what i have a high level plan 

1) Move SQL DB to new server (this will be done by my DBA team)

2) Follow  How to move the Enterprise Vault (EV) SQL databases http://www.symantec.com/docs/TECH35744

3) Follow How to modify the configuration files after moving the Symantec Compliance Accelerator 

http://www.symantec.com/business/support/index?page=content&id=TECH51129

Please let me know if this plan on paper looks fine.

1 ACCEPTED SOLUTION

Accepted Solutions

Kenneth_Adams
Level 6
Employee Accredited Certified

Might I suggest a modification to your plan that will allow for some testing prior to moving all of your EV/CA/DA databases?  If you have both CA and DA:

1) Stop the Enterprise Vault Accelerator Manager Service (EVAMS) on your CA server.

2) Stop the Journal Task to stop the Journal Connector from capturing any new journaled messages.

3) Backup the CA databases on the 'old' SQL server.

4) Take the CA  databases offline (detach them) on the 'old' SQL server.

5) Restore the CA databases on the 'new' SQL server.

6) Follow the instructions in TECH51129 to reconfigure CA to use the dbs on the 'new' SQL server.  Be sure to edit the JournalTask.exe.config file to change the SQL Server name that now hosts the CA Configuration database.

7) Start EVAMS on the CA server.

8) Test CA by running one or more searches and one or more exports to ensure those parts are working properly.

9) Start the Journal Task.

10) Monitor the journal operations to ensure the Journal Task keeps running and the Journal Connector adds items to the CA Customer database (run the SQL query 'SELECT COUNT(*) FROM tblVaultSamples' against the CA Customer database to ensure the count increases throughout the test period.  If the count does not increase, sampling won't be able to have anything new to add to the CA review sets.

11) If all goes well with the CA databases' moves, repeat Steps 1, 3, 4, 5, 6, 7 and 8 for the DA databases.

12) If all goes well with the DA databases' moves:

  a) Stop EVAMS on your CA and DA servers.

  b) Stop the Enterprise Vault Admin Service on your EV server to stop all EV services.

  c) Backup the EV databases on the 'old' SQL server.

  d) Restore teh EV databases on the 'new' SQL server.

  e) Follow TECH35744 to reconfigure EV to use the dbs on the 'new' SQL server.

  f) Start the EV services in the following order, checking the EV Event Log for any errors thrown by the service startup attempt -

     1. Enterprise Vault Admin Service

     2. Enterprise Vault Directory Service

     3. Enterprise Vault Storage Service

     4. Enterprise Vault Indexing Service

     5. Enterprise Vault Shopping Service

     6. Enterprise Vault Task Controller Service

g) Test your EV system by running a quick browser search to ensure it finds items, manually archive something from an user mailbox (if you do user mailbox archiving), and monitoring your journal archiving processing to ensure items are archived from the journal mailbox.

h) If all of the above steps are successful, you can decommission your 'old' SQL Server.  If any of them fail, you can re-attach the appropriate databases and reverse your changes to get your systems working the way they were before the database moves.

I hope this helps.  I may be overly cautious with these steps, but I'd rather err on the side of caution to avoid any data loss or lengthy downtime because some step was missed or something went wrong with the database moves.

 

View solution in original post

3 REPLIES 3

Kenneth_Adams
Level 6
Employee Accredited Certified

Might I suggest a modification to your plan that will allow for some testing prior to moving all of your EV/CA/DA databases?  If you have both CA and DA:

1) Stop the Enterprise Vault Accelerator Manager Service (EVAMS) on your CA server.

2) Stop the Journal Task to stop the Journal Connector from capturing any new journaled messages.

3) Backup the CA databases on the 'old' SQL server.

4) Take the CA  databases offline (detach them) on the 'old' SQL server.

5) Restore the CA databases on the 'new' SQL server.

6) Follow the instructions in TECH51129 to reconfigure CA to use the dbs on the 'new' SQL server.  Be sure to edit the JournalTask.exe.config file to change the SQL Server name that now hosts the CA Configuration database.

7) Start EVAMS on the CA server.

8) Test CA by running one or more searches and one or more exports to ensure those parts are working properly.

9) Start the Journal Task.

10) Monitor the journal operations to ensure the Journal Task keeps running and the Journal Connector adds items to the CA Customer database (run the SQL query 'SELECT COUNT(*) FROM tblVaultSamples' against the CA Customer database to ensure the count increases throughout the test period.  If the count does not increase, sampling won't be able to have anything new to add to the CA review sets.

11) If all goes well with the CA databases' moves, repeat Steps 1, 3, 4, 5, 6, 7 and 8 for the DA databases.

12) If all goes well with the DA databases' moves:

  a) Stop EVAMS on your CA and DA servers.

  b) Stop the Enterprise Vault Admin Service on your EV server to stop all EV services.

  c) Backup the EV databases on the 'old' SQL server.

  d) Restore teh EV databases on the 'new' SQL server.

  e) Follow TECH35744 to reconfigure EV to use the dbs on the 'new' SQL server.

  f) Start the EV services in the following order, checking the EV Event Log for any errors thrown by the service startup attempt -

     1. Enterprise Vault Admin Service

     2. Enterprise Vault Directory Service

     3. Enterprise Vault Storage Service

     4. Enterprise Vault Indexing Service

     5. Enterprise Vault Shopping Service

     6. Enterprise Vault Task Controller Service

g) Test your EV system by running a quick browser search to ensure it finds items, manually archive something from an user mailbox (if you do user mailbox archiving), and monitoring your journal archiving processing to ensure items are archived from the journal mailbox.

h) If all of the above steps are successful, you can decommission your 'old' SQL Server.  If any of them fail, you can re-attach the appropriate databases and reverse your changes to get your systems working the way they were before the database moves.

I hope this helps.  I may be overly cautious with these steps, but I'd rather err on the side of caution to avoid any data loss or lengthy downtime because some step was missed or something went wrong with the database moves.

 

Cdee
Level 6

Thanks Ken it did help a lot.

Kenneth_Adams
Level 6
Employee Accredited Certified

You're welcome.  I'm glad to have been of service.