Centralizing Windows Logs – The Ultimate Guide To Logging

Centralizing Windows Logs

You can use the tools in this article to centralize your Windows event logs from multiple servers and desktops. By by rights administering your logs, you can track the health of your systems, keep your log files secure, and filter contents to find specific information .

Why Centralize Logs?

Centralizing your logs saves time and increases the dependability of your log data. When Windows log files are stored locally on each server, you have to individually log in to each one to go through them and look for any errors or warnings. If the server is unresponsive, you might be out of luck. If you aren ’ metric ton sure which servers are affected, you have to hunt through each one, which can take a retentive time on big networks. The log files are besides safer in a centralized location because even when your instances are terminated or your files are deleted ( intentionally or unintentionally ), the centralized backup copies of your logs are insensible .

Windows Event Subscription

It is potential for a Windows server to forward its events to a collector waiter. In this scenario, the collector server becomes a cardinal depository for Windows logs from early servers ( called event sources ) in the network. The stream of events from a informant to a collector is called a subscription .
This operation demonstrates how to set it up. These steps work on Windows Server 2008 R2, Windows Server 2012, and Windows Server 2019.

Example System

We are using two active Directory Domain–joined Windows Server 2012 systems. The domain name is mytestdomain.com and both machines are registered with the sphere .
Source server MYTESTSQL hosts a SQL Server 2014 case. Collector server MYTESTSERVER works as an event log subscriber to centralize all SQL Server-related logs from MYTESTSQL .

Picture3 1

Setup

Enable the Windows Remote Management Service

Windows Remote Management ( WinRM ) is a protocol for exchanging information across systems in your infrastructure. You must enable it on each of your source computers to exchange log files .

  1. Remotely log into the source computer (MYTESTSQL) as a local or domain administrator.
  2. Enable Windows Remote Management Service from a Command Prompt:
    winrm quickconfig

    If it is already running, a message like to this case is displayed. Picture3 2

Configure the Windows Event Collector Service

You must enable the Windows Event Collector Service on your collector waiter to allow it to receive logs from your sources .

  1. Remotely log into the collector computer (MYTESTSERVER) as a local or domain administrator.
  2. Configure the Windows Event Collector Service from a Command Prompt:
    wecutil qcin

    If prompted like the example, press y Picture3 3

Configure the Event Log Readers Group

By default, certain logs are restricted to administrators. This may cause problems when receiving logs from other systems. To avoid this, you can grant entree to the collector computer by adding it to the Event Log Readers group .

  1. Go back to the source computer (MYTESTSQL).
  2. Open Server Manager.
  3. Open Computer Management.
  4. Expand Local Users and Groups node from the Navigation pane and select Groups.
  5. Double-click Event Log Readers.Picture3 4
  6. Click Add to open the Select Users, Computers, Service Accounts, or Groups dialog.
  7. Click Object Types.
  8. Check Computers and click OK.
    Picture3 5
  9. Enter MYTESTSERVER as the object name and click Check Names. If the computer account is found, it is confirmed with an underline.
  10. Click OK twice to close the dialog boxes.
    Picture3 6

Configure Windows Firewall

If the source calculator is running Windows Firewall, ensure it allows Remote Event Log Management and Remote Event Monitor traffic .
Picture3 7

Create a Subscription

Subscriptions define the kinship between a collector and a source. You can configure a collector to receive events from any number of sources ( a source-initiated subscription ), or specify a limited fructify of sources ( a collector-initiated subscription ). In this example, we create a collector- originate subscription since we know which calculator logs we want to receive .

  1. Start the Event Viewer application on the collector server MYTESTSERVER.
  2. Select Subscriptions from the Navigation pane
  3. Click Create Subscription in the Actions pane.
    Picture3 8
  4. On the Subscription Properties, enter the following as shown in the example:
    Subscription name: MYTESTSQL_EVENTS
    Description: Events from remote source server MYTESTSQL
    Destination log: Forwarded Events
    Select Collector initiated and click Select Computers to open the Computers dialog.
    Picture3 9
  5. Click Add Domain Computers.
  6. Enter MYTESTSQL as the object name and click Check Names. If the computer is found, it is confirmed with an underline.
  7. Click OK.
    Picture3 10
  8. Click OK to return to the Subscription Properties.
  9. Click Select Events to open the Query Filter and enter the following to set the remote server to forward all application events from the last 24 hours:
    Logged: Last 24 hours
    Check all Event levels
    Select By log
    Event logs: Select Application from the drop-down list
    Picture3 11
  10. Click OK to return to the Subscription Properties.
  11. Click Advanced to open the Advanced Subscription Settings and enter the following:
    Select Machine Account
    Select Minimize Latency
    Protocol: HTTP
    Port: 5985
    Picture3 12
  12. Click OK to return to the Subscription Properties.
  13. Click OK to close.

