Naming conventions for SharePoint 2010 environments

[Updated 2011-12-29]
I have updated the guidelines below after some good feeback in the comments.

In my job as a SharePoint Architect, I frequently help different clients setting up their SharePoint environments and helping out with operations and troubleshooting. When operating a SharePoint environment, a consistent naming of SharePoint objects such as web applications, application pools, databases and so on definitely makes life a lot easier. There are no official guidelines regarding how to name things though – administrators are mostly free to give the objects any name they like – but it’s definitely a good practice to have some form of consistency here.

Below is my proposal for naming conventions that should work well for most organizations. It’s not something I have invented myself – it’s rather a compilation of how most clients I have worked with choose to name their SharePoint objects.

Web Applications

Web Applications should be given a name that clearly reflects both the default URL and port number.

Proposed pattern: {Host Header} – {Port}

Example for a site with host header, port 80: – 80

Service Applications

The most straightforward way to name service applications is to use the same name as the service application type. You can see the names of the different service application types in the “New” dropdown button on Manage Service Applications in Central Administration.

If more than one service application exists, just add a dash and an additional value that differentiates the service application.

Excel Services Application
Managed Metadata Service
Secure Store Service

Examples with more than one service application of the same type:
Corporate level: Managed Metadata Service
Department level: Managed Metadata Service – Sales Department

Application Pools

For web applications and service applications with their own application pools, simply give the application pool the same name as the web application or service application. For shared application pools, give it a name which clearly reflects how it’s used.


The database names should have a clear relationship to the web- or service application it belongs to. Also, it’s good to not go too far away from SharePoints default naming suggestions. Without the nasty GUIDs of course.

Option 1 – Web application and service application name
The following option works well if you want a naming convention that’s similar to SharePoints default names, and where each farm has a separate SQL instance.

Proposed pattern for Content Databases: WSS_Content_{URL to Web Application}, dots converted to underscore.
Example: WSS_Content_Intranet_Contoso_Com

Proposed pattern for Service Applications: {Service Application Name}, blankspaces converted to underscore.
Example: Managed_Metadata_Service

If needed, databases could also be prefixed with a value that differentiates the databases. This makes management easier since databases are listed in alphabetical order in SQL Server Manager.

Option 2 – Technology_Organization_Scope_DatabaseType
John W Powell has proposed this pattern for naming database which works well for environments where several farms and organizations share the same database instance. However this system for naming databases differs quite a lot from SharePoint default names and may feel unfamiliar for many admins. And since all databases are prefixed with the specific SharePoint version number, a lot of renaming will be needed after future upgrade to the next version of SharePoint.

Solution Packages

When building your solution packages, you can let your build server add a label to the WSP packages before putting them at the drop location. This makes it easy to see exactly which version is installed in each environment though the Manage Farm Solutions page in Central Administration.

Proposed pattern: {Company}_{Solution Name}_{Version}

Example: contoso_intranet_1.0.0.23.wsp

Other objects

In addition to these naming conventions, there are several other SharePoint objects such as service accounts in Active Directory and server names, where  naming conventions usually applies. Most organizations already have a system in place for naming these objects that needs to be followed, independent of SharePoint.

Share your thoughts and ideas!

What do you think of these proposed naming conventions? Got any additional ideas or alternative options? Feel free to post a comment with your suggestions.

Design Patterns for developing SharePoint 2010 Solutions

Last week at the European SharePoint Conference, I talked about a few different design patterns that you can use when you develop custom solutions for SharePoint 2010, to make sure that your code is easy to maintain, extend and test.

We specifically talked about the following patterns:

• Repository
• Model-View-Presenter
• Service Locator

Each of these patterns offers a solution to different design issues that you might encounter when creating code based solutions. Our development team has successfully applied these patterns on several client projects where a fair amount of custom development was needed. However, applying the patterns will require some initial extra work and requires the developers in the team to be somewhat familiar with the patterns. So only apply them when you really see that you can get some benefit out of them.

Please check out the slides and sample code from the session.

To get started with the sample solution, please do the following:
• Download and unzip the package
• Open the SharePointEurope.DesignPatterns4 solution (the final solution where all patterns have been applied, as well as the configuration settings management)
• Deploy the SharePointEurope.Dependencies package to ensure that the common service locator library and application foundations are deployed to the GAC
• Create a site collection and deploy the SharePointEurope.DesignPatterns4 project to the site.
• Generate a Google Map Key for the host name of your web application and go to the configuration list (/Lists/Microsoft_Practices_SharePoint_ConfigList) and set this value.
• Create a few hotels in the Hotel list (/Lists/Hotels)
• Add the hotel finder web part somewhere and try it out

A few notes regarding the things we discussed at the session:

Repository implementation
There are many different ways to implement the repository pattern in SharePoint. In my sample implementation you have two options when creating the repository: Either provide the repository with a specific SPWeb object in the constructor, or use the context of the current web site. It’s important to make sure that you can use your repository from contexts where SPContext.Current is not available, such as i.e. timer jobs. Another option is to use configuration settings to provide an URL to a centrally located site where the hotels list is located – which is useful if you want to use the repository on other sites than where the list exists.

If you look at how the training management application in SharePoint Guidance 2007 is implemented, you can see that they use a slightly different approach. In that implementation, you need to provide the repository with an SPWeb object in each of the repositorys data access methods.

The problem with this approach is that your repository interfaces becomes cluttred with specific dependencies to SharePoint. An important goal of the repository pattern is that you should make yourself independent of exactly how the data is stored. And if you decide to change the data storage from SharePoint to i.e. SQL Server, you would need to not only change the implementation of the repository, but the interfaces and all the code that depends on it as well. In my opinion, it’s much better to let the repository get the data context it needs internally instead, or to use dependency injection to configure exactly how it’s provided to the repository. Here you could benefit quite a lot from using a proper dependency injection framework rather than the SharePoint Service Locator.

List based configuration
During the demo I showed you a simple example on how you could generate a configuration list and use it to store, retrieve and update settings. If you decide to go for the list based approach, I encourage you to check out the List Based Configuration Quickstart that’s available as a part of the SharePoint Guidance 2010 package. It’s a bit more refined and basically implements the same interfaces as the property bag-based configuration classes do. This makes it possible to use lists to store you configuration settings for any level of the farm (farm, web app, site collection or web) by specifying the path to a centrally located site collection where the settings are stored.

Using Application Foundations in sandboxed solutions
I got a few questions after the session about using the Application Foundations Library in sandboxed solutions.

The application settings manager can be used in sandboxed solutions, but there are a number of limitations of course. You can read more about using the application settings manager in sandboxed solutions here:

I haven’t tried the SharePoint Service Locator in a sandboxed solution yet – if anyone has done that, I would be happy to hear about your experiences. Otherwise, there are plenty of other options for implementing the pattern, including implementing your own simple code-based service locator.

Sweden SharePoint User Group in Stockholm

Last Thursday, Sogeti hosted a Sweden SharePoint User Group (SSUG) meeting in Stockholm. SSUG is a user group which arranges meet-ups a few times each year, where participants can exchange their thoughts and experiences on SharePoint.

The first speaker was Markus Persson from Sogeti SharePoint Center in Stockholm. He talked about and have a demo of a Business Intelligence portal that has been built on SharePoint 2010 for the Municipality of Umeå in Sweden. The solution gives executives on different levels in the organization quick and easy access to the statistics and key performance indicators that are relevant for them.

Another speaker was Peter Nicks, who is Product Marketing Manager for SharePoint in Sweden. He gave a presentation about how to leverage the power of SharePoint within the organization, and how to take advantage of all the features and services that the platform provides. Måns Barklund from Microsoft also held a presentation and demo of Project Server 2010.

SharePoint User Group is a great forum for everyone who works with SharePoint – developers, end users, administrators and IT Pros. More information and upcoming events can be found at the web site

A case study of the the BI solution of Umeå can be found here.


SharePoint 2010 Genesis Framework – A framework that will help you create amazingly structured SharePoint solutions

Summary: SharePoint 2010 Genesis Framework is a framework that helps you declare fields, content types, lists and feature definitions through code. It also helps with provisioning and stronly typed data access.

One of SharePoints greatest strengths is its flexibility. Power users can easily create very powerful solution without much involvement of developers. In many cases though, custom development is needed for parts of a solution. In those cases, it’s very important to properly package the code together with the storage structures such as site columns, content types, lists, views and so on into a solution package.

However, doing this the “classic” way – defining the storage elements with CAML can cause some challenges both during the development phase and when the solution goes to application management. Most developers struggle with the following challenges:

• A lot of CAML/XML needs to be written
• It’s difficult to handle additions and changes to content types already in use
• No strongly typed access to SharePoint Data, unless you choose use LINQ-2-SharePoint

The new upgrade actions in SharePoint 2010 helps somewhat, but when working in an agile manner with deployments every 2-3 weeks, the XML can get really messy.

What many developers do is to manage most of the provisioning of content types, site columns, etc. with code and “ensure-style-features” that incrementally update the content types, lists, views, etc. This requires quite a lot of coding though, and many developers create their own helper classes that quickly evolve into “mini-frameworks”.

Tony Restaino, a senior SharePoint developer at Avega has been working on this issue for a while and have recently released an extensive framework to solve this issue – SharePoint 2010 Genesis Framework (SPGEN).

Tony and I have been working for a client on a two large SharePoint projects for a while now, and we have been using this framework to define content types, site columns, features, etc. and all the provisioning and data access. Want to add a new field to a content type? No problem – just create the field as a class, add it to the content type, rebuild and deploy the code, reactivate the feature and it’s there! The framework has also helped us implementing the repositories with with strongly typed data access in no time!

It’s just amazing how easy life gets with solutions like these! If only Microsoft could be just as thoughtful as Tony when developing the SharePoint API 🙂

A few of the key features of SPGEN:

  • It allows you to create classes that represent the different kind of elements in SharePoint – Site Columns, Content Types, List Instances, Views, Features etc.
  • You set attributes on the classes that correspond to the attributes of the SharePoint XML elements. This gives you strongly typed access to the definitions at any time!
  • The framework provides a lot of helper methods to provision fields, lists, views, etc. It automatically takes care of incremental updates, such as adding a new field to a list.
  • It also provides a way to easily create ListItem–object field mappers that maps list items to any class – no need to use the nasty auto generated mega classes from SPMetal!  You can even create your custom field adapters if you have custom columns that maps to complex data types.
  • It provides data access methods that allows you to do both CAML and LINQ queries against the lists, and returns the result as strongly typed objects.
  • It provides a LINQ implementation that has a LOT better performance the LINQ-2-SharePoint (at least according to our own measurements).

As you can see, it’s a very competent framework that can save a you lot of work – especially when developing custom code-based solutions. I strongly encourage everyone to check it out and give it a try!

Read more and download the framework here:

Configuration Management with Sandboxed Solutions

In our current project, we’re just about to introduce our first sandboxed solution into our SharePoint farms. This raises some interesting questions regarding how this fits into our existing configuration management process.

Until recently, we only had full trust solutions in our farms. Do deploy these, we go through a pretty straightforward change management process: The build server builds the solution packages, labels the code and assigns the version number to the WSP name. Developers can then deploy the packages to the integration environments, to which they have full access as administrators. When the packages are ready for testing, developers sends a request to Configuration Management (CM) to deploy certain packages to the test environment. CM then contacts operations, who perform the deployment. When user acceptance testing is completed, the packages are deployed to production.

This process works very well for full trust solutions. But how do things change when we start introducing sandboxed solutions? It’s not obvious at first how these fit into the established configuration management process.

If the user code service is enabled, sandboxed solutions can be deployed to any site collection without involvement of the farm administrator. It’s considered safe to do so because the code runs in an isolated process, and because the resource usage is monitored and limited. Does this mean that should be free for all site collection administrators to install whatever solutions they want on their sites?

The answer is, of course, no. The sandbox is just an execution model that affects the maintainability and the level of isolation the code runs in. However, from a configuration management point of view, sandboxed solutions are no different than full trust solutions.

Sure, the sandboxed solution can’t compromise the overall stability and performance of the farm, but it can still mess up the site collection it runs in. If the code you write provides features that are business critical for the end users (or might become in the future), it doesn’t matter if you run it in a sandbox or not. If you want predictable results, you still need to test your solution in a production-like test environment. And of course, you still need to keep track of exactly which version is deployed to each environment.

So, we decided to apply the same CM process to all solutions – sandboxed or not. The only difference is that operations doesn’t need to perform the deployment, site collection admins can do that themselves after getting approval from CM. And of course, all packages must go to the test environment first to ensure everything works as expected before deploying to the production environment.

Different techniques for storing application settings in your SharePoint solutions

When building custom SharePoint solutions, you often need to store and retrieve application settings such as connection strings, default values, cache expiry settings, etc. In this post, I will go through a few different options that are available and some considerations you need to make before deciding which way to go.

Application Foundations Configuration Manager
The Application Foundations for SharePoint 2010 includes several useful components such as a service locator, logging utility and application settings manager. The application settings manager provides an API to store and retrieve settings on several different levels – farm, web application, site collection and site. The SharePoint property bag at each level is used to store the values and the unique prefix PnP.Config.Key is used to avoid conflicts with other values in the property bag. The only drawback with this solution is that there is no out of the box GUI for setting and updating the values, so you need to write custom code or use the property bag editor available on CodePlex.

Configuration files stored in the 14 folder
Another option is to store your configuration values in an XML file and deploy it to a subfolder in 14/CONFIG. You can then write a simple configuration settings reader class that reads and caches the values stored in the file. The best thing with this approach is that it’s really easy to deploy your settings to different environments by creating separate configuration WSP packages  that includes the configuration settings files. However, if you need to change a value you would need to update and redeploy the configuration package. Therefore, this technique should only be used for global settings that are fairly static, and doesn’t need to be changed through the UI once the solution has been deployed.

SharePoint list
Another popular option is to use a SharePoint list to store configuration values. You can create a list on the site collection root site called Configuration Settings or similar, and store your values there. There is a handy solution on Codeplex called SharePoint config store that provides a nice API for retrieving the values and it also takes care of caching. Since you’re using a SharePoint list, you can use the out of the box SharePoint GUI to set and update the values. You can also enable versioning on the list to keep track of the configuration changes. The only drawback with this solution is that your settings will be stored on the site collection or site level. For global settings that needs to be available across site collections you would need to use one of the two previous techniques.

Web.config should not be used for storing configuration settings in SharePoint solutions, unless there is no other option available. Unlike a classic ASP.NET application, you are not in charge of the web.config file – SharePoint is. And the only supported option for storing settings in web.config is to use SPWebConfigModification class to register the additions to web.config.

As you can see, each approach has different pros and cons and you should choose the appropriate technique depending on the scope of the setting, and if it needs to be updated  through the UI after the solution has been deployed.

No matter what option you choose, I would recommend that you create a common static configuration settings class with strongly typed property getters to access the settings. That way, you are free to use a combination of the different techniques and, if necessary, to change the underlying storage mechanism for your settings without impacting your code.

December CU for SharePoint 2010 released

Just before new year, the December CU for SharePoint 2010 was release by Microsoft. There seems to be quite a few fixes in this update.

One issue that is resolved is that browser file handling was automatically set to strict on all sites created on a custom site template, not matter what setting the web application had. The only workaround was to correct this with a WebAdded event receiver – not too pretty solution.

Our customer stores e-mail messages in SharePoint sites based on custom site templates and need to open them directly in Outlook, which requires Browser File Handling to be set to Permisive, so we’re really happy that the issue got resolved.

The list of fixes included in the December CU can be found here:

The links to the downloads can be found here: