How To Forward Windows Events To A SolarWinds Syslog Collector

Updated: 2024-03-25

---

Why Forward Windows Events to Syslog

Windows servers generate a wealth of diagnostic and security data — service starts, logon attempts, system errors, and application warnings. However, these events stay siloed inside the Windows Event Log unless you export them.

By forwarding Windows Events to a SolarWinds Syslog collector, you can centralize visibility across both Windows and network infrastructure, correlate events with firewall logs, and trigger SolarWinds alerts in real time. This approach helps unify monitoring and simplifies compliance reporting.

---

Step 1 — Identify Your SolarWinds Syslog Receiver

The SolarWinds Syslog Service (or Log Analyzer / Log Viewer) typically listens on UDP port 514 for incoming messages.

• Confirm the SolarWinds server’s IP address.

• Make sure any firewalls between your Windows host and SolarWinds allow outbound UDP 514 traffic.

• You can test connectivity later using Test-NetConnection -ComputerName <SolarWindsIP> -Port 514.

---

Step 2 — Choose a Forwarding Method

Windows doesn’t natively send events via Syslog, so you’ll need one of the following methods:

1. SolarWinds Event Log Forwarder for Windows (ELF) — a free, lightweight utility from SolarWinds.

2. NXLog or Snare Agent — third-party syslog agents with advanced filtering.

3. Windows Event Collector + PowerShell — for custom or scripted scenarios in labs.

For most environments, the SolarWinds Event Log Forwarder is the simplest and most reliable choice.

---

Step 3 — Install SolarWinds Event Log Forwarder

1. Download and install SolarWinds Event Log Forwarder for Windows on the system you want to monitor.

2. Launch the configuration utility.

3. Click Add Syslog Server, and enter:

   • Server: your SolarWinds Syslog collector IP (e.g., 192.168.1.50)

   • Port: 514

   • Protocol: UDP (or TCP if configured on the collector)

4. Click OK and ensure the connection shows as active.

---

Step 4 — Select Which Events to Forward

In the Event Log Forwarder console:

1. Click Add Rule.

2. Choose which Event Logs to monitor — typically:

   • Application

   • System

   • Security (for logon attempts, failures, etc.)

3. Apply filters as needed — for example, only forward Warning and Error events, or filter by Event ID (e.g., 4625 for failed logon).

4. Set the Syslog Facility (default = local0) and Severity Mapping if desired.

5. Save your rule.

---

Step 5 — Verify Transmission

Back on your SolarWinds server:

• Open Syslog Viewer or Log Analyzer → Live Mode.

• Generate a test event — for example, stop and start a Windows service.

• You should see the syslog message appear with the correct hostname, facility, and severity.

If no messages appear:

• Recheck your firewall and agent configuration.

• Confirm the service SolarWinds Syslog Service is running.

---

Step 6 — Tune and Alert

Once logs are arriving, create custom rules and alerts within SolarWinds:

• Match specific Event IDs or text patterns (like “Audit Failure” or “Service Terminated”).

• Trigger an email or ticket when a high-priority event occurs.

• Use rule actions to forward critical events to another SIEM or archive destination.

---

Step 7 — Test in a Lab

If you’re experimenting in EVE-NG or a similar lab platform, Windows Event Forwarder makes a perfect alert-testing source. You can safely simulate failed logins, service restarts, or system reboots to watch how SolarWinds ingests, filters, and alerts on those messages — invaluable for tuning noise levels before deploying to production.

---

Summary

Forwarding Windows Event Logs to SolarWinds via Syslog bridges the gap between system and network visibility. With just a small agent and a few rules, you can bring Windows events into the same dashboard as your routers, firewalls, and servers — making correlation and troubleshooting dramatically faster.

Whether for enterprise monitoring or lab-level experimentation, this setup is a simple but powerful way to unify your observability under SolarWinds.

Understanding Syslog Facility Codes

Updated: 2014-05-18

---

What Are Syslog Facility Codes?

In any networked environment—whether it’s a Cisco firewall, a Linux server, or a Windows host forwarding event data—Syslog is the de facto standard for event logging. Each Syslog message includes two key identifiers: a facility code and a severity level.

While severity tells you how important a message is (e.g., error vs. informational), facility tells you where it came from—the subsystem or process that generated it.

---

The Role of Facility Codes