The Subscription node in the collector calculator event viewer now shows the raw subscription .
Picture3 13

Verify Events on Collector Computer

choice Forwarded Events from the Navigation paneling on the collector calculator .
Picture3 14
The Computer column in the Details paneling indicates the events are from the outside calculator MYTESTSQL.MYTESTDOMAIN.COM. You can enable or disable the collector subscription by right-clicking on the subscription and choosing Disable. The status of the subscription is then shown as disabled in the chief window. An active collector subscription does not mean it is succeeding. To see if the collector can connect to the source, right-click on the subscription and choice Runtime Status. In this example, the collector can ’ deoxythymidine monophosphate connect to the source. By default, it retries every five minutes .
Picture3 15
If all is o, Subscription Runtime Status shows a green tick with an active status.

Picture3 16

Create a Custom View (Optional)

once the events are forwarded, you can create customs views to see the consolidated events. For example, you might create a customs view for mistake events. This model creates a custom view for SQL Server–related messages. A collector computer may host thousands of records from dozens of servers. Using a customs view enables you to create order from an overload of data. For detail steps, see the section Creating a Custom View in Windows Logging Basics .

Windows Logging Services

There are several Windows services you can use to centralize all your logging data to an external log service. These services send logs over syslog to a cross-platform log server or cloud-based log service like SolarWinds® Loggly® .
We recommend NXLog, a popular, freely downloadable service that runs in the background. alternately, there is syslog-ng and Snare, which are services that collect your log files. All these services provide extra professional support for a fee .

Install NXLog

This example installs and configures NXlog to package your log files .
download and install the current adaptation of NXlog. The download includes an intuitive installer. Once the facility is complete, open the configuration file. By default, the NXLog configuration file is located at C:/Program Files (x86)/nxlog/conf/nxlog.conf
You can create different types of shape modules .

  • Inputs for the source of your logs
  • Outputs for where to send the logs
  • Routes to map your inputs to your outputs

Whenever you make changes to the NXlog shape file, you must restart the NXlog service .

Configure NXLog

This model modifies the NXLog shape file to centralize your Windows event logs. Adding the code snip below to the end of your nxlog.conf file enables the module and gives it the name “ eventlog ”. The im_msvistalog input signal module sends new entries to the Windows consequence log, including system, hardware, application, and security-related events .

# Windows Event Log



# Uncomment im_msvistalog for Windows Vista/2008 and later

Module im_msvistalog

# Uncomment im_mseventlog for Windows XP/2000/2003

# Module im_mseventlog

# If you prefer to send events as JSON data

Exec $Message = to_json();

File Logs

NXLog can be used to read logs files stored on a drive. In this example, the file list is FILE1. SavePos TRUE means that NXLog will track its current placement in the log file on exit. Exec $ Message = $ raw_event means NXLog will ingest the raw log message without applying any extra format. The file name can besides include directories or godforsaken cards .



Module im_file

File "FILE1"

SavePos TRUE

Exec $Message = $raw_event;

IIS Logs

As we covered in the Windows Logging Basics section, IIS logs contain access logs stored in W3C format. We recommend you convert them to JSON format for easy process by a log management tool. NXLog can do this conversion using the W3C extension. Make certain you use the proper format in the shape file, so the parse happens correctly, and you are including log files from all your sites .



