At CSG we’ve been ploughing through SharePoint 2010 installations of late and have been trying to learn from our build experiences from SharePoint 2007. I just read Wouter’s post on naming service accounts that he’s just posted and figured I’d put my 2cents in.

Service Account naming

Completely agree on giving these things:

• readable names - that any AD person can make sense of
• prefix with SP – so that you can see they’re SharePoint Farm related
• postfix with service – I really like taken this a little further by using the below
  • prefix with svc for all accounts
  • suffix apppool for Application Pool accounts
• environment prefix– I also find in most organisations that they use one Domain for Dev, Test, Prod…yes I know…shudder. But you have to play with the cards you’re dealt with. So to overcome this and encourage good separation I use environment suffix’s too:
  • dev for Development environment
  • tst for Test environment
  • prd for Production environments

My experience is that you have to follow the customers standards more often than not so this usually gets thrown out the window.

Another gotcha to watch out for is that AD user names on pre 2008 AD domains will not like names over 20 characters like the ones below and SharePoint will expect them to be entered as the 2000 compatible names e.g. “svcDevIntranetAppPool” –> “svcDevIntranetAppPoo”….<giggle> “jeremy said Poo!” </giggle>

An example 3 environments farm is below:

Database naming

Another thing to bear in mind is Database names. I strongly recommend keeping SharePoint Databases in their own SQL Instances as you give the Farm Account dbcreator and securityadmin roles.

If you use the wizard approach to install you’ll get horrible GUID db names, if you use PowerShell scripts you’ll get choice. @brianlala’s scripts are a great start on this, just needs scripts for all the Service Applications. Again I try and make these names obvious too!

The approach I take here is:

• prefix with SP2010 – prefix with SP2010 to show what major version of the databases it is
• prefix with role of db – what am I?
  • Config – a config database
  • Logging – a logging database
  • WebApp – a web application content database, also then prefixed with which Web App so if there are multiple Content Databases they’re grouped
  • Service – a service application, also then prefixed with which Service Application it is

This makes it great for grouping things together

Now again, this isn’t set in stone, but this is “how I roll”.