Facility codes help network and security monitoring tools (like SolarWinds, Graylog, or Splunk) sort incoming logs into logical categories. This makes filtering, correlation, and alerting far easier.

For example, you can choose to alert only on messages from auth or local4, while ignoring generic daemon chatter. In large environments, this is critical for keeping your event streams organized and meaningful.

---

Common Syslog Facility Codes

Facility Code	Name	Typical Use
0	kernel	Kernel messages (Linux/Unix)
1	user	User-level processes
2	mail	Mail system logs
3	daemon	Background daemons and services
4	auth	Authentication and security logs
5	syslog	Internal syslog messages
6	lpr	Printer subsystem
7	news	Network news (NNTP)
8	uucp	Unix-to-Unix copy protocol
9	cron	Scheduled jobs (cron or at)
10	authpriv	Private authentication logs
11	ftp	File transfer logs
12	ntp	Network Time Protocol service
13	security	Log audit events
14	console	System console messages
15	solaris-cron	Solaris cron jobs
16–23	local0–local7	Custom or vendor-specific use

Note: Many network devices (like Cisco ASA or Palo Alto firewalls) use local0–local7 for their syslog output. You can select which facility to use in the device’s logging configuration.

---

How It Works in Practice

When a Syslog message is sent, the facility and severity are combined into a priority value.
For example, a message from local4 with severity warning (level 4) produces a numeric priority calculated as:

PRI = (Facility × 8) + Severity

If local4 = 20, then PRI = (20 × 8) + 4 = 164.
This number helps Syslog receivers quickly determine both where the message originated and how urgent it is.

---

Why It Matters for Monitoring

Facility codes become especially useful when integrating devices into centralized logging or monitoring tools. You can:

• Route specific facilities to different collectors or dashboards.

• Filter alerts (e.g., only show local4 errors).

• Create per-facility retention rules—keeping security logs longer than debug traffic.

• Test and tune alerts in lab environments like EVE-NG before deploying in production.

---

Summary

Syslog facility codes are simple but powerful—they define the origin of each log message and allow you to maintain clarity in complex environments. Once you understand how they work, you can build smarter filters, reduce noise, and make your monitoring systems far more efficient.

Whether you’re managing a handful of lab routers or a global enterprise network, knowing your facility codes is the first step toward clean, actionable logging.

How To Create SolarWinds Custom Syslog Rules

Updated: 2025-08-13

---

Why Custom Syslog Rules Matter

Syslog is one of the most powerful tools for real-time insight into what’s happening across your network — firewalls, routers, switches, servers, and more. But out of the box, the volume of raw syslog data can be overwhelming. That’s where custom Syslog rules and alerts in SolarWinds come in.

By building your own logic, you can automatically identify critical events — like firewall denials, VPN logins, or service restarts — and trigger actions such as email notifications, ticket creation, or even automated remediation scripts.

---

Step 1 — Open the Syslog or Log Viewer

If you’re running SolarWinds Log Analyzer or the integrated Log Viewer in the Orion Platform:

1. Go to Settings → All Settings → Manage Syslog Rules (or Log Analyzer → Rules).

2. You’ll see a list of existing default rules (e.g., node down, interface flaps). You can edit, disable, or add your own.

---

Step 2 — Create a New Rule

1. Click Add New Rule.

2. Give it a descriptive name (e.g., “ASA VPN Login Alerts” or “Windows Service Restart”).

3. Choose whether the rule applies to Syslog, SNMP Traps, or both.

4. Under Rule Conditions, define the matching criteria. For example:

   • Message text contains “%ASA-6-722051”

   • Hostname or IP address equals 192.168.1.2

   • Facility equals local4

   • Severity equals warning or higher

This lets you target very specific events — down to the subsystem or vendor message ID.

---

Step 3 — Define Actions

Once the condition is matched, choose what happens next. Common actions include:

• Send an email to your operations team.

• Write to a log file for long-term archiving.

• Trigger a SolarWinds alert or update a dashboard widget.

• Execute an external program or script, such as a PowerShell or Python remediation task.

You can also configure separate actions for when a rule triggers and when it resets.

---

Step 4 — Test and Validate

To confirm your rule works, generate a matching event manually. For example, send a test syslog from a Cisco device:

logging host inside 192.168.1.50
logging trap informational
send log 6 722051: Test VPN login

Within seconds, you should see it appear under Active Syslog Messages in SolarWinds, and your alert should fire.

