Support for Rewrites and Redirects on SharePoint

If you use Microsoft SharePoint versions 2007, 2010 or 2013 and also use URL Rewriting techniques, you should review this Microsoft Knowledge Base article:

Supportability of Rewrite and Redirects with SharePoint 2007/2010/2013

According to the article, if you change the path of the URL (the part after the domain, e.g. /pages/home.aspx) received by IIS and send a different one to SharePoint (called asymmetrical URL rewriting in the article) you are unsupported.

If you send the same path of the URL received by IIS to SharePoint, then you run a supported scenario.

 

Why is it important? – you might ask.

It is important because when you run into issues on your implementation and you don’t find a good solution “googling” around, you might have to call Microsoft for support and their answer for you might be: “you’re running an unsupported scenario.”.

In my case, we ran into issues with AXD files not being sent to the browser by SharePoint and the issue looks to be related to both the URL rewriting and the output cache. for now we disabled the output cache as a workaround and it seems to working fine. Let’s see if we can find a good solution for this issue. I’ll probably write more about it here when we figure it out.

If you use any type of URL rewriting on SharePoint or are planning on doing it, you should this article out.

 

See you,

Amadeu.

 

 

Advertisements

Showing/Hiding the Ribbon Based on Permissions

I’ve got a task to check why the ribbon was not being displayed for a user with full control on a page on a SharePoint 2010 Publishing site.

Requirements-wise the request made total sense: the user with full control permissions on a page should be able to see the ribbon, check the page out, edit the page, check it back in and publish it. During my tests I noticed the master page had a SPSecurityTrimmedControl control around the ribbon. This control was preventing to ribbon to be shown for the user because it was configure to only show it for users with ManageWeb permissions.

<SharePoint:SPSecurityTrimmedControl
ID=”TrimRibbon”
PermissionsString=”ManageWeb”
runat=”server”>

Checking the list of SPBasePermissions values for the PermissionString property I was able to find the permission I wanted to use: EditListItems. This way all users with permissions to edit items/pages can see the ribbon.

When I changed the SPSecurityTrimmedControl control to use the EditListItems permission and published the master page, the user was still not seeing the ribbon.

After a couple of tests using different permissions, I found an article by Infowise explaining  the details of the SPSecurityTrimmedControl control and the usage of the PermissionContext property. This property controls the scope of the PermissionString property and by default is uses CurrentSite. Some of the values of the SPBasePermissions are scoped to the List or List Item.

In order to my permission check to work, I had to add the PermissionString property to the SPSecurityTrimmedControl control using the CurrentItem value:

<SharePoint:SPSecurityTrimmedControl
ID=”TrimRibbon”
PermissionsString=”EditListItems”
PermissionString=”CurrentItem”
runat=”server”>

After this change, the user was able to see the ribbon on the pages he had full control permission on and the site admins are still able to see it.

 

During my research, I also found this other article explaining a little bit more of the SPSecurityTrimmedControl control. Worth to check it out.

 

 

See you,

Amadeu.

 

URL Rewriting – Part 3: Integrating with SharePoint 2010

In this series of posts I’m going through the URL Rewriting process using the IIS URL Rewrite feature.

Check the previous posts out:
URL Rewriting – Part 1: The Basics
URL Rewriting – Part 2: Outbound Rule

On the previous posts we installed the feature and configured inbound and outbound rules using the IIS Rewriter. In this article we go further and show how to integrate the IIS URL Rewriter with a SharePoint site.

SharePoint 2010 Support for IIS URL Rewriter

If you search for IIS URL Rewriter on SharePoint you might see some articles about it not being supported on SharePoint 2010. It is kind of true but not completely. It will depend on the type of authentication your site is using. If you want to build a public internet site (anonymous authentication), you can use IIS URL Rewriter on your site with a few tweaks. If you’re building an intranet site (Windows or Claims authentication) you’re not going to be able to use IIS URL Rewriter.

When I first started trying to integrate IIS URL Rewriter and SharePoint 2010 I was building a public internet on my DEV environment and it was configured for both Windows and anonymous authentication. I noticed the anonymous part (mainly content and web part pages) worked fine but the administrative part (list management, user management and settings pages) didn’t. It would always ask me for authentication and it never had a consistent behavior. Every time I tried one of the administrative pages asked for authentication.

Installation

You should install the IIS Rewrite feature on all SharePoint WFE servers. The installation on SharePoint uses the very same process described on the first part of the series.

Tweaks for SharePoint 2010

Disable the LogRewrittenUrlEnabled property

On the WFE servers execute the following command:
reg add HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\InetStp\Rewrite /v LogRewrittenUrlEnabled /t REG_DWORD /d 0


Edit the web.config file

Add the following node under configuration/system.webServer in order to change compression settings:

<urlCompression doStaticCompression=”false” doDynamicCompression=”true” dynamicCompressionBeforeCache=”false” />

Restart IIS

Execute an IISRESET command on all WFE servers.

Testing Inbound and Outbound Rules

Edit the web.config file for your site on all WFE servers.

Add a new inbound and outbound rules to test on your site. Here is a simple example you can add to your web.config under the configuration/system.webServer node:

