Home error codes esent troubleshooting windows server

Windows Server ESENT Errors: Decoding Event ID 327 and 326

Updated: • 0 • min read
Table of Contents

Wrestling with Windows: Taming Those Pesky ESENT Event ID Errors (327 and 326)

Ever feel like your Windows Server’s Application log is throwing a rave, and you weren’t invited? If you’re seeing ESENT Event IDs 327 and 326 popping up faster than popcorn kernels, you’re in the right place. This guide will walk you through understanding and fixing these log-filling gremlins.

Windows Server ESENT Errors
image just illustration

Decoding the ESENT Event IDs 327 and 326 Mystery

These events are like that annoying friend who keeps repeating the same story. They basically tell you that the svchost process is repeatedly attaching to the SystemIdentity.mdb database. Five times a second! Talk about clingy. This constant chatter clogs up your Application log, making it difficult to spot other important messages. It’s like trying to find a specific grain of sand on a beach.

Key Symptoms:

  • Event ID 327: Signals the database engine attaching to the SystemIdentity.mdb database. Includes internal timing sequences and recovery cache information.
  • Event ID 326: Similar to Event ID 327, but also provides storage cache information.
  • Rapid-fire Logging: These events occur at a high frequency (approximately 5 times per second).
  • Overstuffed Application Log: The constant influx of these events quickly fills the log, obscuring other potentially critical events.

These events generally pop up on Windows Server 2012 and later versions. So, if you’re running one of those and seeing these errors, don’t panic! We’ve got this.

The Root of the Problem: SystemIdentity.mdb Woes

The culprit behind these repeating events is typically a hiccup within the SystemIdentity.mdb database itself. Think of it as a small, unassuming database file that plays a role in user access logging. When something goes wrong inside this file, the system gets confused and starts spamming those ESENT events.

Taming the Log-Filling Beast: Two Solutions

Luckily, there are a couple of ways to silence this noisy database. Think of these as your “mute” buttons:

1. The Nuclear Option: Database Deletion and Regeneration

This is the equivalent of hitting the reset button. It’s a straightforward approach that often resolves the issue completely.

  • Step 1: Stop the User Access Logging Service: First, you need to stop the service that’s constantly pestering the database. This is like telling the annoying friend to take a breather.
  • Step 2: Wipe the Slate Clean: Delete all files within the %SystemRoot%\system32\LogFiles\Sum\ folder. Don’t worry; this won’t harm your system. It’s like clearing the whiteboard to start fresh.
  • Step 3: Restart the Service: Once the files are gone, restart the User Access Logging service. The system will then regenerate a brand new, hopefully healthy SystemIdentity.mdb database.

2. The Silent Treatment: Disabling the User Access Logging Service

If you’re not actually using the User Access Logging service, then disabling it entirely is the easiest solution.

  • Step 1: Stop the Service: Again, first stop the User Access Logging service.
  • Step 2: Disable the Service: This time, instead of deleting files, you’ll disable the service from starting up automatically. Open your Services management console (you can search for “services” in the Start Menu), locate User Access Logging, right-click, and choose “Properties”. Change the “Startup type” to “Disabled”. This is like unfriending that annoying friend on social media – problem solved!

Understanding the User Access Logging Service

The User Access Logging service, the source of our woes, is used to track user login activity. While it can be useful for security audits and troubleshooting, if you’re not actively leveraging this feature, disabling it won’t negatively impact your system.

A Quick Recap: What We’ve Learned

  • ESENT Event IDs 327 and 326 flood the Application log when there’s a problem with the SystemIdentity.mdb database.
  • This issue occurs on Windows Server 2012 and later versions.
  • Two main solutions are deleting and regenerating the database or disabling the User Access Logging service.

Your Next Steps: Reclaim Your Log!

Don’t let these pesky ESENT errors take over your server. Choose the solution that best fits your needs and reclaim control of your Application log. If you have any questions, feel free to leave a comment below. We’re here to help you navigate the sometimes-choppy waters of Windows Server administration. Happy logging!

Post a Comment