Category Archives: SharePoint 2013

Save time in SharePoint Central Administration

Posted on by
1

Here are a couple of things I like to do in the SharePoint Central Administration site which claw back a few seconds of my life so that I have time to write blog posts.

First, after every Cumulative Update applied to the farm I go to the Site Settings > Look and Feel > Title, description, and logo and change the description of the site to include the current patch level and build number

centraladmin02

centraladmin03

I always know which version the farm is patched to and it saves me from having to look up Todd Klindt’s SharePoint 2013 Build Numbers to figure out that 15.0.4505.1005 is Apr 2013 CU.

Second, I add links to the Resources section on the right to frequently used pages. That way I can go there with one click instead of having to hunt through the Service Applications list.

centraladmin01

I know these are simple things, but I am always surprised by how many clicks SharePoint administrators are willing to go through to get where they want. Maybe they think it is a penance they have to pay for using SharePoint. Forgive yourself and as a bonus conserve energy by reducing your click count 😉

SharePoint minimum hardware requirements increase hard disk size

Posted on by
Reply

Every SharePoint environment I come across has the following Health Analyzer warning about drives running out of free space:

Title

 Drives are at risk of running out of free space.

Severity

 2 – Warning

Category

 Availability

Explanation
Available drive space is less than five times the value of physical memory. This is dangerous because it does not provide enough room for a full memory dump with continued operation. It also could cause problems with the Virtual Memory swap file: (SERVERNAME – C:).

Remedy
Examine the failing servers and delete old logs or free space on the drives. For more information about this rule, see “http://go.microsoft.com/fwlink/?LinkID=142688“.

Failing Servers
SERVERNAME

Failing Services
SPTimerService (SPTimerV4)

Rule Settings

 View


This happens because without fail every customer is told to setup their server’s system hard drive as an 80 GB drive. Microsoft recommends it and we know they are always spot on with their advice 😉

So why do we get the warning? Well let’s assume we are running a server with 16 GB of memory. 5 x 16 GB = 80 GB so we should be good, except the warning says we need 80 GB of available space. Last time I checked the operating system needed more than zero bytes, a heck of a lot more.

So let’s stop telling our customers that they need an 80 GB drive and start telling them they need a 160 GB drive which seems much more realistic, even for a server with 24 GB of RAM. When was the last time you skimped on the RAM or CPU cores? Never, but when it comes to the lowly hard drive 80 GB is plenty. NO IT IS NOT! Size matters. You have been warned [repeatedly].

SharePoint “We hit a snag”

Posted on by
7

PROBLEM

Click on a site link in the Sites I’m following section and get the message “We hit a snag. This link doesn’t work anymore, likely because the item was moved or deleted. You might have luck searching for it and following it in its new location”.

SOLUTION

Ensure that the application pool service account that your My Sites are running under have SPDataAccess permissions on the content database that contains the site whose link you clicked on.

FURTHER DETAILS

I followed a site in SharePoint 2013, then went to the Sites page and clicked on the site link in the Sites I’m following section and got the message “We hit a snag. This link doesn’t work anymore, likely because the item was moved or deleted. You might have luck searching for it and following it in its new location”

Snag01

I was able to copy the link and open it another browser tab successfully so it hasn’t moved or been deleted. So technically “we” didn’t hit a snag, “you” SharePoint hit a snag and took me along for the bumpy ride.

Even with the diagnostic logging levels turned up to verbose for everything I could not find any indication of a problem in the trace or event logs. I am not sure if this is just my development environment suffering from this lack of verbosity or this is something more widespread. I suspect the latter as I was not able to find anything in the logs at a customer’s farm suffering from the same snag. I finally tracked down the issue thanks to Derek Campanile.

My Portal web application and MySite Host web application use different service accounts for the application pools in IIS as ideally they should do.

Snag02

It seems that when you click on the link in Sites I’m following SharePoint tries to access the content database that the site is stored in. When I checked in SQL Server for the My Sites service account…

Snag03

…I found that the service account did not have permissions to access to the content database

Snag04

I gave the service account SPDataAccess permissions…

Snag05

…and was able to successfully click on the link to my followed site.

This means that every time you add a new content database to your farm you must manually go and assign SPDataAccess permissions to the My Sites application pool service account assuming you are following best practice and using a different service account.

I’m sure Microsoft has a good reason for complicating things for the lowly SharePoint administrator, but I can’t imagine what it is right now.