000038848 - How to move the StealthAUDIT DAG database to a new server in RSA Identity Governance & Lifecycle

Document created by RSA Customer Support Employee on May 19, 2020
Version 1Show Document
  • Comment • 0
  • View in full screen mode

Article Content

Article Number000038848
Applies ToRSA Product Set: RSA Identity Governance & Lifecycle 
RSA Version/Condition: All
 
IssueThe purpose of this RSA Knowledge Base Article is to explain how to move the StealthAUDIT DAG database to another server.
 
TasksSave a screenshot of the StealthAUDIT DAG database settings under the Settings > Storage section of the StealthAUDIT console.
 
ResolutionTo move the StealthAUDIT database, follow the steps below:
  1. Close the StealthAUDIT database.
  2. Check task manager and make sure no StealthAUDIT processes are running. 
  3. Temporarily disable any scheduled tasks. The easiest way to do this is: 

  1. Go into the schedules section of the StealthAudit console.
  2. CRTL click on all the scheduled jobs.
  3. Right click > Disable  

  1. Detach and move the database. (Follow the Microsoft recommended procedure - this is not a StealthBIT procedure.)
  2. Ensure account(s) have the appropriate rights on the new database. 
  3. Create a new Storage Profile in StealthAUDIT for the new database server:  

  1. Open StealthAUDIT. You will receive a message about not being able to connect to the database. 
  2. Navigate to Settings > Storage 
  3. Add a new storage profile by using the name of your new database server.
  4. Look for the expected database name (usually StealthAUDIT), and make sure it is set to the default. 
  Important

  1. You will be asked if you want to migrate information – choose No.
  2. Re-enable your scheduled tasks. 
NotesImportant note on permissions: 

If new permissions need to be applied, make sure that all users connecting to the StealthAUDIT database have: 
  •  Database owner rights on the StealthAUDIT database. 
  •  A dbo default schema.

Another option is to start totally fresh, but the downside would be losing historical data.
 

Best practice info: 

  • Use simple recovery mode - not full mode - else the log files could get enormous.
  • Change auto-growth to grow by percentage 20% or so (this can interfere with Jobs if it is growing all the time - the default grows every 1MB which can cause slowness.)

Attachments

    Outcomes