There's always a lesson to be learned. Such is the nature of the beast! The more we work with this wonderful product called SharePoint, the more we realize how sensitive it can be, and how wierd things just seem to "happen". I've ran into quite a few on this particular project, and decided to post this in hopes of saving others some possible heartache. If you've had errors in your event logs like these:
failure trying to synch site [SITE GUID} for ContentDB [contentdb GUID] WebApp [web app GUID]. Exception message was Access is denied. (Exception from HRESULT: 0×80070005 (E_ACCESSDENIED
or
A runtime exception was detected. Details follow. Message: Access is denied. (Exception from HRESULT: 0×80070005 (E_ACCESSDENIED))Techinal Details:System.UnauthorizedAccessException: Access is denied. (Exception from HRESULT: 0×80070005 (E_ACCESSDENIED))at Microsoft.SharePoint.SPGlobal.HandleUnauthorizedAccessException(UnauthorizedAccessException ex)at Microsoft.SharePoint.Library.SPRequest.AddField(String bstrUrl, String bstrListName, String bstrSchemaXml, Int32 grfAdd)at Microsoft.SharePoint.SPFieldCollection.AddFieldAsXmlInternal(String schemaXml, Boolean addToDefaultView, SPAddFieldOptions op)at Microsoft.SharePoint.SPFieldCollection.AddFieldAsXml(String schemaXml, Boolean addToDefaultView, SPAddFieldOptions op)at Microsoft.SharePoint.SPFieldCollection.AddFieldAsXml(String strXml)at Microsoft.SharePoint.SPFieldCollection.AddInternal(String strDisplayName, SPFieldType type, Boolean bRequired, Boolean bCompactName, Guid lookupListId, Guid lookupWebId, StringCollection choices)at Microsoft.SharePoint.SPFieldCollection.Add(String strDisplayName, SPFieldType type, Boolean bRequired, Boolean bCompactName, StringCollection choices)at Microsoft.SharePoint.SPFieldCollection.Add(String strDisplayName, SPFieldType type, Boolean bRequired)at Microsoft.Office.Server.UserProfiles.SiteSynchronizer.UserSynchronizer.TryAddFieldToUserInfoListWithInternalName(String strWSSInternalName, SPFieldType fieldType)at Microsoft.Office.Server.UserProfiles.SiteSynchronizer.UserSynchronizer.AddFieldToUserInfoList(String strProfilePropName, SPFieldType fieldType)at Microsoft.Office.Server.UserProfiles.SiteSynchronizer.UserSynchronizer.PushSchemaToList(Boolean& bAddedColumn)at Microsoft.Office.Server.UserProfiles.SiteSynchronizer.UserSynchronizer.SynchFull()at Microsoft.Office.Server.UserProfiles.SiteSynchronizer.Synch()at Microsoft.Office.Server.Diagnostics.FirstChanceHandler.ExceptionFilter(Boolean fRethrowException, TryBlock tryBlock, FilterBlock filter, CatchBlock catchBlock, FinallyBlock finallyBlock)
there's a good chance that you have a profile synchronization issue (or several). Here are the steps I took to correct these errors:
1. I downloaded a wonderful, free (yes, FREE!) utility called SharePoint Inspector, created by Gat Bouveret. His blog with a link to the codeplex download site can be found here. I used this tool to identify the web applications and sites referred to by their GUID in the event log errors.
2. I opened a command prompt and typed stsadm- o preparetomove -Site http://whatevertheguiltysiteis -OldContentDb <GUID of the contentdb listed in event log error>
3. After this completed successfully, I ran stsadm -o sync -deleteolddatabases 0 (note: Depending on how long you've been seeing these errors, you may be able to use a switch greater than zero. If it's been 2 days since it synched last, you can use 2. You can tell this by typing stsadm -o sync -listolddatabases <number of days you think> and look for the offending content db guid.
In my case, there were 4 “my site” sites that were not syncing with the profile database. After performing these steps, I rechecked the event log at the top of the hour to see if the errors had reoccurred. GONE!
A little something extra: I have also had to do this on occasions where a web application was deleted, leaving the content db intact, and re-created attaching to the same content db without first running the prepare to move command. Same steps apply.
Hope this helps!