Jump to content

Auditing Data not archiving on schedule


support
 Share

Recommended Posts

ISSUE:

You may find that you are getting an alert from Passwordstate stating that you have excessive auditing records. By default, Passwordstate should move auditing records from the primary "Auditing" table into the "AuditingArchive" table in SQL. If your system is failing to do this, please consider the following:

 

Check 1:

First check that the Passwordstate Service is running on your web server.  The Windows Service is the tool that moves the data across to the archiving table and the service needs to be running.

 

Check 2:

Check your Archiving settings under System Settings and confirm you do not have the maximum number of rows set to 0.  0 means the Service will never move data to the Auditing table.  500,000 is the default value, and is suitable for most environments.  Also, check the Schedule on this same page, and ensure your Passwordstate web server is Powered up at the time of this schedule:

2022-03-31_11-50-44.png

 

Check 3:

Look in your Application Event logs on your Passwordstate webserver and look for any errors related to the Passwordstate Windows Service.  If you find any but are unsure what they mean, please send these to Click Studios Support for analysis: https://www.clickstudios.com.au/support.aspx

 

If you find errors that mention "Violation of PRIMARY KEY constraint 'PK_AuditingArchive'. .AuditingArchive'. The duplicate key value is xxxx" like the screenshot below, we'll need to truncate the Archiving table (instructions below)

AuditingError.png

 

Take a full backup of your database before doing this, and keep that database just in case you need to access the old auditing data at some stage in the future.  Ie, you could restore that database to a test server if needed.  You could possibly export the data and put it into an excel spreadsheet, but if your “AuditingArchive” table has more than a million rows, Excel won’t be able to cope with this.

 

If you want to find out how many rows you have in the AuditingArchive table before deleting everything, please run this script in SQL Management Studio tools, when connected to your Passwordstate database server:

 

USE Passwordstate

SELECT COUNT(*) FROM AuditingArchive

 

To delete everything from this table, please run this command:

 

USE Passwordstate

TRUNCATE TABLE AuditingArchive

 

Now restart your Passwordstate Windows Service on your web server and wait one day.  This should then move excessive entries from the “Auditing” table into the “AuditingArchive” table. 

 

Regards,

Support

 

 

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...