Module xm_csv

Fields $date, $time, $s-ip, $cs-method, $cs-uri-stem, $cs-uri-query, $s-port, $cs-username, $c-ip, $csUser-Agent, $cs-Referer, $sc-status, $sc-substatus, $sc-win32-status, $time-taken

FieldTypes string, string, string, string, string, string, integer, string, string, string, string, integer, integer, integer, integer

Delimiter ' '

QuoteChar '"'

EscapeControl FALSE

UndefValue -



# Convert the IIS logs to JSON and use the original event time



Module    im_file

File    "C:/inetpub/logs/LogFiles/W3SVC1/u_ex*"

SavePos  TRUE

Exec if $raw_event =~ /^#/ drop();

else

{

w3c->parse_csv();

$SourceName = "IIS";

$Message = to_json();

}

SQL Server Error Logs

SQL Server is Microsoft ’ s enterprise-class flagship database platform. It comes in a cortege of database and data warehouse tools. SQL Server typically has its own logs saved in the application ’ s initiation directory in the Windows file system. The default placement for SQL Server 2012 is C:/Program Files/Microsoft SQL Server/MSSQL11.MSSQLSERVER/MSSQL/Log. The log entries are besides sent to the Windows application event log .
SQL Server operations like backup and restore, question timeouts, or slow I/Os are therefore easy to find from Windows application consequence logarithm, while security-related messages like failed login attempts are captured in Windows security consequence log .

Forwarding Logs to a Server

NXLog can forward logs from any of the inputs described above to an external address such as a log waiter or cloud-based log management service. To do this, NXLog uses concepts called Outputs and Routes. Outputs are modules that provide functionality for sending logs to a address, such as a file or remote server. Routes are the paths that a log message takes from an stimulation ( such as the im_msvistalog module ) to an output ( such as a log management serve ) .
To forward logs, add an end product module in your nxlog.conf shape file. then add a Route module to send logs from your choose inputs to your chosen outputs. In this example, we are sending logs as syslog over TCP to the host HOSTNAME over the default option syslog port 514. We create a route that takes logs from the eventlog input and sends it to the newfangled output ( named out ) :



Module om_tcp

Host HOSTNAME

Port 514





Path eventlog => out

respective log management solutions offer specific setup instructions for Windows log. Loggly is an example of one supplier and has more detail information about setting up NXLog to gather your log files in their guide, Logging from Windows .

Encrypting Logs with TLS

By default option, logarithm sent over the Internet are transmitted in open textbook. This means snoopers can intercept and view your logarithm data. It is best practice to encrypt your logarithm data when it ’ s in transit, particularly if it contains sensitive information like personal identification details, government-regulated data, or fiscal information. The most common protocol for encrypting syslog communication is TLS, or Transport Layer Security.

TLS encrypts your logs, preventing anyone from snooping on sensitive data in your logs. Best practice is not to log information like passwords, but some applications do it anyhow. TLS encoding helps keep this data safe. encoding prevents malicious parties located between your log sources and destinations from reading or modifying your logarithm data .
here is an example setting up NXLog shape with TLS encoding for Loggly .

  1. Download Loggly’s digital certificate from the NXLog TLS configuration page.
  2. Copy the digital certificate file to your NXLog cert directory:
    copy loggly_full.crt C:/Program Files*/nxlog/cert
  3. Configure your output module with om_ssl and the certificate location. The default syslog port for encrypted logs is 6514. AllowUntrusted FALSE prevents a connection to the server if the certificate is untrusted or self-signed:
    
    Module om_ssl
    Host server.example.com
    Port 6514
    CAFile %CERTDIR%/example.crt
    AllowUntrusted FALSE
    

How do you centralize your logs ? Add a gloss to let us know !

reservoir : https://thefartiste.com
Category : Tech

About admin

I am the owner of the website thefartiste.com, my purpose is to bring all the most useful information to users.

Check Also

articlewriting1

Manage participants in a zoom meeting webinar

Call the people who attend the meet as follows Alternate host host Who scheduled the …

Leave a Reply

Your email address will not be published.