SharePoint Blues

SharePoint Certificate errors

2012-01-09T11:14:01Z

This article introduces some tools and practices that I’ve seen useful for tackling SharePoint 2010 errors arising from SSL Certificates. The main reason for writing this article is the “The root of the certificate chain is not a trusted root authority” – error.

Let’s first take a look at a useful tool for solving certificate errors. Windows has built in a very good SSL certificate error log called CAPI2. This can be enabled under Application and Services Logs -> Microsoft -> CAPI2 by left clicking “Operational” and pressing “Enable Log”.

Two most common errors in CAPI2 log seems to be errors in Certification Revocation Lists (CRL) and untrusted root certificate chains. Let’s take a look at how one could solve these problems.

Certificate revocation list errors
To make sure that the SSL certificates are valid windows checks for CRL. By default it will try to access this list for 15 seconds. If the list cannot be accessed the process is continued normally.
In SharePoint CRL problems may occur for example as long loading times (especially if the page is not used frequently), broken functionalities, etc.
CRL access errors can be solved by a few quite easy steps:
1. In CAPI2 open error event in Details / XML view and find what CRL (Certificate Revocation List) URL the server is trying to access.
2. You basically have two options for solving this:

a. Enable access to the CRL address
b. Disable certificate revocation list check (not recommended) How to Disable CRL Checking

Untrusted root authority or broken certificate chain error in SharePoint
1.Let’s first make sure that you have the proper error.

a. Open Management console and add certificate snap in.
b. Expand Certificates -> SharePoint -> Certificates and open one of the certificates included in that folder.
c. On the Certification Path -tab should look like as in the following figure.

2. OK, so let’s fix this problem. The problem by the way is that these certificates are issued by a certificate authority which is not trusted.

