Account Names, SharePoint Setups, Server 2008 and Cheese

Recently I got a brand, spanking new Dell Latitude E6400 for work outfitted with Server 2008 (you won’t believe how hard that corporate battle was) and 8GB of RAM. We wanted to run Server 2008 as our workstation which would allow us a) the ability to run SharePoint natively and b) the ability to spin up additional/sandbox SharePoint instances using Hyper-V.

Of course these machines are also on the corporate domain so running SharePoint locally proves a few challenges. For example you really don’t want to use domain accounts for your SharePoint setup as I’m offline a lot so with no domain controller that doesn’t work. Try as I might, I can’t make my machine a domain controller (what I usually do with a VM running SharePoint). The network guys seem to have a problem with that. So it’s local accounts for the SharePoint. There’s a few tricks to this to get it to work though.

When I setup a new SharePoint development environment, I follow Scot Hillier's excellent set of instructions from Building Office 2007 Solutions in C# 2005. They start on page 35 of the book and IMHO the best instructions for configuring a VM or dev environment around as they use the principle of least privilege administration which is how you should roll when you build your dev boxes.

With a machine on the network and the inability to use domain accounts, you regress to using local accounts for a local dev setup. I still setup the accounts as described in the book over a single account, but there are a few gotchas to know when doing this:

  • You cannot use a local group for the farm administrator group so don’t bother creating it. Just add users to the list if you need them. By default, after the install you’ll have BUILTIN\Administrators, the local SPConfigAcct, and whatever account you used to install the system with in the group. This should be sufficient for development.
  • When configuring the Office Server Search Service you must specify the Farm Search Service Account with a fully qualified name (even though it’s a local account) so use MACHINENAME\SPSearchAcct.
  • When configuring the Windows SharePoint Services Search Service you must specify the Service Account with a fully qualified name.
  • When configuring the Windows SharePoint Services Content Access Account use the account name without the machine prefix.
  • When creating sites I use the local hosts file as I don’t have control over DNS so I can’t create new A records. This of course means you can’t use Kerberos locally but that’s okay, NTLM is fine and I have VMs with domain controllers that I use for that testing. Create local host records for http://ssp, http://mysite, and http://sitename for easy access.
  • When creating the new Shared Services Web application you must account name without the machine prefix.
  • When configuring the Shared Services Provider you must specify the SSPServiceCredentials with a fully qualified name.

When I setup a new system I create a few new web apps so I have different web configurations to work with. AC mentions he creates a publishing site, team site, and blank site. I create the following in new setups (YMMV):

  • http://sharepoint – My main development site used for pretty much everything. Things developed here are turned into features to be deployed to a staging/test environment. Uses the collaboration portal template.
  • http://collab – Stock SharePoint site that I create in case I need to get something untouched from it (master pages, etc.). I use this to sometimes see what the original looked like after I screw things up in the sandbox. Uses the Collaboration site template with a set of stock publishing, news, etc. sites created under it.
  • http://wss – Not really Windows SharePoint Services because I install MOSS but a blank site using the WSS templates (team, blank, wiki, etc.) when I need to try things out in pseudo-WSS mode. I have a few WSS VMs that I use for things like testing that something truly works in WSS-only mode but this site does me fine for the most part. Uses the blank site template.
  • http://pub – Publishing site. This uses different master pages and is a good site to have for checking content only type sites. I’ll publish content from sandbox to here sometimes to see what it might look like under different master pages. I’ll install pretty much all the master pages available out there into the site and it’s more of a look-n-feel test site than anything. Uses the publishing portal template.

Hope that helps. Enjoy your Server 2008 setup!

P.S. There is no cheese here.

1 Comment

  • Installing sharepoint onto a domain controller causes issues with the document conversion functionality, something to consider for publishing sites.

Comments have been disabled for this content.