Clearing SharePoint’s Cache

Just a reminder for everyone here are the steps for clearing SharePoint’s Cache:

  1. Stop Windows SharePoint Services Timer service on every server in the farm (found in Windows Services)
  2. Navigate the Cache folder C:\ProgramData\Microsoft\SharePoint\Config
  3. You will see a couple of folders with GUIDs for names, locate the one that contains the “Cache.ini” file
    Note: If you cannot see the ProgramData folder you may need to make the appropriate folder option changes to see system/hidden folders.
  4. Backup all the xml files and cache.ini file contained in the GUID folder¬†because you never know ūüôā
  5. Delete all the xml files (Do Not delete the Cache.ini file!)
  6. Edit the Cache.ini file and delete its entire contents and enter the number 1 then save and exit.
  7. Start the Windows SharePoint Services Timer Service.

Remember this needs to be done on all the servers. It is a good way to refresh any of your timer jobs if you are recieving errors in the event logs or if some of the services are not acting as expected.



PowerShell to determine SharePoint User Permissions

I came across a great post by Aptillon for using PowerShell to determine who has access to what at a SiteCollection:

The custom function (Get-SPUserEffectivePermissions) was great for determining access people have on sites that do not inherit permissions from the parent site.

It could even generate a report across the farm for all items:

PS C:\>$user = "domain\username"
PS C:\>Get-SPSite -Limit All | Get-SPWeb | %{$_.Lists | %{$_.Items | Get-SPUserEffectivePermissions $user}} | Export-Csv -NoTypeInformation -Path C:\report.csv

Check it out as it was a very helpful tool.

PowerShell to Determine which SiteCollections Exists on a Particular Content Database

Hey Guys,

I found this little PowerShell command handy when trying to figure out which sites were on a particular Content DB. Was much easier than browsing every site.

PS C:\> $db = Get-SPContentDatabase -Identity "ContentDB"
PS C:\> Get-SPSite -Limit All | Where-Object{$_.ContentDatabase -eq $db}

Next if you wanted to find out how much space each of these sites were taking up you could do the following. Please Note that I broke each pipeline “|” up to the next line.

PS C:\> $db = Get-SPContentDatabase -Identity "ContentDB"
PS C:\> Get-SPSite -Limit All | 
>> Where-Object{$_.ContentDatabase -eq $db}| 
>> Select-Object URL, @{Label="Size"; Expression={$_.Usage.Storage / 1073741824}} | 
>> Export-Csv -NoTypeInformation -Path "C:\site_sizes.csv"

Hope you found this helpful

User can’t access SharePoint site after granting appropriate permissions

We have been having an issue with a couple of users in which a site admin would grant them access to either a subsite or a document library. But when the user tries to access the location they recieve the standard SharePoint Page stating current user does not have access. So what was going on, if we just granted them access?

It turned out these users that were having problems were either contractors/summer students/interns. All people who have been here in the past but had their Active Directory account temporarily disabled. This in turn must have set a flag on the SharePoint sites in which the users previously had access to from past positions, that their accounts were disabled.

The fix:¬†was to go through the site collection and remove the user from all locations that they had had¬†access. Once they were fully removed everywhere on the site collection we had to go back through and re-add them. Once they have been re-added to the site collection they still maintained the incorrect user information i.e. Title, Name, etc…¬†This information is stored in a hidden User Information¬†List on site collections: http://<SiteCollectionUrl>/_catalogs/users/detail.aspx. The user information list needs to be synced up by running the appropriate User Profile Service Aplication Proxy timer jobs:

“User Profile Service Application Proxy – User Profile to SharePoint Full
“User Profile Service Application Proxy – User Profile to SharePoint Quick

Generally these jobs are scheduled to run every hour and every couple of minutes respectively, so you may not need to run them immediately and could just wait for the next run time. Once they have run you should see the user information updated and the users should be able to access the sites now.

A real handy tool was to use the Check Permissions tab in the permissions ribbon as well as the powershell script developed by Aptillon

*Update: It appears this fix also works for the case of past users with the same username as new hires. i.e. Bob Dole (username: Bdole) leaves the company and Bill Dole (username: Bdole) joins the company. Bill would run into problems when trying to access a site as it would resolve him as Bob. The fix above resolves this.

Hope you found this helpful

SharePoint search not working for a subsite of a site collection

The other day we were having some issues with search on a user’s subsite. For some reason SharePoint Search was not crawling this one subsite but was crawling the rest of the parent site collection.

I checked the crawl logs and found that the url for the subsite was generating the following error: “The SharePoint item being crawled returned an error when attempting to download the item.”

I was doing some searching on this error message but it appears to be a¬†very vague/generic search error. I then checked the SharePoint¬†Diagnostic logs and found the following error message at the same time as the crawl log error: “CSTS3Accessor::Init: SharePointError found in URL http://Server/sites/SiteCollection/Subsite header value 0, hr=8004FD0F¬† [sts3acc.cxx:584]¬† d:\office\source\search\native\gather\protocols\sts3\sts3acc.cxx”

Again there wasn’t much out there for these messages. So I thought I was stuck. A colleague of mine suggested I try the following options:
1. In the crawl log I selected the item which was erroring out and chose recrawl this item in next crawl and ran an incremental.
2. The site was still using 2007 template so I performed a visual upgrade and ran an incremental crawl.
3. I set a rule to exclude the default.aspx page from being crawled and ran an incremental crawl.

After trying these 3 steps, SharePoint search worked again for the subsite and is able to pickup items in document libraries and lists. Unfortunately I am still recieving the errors in the SharePoint Diagnostic Logs and crawl logs.

I hope some people may find this somewhat helpful, and if they know how to make those error messages stop please feel free to leave a comment.