Tag Archive: event id

VSS Event ID 12289

I noticed I was getting 10 errors with the source VSS and ID of 12289 once a day. The error message is:

Volume Shadow Copy Service error: Unexpected error VSS_E_WRITER_STATUS_NOT_AVAILABLE. An older active writer session state is being overwritten by a newer session. The most common cause is that the number of parallel backups has exceeded the maximum supported limit. hr = 0x80042409.


PostSnapshot Event


Maximum supported sessions: 64

Completed sessions: 8

Active sessions: 64

Aborted sessions: 0

Writer failed sessions: 0

New snaphot set: {9e27fa3a-58c4-49e8-ac98-e61ce47e227b}

Old snapshot set: {78b24809-c91f-46d2-ae15-1e3ac517f17c}

Old operation: 1014

Old state: 1

Old failure: 0

Execution Context: Writer

Writer Class Id: {e8132975-6f93-4464-a53e-1050253ae220}

Writer Name: System Writer

Writer Instance ID: {0ded508e-db13-4a3d-ae21-c82dde65cef3}

VSS Event 12289

VSS Event 12289

Each of the 10 events was a different “Writer Name
This is a simple problem, which means that my VSS writers, which handle Shadow Copies as well as Windows Backup, were busy when requested for use.
This is simply a conflict with backup schedules. I h to task manager and sure enough, the VSS was scheduled to make copies at 7 AM of drives C and D.
I have my Windows Server Backup scheduled at 7 AM as well. Moving the Windows Server Backup scheduled time to 6 AM solves this problem.
Alternately, you could move your VSS Shadow Copy Schedule to another time using Task Manager.

I also added Backup Operators Group read permissions on Volume Shadow Copy using GPMC. Create and link a new GPO, navigate to Computer>Windows>Security>System Services>Volume Shadow Copy. Enable the GPO, and set to automatic. Then click the Edit Security button, and add Backup Operators with read permissions.

I would like to point out that Microsoft and others have stated that this issue may be benign and cause no problems. My Backups are ALL completing successfully despite the error.

Logging in today, I noticed something in the Application Log of my SBS 2008. There were three event id’s of 2803 and one of 17137 listed every 5 minutes or so. The viewer could not give me details… figures. There are the three:

Application Log Errors

Application Log Errors

The description for Event ID 17137 from source MSSQL$MICROSOFT##SSEE cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

If the event originated on another computer, the display information had to be saved with the event.

The following information was included with the event:

Then the same message with this attached:


Bound Trees

So after some digging I found information stating that this is caused by SQL closing the database connection when it is not in use, and then reopening it when it is being used. This is not good, if it is happening every 5 minutes.

So, let’s resolve this error.

First, connect to SQL using Management Studio Express. Connect to the MSSQL instance using the name \\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query and Windows Authentication.

Expand Databases.

Right click the database in question, in this case Sharepoint_Admin_Content####, and select properties.

Database Properties

Database Properties

Click on the Options menu on the left. You will see a value displayed in the right windows named AUTO_CLOSE with a value of true. Change this value to false, and save and close SQL Management Studio.



You should see two more events appear in the event log, focusing on changing AUTO_CLOSE to FALSE. They should be event id 5084.

Event Log 5084

Event Log 5084

Thats it! You have fixed the error. Monitor both the database and the event logs for a few days to see how your system reacts. If you notice side effects, then you can always change the value back yto TRUE using a reverse of the same method.

Checking the server for errors as is customary every morning, I open up server manager and see a few warnings and a few errors on the server roles.

ADDS Error

ADDS Error

 Lets investigate the warning on Active Directory Domain Service (ADDS) first. A quick examination of the event log leads me to event 2886.

Event 2886

Event 2886

The security of this directory server can be significantly enhanced by configuring the server to reject SASL (Negotiate, Kerberos, NTLM, or Digest) LDAP binds that do not request signing (integrity verification) and LDAP simple binds that are performed on a cleartext (non-SSL/TLS-encrypted) connection. Even if no clients are using such binds, configuring the server to reject them will improve the security of this server.

