I recently encountered an issue in which documents were not routing to the Dropbox correctly. All the settings were correct. I checked Central Admin settings. I checked the site settings to make sure the Information Management Policy settings were in place (For Example: The In Place Record Management site collection feature activated, and the Content Organizer Site (not site collection) feature activated), and documents were still not moving correctly.
I would notice that the Dropbox library would register a modification, but still no documents. After further investigation, I noticed that under the Rule Managers for Information Management Policy ( Site Settings -> Content Organizer -> Rule Managers, make sure the Content Organizer feature is activated) a personal account was listed.
The personal account listed had been recently disabled, and Information Management Policy uses whatever account that is in the Rule Managers to route the documents. In this case, the personal account no longer existed. After I changed it to a service account, the routing of documents started to work.
Lesson: Rule Managers should be a service account!
Tuesday, June 7, 2016
SharePoint 2010/2013 Site Unavailable
Is your SharePoint environment going down every weekend on a schedule around 1 AM? If you have tried everything and still cannot determine why the farm continues to go down, check the recycle bin of the site that continues to go down. If it is large, manually empty it out.
For the longest I was not able to determine what was happening with the site crashing, and after investigating on the SQL side, it was noticed that there was tons of locks happening on the content database, however we needed to do further investigation as to what stored procedure was causing the main lock.
Through this we were able to determine that the main issue was the Recycle bin stored procedure. I proceeded to check the Recycle Bin, and noticed there were couple of large files. After emptying out the Recycle bin manually, SharePoint started operating as normal.
For the longest I was not able to determine what was happening with the site crashing, and after investigating on the SQL side, it was noticed that there was tons of locks happening on the content database, however we needed to do further investigation as to what stored procedure was causing the main lock.
Through this we were able to determine that the main issue was the Recycle bin stored procedure. I proceeded to check the Recycle Bin, and noticed there were couple of large files. After emptying out the Recycle bin manually, SharePoint started operating as normal.
Subscribe to:
Posts (Atom)