Tuesday, December 11, 2012

No search results on anonymous SP2010 website

Last week I had an issue with search on SharePoint 2010. It turned out that we didn't had any results on our public website with anonymous access. Results showed up in our authoring zone (with authenticated users).
A lot of the suggestions Google came up with weren't applicable in this situation. It turned out the Anonymous policy on one of the zones of the web application was 'Deny all'. This zone wasn't crawled, but the policy was still propagated to the index and used on the other zone. This meant that, as the content had a deny all flag for anonymous users, security trimming didn't allowed the return of any results.

Tuesday, June 5, 2012

Bug in Duet Enterprise NetWeaver configuration wizard

With Duet Enterprise FP1 came a wizard that lets you configure the settings for user mapping between SAP and SharePoint users. Duet Enterprise is using SAML tokens of SharePoint to single sign on these users to SAP. You can configure this mapping on the NetWeaver machine, but as described in the Duet Enterprise support blog, this mapping is case sensitive based on the values in the SAML token.

What turns out is that you can specify the user name prefix in the Configuration wizard, but the wizard always turns the characters to uppercase. So the wizard step is quite pointless, as you need to delete the user mapping and recreate it again with the proper casing with SPRO, SAP Reference IMG - SAP NetWeaver - Gateway - Configuration - Connection Settings - SAP NetWeaver Gateway to Consumer - Define Consumer Issuer Certificate & Map SAP User Names to Consumer.

Update: this behavior is addressed in SAP Note 1688843.

Thursday, March 1, 2012

MSOCAF false positives

I've been struggling with MSOCAF lately. It turns out that validation of the developed SharePoint solution is quite hard. And it turns out that the validation of the tools still has a lot of errors.
A couple of examples:
  • The tool implements SPDispose check. It is a fantastic tool to detect the right disposal of SharePoint objects, but sometimes it can't determine the context right. These errors are taged with 'could be false positive'
  • MSOCAF implements a couple custom FxCop rules, but these are the quite problematic ones. For example, it detects the usage of deprecated classes and members. It uses the list found on MSDN with deprecated members. But in the notes added, there is the source of errors:
    Note: Types and methods in the Microsoft.SharePoint.Portal namespace are not included in these lists because, with a few exceptions, the entire namespace has been made obsolete.
    What it means, the Microsoft.SharePoint.Portal namespace? If you look at the MSDN documentation, you see that all classes directly in this namespace are deprecated or internal. But the FxCop rule is implemented as (thank you Reflector):
    if (fullName.Equals(str3) || fullName.Contains("Microsoft.SharePoint.Portal"))
    . And here disaster strikes. My code use a new SP2010 class AverageRatingFieldControl. But as this one is in the Microsoft.SharePoint.Portal.WebControls namespace, it is marked as a deprecated class (see FxCop rule). And now I need time to justify the use of a deprecated method.
  • MSOCAF does like logging to ULS, no problem with that. It checks a couple of rules:
    1. detects if Unified Logging Service (ULS) logging is performed in every catch block.
    2. SPDiagnosticsService should be called at start and end of Timer Jobs, Event Receiver, Feature Receiver, and Web Services functions.
    3. Any errors happening in the Feature Receiver upon activation and deactivation should be logged to the ULS and the exception must be reported back to SharePoint.
    But as with logging in code, developers like to create a generic method for that, where my custom application categories will be set. But no, MSOCAF keeps complaining that your ULS is not filled with data. And again, inspecting the FxCop rules turns out that it expect you to directly call the SPDiagnosticsService.Local.WriteTrace method. As it checks the IL generated code, sometimes this won't check right in debug mode. Also, using properties as parameters in the WriteTrace function will mess with the callstack, and probably influence the outcome of the FxCop rule negatively.

Too bad that the rules used in MSOCAF still need some tweeking.