Monday, 5 November 2018

SharePoint 2013 ::: Event ID 6482 ::: An update conflict has occured

Hi all,

Today, I'm facing with Event ID 6482, indicating that the job is failing due to an update conflict.



The resolution for this issue is to delete ALL .xml files where the mentioned file is located.


1. Finding the filename:
The first line give the file name of the .xml file to find. The name is located into the brackets at the end of the line:
service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance (a5744ce1-d592-42fc-a081-82188cbee126).

2. Stop the "SharePoint Timer Service"

3. Browse on each servers of your farm to this path:
C:\ProgramData\Microsoft\SharePoint\Config

4. Delete all .xml files present into the folder where .xml files are located (the other folder does contain  ".PERSISTEDFILES" : do not toutch them)

5. Edit the file "Cache.ini", and write down the number "1"

6. Save the "Cache.ini" file

7. Repeat steps 2 to 6 on each servers of your farm

8. Restart the "SharePoint Timer Service" on each servers of your farm.

9. Check that all cache files are automatically recreated.

10. Check that the file "Cache.ini" contains another number then "1"



==> Problem solved.




Voilà,


That’s all Folks !!

Tuesday, 23 October 2018

SharePoint 2013 ::: .NET Server Error ::: Event ID 1023


Hi all,

Today, I'm checking one of my Farms, in my test environment, and while opening Central Administration site, I was faced to this nice Runtime Error:




Following this discover, I've tested to access to the Farm via PowerShell commands.

- First, let's load the SharePoint snapin:
          add-pssnapin Microsoft.SharePoint.PowerShell
     ==> no errors, ths it means that my farm isn't broken.

- Secondly, let's check the Farm version:
     ==> (Get-SPFarm).buildversion

Major  Minor  Build  Revision
-----  -----  -----  --------
15     0      4957   1000   


Ok, defenitely, it is not a SharePoint Farm issue.

Then, I saw some .NET Runtime (Event ID 1023) errors in the Event Viewer.
After googleling a little bit, I found the solution explained by Bryan Peters in this post.

I've made the exactly same procedure, on my both servers, and the Farm is back to live.

Create a new DWORD, followed by an IIS Reset:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework
New registry DWORD : LoaderOptimization
Value : 1
IIS Reset


==> Problem solved.




Voilà,


That’s all Folks !!