Skip to main content

MOSS 2007 Installation – Service Accounts

In order to do a MOSS (aka Sharepoint) 2007 install using best practices, Microsoft recommends creating and using service accounts.
Click here for Microsoft article

I will summarise the long article into more relevant details (and for futher reading, you can click the link above)
Following are the service accounts I created and the permission levels specified for MOSS to install and function properly.

1. MOSS Setup Account (MOSS_Setup)
Typically, this is the account used to do a MOSS/Sharepoint install and setup.
This account is used for a lot of tasks – MOSS installation, creating new IIS sites and SQL Server databases.
It must belong to the Local Administrators group. Also, this account must be a Domain User, have access to the SQL Server instance to be used, with securityadmin and dbcreator roles.

2. SQL Server Service Account (SQL_Svc)
This is the account used to install the SQL Server instance to be used for MOSS databases.
I have used the account to run the SQL Server Service & SQL Server Agent Service.
Can be setup as a Domain User with no elevated permissions.

3. MOSS Farm Account (MOSS_Farm_Svc)
This account is used by the MOSS Server to access the SQL Server databases, and should be used as the identity for the Central Administration application pool and the WSS Timer service.
This account can be setup as a Domain User, need not be a local admin.

4. MOSS Application Pool Process Account (MOSS_AppPool)
When each application pool is setup, you must specify an account that will be used for that specific application pool’s identity. This account will be used to access the content databases associated with the web application. It is recommended that a new service account is created for each application pool. This should be a Domain Account with no specific permissions. When the account is specified & SharePoint creates the application pool, it automatically grants the account additional needed permissions.

5. Shared Service Provider Account (MOSS_SSP1_Svc)
This account is used for the Shared Services Provider (SSP) Web Services & the SSP Timer jobs.
It should be a Domain User with no elevated permissions.
It is a good practice to name the account using a number, since each SSP can run under its own account. This also helps connect the SSP Accounts back to the related SSP.

6. Office SharePoint Server Search Account (MOSS_Search_Svc)
This is an account used by the Shared Service Provider to crawl local & remote content.
This account should be a Domain User, having Local Administrator permissions on each MOSS server.

7. Default Content Access Account (MOSS_SSP#_ContentAccess_Svc)
This is the account used if a specific account (see #8) is not specified for the content source being crawled, unless a different authentication method is specified by a crawl rule for a URL or URL pattern.
Specific for each individual SSP, this account should be a Domain User and must have read access to the content sources it needs to crawl.

8. Content Access Account (MOSS_Content_Svc) - Optional
This is a specific account, specified when you create a new crawl rule, and configured to access a content source.
For example, content sources that are external to Office SharePoint Server 2007 (such as a file share) might require a different access account.
Like #7 above, this account should be a Domain User and must have read access to the content sources it needs to crawl.

9. Windows SharePoint Services Search Account (WSS_Search_Svc) – Optional
The WSS Services Search is only used to provide search capabilities within the Help content.
This account should be a Domain User with default permissions.

Comments

Popular posts from this blog

How to get SPUser or SPGroup from Person or Group field

You have person or group field in SharePoint list and you want to programmatically get the user or person. The below code to gets SPUser from User or Group field in the list when multiple choice and Groups are not allowed in the field: //get SPUser SPFieldUser userField = (SPFieldUser)item.Fields.GetField("Users"); SPFieldUserValue userFieldValue = (SPFieldUserValue)userField.GetFieldValue(item["Users"].ToString()); SPUser user = userFieldValue.User; This part of code would help you to get SPUser when multiple choice is allowed and groups are not allowed: //Multiple choices are allowed SPFieldUser userField = (SPFieldUser)item.Fields.GetField("Users"); SPFieldUserValueCollection userFieldValueCollection = (SPFieldUserValueCollection)userField.GetFieldValue(item["Users"].ToString()); foreach (SPFieldUserValue userFieldValue in userFieldValueCollection) {     Console.WriteLine("     " + userFieldValue.User.LoginName); } And when group

SharePoint publishing page scheduling

In SharePoint 2010 publishing enabled team site collection is not showing schedule button in publish ribbon. Solution: Here is how to enable it  though the UI: Locate the SharePoint Server Web site on which you want to enable content approval and item scheduling. Click  Site Actions , click  Site Settings , and then click  Modify Pages Library Settings . Under  General Settings , click  Versioning Settings . Click  Yes  next to  Content Approval , and then click  OK . Click  Manage item scheduling .   Click to enable the  Enable scheduling of items in this list  check box, and then click  OK .

Changing Content Type Hub URL

Change the Hub URL through powershell by using: Set-SPMetadataServiceApplication -Identity " " -HubURI " " For Ex: Set-SPMetadataServiceApplication -Identity "Managed Metadata Service" -HubURI "http://contenttype.Domain.Com" When you try to do this you get this rather scary message: This is SharePoint telling you that this is a major thing so be careful! Essentially all your content types that you have published out will be removed if they can, and you have to republish all of your content types out again which can cause some issue.