PointBridge Blogs - Apryl Crossland

Unable to access SharePoint claims-based site - Event ID 8306

By: Apryl Crossland Posted: October 12, 2011 at 4:31 PM

System Specs

SharePoint 2010 farm hosting multiple web apps using claims authentication. Each web app has multiple zones.

Symptoms

After a code deployment we were unable to access the Intranet zone (NTLM Authentication) for all claims-based we apps in the environment.

The following is the error that was encountered when trying to access the sites in IE.

The following is the error that was being captured in the Application event log.

Log Name:      Application
Source:        Microsoft-SharePoint Products-SharePoint Foundation
Date:          10/11/2011 8:37:04 PM
Event ID:      8306
Task Category: Claims Authentication
Level:         Error

Description:
An exception occurred when trying to issue security token: The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework 3.0 SDK documentation and inspect the server trace logs.

Resolution

The following three services were in a stopped state. Once these services were started the sites started responding normally.

Managed Metadata Service: Content Type Hubs and Publishing Architecture Considerations - Part I

By: Apryl Crossland Posted: January 3, 2010 at 3:51 PM

2
Comments

The Managed Metadata Service is a highly configurable service application that controls three distinct features: keyword store, managed terms and content type publishing. The access to and control of these three features needs to be considered individually when determining the structure of the service applications and connections among the various web apps in the farm(s).

The content type hub is designated at the Managed Metadata Service (MMS) service application level which creates a whole new shift for managing content types that is a vast improvement over SharePoint 2007. Content types are created, edited and removed from the hub site and any subscribing site collection has a read-only version that is modified accordingly. To be a subscribing site, the web app the site collection is in just needs a connection to the MMS service application proxy. This is very easily configured through Central Administration.

So what are the considerations for content type hubs and subscribers to a Managed Metadata Service? There are many different scenarios that could be employed when publishing and managing content types, but the two driving factors are going to be keyword/term management and content type administration.

Keyword/Term Management

The MMS service application can house keywords and managed terms in addition to designating the content type publishing hub. This means that if the MMS service application is the keyword store as well as the content type publishing service, then all web apps that have a connection to the service application will not only subscribe to content types, but they will also have access to the keyword store and managed terms.

I think this puts forth a good case for creating multiple MMS service applications in order to separate content type publishing, keyword store and managed terms. Let's apply this to a real-world scenario.

Example

I have two web apps. One web app houses my Internet and the other web app houses my Intranet. The Intranet has a site that has been developed to manage property listings. The site contains five custom content types. What we would like to do is allow some users from the Internet site to enter property listings.

Scenario #1

In SharePoint 2007 this would have meant creating five content types that duplicate what we have in the Intranet site and then ensuring that any future changes are made in both the Intranet and Internet sites. However, with SharePoint 2010 we can set the Intranet site as the content type hub in our MMS service application and then the Internet web app would only need to have a connection to the MMS service application proxy to be a subscriber to the Intranet content types. This would allow the Intranet site to publish the five custom content types to the Internet where they would be read-only. It also allows and changes to the content types to be made from the Intranet site and then re-published (updated) to the Internet site as necessary.

Scenario #2

The rub here is that we do not want the keyword store or managed term sets of the Intranet site to be accessible to the Internet. This means we should create two MMS service applications for the Intranet web app - one for the keyword store and managed term sets and the other for content type publishing.

Scenario #3

Now we have two MMS service applications for our Intranet - one for content type publishing and the other for the keyword store and managed term sets. The property system that was created on the Intranet uses some custom forms that have columns that rely on managed terms. The managed terms allow for consistency in data and better organization of the property content. Therefore, we want to continue that approach with users entering property listings on the Internet.

In this case, we still want to setup multiple MMS service applications, but with a slight twist from Scenario #2. The first MMS service application for the Intranet would house the keyword store. The second MMS service application would control content type publishing and house the managed term sets. This would allow the Internet site to subscribe to the content types from the Intranet as well as consume the managed terms used in the custom forms.

Conclusions

The Managed Metadata Service controls three distinct features. Not all web apps will need to share all three types of content, so it will be necessary to map out content availability between web apps during the architecture planning process.

Another consideration for content type publishing is administration. Read Part II of this blog

Managed Metadata Service: Content Type Hubs and Publishing Architecture Considerations - Part II

By: Apryl Crossland Posted: January 3, 2010 at 3:50 PM

