SharePoint Dragons

Nikander & Margriet on SharePoint

Monthly Archives: March 2012

SharePoint Taxonomy info nugget

Sometimes you come across these little pieces of knowledge. In this case, we came across this little nugget of info about taxonomy:

Architecture document for SharePoint

Nice blueprint for approaching an architecture document for SharePoint can be found at: We actually found that the TOC provides a nice comparison with what you might have already.

List throttling settings

Why is it that hordes of SharePoint 2010 developers try to lift the list throttling settings or think that it’s a magical button that allows you to optimize the SharePoint farm for whatever amounts you may need (e.g. I want to retrieve 100.000 items, luckily, if I raise the list throttling settings to 100.000 it won’t affect server performance at all!). There’s gotta be some best practices regarding this area, no? We propose the following Wiki page as the starting point:

Copy a site collection

Nice explanation of moving a site collection from a source farm to a target farm:

SharePoint 2010 Best Practices: Folders not necessarily considered evil

Security settings based on metadata

We didn’t hear about it before, but the TITUS Metadata Security for SharePoint allows organizations to set security settings based on metadata: Interesting, but we are wondering though: does this revert to item based security? Why not use folders instead (we know, a sensitive topic for many) and save some money?

We’ve learned that in general sales people of 3rd party vendors tend to read this blog, so we won’t be surprised if the answers to these questions pop up in a while in the form of comments. We’ll just have to wait and see.

SharePoint 2010: Best Practices

This Wiki page contains an overview of SharePoint 2010 Best Practices:

SharePoint 2010: WCF best practice

If you’re creating a WCF service you basically have two options:
– Create a WCF service in a SharePoint context.
– Create a separate WCF service.

So, when it comes to choosing one of the two scenarios, which one is best practice, and why? Check out our Wiki page at

Windows AppFabric Cache API

A couple of years ago we wrote an article about the different ways of accessing SharePoint list items and leveraging enterprise cache in the process: . As it turns out, the contents of the article are still very actual, but the Enterprise cache sample code for the Windows AppFabric Cache (which was called Velocity at the time) needs an update, although the process didn’t actually change that much.

First of all, don’t create any secondaries anymore when creating a new cache on a single server. Instead, do this:

new-cache -CacheName myCache -Secondaries 0

Adding references to the AppFabric caching assemblies is different too:

The sample code has changed as well. Signatures have changed a bit, and a couple of class names get prefixed with “Data”:

//Inspired by:

//Define Array for 1 Cache Host     
List<DataCacheServerEndpoint> servers = new List<DataCacheServerEndpoint>(1);      

//Specify Cache Host Details      
//  Parameter 1 = host name    
//  Parameter 2 = cache port number     
servers.Add(new DataCacheServerEndpoint(“astro”, 22233));      

//Create cache configuration     
DataCacheFactoryConfiguration configuration = new DataCacheFactoryConfiguration();            

//Set the cache host(s)     
configuration.Servers = servers;            

//Set default properties for local cache (local cache disabled)     
configuration.LocalCacheProperties = new DataCacheLocalCacheProperties();      

//Disable tracing to avoid informational/verbose messages on the web page     

//Pass configuration settings to cacheFactory constructor     
var factory = new DataCacheFactory(configuration);      

//Get reference to named cache called “default”     
//var cache = factory.GetCache(“default”);      
var cache = factory.GetCache(“c1”);

//Then create a region inside the named cache:
    // No region found, but that’s ok.

// Pass true if you want to allow the eviction of cached objects.

cache.Put(“testregion”, “test”);


Finally, start the Caching Administration Windows PowerShell command prompt and use the following PowerShell command to check out the results of the code:

Get-CacheStatistics myCache

Monitoring WCF services via AppFabric – note to self

Finally, after a bit of head slamming and crying: “why does this simple WCF service keeps having an empty WCF call history?” we found the answer.

First, we studied the web.config file of the service:

<?xml version=”1.0″ encoding=”UTF-8″?>

    <compilation debug=”true” />
    <customErrors mode=”Off” />


   <service name=”NikWasService.Service1″ behaviorConfiguration=”BC”>
     <endpoint address=”” binding=”wsHttpBinding” contract=”NikWasService.IService1″ />

     <endpoint address=”mex” binding=”mexHttpBinding” name=”mexHttpEndpoint” contract=”IMetadataExchange” />


      <behavior name=”BC”>
        <serviceMetadata httpGetEnabled=”true” />
        <serviceDebug includeExceptionDetailInFaults=”true” />
                <behavior name=””>
                    <serviceMetadata httpGetEnabled=”true” />
                    <etwTracking profileName=”Troubleshooting Tracking Profile” />
  <serviceHostingEnvironment multipleSiteBindingsEnabled=”true” />
        <diagnostics etwProviderId=”435613c0-3c9f-4a1e-aafe-7a314fbd9b0a”>
            <endToEndTracing propagateActivity=”true” messageFlowTracing=”true” />

            <default enabled=”true” connectionStringName=”ApplicationServerMonitoringConnectionString” monitoringLevel=”Troubleshooting” />

Nothing wrong with that in particular. Double-checked that monitoring was enabled in the config file. We invoked the WCF service using the WCF Test Client. Nothing… Waited 10 seconds and tried again… Still nothing. Then, it hit us: the AppFabric Event Collection Service and Windows Event Collector services weren’t started. If nothing else, this is a note to self to insure we won’t make this mistake again!