a. First we must export the root certificate from SharePoint by using the following PowerShell commands:
($rootCert = (Get-SPCertificateAuthority).RootCertificate
$rootCert.Export("Cert") | Set-Content C:\ConsumingFarmRoot.cer -Encoding byte
b. Then import the SharePoint root certificate to trusted root authorities

3. If all went well the certificates under SharePoint certificate store should look like in the following figure.

Allthought we have focused on SharePoint 2010 in this blog post these tools and practices can alse been applied for many other software running on Windows platform.

Anonymous Access and Publishing Web Pages List

2011-12-22T12:57:10Z

As You know, using PublishingWeb.GetPublishingWeb(web) method causes Access Denied exception for anonymous users. You will also get the same exception if you try to access the PublishingWeb.GetPagesListId(web) or PublishingWeb.GetPagesListName(web) methods.
There are solutions here and here and in many other blogs. These solutions use SPSecurity.RunWithElevatedPrivileges, but that’s not ideal solution for anonymous sites.
So how to get pages list from a web, if you don’t even know if the web is publishing site and you are not able to use PublishingWeb.IsPublishingWeb(web)?
Heres yet another solution. Open the web you want to check if it is a publishing site and try to get the pages list using TryGetList method with the right localized pages list name. You will get the localized name from cmscore.resx file using SPUtility.GetLocalizedString method with resource key “List_Pages_UrlName”.

var pages = web.Lists.TryGetList(SPUtility.GetLocalizedString(
string.Format("$Resources:{0}", "List_Pages_UrlName"),
"cmscore", web.Language));

if (pages != null)
{
// do the do
}

It all gets interesting, if the site is not publishing web, but still contain a list called “Pages”. Then You might want to check another things from returned list, not just if it’s null like in the snippet above.

***********************************************
Jerry Seinfeld: Why not? We’re neighbors. What’s mine is yours.
Cosmo Kramer: [leaning against the door-frame and looking around in wonder] Really?
***********************************************

Remove Keys From PropertyBag on FeatureDeactivating Override

2011-12-13T12:25:09Z

You can add keys to spweb propertybag trough a feature using CAML:

version="1.0" encoding="utf-8"?>
xmlns="http://schemas.microsoft.com/sharepoint/">
ParentType="Web" RootWebOnly="False">
Name="MyCustomProperty"
Type="string" Value="MyValue" />
>
>

The property is written to SPWebs AllProperties propertybag. When you deactivate the feature, it does not remove the keys.
If you want to remove the keys when deactivating the feature, add Event Receiver to your Feature and the following code to the FeatureDeactivating override.

public override void FeatureDeactivating(SPFeatureReceiverProperties properties)
{
var web = (SPWeb)properties.Feature.Parent;
var allowUnsafeUpdates = web.AllowUnsafeUpdates;
var elementDefinitions = properties.Definition.GetElementDefinitions(CultureInfo.CurrentCulture);

foreach (var n in from SPElementDefinition elementDefinition in elementDefinitions
where elementDefinition.ElementType == "PropertyBag"
select elementDefinition.XmlDefinition into xml
where xml.Attributes != null && xml.Attributes["ParentType"].Value == "Web"
from n in
(from XmlNode xNode in xml
let xmlAttributeCollection = xNode.Attributes
where xmlAttributeCollection != null
select xmlAttributeCollection["Name"])
select n)
{
web.AllProperties.Remove(n.Value);
web.Update();
}
web.AllowUnsafeUpdates = allowUnsafeUpdates;
web.Update();
}

This sample only removes the keys, if the propertybag ParentType is “Web”, which means the key will be written to SPWebs AllProperties propertybag.

SPList’s Title Property & SPField’s DisplayName not Updating

2011-11-21T19:48:08Z

We encountered a problem which seemed really strange while provisioning our site collection with PowerShell (New-SPSite). Our provisioning contains programmatic custom list creation to our publishing webs via feature receivers. The procedure is that the feature receiver creates the list with a URL friendly Title and then changes the Title to a UI friendly version. Say, a list “orderform” is created and then the name of the list is changed to “Order Form” would result that we have a list “Order Form” at URL http://sharepointsite/lists/orderform.

What would you say if I told you that you can’t change the Title of a list after it is created with PowerShell or custom console app, if you are working with sites any other language than English. Well it’s true. I’ve tested it with two Team Sites, one in English and another in Swedish and by creating a generic list “Temp” to both of them. Then I tried the following PowerShell commands on both of the sites.

$web = Get-SPWeb(“http://sharepointsite”)
$list = $web.Lists[“Temp”]
$list.Title = “Temp2”
$list.Update()

The commands above update the “Temp” List’s Title to “Temp2″ when my $web is the English team site but nothing happens if I run the same commands to my Swedish site. First I run the PowerShell commands to the sites

Then I wonder why the Swedish site’s list title has not been updated…

…while the English site’s list title is updated as expected.

The resolution to the problem lies in the API. While trying to figure out what was going on by narrowing our use case which was a pretty large scale provision to the fact that you can’t edit list’s title even with PowerShell consisted of the following steps and remarks:

The SPList SchemaXml property consists of a root element List, which has an attribute Title: the english site had Title=”Temp2″ while Swedish site had Title=”Temp” but the SchemaXmlInCurrentUiCulture property had a correct Title-attribute in the Swedish site’s case Title=”Temp2″
After running IISRESET, the first page load in Swedish site’s /_layouts/viewlsts.aspx showed the updated Title “Temp2″ of the list but after that page loads resulted the Title being the original “Temp”
While Googling, I came across this blog post by Vojtech Nadrovnik, which describes a similar problem but with SPField‘s DisplayName and the fact that Vojtech resolved the issue with reflection after first digging into the SharePoint code with a disassembler
Following Vojtech’s example, I tried some disassembling myself with ILSpy and found out that there is a very similar condition in SPList’s Title property’s setter (the last if) as seen in Vojtech’s SPField case

Some properties ARE NOT updated if the Thread’s UI Culture IS NOT the same as the web’s UI Culture.

If you have a feature and a receiver which might be activated by some other means than from the UI (_layouts/ManageFeatures.aspx) or any other piece of code that might be run outside SharePoint’s context, you could handle the problems described above by changing the thread’s UI Culture to the web’s UI Culture programmatically and it would work in any language as the following sample illustrates (different from Vojtech’s resolution):

public override void FeatureActivated(SPFeatureReceiverProperties properties)
{
SPWeb web = properties.Feature.Parent as SPWeb;
string title = "Temp";
string displayName = "Temp2";
CultureInfo originalUICulture = Thread.CurrentThread.CurrentUICulture;
bool allowUnsafeUpdates = web.AllowUnsafeUpdates;
try
{
if (SPContext.Current == null)
{
// IF CURRENT THREAD'S UI CULTURE
// IS NOT THE SAME AS WEB'S UI CULTURE,
// STRANGE THINGS CAN HAPPEN
Thread.CurrentThread.CurrentUICulture =
new CultureInfo((int)web.Language);
}
web.AllowUnsafeUpdates = true;
// create list
Guid listId = web.Lists.Add(title, "",
SPListTemplateType.GenericList);
// get newly created list by id
SPList list = web.Lists[listId];
// change list's title
list.Title = displayName;
list.Update();
}
finally
{
web.AllowUnsafeUpdates = allowUnsafeUpdates;
if (SPContext.Current == null)
{
// TOGGLE THE UI CULTURE BACK
Thread.CurrentThread.CurrentUICulture =
originalUICulture;
}
}
}

Publishing cross farm Managed Metadata in cross forest environment with one way trust

2011-04-28T13:37:53Z

Recently we ended up in a situation where there was a need to publish services from one farm to another. Basically there’s nothing special, but we needed to do that between SharePoint farms located in different forests. Only a one way trust was established.

The main idea is that Farm 2 will produce Managed Metadata Service (MMS) to be consumed in Farm 1. The setup can be seen in the figure.

Publishing services between two farms can be done through Central Admin or by using PowerShell. There is an excellent guide for publishing cross farm services written by Mark Rhodes. http://mrhodes.net/2010/05/19/publishing-service-applications-between-sharepoint-2010-farms-part-1-8/

We did everything as written in Rhodes’ guide. The outcome was that we were able to share the service, but it couldn’t be accessed through the consuming farm (Farm 1). When trying to access the Term Store following Error message appeared.

The Managed Metadata Service or Connection is currently not available. The Application Pool or Managed Metadata Web Service may not have been started. Please Contact your Administrator.

The problem was that although we had granted permission for the service application we hadn’t granted permissions to the Term Store.

Granting permissions to the Term Store can be done with the following PowerShell (PS)script.

In the consuming farm (Farm 1) run the following command:

(Get-SPFarm).Id

Run the following PowerShell commands on the publishing farm:

$ap = Get-SPServiceApplication –Identity “Managed Metadata Service Application”
$security = Get-SPMetadataServiceApplication $ap | Get-SPServiceApplicationSecurity
$principal = New-SPClaimsPrincipal -ClaimType "http://schemas.microsoft.com/sharepoint/2009/08/claims/farmid" -ClaimProvider $claimProvider -ClaimValue "farm id from previous"
Grant-SPObjectSecurity -Identity $security -Principal $principal -Rights "Full Access to Term Store"
Get-SPMetadataServiceApplication $ap | Set-SPServiceApplicationSecurity -ObjectSecurity $security

After running the script we could access the MMS through farm 1, but all groups were grayed out and we were not able to make any changes.

The solution is to grant the user permissions to the term sets. One can grant the permissions in farm A. OOTB the people picker doesn’t recognize users in Forest B, but this problem can be solved by using the following stsadm script. The script should be run on the server where CA is running for all web applications including CA.

STSADM.exe -o setproperty -pn peoplepicker-searchadforests -pv "forest:domaina.com,DOMAINA\sp_admina,password; forest:domainb.com,DOMAINB\sp_adminb,password" -url http://webapplication

After that we were able to grant permissions for term sets for users in both forests in farm 1. Unfortunately because the Farm 2 can’t see users in Forest 1 the MMS management site won’t open if you have granted permissions for users in both forests. In our case this was acceptable because the idea is that Managed Metadata is fully administered in Farm 2. So we granted Farm 1 write permissions, run our code that generated the Metadata structures and then changed the write permission back to Farm 2.

Conclusion

It is possible to publish Managed Metadata between two farms when there is only one way trust between the forests present. In any case this causes problems if you want to add or edit terms in both farms.

Extending the SocialCommentControl

2011-04-07T06:44:32Z

SocialCommentControl is the control, which enables commenting on a page. You can use social commenting feature with the Note Board web part (Social Collaboration > Note Board) by adding the web part onto your page. You would have to have User Profile Service Application provisioned to enable social comments. Comments are stored in the Social DB (SocialComments table) of your Service Application.

What we did recently was that we extended the out-of-box SocialCommentControl to be included in a custom page layout with a custom content type. The content type contains a boolean field to indicate, if commenting would be enabled on the published page. Another thing is that we can catch the events when a new comment is added, deleted or updated and build our own custom functionality, if needed, to handle those events.

The first thing was to take a look at the SocialCommentControl class with reflector in Microsoft.SharePoint.Portal assembly. The control inherits from System.Web.UI.WebControls.WebControl and implements the System.Web.UI.WebControls.ICallbackEventHandler. The event handling for comments takes place in RaiseCallBackEvent and the code can be dug out with reflector.

So what if there was a case where the editor wants to specify if commenting is allowed on a published page and wants to get the added comments via email if commenting would be enabled to the page. The scenario is not from our business case and is purely hypothetical but as a demo the case will do just fine.

Below is a quick demonstration of how to handle enabling commenting on a page and get the editor of the page to receive email every time a comment is either added or edited. The sample contains also a workaround for the inconvenient behavior of the out-of-box SocialCommentControl which breaks the DOM and makes web designers mumble when they come across the fact that one div is unclosed.

public class SocialComments : SocialCommentControl, ICallbackEventHandler
{
public SocialComments()
{
Load += SocialComments_Load;
}

protected void SocialComments_Load(object sender, EventArgs e)
{
var item = SPContext.Current.ListItem;
// check if the current page has commenting allowed
var allowComments = (item["AllowComments"] != null &&
(bool)(item["AllowComments"])) ? true : false;
if (!allowComments)
{
Visible = false;
return;
}
}

protected override void CreateChildControls()
{
base.CreateChildControls();
// the DOM is a terrible thing to break
// http://www.sharepointblues.com/2010/09/28/fix-disabled-page-scrolling-on-navigation-settings/
Controls.Add(new LiteralControl("

"));
}

public string GetCallbackResult()
{
return base.GetCallbackResult();
}

public void RaiseCallbackEvent(string eventArgument)
{
base.RaiseCallbackEvent(eventArgument);

try
{
var item = SPContext.Current.ListItem;
var page = PublishingPage.GetPublishingPage(item);
var editorEmail = page.CreatedBy.Email;
var url = SPContext.Current.Web.Url + "/" + item.Url;
var currentUser = SPContext.Current.Web.CurrentUser.Name;

var document = new XmlDocument();
document.LoadXml(eventArgument);
var documentElement = document.DocumentElement;

/*
eventArgument when added:

News
This is a new comment

*/
/*
eventArgument when edited
SequenceId='0'
CommentId='144'
CurrentPage='1' >
This is an edited comment

*/
if (documentElement != null)
{
var event = documentElement.GetAttribute("type");
if (event != "Get")
{
if (event == "Add" || event == "Edit")
{
var contentElement =
(XmlElement)documentElement.
SelectSingleNode("./RTEContents");
var content =
SPHttpUtility.NoEncode(contentElement.
InnerText);
var subject =
string.Format("Comment event '{0}' at {1}",
event, DateTime.Now);
var message =
string.Format("Content:
{0}

By {1}

Url: {2}",
content, currentUser, url);
SPUtility.SendEmail(SPContext.Current.Web, true,
false, editorEmail, subject, message);
}
}
}
}
catch(Exception ex)
{
// log the exception
}
}
}

Below is the email the editor would get when a new comment is added to the page where commenting is enabled and the custom extension of the SocialCommentControl is included.

Fix SharePoint 2010 for Opera Part I

2011-03-29T06:14:03Z

I can’t use IE9 because UAG doesn’t support it yet on VPN connections. I can’t use IE8 or older because they don’t play well with the rest of the Web. I can use Google Chrome, Apple Safari, Mozilla Firefox and of course Opera. SharePoint 2010 plays fine with all these new generation browsers, except for the one: Opera. Opera isn’t supported, and I’m glad to disagree.

Scrollbars are handy but sometimes we don't need them

First things first. The top portion of the Ribbon has a nasty scrollbar slobbering all over it. We’ll get rid of that with a simple CSS rule:

#s4-ribbonrow { overflow: hidden; }

Now onto the hard part. Click the Site Action button on the top left corner of the viewport. Nothing happens? I’m going the skip right through the details. The OnClick event of the Site Actions button calls the MMU_Open() -function which itself calls the MenuHtc_show() -function in order to display the pop-up menu. Both of these functions are located in the Core.js.

A look on the MenuHtc_show() -function tells us the the execution of the function stops, if the browser object doesn’t hold a fresh enough version.

if (!(browseris.ie55up || browseris.nav6up || browseris.safari125up))
return false;

Apparently the latest Opera build isn’t good enough for SharePoint (in my opionion it’s the other way around). The browseris-object is built in the init.js and there we can see no references to the Presto layout engine Opera uses. I will add a simple and dirty support for opera and I’m not going to modify these two files since that is not in line with best practices. Obviously this is something Microsoft usually fixes in the future with cumulative updates, and they might change something that we are not aware of, making the page scream with Opera again.

I’ve got my external JS file somewhere in the hive, and I’ll just add ‘support’ for Opera. The trick is to camouflage Opera as a Mozilla browser. To do this, I’ll use my favourite JS lib jQuery for dead simple browser detection and pass true the nav6up property of the browseris object if the browser is Opera with a recent major version.

browseris.nav6up = ($.browser.opera && $.browser.version >= 10) ? true : browseris.nav6up;

There you go. The Site Actions menu works and the Fat Lady can sing. Unfortunately there is more. Once you hover over the menu items, the ribbon content goes up. The webpart properties menu is also dead. But this should be enough to get you started with Opera. On the next part, I’ll concentrate on those issues.

How to Configure Crawl for Anonymous SharePoint 2010 Site

2011-03-01T09:57:10Z

Are You getting errors like described in Mikes blog? Well atleast I did, and here is one way to fix it.

First of all, you need to have a web application with only anonymous access enabled. You can have it extended to another zone, with windows authentication , to make it available for editing. Here is one guide how to make site anonymous. To disable view for form pages, guide for that in here.

When you are configuring your search and you want to use the anonymous site for crawling, you might get following error in you craw log and not getting anything crawled.

Access is denied. Verify that either the Default Content Access Account has access to this repository, or add a crawl rule to crawl this repository. If the repository being crawled is a SharePoint repository, verify that the account you are using has “Full Read” permissions on the SharePoint Web Application being crawled.

The key here is that you need to crawl the site as Web site, not as SharePoint site. Basically it makes sense, you are using the site as anonymous, so what you can’t see should not be crawled.

[edit: You can also use SharePoint site as crawl type and and use the same crawls rule as described here, but if the crawl does not get all content you want, you can't add more start URLs because each start url needs to be a web application or site collection. And without the crawl rule you will be getting the same error as mentioned above.]

1. Go to your Search Service Application, select Content Sources from the navigation on the left and create a new content source by clinking the link New Content Source.

2. Set the Content Source Type to Web site and Type the URLs from which the search system should start crawling. Some times it only crawled only the root web and did not follow the links in top navigation. If this happens, add more start URLs, like the URLs found in top navigation of your site collection.

3. Click Crawl Rules from the left navigation and create crawl rule.

3.1 Rule

Start your crawler…

Drag & Drop Web Part Y-offset Problem

2011-01-19T11:54:26Z

I’ve come across a bug in SharePoint 2010 with my custom master page that is based on minimal.master. In the edit mode, if I try to drag and drop web parts around, the element that is used to mark the drag position has a strange offset. Upon more investigation it appears that the javascript function that positions the marker with the class ‘ms-SPZoneIBar’ ignores the scroll position of the #s4-workspace div.

Override the javascript function with your own, and everything is golden once again.

MSOLayout_GetRealOffset = function (StartingObject, OffsetType, EndParent) {
var realValue = 0;
if (!EndParent) EndParent = document.body;
for (var currentObject = StartingObject;
currentObject != EndParent &&
currentObject != document.body &&
currentObject != null;
currentObject = currentObject.offsetParent) {
realValue += eval('currentObject.offset' + OffsetType);
}
return (OffsetType == 'Top') ? realValue - document.getElementById('s4-workspace').scrollTop : realValue;
};

Blog Site in Anonymous Use

2011-01-10T08:47:51Z

Anonymous user cannot enter a blog entry in a SharePoint site if ViewFormPagesLockDown feature is active at site collection level and ViewFormPagesLockDown feature is active if site collection is based on publishing portal. After googling we came accross plenty of resources considering this matter:

We didn’t want use the solutions suggested in the links above. To disable the ViewFormPagesLockDown “…leaves you wide open from a security perspective…”. To have our blog site in another site collection. Well that’s just not what we want to do to solve this tiny little thing with permissions.

Me and Aapo dug with reflector into ViewFormPagesLockDown feature and found out what the feature receiver does.

The highlighted sections of the feature receiver show what happens to Guest’s permissions at rootweb level when you disable ViewFormPagesLockDown site collection level feature.

So why not just take the solution from where it is and develop a web scoped feature which does the exactly same thing to the blog site but not to all webs in the site collection because that’s not what we want.

Develop a feature receiver as follows:

using System;
using Microsoft.SharePoint;

namespace My.Assembly
{
public class FormPagesLockDownReleaseReceiver : SPFeatureReceiver
{
public override void FeatureActivated(SPFeatureReceiverProperties
properties)
{
using (var web = (SPWeb)properties.Feature.Parent)
{
var anonymousState = web.AnonymousState;
// continue only if anonymous use is enabled
if (anonymousState == SPWeb.WebAnonymousState.Disabled)
return;
web.AllowUnsafeUpdates = true;
// break inheritance to set permissions per site
web.RoleDefinitions.BreakInheritance(true, true);
// permission granting from LockDownViewFormPages
var byType = web.RoleDefinitions.GetByType(SPRoleType.Guest);
byType.BasePermissions |= SPBasePermissions.EmptyMask |
SPBasePermissions.ViewFormPages;
byType.BasePermissions |= SPBasePermissions.UseRemoteAPIs;
byType.Update();
// reset the anonymous state programmatically
web.AnonymousState = SPWeb.WebAnonymousState.Disabled;
web.AnonymousState = anonymousState;
web.Update();
web.AllowUnsafeUpdates = false;
}
}
}
}

Resetting the anonymous state is just a thing you would have to do from UI when you toggle permissions. Lockdown Mode in SharePoint 2010: “If anonymous is already setup, you may need to disable\re-enable anonymous on the site.”

Then a web scoped feature that consumes the receiver:

xml version="1.0" encoding="utf-8" ?>
<Feature
Id="{6189C7B4-6FDC-4BAA-95FD-03DD318031E5}"
Title="Blog Anonymous Access Staplee"
Description="Enables Anonymous Access to Blog Entries"
Scope="Web"
ReceiverAssembly="My.Assembly,
Version=1.0.0.0,
Culture=neutral,
PublicKeyToken=e3e48257ada349c4"
ReceiverClass="My.Assembly.FormPagesLockDownReleaseReceiver"
Hidden="FALSE"
xmlns="http://schemas.microsoft.com/sharepoint/">
Feature>

You could set the feature hidden to avoid accidental feature activations.

Then a stapling mechanism at site collection level to staple the feature to Blog sites by default.

Stapling.xml

xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">

<FeatureSiteTemplateAssociation
Id="6189C7B4-6FDC-4BAA-95FD-03DD318031E5"
TemplateName="BLOG#0" />
Elements>

xml version="1.0" encoding="utf-8" ?>
<Feature
Id="{7DF309A4-7E3B-488A-9D2A-F3B88D656465}"
Title="Blog Anonymous Enabling Stapler"
Description="Staples Anonymous Access to Created Blog Sites"
Version="1.0.0.0"
Scope="Site"
xmlns="http://schemas.microsoft.com/sharepoint/"
ActivateOnDefault="FALSE">
<ElementManifests>
<ElementManifest Location="Stapling.xml" />
ElementManifests>
Feature>

Voila, you have a mechanism to allow viewing form pages only in blog sites when you activate the stapler feature at site collection level. Of course, if you want, you could even set the needed permissions at list level in the Blog site, I suppose, but that’s not what we’ve done here.