SharePoint 2010 Event ID 6482, oh the joy!

On October 7, 2011, in Ramblings, by IceaTronic

So, after banging my head against a wall for a few hours trying to figure out why the User Profile Synchronization Service was misbehaving on a clients farm i was able to nut it out to one of two problems. The first of which being solved by a re provision of the UPSS via power shell, which then lead me to this error being spat into Event Viewer:

SharePoint 2010 Event ID 6482 Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance

After quite a bit of Google-Fu and 4 of the strongest coffees i could find, I stumbled across this post from Jeff DeVerter. Basically, what I was seeing in Event Viewer was the following error being displayed roughly every minute or there abouts:

Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance (b03825bc-a4ea-4eba-ae1f-65aebe37215a).
Reason: An update conflict has occurred, and you must re-try this action. The object SearchDataAccessServiceInstance was updated by DOMAIN\user, in the OWSTIMER (13896) process, on machine SHAREPOINTSERVER. View the tracing log for more information about the conflict.
Technical Support Details:
Microsoft.SharePoint.Administration.SPUpdatedConcurrencyException: An update conflict has occurred, and you must re-try this action. The object SearchDataAccessServiceInstance was updated by DOMAIN\user, in the OWSTIMER (13896) process, on machine SHAREPOINTSERVER. View the tracing log for more information about the conflict.
at Microsoft.Office.Server.Search.Administration.SearchServiceInstance.Synchronize()
at Microsoft.Office.Server.Administration.ApplicationServerJob.ProvisionLocalSharedServiceInstances(Boolean isAdministrationServiceJob)

As I said, there was a very large amount of head banging and coffee consumption used to try and resolve this issue. With thanks to Jeff over at www.social-point.com I was able to follow these step to resolve the issue:

  1. Stop the Windows SharePoint Services Timer service (Found in Windows Services)
  2. Navigate to the cache folder
  3. In Windows Server 2008, the configuration cache is in the following location:
  4. Drive:\ProgramData\Microsoft\SharePoint\Config
  5. Locate the folder that has the file “Cache.ini”
  6. Back up the Cache.ini file.
  7. 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.
  8. 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.
  9. Double-click the Cache.ini file.
  10. Select the entire contents of the Cache.ini file and delete it, replacing all the text with the number ‘1’. Save the file and close
  11. Start the Windows SharePoint Services Timer service
  12. 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.
  13. 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.
In the case of step 13 for my self, I checked the Cache.ini file and saw that it had been updated with a new value greater than the one that was previously there, so I did not have to re-copy the data across from the backup.
Other than that, this worked perfectly for me and after about 2-3 minutes the errors stopped appearing in Event Viewer, which made me a happy chappy and as such i celebrated with another coffee 😀
Never the less, this turned out to be a relatively simple solution for seemed like an impossible error. Once again, thanks go to Jeff over at www.social-point.com for the fix for this one!
IceaTronic

Scheduled and Automated SharePoint 2010 Backups

On January 17, 2011, in Tech Tips, by Michael

With all the happenings with in the SharePoint Multiverse, I needed to come up with a method to perform a SharePoint Farm Backup on a scheduled basis.

To perform this function, i have found a nifty feature within the SharePoint Powershell console which will perform full and incremental backups of a SharePoint Farm and allow you to dictate where these backups are then placed.

The script it self is fairly straight forward and looks something like this:

Add-PSSnapin Microsoft.SharePoint.PowerShell
backup-spfarm -directory “(local directory or UNC path)” -backupmethod full

Within the script you can also substitute out the ‘full’ option for an ‘incremental’ as well. Save the script some where easy to remember such as’ C:\Scripts’

What i have ended up doing, is putting this in power shell script and naming is sharepoint_farm_full_backup.ps1. From here, i have then created a simple 3 line batch file which then calls powershell and the script:

@echo off
powershell C:\scripts\sharepoint_backup_full

end

Save this in the same folder as the PowerShell scripts that you created as something to indicate that this will launch the full backup, say’ full_backup_launch.bat’.

Then you need to configure the Scheduled Task to run. This is a fairly straight forward step, with one gotcha that ive found. Ill explain in a moment.

First, you need to create your New Scheduled Task. Name it something logical, ‘SharePoint Farm Full Backup’. Make sure that you run the task  as some one that has sufficient privileges over your SharePoint Farm. When on the account details page, MAKE SURE that you tick ‘Run with highest privileges’ to ensure that the account calls its ‘Admin’ counterpart to run the script for you. In the actions page, tell the task to look at the batch file that youve created.

When done, set up your schedule and away you go!

Tagged with: