Microsoft Office Tutorials and References
In Depth Information
If you are using SQL 2005, you will need to enable remote access manually (it is not automatically
enabled, as it is for SQL 2008). So if a server farm install keeps failing no matter how perfect your
settings, you will need to do the following:
1 .
Use the SQL Server Surface Area Configuration Tool. You can select it by choosing Start
All Programs Microsoft SQL Server 2005 Configuration Tool SQL Server Surface Area
2 .
In the SQL Server 2005 Surface Area Configuration window, in the Configure Surface Area For
Localhost section, select Surface Area Configuration For Services And Connections.
3 .
In the window that opens, in the list of services and connections on the left, make certain you
are using the correct server instance (mine is the default MSSQLSERVER instance), and then
select Remote Connections. In the configuration area on the right of this selection, you’ll specify
whether SQL Server 2005 will allow remote connections, which SharePoint needs. Choose Local
and Remote connections, and then select Using TCP/IP and Named Pipes (because locally that
is what SQL uses). This will make SQL available to SharePoint.
4 .
When you’ve made your selections, click OK. Close the SQL Server 2005 Surface Area
Configuration window.
As you know, additional accounts should be specified during the configuration of SharePoint
in a server farm scenario. In a single-server environment, the local service and network service
accounts will work fine as the account identities for all SharePoint’s services. Domain accounts
come into play only when the SharePoint services may need to access resources (such as
databases on a remote SQL server) that are not on the local server.
For a server farm installation, in addition to the setup account, the server farm (or just “farm
account),” Search, Index (content access), and Content Database (web application, database access,
or just database account) services also require an account context in which to run.
The following is a rundown of the service accounts we need, plus my example of the domain
user accounts I will be using. None of these accounts is more than simple domain users (so if you
are using the instructions from the “Setup Account, Meet Server Farm” sidebar, do not add these
accounts to the Domain Admins group). They do not need administrative rights to anything. Any
permissions to SharePoint folders or databases will be assigned by the farm account as needed.
One of the problems with having numerous domain accounts used as identities for all of these
services is managing password changes for the accounts. This is one of the reasons some businesses
limit the number of service accounts used with SharePoint. Previously, if an account was used by
an application pool or service and that account’s password changed, there was no automatic way for
SharePoint to know, and because it didn’t know, it would use the wrong password when prompted
(behind the scenes). This means the password for the service accounts had to be manually updated
for any service account used by SharePoint. This has changed with SharePoint Foundation.
Search JabSto ::

Custom Search