SBS, Healthmon: Article 6, Specific items to monitor for using healthmon

Without giving away our edge here, I wanted to document a few of the healthmon alerts that I like to use, and alluded to in the previous five SBS healthmon posts (linked below). This is by no means exhaustive or comprehensive, but using commonsense, you can start to see some of the real value you can add by leveraging healthmon in your offerings. And remember, this is all out-of-the-box type functionality, and the key is that it provides real business-value.

Why did that server go down over the weekend? Are my backupexec remote agents running? When was that computer account created, and why? Who created that user account?

In the enterprise, these items would be covered and then documented as part of a change management process. In any environment, these are really key building blocks in establishing a “managed services model”.

So, listed below are a few of the alerts I use, as well as the relevant alert configurations. Each one has a justification section explaining why they’re being used. Take a look. If you have something you’re using effectively, why don’t you go ahead and add a comment to that effect?

Type: Core server alert, Data Collector>Service Monitor
Name: SBS Server, BackupExec Remote Agent
Details, Service: BackupExecAgentAccelerator
Details, Properties: Display Name, Started, State, Status,
Actions: Send Email>Execution condition, Critical>Reminder:6 hours
Message: standard service monitor message (state and condition), plus server name.

Justification: Alert sysadmin when the Veritas Backup Exec remote agent service on the SBS 2003 server fails. The “backup server” is located on another machine.

Type: Core server alert, Data Collector>Windows Event Log monitor
Name: SBS - Computer Account Created (645)
Details: Success audit
Details, log file: Security
Details, Event ID: 645
Actions: Warning, and Critical email
Schedule: all days, all times, every 1 second, 1 sample needed
Message: Computer account created

Justification: Alert sysadmin whenever a computer account gets created. Computer accounts created by non-admin’s need to be reviewed for security compliance (a/v, patch, OS, etc).

Type: Core server alert, Data Collector>Windows Event Log monitor
Name: SBS - Computer Account Deleted (647)
Details: Success audit
Details, log file: Security
Details, Event ID: 647
Actions: Warning, and Critical email
Schedule: all days, all times, every 1 second, 1 sample needed
Message: Computer account deleted

Justification: Alert sysadmin whenever a computer account gets deleted. Computer accounts typically shouldn’t be deleted by non-technical owners and sysadmins should be alerted to review the issue.

Type: Core server alert, Data Collector>Windows Event Log monitor
Name: SBS - User Account Created (624)
Details: Success audit
Details, log file: Security
Details, Event ID: 624
Actions: Warning, and Critical email
Schedule: all days, all times, every 1 second, 1 sample needed
Message: User account created

Justification: Alert sysadmin whenever a user account gets created. User accounts typically shouldn’t be deleted by non-technical owners and sysadmins should be alerted to review the need/assignment of the account and account properties.

Type: Core server alert, Data Collector>Windows Event Log monitor
Name: SBS - User Account Deleted (630)
Details: Success audit
Details, log file: Security
Details, Event ID: 630
Actions: Warning, and Critical email
Schedule: all days, all times, every 1 second, 1 sample needed
Message: User account deleted

Justification: Alert sysadmin whenever a user account gets deleted. User accounts typically shouldn’t be deleted by non-technical owners and sysadmins should be alerted to review the change.

Type: Core server alert, Data Collector>Windows Event Log monitor
Name: SBS - Failed Password Attempt (529)
Details: Success audit, Failure audit
Details, log file: Security
Details, Event ID: 529
Actions: Critical email
Schedule: all days, all times, every 1 second, 1 sample needed
Message: User account deleted

Justification: Excessive failed password attempts should be reported to a sysadmin for event follow-up.

Name: Member Server – Server-Name (no-ups) Ping (ICMP) Monitor
Details: System, “server-name”, timeout(msec): 1000
Actions: Critical email
Details: Success audit, Failure audit
Details, log file: Security
Details, Event ID: 529
Actions:
Schedule: all days, all times, every 10 minutes, 6 samples needed
Message: Server-name down: Ping failed (power-issue?)

Justification: For servers that do not have a UPS attached, downtime should be recorded and reported to a sysadmin as justification for possible purchase (non-sbsers probably won’t get this one).

Previous 5 SBS, Healthmon articles in order of posting:
SBS: "sbsmonacct" and healthmon alerts
SBS Healthmon: Filtering events for notification
SBS, Healthmon: Why would I care about notifications?
SBS, Healthmon: Why would I care when a computer account gets created/deleted?
The managed services model

SBS, Healthmon: Why would I care when a computer account gets created/deleted?

