Category: Error

Running the SBS 2008 BPA, you receive a warning item that states:

The log file for the Windows SharePoint Services configuration database is larger than 1 GB in size. For information about how to reduce the size of the log file, see the Knowledge Base at

SQL Config Log Warning in BPA

SQL Config Log Warning in BPA

If you follow the link, Microsoft explains how to make a SQL script that will trim your database. My problem was that even after trimming the database, it was still over 1Gb in size- 1.4Gb actually. Let’s solve this.

This is not a permanent solution, but rather a solution to temporarily shrink the log files. They will eventually build back up- I plan to execute this plan when ever I get the warning.

Also note that doing this process will make the database temporarily “Full Recovery” only. which means that if you use differential backup and recovery, after this process takes place you can only do a full recovery untill the log files build back up over transactions.

Perform a full server backup.

Now check the size of the database.

Log into your Microsoft##SSEE Database (Windows Internal Database).

By entering \\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query as your server name. Select Windows Authentication. Click Connect.

Connect to Microsoft##SSEE

Connect to Microsoft##SSEE

You will see several databases- we will be working with the one titled Sharepoint_Config_#########.



Right click on that database and select Properties. You will see two numbers for Size and Space Available. Look at the size. Mine was 1449 Mb. I ran the Microsoft suggested SQL script, and it was still the same size. So here is what to do.

Under the options tab of the database properties, change the Recovery Model dropdown from Full to Simple. This tells SQL to truncate the log files, meaning only a full recovery is available.

Recovery Model: Simple

Recovery Model: Simple

Click Ok.

Now Run the logshrink.sql to trim the database. You can do this through a command prompt by running command:

sqlcmd -S \\.\pipe\mssql$microsoft##ssee\sql\query -E -i
You can double-click logshrink.sql. It will ask you to log in, use the same information as above. Above the window that opens, click Execute.
Execute Script

Execute Script


Now go back into the Properties of the config database, click Options, and change Recovery Model back to Full.

Trimmed Database

Trimmed Database

You should see your file size WAY smaller now, happy shrinking.

So the search service that comes with SBS 2008 is not installed by default. Desktop Search is, but not Server Search, which lets you index shared files and the like. Out of the box, WSS Search SHOULD work. In all three of my SBS set-ups, it has not worked, and this has plagued me for ages, so I finally set about fixing it today. I can’t tell you the exact reason that it is broken for me, but it is most likely caused by an update, service pack, hardware change, or just plain old incorrect permissions or WSS set-up.

First thing I did was install Windows Search Service.
Open up Server Manager, and select File System. Click Add Services on the right.
Click to check Windows Search Service.

Windows Search Service

Windows Search Service

This took about 15 minutes, and at the end an error was displayed. Closing the windows, I noticed that Windows Search Service was installed and running, and the service was also running under the Services Console.

Hrmmph. At this point I go into Sharepoint Central Administration, and Search still will not work. So now I set about making two new accounts to run the search.

I created WSS_Search, set a password, and added it to the group Administrators.

I then created WSS_Content, and added it to two groups:

SQL Accounts

SQL Accounts

These two accounts might differ from what you have. What we need is an account that has READ access to the Sharepoint Content Database. It can not be an administrator account, or a system account, though I believe it can be Local Service.

Now I tried my search and it still would not work. As a matter of fact, I could not start the search service at all now. So I go to Services Console, scrolls down to Windows Search Service. Right click it and select Properties. Make sure Local System is selected under the Log On tab. Exit out, and go to Windows Sharepoint Services Search. For this Log On, select This Account: and enter the information you used for the WSS_Search account. Change type to automatic, and click apply and start.

Log On Properties

Log On Properties

You will receive a message about the account being granted run as a service privileges.

So far all is well, though Sharepoint still wont Search. Open up Sharepoint Central Administration 3.0 under Administrative Tools.

Click Operations Tab, and then Services on Server.

Services on Server

Services on Server

Click on Windows Sharepoint Services Search.

Now fill in the fields.

  • Service account is WSS_Search, and password.
  • Content Access Account is WSS_Content and password.
  • Database server is grayed out, but should me by default np:\\.\pipe\MSSQL$Microsoft##SSEE\sql\query
  • Database name is grayed out, but it will be your Search database, such as WSS_Search_WIN-EUGSO7LO7PY
  • Authentication is whatever method you use. Default, it is Windows Authentication. This must be left alone for Microsoft##SSEE. If your database is different, configure the login that would be used to access the database.
  • You can change the time if you wish, I set mine to default every 5 minutes, as we do not have a ton of content on the server.


Click ok. Close all browsers.

Open a command prompt and type iisreset.

Restart both Windows Search and Sharepoint Search Services. Good to go- your site should now be searchable.

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.

This post has no real meaning, but I thought I would post a screen shot of this tab. For the first time in over a year and a half, this screen is all green. All computers are updates, AV and AM is working, no one shut their computer down over the weekend. Nice.

I removed the computer names to protect the identity of my users.

Green SBS

Green SBS

%d bloggers like this: