Author: way0utwest

When you create a server audit, one of the things that might surprise you is that the audit doesn’t record data. So you create an audit for failed logins, as I did recently. You then login:

Using a bad password will get you this:

When you check the logs

you see:

What’s wrong? By default, when you create an audit, it isn’t enabled, so no data gets logged. You can enable it easily:

And then when you have a failed login:

You’ll find data in the logs:

It’s a small detail, but one you want to keep in mind as you create audits. Be sure that they are enabled before you walk away from your production systems.

A holiday in the US, commemorating the men and women who have died in the service of our country.

Most years in the US, I’ve spent the day with family, starting summer, and while we remember those in the military, it’s primarily been a time where we spend time with each other, often doing something as a family. We’ve used the time to go away, usually taking a long weekend camping or traveling around.

This year my son is participating in a Scout event, commemorating those that have died from our local area, at a local cemetery. He is hoping to serve our country in the Marine Corps at some point in his life, so this is a meaningful holiday for him, and I’m proud to be there helping him celebrate it.

I wrote about setting up a basic server audit recently. That showed about how a server level audit is set up, but that’s a just a shell. The audit itself is just a container in which you can store various audited items. Like a SQL Server Agent job, it doesn’t do anything until you add some details.
One of the details that I think is worth adding is the failed login audit at the server level. Finding a large number of failed logins can clue you in to some hacking going on, so it can be good to log these.
To add these, you first need to add a server audit specification, which is like a job step. It’s a detail at the server level. Using the SSMS GUI, you can do this by right clicking the Server Audit Specification under Security. Select “New Audit Specification”
 
That gives you a dialog where you can add a name:

And then select an audit to which you assign this particular detail.

For my purposes, I need to audit failed logins, so I select that change group. You can get all change groups in BOL.

Once this is done, your audit appears in the folder in SSMS.

Now when someone tries to log in and can’t, you can view this in the logs:

I got new drives for my Windows Home Server the other day and decided to add some space to the box. I don’t need the space so much as I’d like to be sure that I’m protected with some extra drives.

The first step, obviously, is to shut down the server and add the physical hardware. That was easy enough. Then you connect to the Home Server console and click the Server Storage link and verify that the drive is there. It will be listed as non-WHS storage.

You select it, click “Add” at the top, and a few minutes later the space is available.

I had 3.3TB on my server and added another 2TB to it. It took about 2 minutes after I installed the drive, and I was more protected. I am waiting on an RMA of another 2TB drive, and once I get that, I’ll add it in as well to give myself a little more protection and storage space.