Steve Goodyear's Blog

Determining Between SharePoint Site Collections and Sub-Sites

2009-07-26T07:11:00Z

Personally, I am in favour of a liberal use of site collections. In short, when in doubt, or unless I have a good reason for creating a sub-site, my default choice is a new site collection.

Having site collections really sets IT up with greater freedom to manage and scale the service down the road, whereas sub-sites are generally more limiting. For example, sub-sites all exist in the same site collection container and if two sub-sites grow beyond a manageable size for a single site collection, that container cannot scale out its storage without breaking the collection apart into several site collections and facing other challenges (like changing URLs or having managed path complexity, and data migration efforts).

On the other hand, if they are each individual site collections, we can easily separate them into their own physical database, and then potentially scale even further by storing those databases on different physical SQL Servers. This way, we can adjust the physical storage for site collections without affecting the logical URL structure of the site the end-user interacts with, and with minimal downtime.

Having site collections also gives you more control over monitoring the service, as we apply quotas at the site collection level. Rather than having one very large quota (or worse, no quota at all), it is better to have several small quotas on different sites that you can monitor and potentially develop reports for different types of sites, or even implement a charge-back model associated with site quotas. All signs indicate SharePoint 2010 will continue with the quota concept at the site collection level, and potentially build on some of the capabilities it offers. Quotas are a good long-term investment, not to limit end-user adoption, but to allow IT to adapt to and plan for that adoption.

I also find it easier to track and report on the site's lifecycle at the site collection level rather than individual sub-sites within it. The built in Site Usage and Confirmation feature also works at the site collection level, and I've found any workflow or customization I have developed to offer additional experiences than the built in site usage functionality offers to be the least complex when built targeting the site collection.

Finally, if I need to change an URL of a site, having a deep hierarchy of sub-sites will break links for many more locations than the site itself. If instead they are all site collections that just link to each other, I can update those links and the impact to my end-users is limited to just the one site that needs to change. If you think about it, the internet has a very flat and wide hierarchy that uses links to point to different resources, and does so in a structure that simulates a hierarchy. Your SharePoint sites can be set up with a virtual hierarchy too that uses a taxonomy structure built from links rather than a physical implementation.

It is true that sub-sites can inherit things like permissions and navigation, and this is usually the main argument to trade off a flatter site collection taxonomy for a physically deeper taxonomy based on sub-sites. Using Active Directory groups for membership and granting permissions against those groups should resolve being able to manage permissions centrally. Using separate site collections, you will have to set up the navigation on each site, or you can implement a custom navigation provider. Another challenge is that the Content Query Web Part will not work across site collections, but you could use the search results web part or build your own, and achieve the same goal of aggregating content across site collections.

Some of the key things I look at when determining whether to split content into multiple site collections rather than a single site with many sub-sites, beyond the content size and number of databases I would like to span, include:

If the top-level site reaches the end in its lifecycle, can I delete all the sub-sites when I delete it? If not, maybe those sub-sites should be in a different or their own site collection so they can have a different lifecycle.
Will the permissions for the sub-site be the same or a subset of the top-level root site? If not, this might indicate the permission hierarchy is getting overly complex with broken inheritance and would be more manageable in the future separated into different site collections.
Will I want to build site reports differently between sites? If I want to report on several sites as a group, it is often easier using out-of-the-box reports if the sites belong to a single site collection.
Will the navigation change frequently? Having multiple site collections point to each other is as easy as setting a global navigation for each site that links to each other. Nevertheless, if that global navigation changes frequently, it might be easier to have the sites as sub-sites. Or, keeping in mind that ease of updating the global navigation across site collections is achievable still by implementing a custom site map provider, site collections might work just as well.

Ultimately, it is a trade-off between easy initial site setup verses an implementation with a design for greater flexibility and manageability in the future.

The following diagram captures my typical decision process when determining the physical site structure.

This other article also discusses some of these points and has a few other questions to help you decide when to use a site collection and when to use a sub-site: http://technet.microsoft.com/en-us/library/cc288638.aspx

Remember, the virtual structure and site taxonomy (directory) can be anything, because they are just hyperlinks pointing to content. Avoid making physical structure decisions when links will do!

Updating the docicon.xml File with a Feature

2008-06-15T08:30:00Z

File types are associated to an icon in SharePoint by mapping a particular file extension to a specific icon. This makes the file easily recognizable to end users as they navigate a site and skim a document library. For licensing reasons, only a select list of file types has an icon associated with them by default. This also helps prevent bloating the document icon list with an exhaustive list of file types.

You can map a file extension to a particular icon in SharePoint by editing the docicon.xml file and adding a mapping element with the file extension and icon path. This file is located in the TEMPLATES\XML folder within the SharePoint 12 hive. You will need to edit this file on each web front-end server, making it a good candidate to accidently have a server go out of sync with the other servers. No different from challenges faced with any manual configuration or customization. By instead making the changes via a SharePoint feature, the solution is repeatable, testable, and ensures all servers reflect any changes.

To illustrate an example I will use a file type I often like to add an icon for, PDF files. I created a new feature with a farm scope and a receiver class to override the FeatureActivated and FeatureDeactivating methods. Below is my code for the FeatureActivated method where it loads the docicon.xml document, check if a mapping element exists for the PDF extension, and add one if not.

Being fussy about my code and maintaining consistency, I first attempt to add the new PDF Mapping element in alphabetical order by checking for a file extension in the list that would fall after "PDF" and insert the node before that. Otherwise, I append the PDF Mapping element as the last element. Finally, I save the file overwriting the original with the changes.

public override void FeatureActivated(SPFeatureReceiverProperties properties)

{

XmlDocument xmlDocument = new XmlDocument();

xmlDocument.Load(DocIconFilePath);

XmlNode documentElement = xmlDocument.DocumentElement;

XmlNode pdfNode = documentElement.SelectSingleNode("ByExtension/Mapping[@Key='pdf']");

if (pdfNode == null)

{

pdfNode = xmlDocument.CreateElement("Mapping");

pdfNode.Attributes.Append(

xmlDocument.CreateAttribute("Key")).Value = "pdf";

pdfNode.Attributes.Append(

xmlDocument.CreateAttribute("Value")).Value = "pdf.gif";

bool wasAdded = false;

XmlNode byExtensionNode = documentElement.SelectSingleNode("ByExtension");

foreach (XmlNode node in byExtensionNode.ChildNodes)

{

if (node.Attributes["Key"].Value.CompareTo("pdf") > 0)

{

byExtensionNode.InsertBefore(pdfNode, node);

wasAdded = true;

break;

}

if (!wasAdded)

byExtensionNode.AppendChild(pdfNode);

xmlDocument.Save(DocIconFilePath);

}

The FeatureDeactivating method reverses the configuration changes when administrators deactivate the feature. However, changes may require recycling an application pool before the changes take effect and the icon reverts to the common plain white one. Below is my code for the FeatureDeactivating method where it loads the same docicon.xml file and checks if a Mapping element exists for the PDF extension. If a PDF Mapping element exists, it removes the element and then saves the file back with the changes.

public override void FeatureDeactivating(SPFeatureReceiverProperties properties)

{

XmlDocument xmlDocument = new XmlDocument();

xmlDocument.Load(DocIconFilePath);

XmlNode documentElement = xmlDocument.DocumentElement;

XmlNode pdfNode = documentElement.SelectSingleNode("ByExtension/Mapping[@Key='pdf']");

if (pdfNode != null)

{

XmlNode byExtensionNode = documentElement.SelectSingleNode("ByExtension");

byExtensionNode.RemoveChild(pdfNode);

xmlDocument.Save(DocIconFilePath);

}

Loading and saving the docicon.xml file in the FeatureActivated and FeatureDeactivating methods use the DocIconFilePath property. This property looks up and builds the path on first access. Below is my code for the property where I combine the TEMPLATE\XML directory with the docicon.xml file to build the full path.

Instead of hard coding the directory to the most common path of the 12 hive, I used a static utility method in the SharePoint API to encapsulate the path and make it less fragile to changes. Calling SPUtility.GetGenericSetupPath with an empty string will return the full path to the 12 hive as a string (most typically this path is "C:\Program Files\Common Files\Microsoft Shared\web server extensions\12"). The utility takes string parameters and combines them as a subdirectory of the 12 hive, and then returns the full path with the subdirectory.

private string _docIconFilePath;

private string DocIconFilePath

{

get

{

if (_docIconFilePath == null)

_docIconFilePath = Path.Combine(

SPUtility.GetGenericSetupPath("TEMPLATE\\XML"),

"DOCICON.XML");

return _docIconFilePath;

}

I deploy the PDF icon file in the WSP solution package with the feature by adding a command to the DDF file that copies it to an Images directory in the WSP. The solution manifest file includes the following TemplateFile element that copies the PDF icon file to the TEMPLATE\IMAGES directory of the 12 hive for each server in the farm during solution deployment.

Once the solution is packaged and deployed on the server, activate the feature in the farm features management area of SharePoint Central Administration. Upload a PDF file to a document library and verify the icon next to it matches the icon set in this feature.

Changing the Port and Host Header for the Central Administration Web Application

2008-03-22T20:59:00Z

The first server in a SharePoint farm that runs the SharePoint Products and Technologies Configuration Wizard provisions the SharePoint Central Administration web application and SharePoint configuration database. This Central Administration web application uses the server's name as its host header, and by default a random port number. It also creates a content database for the Central Administration web application, which I previously discussed how to rename.

Using a non-default port adds an extra security layer that follows our defence in depth best practices. Firewalls are more likely to block traffic on these non-default ports, isolating access to SharePoint's Central Administration. In other situations however, it may be desirable to access the Central Administration using friendlier URLs like the default HTTP over port 80, or preferably HTTPS over port 443. One place I like to use default HTTP/HTTPS ports is in my lab so I can follow a simple naming convention like https://spadmin and not have to remember port numbers.

Following are the steps I find work best for me when I want to change the Central Administration web application's port and host header:

Navigate to the "Application Management" tab in SharePoint Central Administration.
Click the Create or Extend Web Application link.
Click the Extend an existing Web application link.
Select the "SharePoint Central Administration v3" web application.
Enter the port (i.e. 80 or 443) and the host header that matches an available DNS entry you have set up (i.e. "spadmin"). If desired, select the "Use Secure Sockets Layer (SSL)" option.
Verify the URL matches (i.e. "https://spadmin:443") and click OK.
Test the new URL.

I've found it best not to change the Default value in the Alternate Access Mapping from the one SharePoint assigned with the SharePoint Products and Technologies Configuration Wizard as that wizard can experience errors if you have to run it again, like after applying a service pack. Instead leave your custom URL in the intranet mapping field.

Renaming the SharePoint Central Administration Content Database (SharePoint_AdminContent)

2007-12-09T20:54:00Z

Installing SharePoint using the GUI works really well and makes the install process pretty simple. Using the Command Prompt to perform the install on the other hand probably gives you a better sense for what is being done. It certainly gives you more control over the naming of things like databases and application pools. One in particular is the SharePoint Central Administration site collection's content database. By default it is named by concatenating "SharePoint_AdminContent_" with a newly generated GUID.

This Central Admin content database name may not be aesthetically pleasing, or DBAs may have different naming conventions or standards they will want this database to follow. All is not lost if you have used the setup wizard GUI and SharePoint has generated a database with a name like this. Content databases can be renamed by backing up and restoring the database with the new name, and then removing the old one from the web application and adding the new one in its place.

Unlike renaming regular web applications, it is best to remove the old content database and add the database restored with the new name using the Command Prompt. There is a Content Databases section in Central Administration, but in this case the content database is the same one on the backend that hosts Central Administration and that section.

Following are the steps I find work best for me when I need to rename the Central Administration content database:

Stop the Central Administration application pool in IIS. This will prevent data loss and ensure no one else is performing operations while the content database is adjusted.
By default, the Central Administration application pool is called "SharePoint Central Administration v3" in IIS.
Backup the Central Administration content database using SQL Server Management Studio. I backed up the database "SharePoint_AdminContent_b73dd91a-a0f2-4d8bad9f-ba4ab59a4de3" in this example.
Restore the previously backed up Central Administration content database to a new database using a new name. I restored that database with the name "SharePoint_AdminContent" (without the GUID) in this example.
Open a Command Prompt window under the context of the SharePoint server farm account. This is the same account used as the identity of the Central Administration application pool.
The easiest way is to right-click the Command Prompt in the start menu, then choose "Run As" and enter the service account's credentials.
Enter the STSADM command in the Command Prompt window using the "deletecontentdb" option. For example, I entered the following STSADM command:
stsadm -o deletecontentdb -url http://Example:41000/ -databasename SharePoint_AdminContent_b73dd91a-a0f2-4d8bad9f-ba4ab59a4de3
Enter another STSADM command using the "addcontentdb" option. For example, I entered the following STSADM command:
stsadm -o addcontentdb -url http://Example:41000/ -databasename SharePoint_AdminContent
Delete the old content database. I deleted "SharePoint_AdminContent_b73dd91a-a0f2-4d8bad9f-ba4ab59a4de3" in this example.
Restart the Central Administration application pool in IIS (SharePoint Central Administration v3).

Adding New SSP Administrators

2007-06-21T06:15:13Z

Delegating administration duties for a SharePoint Shared Service Provider (SSP) separates duties while keeping the environment secure and practicing the principle of least privilege. The process to grant access to other administrators might not be so obvious at first because you do not assign all SSP permissions in the Site Permissions section using SharePoint groups as one might expect.

When you add a new user account to the SSP site, even if you grant them Full Control permissions or add them as a Site Collection Administrator, initially they will experience access denied error messages when they click on any of the following links:

User profiles and properties
Profile services policies
My Site settings
Personalization services permissions
Audiences
Import application definition
Business Data Catalog permissions

These sections need to have permissions explicitly set. Initially, the setup account will have full access to the SSP, so use that account to grant rights to new SSP administrators you wish to delegate SSP administrative duties to.

Notice the items highlighted in bold in the list above. These are where you assign the remaining SSP permissions. Adding new SSP administrators to the "Personalization services permissions" section and granting appropriate rights will grant rights related to the first five links in the list above. Repeating the process in the "Business Data Catalog permissions" section will grant rights related to the last two links.

At this point, the new SSP administrator has all the appropriate access permissions they need to administrate the SSP.

Custom Web Applications Coexisting with SharePoint 2007

2007-05-08T03:17:31Z

SharePoint has the concept of managed and unmanaged paths. As the names imply, managed are paths that SharePoint processes and handles such as sites and site collections. Unmanaged on the other hand are those paths that are outside of SharePoint and are not processed by the SharePoint engine. Custom web applications that need to coexist with SharePoint on the same IIS Virtual Server (also referred to as a Web Application in SharePoint speak) typically exist on an unmanaged path.

In 2003, SharePoint allowed paths to be configured as included or excluded. Implicitly and explicitly included paths are still configured at the Web Application level in SharePoint 2007, but excluded paths are no longer declared. This is true using both the SharePoint Central Administration web page and the STSADM SharePoint command line tool. Instead when you create an IIS Virtual Directory, SharePoint treats it as an excluded and unmanaged path.

This works great and reduces administrative overhead with consolidating the two applications on the same IIS Virtual Server. There are however, a couple more steps to take. ASP.NET does a wonderful job constructing a hierarchy of configuration settings. Since the IIS Virtual Directory for the custom application is below the SharePoint directory in the hierarchy, the custom application will inherit the SharePoint application's Web.config settings. Potentially the configuration settings there might conflict with the desired or assumed configuration of the custom ASP.NET application.

A close look at the Web.config for the SharePoint application shows the httpHandlers section specifically set for SharePoint. These changes configure the SPHttpHandler object to handle requests so the SharePoint engine can process requests based on virtual paths constructed in memory from content stored in the SQL Server database as opposed to the file system. Often this extra processing is not required in custom web applications. In those cases using the ASP.NET CustomPageHandlerFactory object instead would be more efficient.

To revert back to default ASP.NET handlers for ASP.NET web pages and web services, make the following changes to the httpHandlers section of the Web.config of the custom web application:

<add verb="*" path="*.aspx"

type="System.Web.UI.PageHandlerFactory"/>

<add verb="POST,GET" path="*.asmx"

type="System.Web.Services.Protocols.WebServiceHandlerFactory,System.Web.Services, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"

validate="false" />

</httpHandlers>

Edits to the httpModules section in the SharePoint application Web.config include adding the SPRequest and PublishingHttpModule objects. Again, this extra processing is often not needed in custom web applications. The PublishingHttpModule enables or disables ASP.NET output caching for resources in SharePoint and can cause an Event ID 5785 to be wrote to the event log with the description "Unable to connect publishing custom string handler for output caching" when inherited in custom web applications and certain requests like web service calls or static CSS files are made.

To revert back to default ASP.NET modules, make the following changes to the httpModules section of the Web.config of the custom web application:

<add name="OutputCache"

type="System.Web.Caching.OutputCacheModule"/>

<add name="Session"

type="System.Web.SessionState.SessionStateModule"/>

<add name="WindowsAuthentication"

type="System.Web.Security.WindowsAuthenticationModule"/>

<add name="FormsAuthentication"

type="System.Web.Security.FormsAuthenticationModule"/>

<add name="PassportAuthentication"

type="System.Web.Security.PassportAuthenticationModule"/>

<add name="UrlAuthorization"

type="System.Web.Security.UrlAuthorizationModule"/>

<add name="FileAuthorization"

type="System.Web.Security.FileAuthorizationModule"/>

</httpModules>

Another change to make is with the trust level to either increase or further restrict the trust for the custom web application. To override the inherited SharePoint trust level and set the trust level to full trust, make the following changes to the trust node in the Web.config of the custom web application:

Finally, when exposing Web Services through the custom web application, you may need to add the protocols for the Web Service so the application is able to process the request. Requests made on missing protocols throw an InvalidOperationException with the message "Request format is unrecognized for URL unexpectedly ending in '/...'" To add both the Get and Post protocol, make the following changes to the webServices section of the custom web application:

</protocols>

</webServices>

Generally I try to keep customizations within SharePoint as much as possible. One technique is to add PageParserPath nodes to the PageParserPaths section of the SharePoint application's Web.config. This will allow server-side code blocks added to custom ASPX pages hosted in SharePoint to execute. Another technique for web services is to deploy them to the ISAPI directory which maps to the _vti_bin IIS Virtual Directory.

Nonetheless, pre-existing custom web applications can quickly be consolidated and coexist with SharePoint applications by including the updates I mentioned throughout this discussion. These updates should help avoid some errors and ease the coexistence challenges.