---

Step 5 — Tune and Iterate

The best part about SolarWinds’ rule engine is its flexibility. In a lab environment — such as an EVE-NG setup — you can forward synthetic logs from simulated firewalls or routers to safely test and tune alert thresholds before rolling them into production. This hands-on approach helps you eliminate false positives, reduce noise, and fine-tune exactly what warrants attention.

---

Step 6 — Monitor and Maintain

Once your rules are deployed:

• Periodically review rule hit counts to ensure they’re still relevant.

• Adjust conditions if devices or firmware versions change.

• Archive or disable rules that no longer serve a purpose to keep your alert stack clean.

---

Summary

Creating custom Syslog rules and alerts in SolarWinds transforms raw log data into actionable intelligence. By carefully defining message patterns, severity filters, and targeted actions, you gain a proactive window into network events that matter — while filtering out the noise.

Whether you’re protecting production infrastructure or experimenting in a lab, custom Syslog logic in SolarWinds is a powerful way to elevate visibility, refine automation, and keep your network one step ahead.

How To Forward Cisco ASA Syslog Data to SolarWinds

Updated: 2025-10-16

---

Why Forward ASA Logs to SolarWinds

If you’re running a Cisco ASA firewall, its syslog output is a goldmine of security and performance insights. By forwarding that data into SolarWinds, you can centralize monitoring, trigger alerts for key events (like denied connections or VPN logins), and build dashboards that reveal trends across your network. The process is straightforward, and once configured, SolarWinds can handle parsing and correlation automatically.

Pro Tip: Forwarding ASA syslog data into SolarWinds is also a great way to test and tune alerting safely in a lab environment. If you’re using a simulation platform like EVE-NG, you can generate synthetic ASA events to see how SolarWinds reacts—perfect for refining thresholds, validating rule logic, and ensuring your alert noise levels are under control before deploying to production.

---

Step 1 — Identify Your SolarWinds Syslog Receiver

In most SolarWinds environments, Orion Syslog Service (or the newer Log Viewer / Log Analyzer) listens for incoming syslog traffic on UDP port 514 by default.

• Verify the SolarWinds server’s IP address.

• Make sure your firewall rules allow inbound UDP 514 from your ASA device.

---

Step 2 — Configure Syslog on the ASA

Connect to your ASA via SSH or the console, and run the following commands (adjust IPs and interfaces as needed):

conf t
logging enable
logging timestamp
logging device-id hostname
logging trap informational
logging host inside 192.168.1.50
exit
wr mem

Explanation:

• logging enable — Turns on syslog output.

• logging trap informational — Sets the severity level (6). You can increase or decrease verbosity with levels like warnings or debugging.

• logging host inside 192.168.1.50 — Sends logs to your SolarWinds server’s IP address.

• logging timestamp and device-id hostname help SolarWinds display readable, properly time-stamped messages.

---

Step 3 — Confirm Delivery

Back on the SolarWinds server:

• Open Log Viewer or Syslog Viewer.

• Filter by the ASA’s hostname or IP.
  You should begin seeing live syslog entries. If not, confirm connectivity and ensure the ASA’s interface used for logging has reachability to the SolarWinds server.

---

Step 4 — Categorize and Alert

Once data is flowing, you can build custom rules or alerts for specific events — for example:

• “%ASA-6-106100: access-list denied” → Possible attack or misconfiguration.

• “%ASA-4-313004: Denied ICMP type 8” → Ping floods or blocked diagnostics.

• “%ASA-6-722051: Group User Connected” → VPN session notifications.

Use Log Analyzer → Rules → Add Rule, set matching text patterns, and define actions (email, SNMP trap, ServiceNow ticket, etc.).

---

Step 5 — Tune for Noise

Cisco ASA syslogs can be extremely verbose. Periodically review the log stream and tune severity levels or exclude unimportant message IDs. A balanced configuration ensures you’re alerted to real issues — not overwhelmed by chatter.

---

Step 6 — Monitor and Visualize

Once integrated, you can:

• Build dashboards showing top denied connections or VPN sessions per day.

• Correlate ASA events with node health data in SolarWinds.

• Combine syslog data with NetFlow for richer context.

---

Summary

Forwarding Cisco ASA syslogs into SolarWinds centralizes visibility, strengthens incident response, and unlocks powerful analytics. In just a few commands, your firewall’s event data becomes part of your broader monitoring strategy — helping you move from reactive troubleshooting to proactive insight.

