Symptoms:
When you try to start User Profile Synchronization (Full/Incremental) or start the "User Profile Synchronization Service" found under "Services on server" in SharePoint 2010, you receive an error
"An update conflict has occurred, and you must re-try this action. The object UserProfileApplication Name=User Profile Service Application was updated by [User]"
Full details about this error as it is logged in various places has been detailed below:
ULS:
ConcurrencyException: Old Version : 241817 New Version : 241817 99a7a04b-0297-4ecc-9621-a38b05c8ccce Microsoft.SharePoint.Administration.SPUpdatedConcurrencyException: An update conflict has occurred, and you must re-try this action. The object UserProfileApplication Name=User Profile Service Application was updated by [User], in the OWSTIMER (3456) process, on machine [Server Name]
ULS:
SharePoint Foundation Runtime Unexpected Microsoft.SharePoint.Administration.SPUpdatedConcurrencyException: An update conflict has occurred, and you must re-try this action. The object UserProfileApplication Name=User Profile Service Application was updated by [User], in the OWSTIMER (3456) process, on machine [Server Name]
Event Viewer:
The Event 6482 is logged once every minute and has the following data:
An update conflict has occurred, and you must re-try this action. The object SearchDataAccessServiceInstance was updated by [User], in the OWSTIMER (1756) process, on machine [Server Name].
Troubleshooting:
Our initial thoughts went in the direction of Active Directory. We have started investigating whether any changes have been made to the AD that may be causing the issue. After confirming that no AD changes have been made, we tried to see why it is failing using the "Microsoft Forefront Identity Manager 2010" as it provides step by step detail about what happens. The "Microsoft Forefront Identity Manager 2010" failed to start because the "User Profile Synchronization Service" and the forefront windows services (Forefront Identity Manager Service and Forefront Identity Manager Synchronization Service) were in stopped state. When we tried to start the "User Profile Synchronization Service", we got the same error detailed above.
We took the whole farm backup and investigated further.
Cause:
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.
Resolution:
To resolve this issue, clear the file system cache on all servers in the server farm on which the Windows SharePoint Services Timer service is running.
Microsoft has provided a step by step procedure on clearing file system cache from the SharePoint front-end servers in this kb article.
When you try to start User Profile Synchronization (Full/Incremental) or start the "User Profile Synchronization Service" found under "Services on server" in SharePoint 2010, you receive an error
"An update conflict has occurred, and you must re-try this action. The object UserProfileApplication Name=User Profile Service Application was updated by [User]"
Full details about this error as it is logged in various places has been detailed below:
ULS:
ConcurrencyException: Old Version : 241817 New Version : 241817 99a7a04b-0297-4ecc-9621-a38b05c8ccce Microsoft.SharePoint.Administration.SPUpdatedConcurrencyException: An update conflict has occurred, and you must re-try this action. The object UserProfileApplication Name=User Profile Service Application was updated by [User], in the OWSTIMER (3456) process, on machine [Server Name]
ULS:
SharePoint Foundation Runtime Unexpected Microsoft.SharePoint.Administration.SPUpdatedConcurrencyException: An update conflict has occurred, and you must re-try this action. The object UserProfileApplication Name=User Profile Service Application was updated by [User], in the OWSTIMER (3456) process, on machine [Server Name]
Event Viewer:
The Event 6482 is logged once every minute and has the following data:
An update conflict has occurred, and you must re-try this action. The object SearchDataAccessServiceInstance was updated by [User], in the OWSTIMER (1756) process, on machine [Server Name].
Troubleshooting:
Our initial thoughts went in the direction of Active Directory. We have started investigating whether any changes have been made to the AD that may be causing the issue. After confirming that no AD changes have been made, we tried to see why it is failing using the "Microsoft Forefront Identity Manager 2010" as it provides step by step detail about what happens. The "Microsoft Forefront Identity Manager 2010" failed to start because the "User Profile Synchronization Service" and the forefront windows services (Forefront Identity Manager Service and Forefront Identity Manager Synchronization Service) were in stopped state. When we tried to start the "User Profile Synchronization Service", we got the same error detailed above.
We took the whole farm backup and investigated further.
Cause:
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.
Resolution:
To resolve this issue, clear the file system cache on all servers in the server farm on which the Windows SharePoint Services Timer service is running.
Microsoft has provided a step by step procedure on clearing file system cache from the SharePoint front-end servers in this kb article.
- Stop the Windows SharePoint Services Timer service (Found in Windows Services)
- Navigate to the cache folder
In Windows Server 2008, the configuration cache is in the following location:
Drive:\ProgramData\Microsoft\SharePoint\Config
In Windows Server 2003, the configuration cache is in the following location:
Drive:\Documents and Settings\All Users\Application Data\Microsoft\SharePoint\Config
Locate the folder that has the file "Cache.ini"
(Note: The Application Data folder may be hidden. To view the hidden folder, change the folder options as required) - Back up the Cache.ini file.
- 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.
- Double-click the Cache.ini file.
- On the Edit menu, click Select All. On the Edit menu, click Delete. Type 1, and then click Save on the File menu. On the File menu, click Exit.
- Start the Windows SharePoint Services Timer service
- 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.
- Make sure that the Cache.ini file in the GUID folder now contains its previous value. For example, make sure that the value of the Cache.ini file is not 1.
Hi!
ReplyDeleteI've created a PowerShell script for this topic:
http://ikarstein.wordpress.com/2011/11/04/powershell-script-for-recreating-the-server-cache-related-to-error-in-windows-event-log-event-id-6482-application-server-administration-job-failed-for-service-instance-microsoft-office-server-searc/
Kind regards
Ingo