Pages

Monday, June 17, 2013

SharePoint 2013: Event ID 6398 An update conflict has occurred, and you must re-try this action

Symptom:
You get this error in the event logs:
Log Name:      Application
Source:        Microsoft-SharePoint Products-SharePoint Foundation
Date:          6/17/2013 6:13:00 AM
Event ID:      6398
Task Category: Timer
Level:         Critical
Keywords:     
User:          DOMAIN\account
Computer:      servername.domain.com
Description:
The Execute method of job definition Microsoft.SharePoint.Diagnostics.SPDiagnosticsMetricsProvider (ID d9aa8058-e64c-49dc-9898-003cd8066c14) threw an exception. More information is included below.

An update conflict has occurred, and you must re-try this action. The object SPWebService was updated by DOMAIN\servername, in the OWSTIMER (9920) process, on machine PRDSPTWEB02.  View the tracing log for more information about the conflict.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-SharePoint Products-SharePoint Foundation" Guid="{6FB7E0CD-52E7-47DD-997A-241563931FC2}" />
    <EventID>6398</EventID>
    <Version>15</Version>
    <Level>1</Level>
    <Task>12</Task>
    <Opcode>0</Opcode>
    <Keywords>0x4000000000000000</Keywords>
    <TimeCreated SystemTime="2013-06-17T13:13:00.916213700Z" />
    <EventRecordID>62256</EventRecordID>
    <Correlation ActivityID="{1347269C-5F82-C01F-4FEA-47459A131F73}" />
    <Execution ProcessID="3024" ThreadID="1128" />
    <Channel>Application</Channel>
    <Computer>servername.domain.com</Computer>
    <Security UserID="S-1-5-21-1130582348-1049843267-782984527-44575" />
  </System>
  <EventData>
    <Data Name="string0">Microsoft.SharePoint.Diagnostics.SPDiagnosticsMetricsProvider</Data>
    <Data Name="string1">d9aa8058-e64c-49dc-9898-003cd8066c14</Data>
    <Data Name="string2">An update conflict has occurred, and you must re-try this action. The object SPWebService was updated by DOMAIN\account, in the OWSTIMER (9920) process, on machine SERVERNAME.  View the tracing log for more information about the conflict.</Data>
  </EventData>
</Event>
Issue:
(from MicroSoft) This issue occurs if the contents of the file system cache on the front-end servers are newer than the contents of the configuration database. After you perform a system recovery, you may have to manually clear the file system cache on the local server.
In my case, I deleted and recreated service applications and managed paths when getting the farm up and running.

Solution:
Stop the timer service, clear the cache, then restart the timer service.

I found http://support.microsoft.com/kb/939308 that helped me solve this. Although the only article I saw for this was referring to a 2007 installation, the fix is still valid. I corrected the references to services that are now named different and took out paths to WSS 2003 in this version:

  1. Stop the Timer service. To do this, follow these steps:
    1. Click Start, point to Administrative Tools, and then click Services.
    2. Right-click SharePoint Timer Service, and then click Stop.
    3. Close the Services console. (Do this on each front end)
  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 hidden folder
    Drive:\ProgramData\Microsoft\SharePoint\Config\GUID
    Note: There may be two folders with a GUID name in the config directory.  One has persisted files in it.  You will be working with the one that has XML files and a cache.ini file in it.
    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 ProgramData 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.
  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:
    1. Click Start, point to Administrative Tools, and then click Services.
    2. Right-click Windows SharePoint Services Timer, and then click Start.
    3. 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.
The directions in the KB article say to check the Config Refresh job in Central Administration, but I didn't find that job.  What I did do was look in the same directory and checked that the cache was rebuilt for all of the front ends.

Update:
Do I want to do this automatically with PowerShell and skip these manual steps?  Heck, yeah, I do.  Follow the instructions here:
http://sharepoint-kb.blogspot.com/2013/05/clear-sharepoint-config-cache-with.html 
Basically, I created a .ps1 file and ran it in a PowerShell command prompt.  Nice.

No comments:

Post a Comment