Login prompt accessing list on SharePoint site with anonymous access enabled

PROBLEM

You have a SharePoint Publishing site with anonymous access enabled. Users are able to get to most of the pages and document libraries that you have exposed via anonymous access, but you have one or more lists which stubbornly prompt the user to login.

This problem also commonly occurs on anonymous access Blog sites living under a Publishing site where users are prompted to login to post comments. That is because comments are stored in a SharePoint list and this problem is related to SharePoint lists exposed to anonymous users.

SOLUTION

Many solutions to this problem suggest disabling the Site Collection feature ViewFormPagesLockdown as this is enabled by default on Publishing sites. This is a bad idea as it exposes various pages such as /layouts/viewlsts.aspx, more commonly known as Site Contents, that you do not want to give anonymous users access to. ViewFormPagesLockdown on an anonymous site is a good thing, but it does cause us grief with lists we want to expose anonymously.

I have created a PowerShell script below that enables anonymous access on a list living under a publishing site without having to resort to disabling the ViewFormPagesLockdown feature.

####################################################################################################
#
#  Author.......: Khalid Ansari
#  Date.........: 17 Jan 2014
#  Description..: Allow anonymous access to a list in a publishing site
#                 For details of the problem this script solves go to http://wp.me/p3Cf9P-aL
#  Parameters...: [Required] SiteUrl = Url of site (not site collection, unless they are the same)
#                 [Required] ListDisplayName = Display name of list
#
####################################################################################################
param(
    [parameter(Mandatory=$true)] [string] $SiteUrl
    , [parameter(Mandatory=$true)] [string] $ListDisplayName
)

$spAssignment = Start-SPAssignment

$web = Get-SPWeb $SiteUrl -ErrorAction Stop
Write-Host -f Green "Found site $($web.Title)"
$list = $web.Lists[$ListDisplayName]
if ($list) {
	Write-Host -f Green "Found list $($list.Title)"

	$list.BreakRoleInheritance($true, $false)
	$list.AllowEveryoneViewItems = $true
	Write-Host -f Yellow "Existing permissions: $($list.AnonymousPermMask64)"
	$list.AnonymousPermMask64 = "ViewPages, OpenItems, ViewVersions, Open, UseClientIntegration, ViewFormPages, ViewListItems";
	$list.Update();
	Write-Host -f Yellow "Updated permissions.: $($list.AnonymousPermMask64)"
	Write-Host -f Green "Anonymous access enabled on list"
}
else {
	Write-Host -f Red "List $($ListDisplayName) not found"
}

$web.Dispose()
Write-Host
Write-Host "Script Completed"
Stop-SPAssignment $spAssignment

Running the script above results in output similar to that shown below:

listanonaccess01

Note that in order to enable these permissions it is necessary for the script to break permission inheritance on the list. After running the above script your list should be accessible anonymously and you didn’t have to disable the ViewFormPagesLockdown feature.

AutoSPInstaller – SharePoint Installation & Configuration Made Simple

I have completely abandoned installing and doing initial SharePoint configuration the old-fashioned hard way using a lethal mix of installers, Central Admin, PowerShell and an easily distracted mind.

I now use AutoSPInstaller from CodePlex to make all my SharePoint installation and configuration tasks a breeze. OK that is a lie because using AutoSPInstaller is also very hard as it requires you to painstakingly hand code an unforgiving XML configuration file using an IntelliSenseless tool such as Notepad.

autospinstaller02

Fortunately for us Ivan Josipovic found the time to create AutoSPInstallerGUI which makes creating the AutoSPInstaller XML files a walk in the park. Thanks Ivan!

autospinstaller03

AutoSPInstaller is a set of PowerShell scripts which use the XML configuration file to install all the SharePoint components including Service Packs, Cumulative Updates etc. The scripts will then setup the managed accounts, create and configure all the service applications, search topology, user profile synchronization, web applications, site collections and bunch of other configurations typically done on a new farm such as IIS, ULS and usage log settings, object cache accounts, email settings, etc.

Plus it sets up all the SharePoint databases using sensible naming conventions. No crazy GUID database names. It shocked me too. Crazy idea not having a GUID in the name, but somehow it works. Clearly these AutoSPInstaller guys are not destined for jobs at Microsoft.

autospinstaller01

It also allows you to do remote parallel installation and configuration of all the servers in a farm. Actually this is where AutoSPInstaller and I had a fight. Unfortunately documentation for the tool is well non-existent really. The community has put together some documentation but none of it explains how to use AutoSPInstaller to configure multiple servers in a farm. I struggled with this for quite and while and then realized I was wasting more time to get this to work then it would take me to manually configure the additional servers. This is not something I have had the time to figure out, but despite this problem AutoSPInstaller has been a huge time saver in setting up servers in a consistent manner.

Once you have created a configuration file for a farm it is easy to reuse this for other similar farms or for different environments; production, staging, QA. The configuration file can safely be re-run multiple times to fix issues or rebuild parts of the farm you may have removed. For instance you can delete a web application, site collection or a service application and re-run the script to recreate it. I also find that the configuration file acts as documentation of everything done to setup and configure a farm.

AutoSPInstaller and AutoSPInstallerGUI are huge time savers and are now part of my essential SharePoint toolkit.

Configure SharePoint outgoing email to use an SMTP server which does not listen on port 25

You just found out that the SMTP server that your SharePoint server needs to configure in the Outgoing E-Mail Settings does not listen on port 25.

The bad news is that SharePoint does not allow you to configure this. It always connects to port 25 because only the foolhardy would use an alternate port.

The good news is the steps to get around this using the SMTP service installed on to the SharePoint server have been documented by David Lozzi at Sending SharePoint emails through alternate ports

If you are using Exchange Online as your SMTP server to send emails you can follow the instructions at Step by step configuration of Outgoing Emails from SharePoint to Microsoft Online

Save time in SharePoint Central Administration

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

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”

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.