Access Denied while creating Publishing Pages


I ran into one of those weird errors that just kind of gets under your skin because you think you’ve checked everything.

You’ve all seen Access Denied errors in SharePoint, but have you run into the one where users WITH proper permissions get it when trying to create a list item – in this case Publishing Pages? Very bizarre.

I checked all of the usual suspects, permission inheritance, draft items in Style Library, Master Page Gallery, etc. Nothing. But then when I reached out to the search engines just for giggles, I found this post by Gunnar Peipman which gave me exactly what I needed.

The permissions on the Master Page Gallery are unique, and users need at least “Restricted Read” to create pages. What’s frustrating is if you go into Site Permissions and view the Uniquely Secured Content, Master Page Gallery DOES NOT show up in that list. You’d think it would show you all uniquely secured content, but that’s not the case.

Thanks Gunnar for the short post with the fix!

1.Go to Site Actions -> Site Settings ->Modify all site settings
2.Go to Galleries -> Master pages and page layouts
3.From the list toolbar, select Settings -> Document library settings
4.Select permissions for this document library
5.Add ‘Restricted Read’ access to the required groups.

Retrieve SharePoint Groups using PowerShell


Disclaimer: This post and function is 100% taken from the book by Gary Lapointe and Shannon Bray entitled “Automating Microsoft SharePoint 2010 Administration with Windows PowerShell 2.0.”

As I frequently do when I’m looking for a topic to blog about, I reach for my favorite tool – PowerShell. Over the weekend I was reading some of the aforementioned book and I came across a set of tasks which do not have corresponding cmdlets out-of-the-box.

There are a set of functions described in Chapter 8 – Managing Site Collections and Sites which can be created and used to manage SharePoint Groups. There are 3 functions: Get-SPGroup, New-SPGroup and Remove-SPGroup. This post will only focus on the first and easiest, Get-SPGroup.

The Get-SPGroup function is pretty simple, and other than my obligatory comment-based help (which accounts for 23 of the 33 lines 🙂 ) – this function is very short.

Essentially all it’s doing is obtaining the SiteGroups collection property from an SPWeb object and returning the information on the property.

Here’s the function:

function Get-SPGroup {
<#
.Synopsis
	Use Get-SPGroup to retrieve a SharePoint Group.
.Description
	This function uses the SiteGroups collection property of an SPWeb object to return a specific group and its properties.
.Example
	C:\PS>Get-SPGroup -Web http://intranet -Group "Members"
	This example retrieves the properties of the "Members" group in the http://intranet site.
.Notes
	Name: Get-SPGroup
	Author: Ryan Dennis
	Last Edit: July 18th 2011
	Keywords: Get-SPGroup
.Link
	http://www.sharepointryan.com
 	http://twitter.com/SharePointRyan
.Inputs
	None
.Outputs
	None
#Requires -Version 2.0
#>
	[CmdletBinding()]
	Param(
	[Microsoft.SharePoint.PowerShell.SPWebPipeBind]$Web,
	[string]$Group
	)
$SPWeb = $Web.Read()
$SPGroup = $SPWeb.SiteGroups[$Group]
$SPWeb.Dispose()
return $SPGroup
}

I’ll soon be posting the other two functions…

RD

Access Denied (401) on SharePoint 2010 Sites


I came across a weird error today, site collections which were working great just last week are now giving Access Denied errors. Surely I have access, I’m using the System Account… So I tried the normal things like trying to go straight to http://myintranet/_layouts/settings.aspx, etc but to no avail.

After some log reading and searching, I came across this Technet Post which triggered my memory. I was getting the SuperUser Cache warning in my Health Analyzer, so I created a domain account (DOMAIN\SPCache) and configured it to be the super user cache account. Great I thought at the time, warnings now gone, cache working, awesome… Not so awesome, this super user account needs Full Control to the Web Application(s) which it caches.

Not a big deal, I added the account to the Web Application User Policy with Full Control and Voila!; the sites are now back to normal. Whew!

SharePoint/Office Integration “Gotchas”


While testing with a domain test account, I discovered an interesting issue/bug/feature with Office and SharePoint integration.

Using the domain account with “Restricted Reader” permissions, I navigated to a SharePoint Document Library and clicked the document icon to open in Word.

Word launched as expected with the yellow “You must checkout this document” warning/dialog. Seems normal and in fact it is, however clicking the “Check out” button as a restricted reader should NOT allow you to check the document out. It did. Initially this seems like a bug, but after some trial, error and thought; it’s not.

Issue: I logged onto the SharePoint site as the test user, however I’m logged into the MACHINE as DOMAIN\Username. Word thinks of us as who we are logged into the machine as, NOT who we’re logged into SharePoint as.

Resolution: To accurately test things like this, it is highly recommended to log onto the machine with the test account that you intend to use. This will prevent issues like this, and your test will be more accurate.