<rewrite>
  <rules>
    <rule name="Home Page Rewrite" stopProcessing="true">
      <match url="^(/$|$)" />
      <action type="Rewrite" url="/pages/default.aspx" />
    </rule>
  </rules>
  <outboundRules>
    <rule name="Home Page Outbound Rewrite" stopProcessing="true">
      <match filterByTags="A, Link" pattern="(/?)pages/default\.aspx$" />
      <conditions>
        <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
      </conditions>
      <action type="Rewrite" value="{R:1}" />
    </rule>
  </outboundRules>
</rewrite>

These rules will remove the home page redirect from the browser’s address bar and rebuild all the links to the home page to point to /.

References

http://codeblog.shawson.co.uk/iis7-urlrewrite-outbound-links-with-compression-enabled/

http://blogs.msdn.com/b/danielvl/archive/2010/01/07/registry-values-for-iis-url-rewrite.aspx

On the next articles of this series we will talk about custom IIS Rewriter providers and how to implement them.

See you,

Amadeu.

Retrieve a List of All Items Checked Out in a Site using Powershell

Hi there!

This is a scripts to list files which are currently checked out on a site collection. Some times users check files out and forget to check them back in. It was based on a script found at http://www.thorntontechnical.com/tech/powershell-tech/powershell-tip-find-all-checked-out-files.

$webAppURL = "http://yourwebapplication.com" 

function ReportCheckedOutItems() {
	$webapp = Get-SPWebApplication $webAppURL

	foreach ($site in $webapp.Sites) 
	{
		write-host "Site Collection: $($site.Url)"
		$allwebs = $site.allwebs
		foreach($web in $allwebs)
		{
			$count = 0
			write-host "--Site: $($web.Url)"
			foreach ($list in ($web.Lists | ? {$_ -is [Microsoft.SharePoint.SPDocumentLibrary]})) {
				Write-Host "-----List: $($list.RootFolder.ServerRelativeUrl)..."
				foreach ($item in $list.CheckedOutFiles) 
				{
					if (!$item.Url.EndsWith(".aspx")) 
					{ 
						continue 
					}
					write-host "File: $($item.Url) - checked out by $($item.CheckedOutBy)" -ForeGroundColor Red
					$count++
				}
				foreach ($item in $list.Items) 
				{
					if ($item.File.CheckOutStatus -ne "None") 
					{
						if (($list.CheckedOutFiles | where {$_.ListItemId -eq $item.ID}) -ne $null) 
						{ 
							continue 
						}
						write-host "File: $($item.Url) - checked out by $($item.CheckedOutBy)" -ForeGroundColor Red
						$count++
					}
				}
			}
			if ($count -gt 0)
			{
				write-host "Found $count checked out files for site $web" -ForeGroundColor Red
			}
		}
	}
}

ReportCheckedOutItems

 

You can download the script file here

I hope it is useful for you as it is for me.

 

See you,

Amadeu.

Permissions to Administer SharePoint 2010

I’ve been reading some articles on how to set a user up as a SharePoint Administrator and noticed there is no consensus on which should be the steps to achieve it.

In our environment we follow these steps:

  • Add as local admin to the servers on the farm
  • Add to the farm administrators group
  • Add as powershell admin using the command: add-spshelladmin -username domain\user
  • Add user as DB_OWNER to the Config and to the content databases

See you,

Amadeu.

SharePoint 2010 Error Creating Sub-Sites: Unexpected error in Silverlight Application

If you see an “unexpected error in Silverlight application” error message when trying to create new sub-sites or other items on a SharePoint 2010 you need to check the web page security validation on your web application. Probably it is set to Off.

 

To change it:

  • Go to Central Administration.
  • Go to Application Management > Manage Web Applications.
  • Select the web application with the issue and click General Settings on the ribbon.
  • Change the Web Page Security Validation from Off to On.
  • Click OK to close the dialog.

Test the sub-site creation and the Silverlight should work just fine.

 

See you,

Amadeu.

Object Cache User Accounts and the ‘User does not exist or is not unique’ Error Message

Hi all.

SharePoint 2010 uses a cache to power publishing pages and web parts to reduce the load on the SQL Server databases, the latency and increase the throughput. In order to take advantage of this feature we need to configure the object cache user accounts: Portal Super User and Portal Super Reader.

The script to configure it is quite simple:

$wa = Get-SPWebApplication -Identity "http://yourwebapplicationurl.com"
$wa.Properties["portalsuperuseraccount"] = "SuperUser"
$wa.Properties["portalsuperreaderaccount"] = "SuperReader"
$wa.Update()

The trick part is what should be provided as the user names.

If you use Classic Mode Authentication you need to use the format DOMAIN\Username.

If you use Claims Based Authentication you need to use the format i:0#.w|DOMAIN\Username.

 

If you don’t specify a valid user name in the valid format you should see the following error message:

The user does not exist or is not unique.

 

This is a very generic error message but I was able to find the explanation on how to solve it on the post “SharePoint 2010: The user does not exist or is not unique“.

 

See you,

Amadeu.