Naming conventions for SharePoint 2010 environments
December 28, 2011 8 Comments
[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 intranet.contoso.com, port 80:
intranet.contoso.com – 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.
Examples:
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.
Databases
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.
Christoffer von Sabsay 