So you’ve read the previous few posts, and you’re a little interested in using healthmon. But maybe you’re just not yet to the point of actually doing anything about it. You’re probably sitting there asking yourself, “Hey, great, so I can tell when my customers are adding computers. Why should I care?”

You should care because you’re a driven professional who takes pride in your work. And depending on the type of contracts you’ve been able to secure, you should start getting preventative, and take technical ownership of the installations (obviously to the extent that your customer has directed). Beyond that, you should care because you want to add value. Remember that you’re there to protect the customer’s IT infrastructure, and sometimes that means protecting it from the customer.

It’s great when a customer is technical enough to add their own computers to the domain. But it’s not so great when those systems are added without considering the workstation lifecycle. How are those systems going to get updates from the WSUS server? Who’s responsible when they’re not added to the managed antivirus installation? Who’s accepting these risks, and the costs associated with them.

Obviously, there’s still a healthy balance to mind, because you and I both know the customer is not going to perceive any value from you bugging them to update the BIOS revisions on their workstations every few months.

Mind that healthy balance, and focus on adding real value.

Additional resources:
sbsmonacct notifications:
Filtering Events using SBS Healthmon:

SBS, Healthmon: Why would I care about notifications?

So you’ve read the previous few posts, and you’re a little interested in using healthmon. But maybe you’re just not yet to the point of actually doing anything about it. You’re probably sitting there asking yourself, “Hey, great, so I can tell when my customers are adding computers. Why should I care?”

You should care because you’re a driven professional who takes pride in your work. And depending on the type of contracts you’ve been able to secure, you should start getting preventative, and take technical ownership of the installations (obviously to the extent that your customer has directed). Beyond that, you should care because you want to add value. Remember that you’re there to protect the customer’s IT infrastructure, and sometimes that means protecting it from the customer.

It’s great when a customer is technical enough to add their own computers to the domain. But it’s not so great when those systems are added without considering the workstation lifecycle. How are those systems going to get updates from the WSUS server? Who’s responsible when they’re not added to the managed antivirus installation? Who’s accepting these risks, and the costs associated with them.

Obviously, there’s still a healthy balance to mind, because you and I both know the customer is not going to perceive any value from you bugging them to update the BIOS revisions on their workstations every few months.

Mind that healthy balance, and focus on adding real value.

SBS Healthmon: Filtering events for notification

To follow-up on yesterday’s post, I wanted to add some details on using healthmon.

To begin with, let’s just start by opening healthmon on your SBS2003 machine (start>programs>administrative tools>Health Monitor). Expand the “Small Business Server Alerts” object. Here you’ll find all of the current alerts that come pre-configured on your SBS machine.

This is where data collection for alert notifications is setup. So if you’re already receiving the occasional “Extended Server Usage Report for…”, message, then you’re good to go. If not, then you need to go back and configure “Monitoring and Reporting” under the SBS 2003 “Server Management” snap-in.

Next, let’s go ahead and create alerts to monitor the creation and deletion of computer accounts.

While in healthmon, right-click “Core Server Alerts”, click New, data collector, windows event log monitor. Click the details tab. Put a check-box in “Success Audit”. For the log file, choose “Security”. Under event ID, type “645”. Click the Actions tab, and create a new email alert. Under execute condition, check the “Warning” and “Critical” checkboxes. Under schedule, make sure all days are selected, and all times are selected. For collection interval, collect every “1” second, and total samples for collection, set it to “1”. Under the “Message” tab, in the section that says “when status changes to Critical or Warning” type “Computer Account Created”.

Great, so now an alert will fire whenever a computer account gets created. But what about when one gets deleted? Follow the same process outlined above; expect you’ll be looking for event “647”.

Expect some more follow-up and healthmon-related posts, including events that we monitor for, and our monitoring-approach for the small-to-midsized market segment.

SBS: "sbsmonacct" and healthmon alerts

For those of you that are old hats at the SBS support thing, you’ve probably long since ran across, and forgotten about the creation and deletion of the “sbsmonacct” account in the security log (filter for event ID 624 and/or 630; 4:30am-ish). I recall seeing this *way back* when I was first taking a look at SBS 2003. Having noticed it, I promptly filed it away for future reference.

Interestingly enough, I came across it again over the weekend after adding some monitoring alerts in healthmon to a customer’s installation on Friday. In checking my email on Saturday, I noticed that I had some account creation/deletion notices that had been fired off. Having since logged in to evaluate this, I was able to determine that this was expected behavior.

That, and… my alerts are firing nicely.