How To Create SolarWinds SAM Custom Alerts

Updated: 2025-10-20

---

Here’s a quick guide on how to create custom alerts in SolarWinds Server & Application Monitor (SAM) — designed for admins looking to refine monitoring and notifications in the platform.

---

Why create custom alerts?

Out-of-the-box, SAM comes with dozens of predefined alerts (for nodes down, SSL certificates expiring, application status changes, etc.).
But your environment likely has unique applications, thresholds, or stakeholders — custom alerts let you:

• Monitor tailored conditions.

• Notify the right people/groups.

• Reduce noise by filtering out irrelevant alerts.

• Automate actions when particular metrics are hit.

---

Step-by‐step: Creating a Custom Alert

Here’s a streamlined workflow.

1. Access Alert Management

   • In the SAM web console, go to Alerts & Activity → Alerts → Manage Alerts.

   • You can either duplicate an existing alert and edit it, or create a new one from scratch.

2. Define Alert Properties

   • If duplicating: select the alert, click Duplicate & Edit.

   • If new: click Add New Alert.

   • Enter a meaningful name, description, severity (Warning/Critical), what time-frame it’s evaluated etc.

   • Specify who can view/manage the alert (roles, teams) if needed.

3. Set Trigger Conditions

   • Select the object type you’re alerting on (node, application monitor, component, etc.).

   • Define one or more conditions. For example:

     • The monitored application status = Down.

     • The specific component metric > X threshold.

   • Use the “Add [+]” button if you need multiple trigger clauses.

   • You can target specific objects (e.g., certain applications, servers) or use groups.

4. Define Reset Conditions

   • When should the alert go away (reset)? For example, status returns to Up, metric falls beneath threshold.

   • Setting clear reset logic avoids “stuck” alerts and ensures you don’t get duplicates or lingering notifications.

5. Define Actions

   • What happens when the alert fires? Common actions: Send Email/Page, Log Event, Trigger Script, etc.

   • Configure the action details: recipient list (team alias or individuals), subject, body (use variables like ${Variable} for dynamic data).

   • Optionally: define a different action for when it resets (e.g., “all clear” email).

6. Schedule & Scope

   • Set when the alert is active (24/7, business hours only, etc.), how often conditions are evaluated, and if there are any suppression windows.

   • Confirm the alert applies to only the relevant nodes/applications (scope) so you don’t flood yourself with irrelevant triggers.

7. Review & Submit

   • Review the summary of your configurations.

   • Submit and enable the alert. It will start monitoring based on your defined criteria.

   • Monitor the alert’s execution: you’ll see it in Active Alerts list when it fires.

---

Tips & Best Practices

• Use meaningful naming: so when someone sees the alert, they know what it means and who should respond.

• Avoid too many trivial alerts: custom alerts are powerful — too many minor ones = noise and alert fatigue.

• Test your alert conditions: Use a non-production object or controlled threshold to ensure it triggers and resets as expected without unintended side-effects.

• Use variables in messages: The ${variable} syntax allows you to include dynamic details (object name, value, etc).

• Document alert logic: If someone else inherits your environment, they’ll thank you for clear definitions of what triggers exist and why.

• Review periodicity and suppression: If a system is undergoing heavy activity/maintenance, you may want to suppress alerts temporarily rather than disable them.

• Use scopes wisely: Apply the alert only to relevant nodes/applications — this keeps results meaningful and your alert console clean.

---

Summary

Setting up custom alerts in SolarWinds SAM isn’t difficult — once you know the steps: define properties → trigger conditions → actions → review & enable. The real value lies in tailoring alerts to your environment and teams, reducing noise, and ensuring you’re notified only when something actionable occurs.

If you like, I can pull in some example templates (with queries/thresholds) or sample email body content you can copy and adapt. Would you like that?

How To Create An Unprivileged WMI Service Account

Updated: 2014-01-23

---

In Chapter 1 of SolarWinds Server & Application Monitor: Deployment and Administration you will find a step-by-step guide on how to create an Active Directory service account for WMI polling purposes. The tutorial instructs you to create the account with Domain Admin privileges. This is useful to get things up and running, for testing purposes, and for troubleshooting. That said, as stated in the book, once you roll things into production it is not a recommended best security practice.