“Access Denied” Error in Discussion List Templates

Another strange error happened to me on customer premises.


You have developed a custom discussion list in SharePoint. You have saved the custom discussion list as a template. You create a new discussion list from this template.

When you create a new thread or a post in this new list (created from a template), you don’t see the “Edit Properties” or “Delete” buttons, even if you have the right permissions. Additionally, you might have “Access Denied” errors if you try to edit the thread or the post directly.


I was puzzled by this one at first. However, the customer contact (thank you, Toni) had previously found a useful blog entry, related to the problem although not exactly the same. To make it short, the problem resides in the fact that SharePoint somehow corrupts the security information saved for the list when it saves the list as template. More specifically, it drops the RenderXMLUsingPattern boolean attribute in PermMask field of the discussion list.

This seems to be a known bug in SharePoint, confirmed by Microsoft.


There are several possible solutions, depending on whether we want to fix an existing discussion list created with the “broken” template or we want to fix the template.

Fix an Existing Discussion List

In essence, we need to change PermMask field of the existing list and add the missing attribute (RenderXMLUsingPattern=”TRUE”). You can do it with:

Fix the Template

The process here is to repack the template with the correct XML.

  1. Download the template STP file from the List Templates of your site collection to your local disk
  2. Change the file extension to CAB
  3. Extract the contents of the CAB file into a folder
  4. Open manifest.xml file in the folder
  5. Look for the Field ID=”{BA3C27EE-4791-4867-8821-FF99000BAC98}” Name=”PermMask” entry. Add the following attribute in the Field node: RenderXMLUsingPattern=”TRUE”
  6. Repack the files in the folder with a CAB creation utility (such as CAB Maker), creating a new CAB file
  7. Change the file extension to STP
  8. Upload the new template to List Templates of your site collection

Talking to a WCF Service From Silverlight

In this second installment of “My Adventures with Silverlight” series, I will talk of how to successfully invoke a WCF service from Silverlight client.

The Basics

In a nutshell: you have a Silverlight client application that wants to consume data available in a remote service. This service is hosted in a classic ASP.NET web service (.asmx) or, like in this example, in a Windows Communication Foundation (WCF) service (.svc).

Silverlight has a built-in support for invoking WCF services in System.ServiceModel namespace. You should add a reference to the WCF service from “Add Service Reference” option in your Silverlight project when it’s open in Visual Studio.


In this dialog box you specify the URL of the service you want to add.


If everything goes well, after clicking OK you should see the service referenced correctly:


After the service is referenced, you must instantiate a service proxy (a class which is created automatically when the service reference is added). Then, you invoke the service methods in the proxy. The proxy itself invokes those methods in the remote service, sending SOAP-encoded messages over the HTTP connection.

The Limitations

In order to successfully connect your Silverlight application to a WCF service, you should abide by some known restrictions.

The first limitation is that standard WCF services use wsHttpBinding binding configuration, which enables security and other enhancements. Silverlight 2 is currently limited to basicHttpBinding configuration, which doesn’t include them (but, in the other hand, is much more interoperable with non-WCF services). So, in order to successfully add a service reference, you should manually change the binding information in your service web.config file, as shown here:



Additionally, you must enable ASP.NET pipeline support in your WCF service. This is accomplished by adding a AspNetCompatibilityRequirements attribute to your WCF service class and adding a AspNetCompatibilityEnabled node in your WCF service web.config file.



If you use the standard Visual Studio WCF Service template, you will have to do these changes manually. If you use the Silverlight-enabled WCF Service template, these settings will be applied automatically.

Message Size Limit

If one of your service methods has a parameter that can grow in size, like a humble String, you need to know that the default service configuration in WCF has a limit somewhere around 7780 bytes of message size. A message bigger than that will throw a NotFound —> System.Net.WebException. This exception is a catch-all generic exception when something goes wrong in communication with the WCF service. You will need a Http Debugging Proxy (more on that in next posts) to really dig out the real culprit.

To fix this you can follow the suggestion in Silverlight Official Forum:

  • Change the binding entry in ServiceReferences.ClientConfig file of your Silverlight project to something like this:
    <binding name="BasicHttpBinding_YourService" maxBufferSize="2147483647" maxReceivedMessageSize="2147483647">

  • Add a new binding entry in system.ServiceModel node of the service web.config. Change the endpoint bindingConfiguration to use this new binding.