***Update: If this doesn't solve your problem, try the following.
We recently started to get the following application event log error:
Because it was a test environment we went ahead and reset the search index and restrated the search application, but the errors kept coming back.
The fix was to reset the cache on alll four servers in the farm. Once we did that the errors disappeared. To see directions on resetting the cache, have a look at the directions below, or go to http://support.microsoft.com/kb/939308
***Note*** Complete these steps on any server running the SharePoint Timer Service in the farm.
1.Stop the Timer service. To do this, follow these steps:
•Click Start, point to Administrative Tools, and then click Services.
•Right-click Windows SharePoint Services Timer, and then click Stop.
•Close the Services console.
2.On the computer that is running Microsoft Office SharePoint Server 2007 and on which the Central Administration site is hosted, click Start, click Run, type explorer, and then press ENTER.
3.In Windows Explorer, locate and then double-click the following folder:
Drive:\Documents and Settings\All Users\Application Data\Microsoft\SharePoint\Config\GUID
Notes
◦The Drive placeholder specifies the letter of the drive on which Windows is installed. By default, Windows is installed on drive C.
◦The GUID placeholder specifies the GUID folder.
◦The Application Data folder may be hidden. To view the hidden folder, follow these steps:
1.On the Tools menu, click Folder Options.
2.Click the View tab.
3.In the Advanced settings list, click Show hidden files and folders under Hidden files and folders, and then click OK.
◦In Windows Server 2008, the configuration cache is in the following location:
Drive:\ProgramData\Microsoft\SharePoint\Config\GUID
4.Back up the Cache.ini file.
5.Delete all the XML configuration files in the GUID folder. Do this so that you can verify that the GUID folder is replaced by new XML configuration files when the cache is rebuilt.
Note When you empty the configuration cache in the GUID folder, make sure that you do not delete the GUID folder and the Cache.ini file that is located in the GUID folder.
6.Double-click the Cache.ini file.
7.On the Edit menu, click Select All.
8.On the Edit menu, click Delete.
9.Type 1, and then click Save on the File menu.
10.On the File menu, click Exit.
11.Start the Timer service. To do this, follow these steps:
•Click Start, point to Administrative Tools, and then click Services.
•Right-click Windows SharePoint Services Timer, and then click Start.
•Close the Services console.
Note The file system cache is re-created after you perform this procedure. Make sure that you perform this procedure on all servers in the server farm.
12. Make sure that the Cache.ini file has been updated. For example it should no longer be 1 if the cache has been updated.
13.Click Start, point to Programs, point to Administrative Tools, and then click SharePoint 3.0 Central Administration.
14.Click the Operations tab, and then click Timer job status under Global Configuration.
15.In the list of timer jobs, verify that the status of the Config Refresh entry is Succeeded.
16.On the File menu, click Close.
Friday, June 28, 2013
SharePoint 2010 Event ID 6482 - Part 2
This is a follow up to an earlier blog post we wrote. In that case, clearing the SharePoint cache on all the servers in the farm did the trick. We recently saw the 6482 event log error again and tried clearing the cache, but this time it didn't work.
What else was going on?
What else was going on?
- We had just migrated the SharePoint databases from SQL 2008 to SQL 2012.
- Looking at the services on the search server, the SharePoint Server Search 14 service would fail starting up.
- When we tried to do anything in Application Management - Manage Service Applications - Search Service Application (ex: look at content sources, crawl log, crawl rules, etc...) it would generate a SharePoint error with a correlation ID.
How did we fix it?
After scouring the Internet, we found someone who got the search app running again by adding the service account used to run the search application to the local admin group on the server. Once we did that, we were able to start the SharePoint Server Search 14 service through the services interface. Once it was going, we simply removed the account from the admin group.
Subscribe to:
Posts (Atom)