Some clients may currently be relying on unsigned SASL binds or LDAP simple binds over a non-SSL/TLS connection, and will stop working if this configuration change is made. To assist in identifying these clients, if such binds occur this directory server will log a summary event once every 24 hours indicating how many such binds occurred. You are encouraged to configure those clients to not use such binds. Once no such events are observed for an extended period, it is recommended that you configure the server to reject such binds.

They further go on to describe the problem in these words:

The security of a directory server can be significantly improved by configuring the server to reject Simple Authentication and Security Layer (SASL)LDAP binds that do not request signing (integrity verification) and LDAP simple binds that are performed on a clear text (non-SSL/TLS-encrypted) connection. SASLs may include protocols such as Negotiate, Kerberos, NTLM, or Digest.

Unsigned network traffic is susceptible to replay attacks in which an intruder intercepts the authentication attempt and the issuance of a ticket. The intruder can reuse the ticket to impersonate the legitimate user. Additionally, unsigned network traffic is susceptible to man-in-the-middle attacks in which an intruder captures packets between the client and the server, changes the packets, and then forwards them to the server. If this occurs on a LDAP server, an attacker can cause a server to make decisions that are based on forged requests from the LDAP client.

If you don’t understand these security features and what SASL bind or LDAP simple binds are- then imagine it simply as clients accessing and communicating with the AD using plain english, which anyone could eavesdrop on. You certainly don’t want anyone listening to your AD.

In order to see if your clients are using these communication methods, we need to turn up the logging level for LDAP Interface Events, and then wait to see if we get any error messages. I would suggest monitoring these events for a few days before making changes- blocking these binds will cause a client using them to disconnect, and better to work on that proactively.

Open Regedit (Start>Run>Regedit) and navigate to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics



You will see that this key has listed a bunch of diagnostic features, all set to zero. You can enable the logging for each of these events by changing the number to anything up to 5. A list of what each number does can be found here.

Change the value of 16 LDAP Interface Events to 2 by double clicking it and changing 0 to 2, and hitting enter.

Now keep your eye on the Event Log for event ID 2889, which will contain the IP Address of the client connecting with these binds.

Alternately, if you disable these binds, the server will post one log event every 24 hours with ID 2888.

After a few days, or hours, or no time depending upon how patient you are, you may check the Event Log and find these entries, or not. To make things easier you could create a custom log in event viewer, and filter in only event id’s 2886, 2888, and 2889.

LDAP Event Log

LDAP Event Log

As you can see, my filter is only finding event id 2886, which is the security for the bind warning. I am not seeing any 2888 or 2889, which would mean that clients were connecting using these binds. So let’s go ahead and correct the security vulnerability less privilege is more.

To do this, we need to configure the server to REQUIRE LDAP signing. This is done by Group Policy. Microsoft recommends that you make this change in the Default Domain Policy– yet I do not touch that one. So I am going to make a new GPO and link it in the domain, then apply it to all computers. You can make the changes to the Default Domain Policy if you want.

Open up GPMC from Start>All Programs>Administrative Tools>Group Policy Management.

Right click your domain, and click Create a GPO and link it here…



Name it something appropriate, like LDAP Signing.

Then open the GPO by right clicking it and selecting Edit. Now drill down to:

Computer Configuration>Policies>Windows Settings>Security Settings>Local Policies>Security Options.

Right-click on Domain Controller: LDAP Server Signing Requirements and select properties.

Check off Define this Policy Setting.

Select Require Signing in the drop-down box.

Require Signing

Require Signing

Click ok and accept the warning. You can follow the link to Microsft’s KB article describing what is going on.

Basically, older clients might be configured to use these unsigned binds, pretty much pre XP Pro SP2. If all of your clients are updated or using newer Windows versions, you don’t have to worry about configuring them to start signing. If you have older clients, and don’t know how to change them- you might want to leave this setting alone.

This is a good setting to change to lock down your server, and close unneccessary vulnerabilities in the path between client and server. A hacker might be able to intercept a unsigned packet and change it, then forwarding it to your server. The server would read the packet and execute actions based on the hackers unsigned packet.

As always if you break your network, it’s not my fault 🙂

%d bloggers like this: