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.

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.