First and foremost, we always recommend testing our products in a lab environment. Test in production at your own risk. We understand you want to get real data and it makes sense but testing in production comes with risks. Am I saying you should never do it? Yes. That’s what I’m supposed to say but if you insist otherwise, make sure you have a back-out plan.

I always recommend backing up your Change Auditor database on a daily basis whether you plan to test a Change Auditor module in production or not. The database is where everything lives including the audit events and the configuration of your CA environment.

Let’s talk a bit about our Change Auditor modules. Our Change Auditor modules do exactly what you want them to do. Sometimes customers are surprised how well they work. If you have 500 servers (DCs/Member Servers) running our Change Auditor agent and you install the Change Auditor for Logon trial key, guess what, without any other configuration required, you will now start receiving Logon audit data from 500 servers. Who knew? Well actually, it’s on page 9 of the Change Auditor Logon Activity User Guide.

Let me give you an example. I’ve spoken to many customers that were interested in auditing all Logon activity on all servers. We say, no problem, our Change Auditor for Logon module will do that for you. It can track different types of authentications as well as detailed logon sessions. We offer to walk them through a POC and next thing you know we receive a late email from the customer stating that the trial key was put in production and now the database has doubled in size. What do you do first? Don’t panic, take a deep breath and call our Support folks.

I won’t be walking you through any steps to make any changes in this blog because every environment is a bit different but I will talk about some of the options you’ll have to deal with in this scenario. Calling our Support folks and emailing your Sales Rep should be your first move.

Some of the options you will have to consider are:

  • Adjust your SQL environment to accommodate additional event data
  • Exclude accounts that may be creating unwanted events
  • Create a purge job that will specifically target the type of events being produced
  • Create an archive job to move the data to a 2nd database
  • Stop the entire auditing process so that you can go back to the drawing board and come up with a game plan
Related Content