1
Comment

In Part I of this topic we covered the considerations for content type publishing that relate to keyword/managed terms. In this part we'll cover considerations for content type publishing as they relate to content type administration.

Again, the content type hub is the designated site collection that will be used to publish and administer content types to all subscribing sites. There can only be one content type hub per Managed Metadata Service (MMS) service application and any site in a web app that has a connection to the service application will be a subscriber to the content type hub. One key thing to keep in mind is that a site can be a hub as well as a subscriber.

Administration and security in my experience is something that is typically comes after implementation which can be an issue in itself. With the new shift to designating the content type hub at the service application level in Central Administration, determining content type security and administration rights during planning becomes important.

There are two main options:

1. Store content types in a dummy site collection designated as the hub

2. Store content types in the site collection that is the main consumer of them and designate it as the hub

Configuration #1 - Separate Dummy Site Collection Hub

The separate dummy site collection approach to storing and administering content types allows for total isolation of content types. This allows for minimal consideration of security and permissions ahead of time as the site collection will only be accessed by farm or site collection administrators and only when content type administration and management needs to be completed.

This prevents the necessity of complex security and permissions configuration on a site collection and also limits the possibility of inadvertent content type changes.

The disadvantage to this approach is that an additional site collection and layer of complexity is added to an implementation.

Configuration #2 - Main Consumer Site Collection Hub

By storing content types in the main consumer site and designating it as the content type hub we would be using the most intuitive approach. This would be the most intuitive setup and the most desirable for simple implementations where little division of administration is necessary.

The disadvantage to this approach is that security and permissions need to be considered as all site collection administrators as well as site Owners will have the ability to publish, change or remove content types which will affect all subscribers.

Conclusion

During planning have a realistic conversation about administration and division of labor. For most implementations, storing content types in the main consumer site and making it the content type publishing hub will suffice. However, if there will be multiple permission levels or different types of administrators with varying degrees of permissions, then opt for storing content types in a dummy site collection only for content type storage, administration and publishing.

Planning to implement Social Networking in your MOSS environment? Does the term “Requirements Gathering” have you running for the hills?

By: Apryl Crossland Posted: June 28, 2008 at 9:58 AM

Requirements gathering is something nobody really wants to do, but when it comes to implementing Social Networking there are some decisions that must be made up-front.

1. Decide what information will be useful. This means getting feedback from multiple places within the organization.

2. Figure out where the information will come from. Does it already exist? Will users need to enter it themselves?

3. Ensure the information you want to capture and display will not expose the organization to any legal consequences.

Take a look at the public profile page (Person.aspx) to use as a starting point during brainstorming. Then add and remove content from there. All the information on this page is stored as Profile Properties in the profile store in MOSS. I have created a workbook that helps ensure that you capture all the necessary data for additional Profile Properties.

The first worksheet in the workbook contains information and instructions for use. Also, the Profile Fields worksheet contains a list of the Profile Properties that MOSS creates by default as well as all of their settings to get you started. Below is a link to the file in Excel 2007 or Excel 97-2003 format.

Excel 97-2003 Version

Excel 2007 Version

Requirements are not easy. If they were everyone would get them. Hopefully, this workbook will help ease the way.

Creating a Custom List Definition and Don’t Need the Title Column?

By: Apryl Crossland Posted: June 28, 2008 at 9:56 AM

1
Comment

The Title column is a required column because a Custom List inherits from Item in SharePoint base content type hierarchy. The Item content type has one required column – Title. So what to do?

Ari Bakker has a great blog about creating a custom list, including xml structure for Site Columns, Content Type and Custom List. In my example I have created site columns, a content type and a custom list for Projects following Ari’s blog. Below are links to open my XML.

Site Columns

Content Type

Custom List

Let’s start by making a copy of the schema.xml file from the SharePoint Custom List. This will give us a basic schema that we can tweak.

Add your columns to the fields section, and here is the trick – Change the Name property of one of your text columns to LinkTitle. Internally the list uses LinkTitle for many controls, but your column in the UI will show DisplayName.

<Field ID="{82642ec8-ef9b-478f-acf9-31f7d45fbc31}"

Name="LinkTitle"

DisplayName="Project Name"

Sealed="TRUE"

SourceID="http://schemas.microsoft.com/sharepoint/v3"

StaticName="LinkTitle" />

<Field ID="{bc91a437-52e7-49e1-8c4e-4698904b2b6d}"

Name="LinkTitleNoMenu"

DisplayName="Project Name"

Sealed="TRUE"

SourceID="http://schemas.microsoft.com/sharepoint/v3"

StaticName="LinkTitleNoMenu" />

<Field ID="{fa564e0f-0c70-4ab9-b863-0177e6ddd247}"

Name="Title"

DisplayName="Project Name"

Required="TRUE"

ShowInNewForm="TRUE"

ShowInEditForm="TRUE"/>

<Field ID="{b60d7dac-e8df-4e9f-9c7f-b744f7728cd3}"

Name="ProjectNumber"

Group="My Projects Site Columns"

Type="Text"

DisplayName="Project Number"

SourceID="http://schemas.microsoft.com/sharepoint/v3/fields"

StaticName="ProjectNumber"

Description="Enter project number (SAP #, IT PIE Project #)."

MaxLength="50"

DisplaySize="50"

Sortable="TRUE"

Required="TRUE"

AllowDeletion="FALSE">

</Field>

<Field ID="{4ca657a3-e843-444b-b7f1-56c47d540fc9}"

Name="ProjectDescripton"

Group="My Projects Site Columns"

Type="Note"

DisplayName="Project Descripton"

SourceID="http://schemas.microsoft.com/sharepoint/v3/fields"

StaticName="ProjectDescripton"

Description="Enter a brief description of the project."

RichText="TRUE"

RichTextMode ="FullHTML"

NumLines="6"

Sortable="FALSE"

Sealed="TRUE"

Required="TRUE"

AllowDeletion="FALSE">

</Field>

<Field ID="{fb04e565-49e9-4a54-b0d6-83bb2c0eafcb}"

Name="ProjectRole"

Group="My Projects Site Columns"

Type="Choice"

DisplayName="Project Role"

SourceID="http://schemas.microsoft.com/sharepoint/v3/fields"

StaticName="ProjectRole"

Description="Select your main role in the project."

Sortable="TRUE"

Sealed="TRUE"

Required="TRUE"

AllowDeletion="FALSE"

FillInChoice="FALSE">

<CHOICE>Sponsor</CHOICE>

<CHOICE>Owner</CHOICE>

<CHOICE>Project Manager</CHOICE>

<CHOICE>Team Member</CHOICE>

<CHOICE>Subject Matter Expert</CHOICE>

<CHOICE>IT Partner</CHOICE>

<CHOICE>Conultant</CHOICE>

</CHOICES>

</Field>

<Field ID="{84652802-5863-4d42-8018-5554f69a58fd}"

Name="ProjectStatus"

Group="My Projects Site Columns"

Type="Choice"

DisplayName="Project Status"

SourceID="http://schemas.microsoft.com/sharepoint/v3/fields"

StaticName="ProjectStatus"

Description="Select the project status."

Sortable="TRUE"

Sealed="TRUE"

Required="TRUE"

AllowDeletion="FALSE"

FillInChoice="FALSE">

<CHOICE>Pending</CHOICE>

<CHOICE>Active</CHOICE>

<CHOICE>Complete</CHOICE>

</CHOICES>

</Field>

<Field ID="{05084a28-be56-4ff6-9af6-d4601fa8f7e6}"

Name="ProjectComplete"

Group="My Projects Site Columns"

Type="DateTime"

DisplayName="Project Completion Date"

SourceID="http://schemas.microsoft.com/sharepoint/v3/fields"

StaticName="ProjectComplete"

Description=""

Sortable="TRUE"

Sealed="TRUE"

Required="FALSE"

StorageTZ="UTC"

AllowDeletion="FALSE"

FillInChoice="FALSE">

</Field>

<Field ID="{8da26d97-b873-4a8c-87fa-5cb093576b7f}"

Name="ProjectLink"

Group="My Projects Site Columns"

Type="URL"

DisplayName="Project Link"

SourceID="http://schemas.microsoft.com/sharepoint/v3/fields"

StaticName="ProjectLink"

Description="Enter the link to an existing SharePoint site or network file share."

Sealed="TRUE"

Required="TRUE"

AllowDeletion="FALSE">

</Field>

</Fields>

Once you have done that add your columns to all ViewFields sections. The trick here is to leave both the LinkTitle or LinkTitleNoMenu references and simply add your additional columns.

First ViewFields Section: