Home > Microsoft, SharePoint > SharePoint takes a plan and other requirements…

SharePoint takes a plan and other requirements…


SharePoint is not a system that you can just deploy.  Basically, if you compare SharePoint 2010 with SharePoint 2003 it would be the same as Comparing a 2010 Dodge Challenger with one built in 1975.  The may look similar on the outside but the insides are all different (scratch that… you can make SP2010 look like 2003 but why?).  In 75, you could tweak or replace a carburetor for better performance but with the 2010 model, it’s a setting managed by the onboard computer system.  Even changing the light bulb on the new Challenger is a challenge (trust me, you have to pull the front bumper off…)!  Sorry, back to SharePoint.

With Improvement Comes Complexity

Under the hood, SharePoint is all new.  While there may be some remnants hanging around the new beast is really comprised of a bunch of independent services.  Something you discover pretty quickly after the bits are installed and you’ve visited both sides of the administration points.  Both sides?  Well, that depends on the the number of folks working on the project, who’s on first, what’s on second and so on.

image

The thing that’s nice about the service model is the ability to scale out over multiple servers.  This adds a nice bit of scalability to the platform and reduces the strain on the crystal ball.

Search

Now promoted and does more.  Check…SNAGHTML1799997  Well, a little more than that.  Native search is one of the new services.  Now, just because you’ve enable the service doesn’t mean it just works…  There are a few steps and site particulars that need to be addressed before search is usable.  See Post-installation steps for search…

But just talking about search brings up some interesting points.  Which version of SharePoint you run will largely be dependent on the budget available.  Enterprise builds upon Standard that builds upon Foundation.  In fact, Foundation may be all the SharePoint you need at this time. See SharePoint Products.  For some additional content, see SharePoint Server 2010 Operations Framework and Checklists.

SharePoint is a large ecosystem with deep features.  Great stuff but be prepared for a learning curve.

Heath and Well Being of SharePoint

This one gets a bit sticky.   It was also the most challenging point to convince the IT department to set up a sufficient number of service accounts.  What really doesn’t help is the challenge of finding a concise list of what accounts are needed.  You are going to love to learn to hate this:

image

You’ll spend a lot of time going through messages like:

image

Now, the ability to get help from within the application has improved.  When I first started clicking on the links,  the web page that opened was the general SharePoint landing page with no reference to the error provided the link…

Now, 9 time out of 10, you land on a page with helpful information:

image

The following figure shows that there is just one or two accounts that can be specified for SharePoint:

image

First, as far as accounts go, you need a specific administration account to set up and configure the server.  After that is done, you’ll use that account to log into the server to specify the individual DOMAIN accounts to use for SharePoint.  Some services can use the same account while others it is best to specify their own account.

One of the nice features to plan for is Automatic Password Change.  Your domain accounts are going to be subjected to password expiration rules unless you override that policy.  Since SharePoint can manage its own password change process, it’s a good thing.

image

A good document that addresses the accounts is Account permissions and security settings.    Basically the list is as follows:

Account Used for Comments
sp_Admin Server administration / Farm administration Domain account, used when the server is created.  Gets many of it’s permissions through components.
sp_SetupUser used to setup each server in the farm Must be a domain account, a member of the local admin, and must be able to access the SharePoint server database.  If PowerShell is used the account must be a member of db_owner on the database server and have security admin and dbcreator rights.  You’ll want to keep this account around.  Removing it can cause all sorts of chaos.
sp_FarmService (database access account) application poll identity for central admin,  process account for SharePoint foundation and runs the TimerService Must be a domain account with user account permissions
Granted additional permissions through SharePoint tools.
sp_SearchService SharePoint basic search features Must be a domain account with user account permissions
Granted additional permissions through SharePoint tools.
sp_SearchContentAccess crawls across sp content sites Must be a domain account with user account permissions
Must be a member of the Farm Admin group
Granted additional permissions through SharePoint tools.
sp_ApplicationPool application pools Given machine level permissions through SharePoint tools or configured separately through PowerShell
sp_MySiteAppPool application pool Must be a domain account with user account permissions
Must not be a member of the farm admin group

That’s a start.  for additional information, see the provided link above.  For all accounts listed that need to be a domain account the format is <domain>\<user account>.  ex: Domain\sp_Admin

Advertisements
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: