Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Use the Domain Groups for Clustered Services page of the Microsoft SQL Server Installation Wizard to specify global or local ___domain groups for the clustered services that will be installed as part of your SQL Server 2005 failover cluster.
To ensure a secure operating environment, access to resources on failover cluster nodes must be restricted. On a SQL Server 2005 failover cluster, ___domain groups that are common to all cluster nodes are used to control access to registry keys, files, SQL Server objects, and other cluster resources. All resource permissions are controlled by ___domain-level groups that include SQL Server service accounts as members.
Adding ___domain groups is one of the principal responsibilities of a ___domain administrator. Ensure that all ___domain groups for your SQL Server 2005 failover cluster are created or modified with consideration for the security policies of your organization.
Options
SQL Server service, SQL Server Agent service, Analysis Services service, and Full-Text Search service must run as ___domain accounts. The ___domain groups for these services must exist at the time SQL Server Setup is run. If necessary, ask your ___domain administrator for the names of existing global or local ___domain groups, or to create ___domain groups for your failover cluster.
For each clustered service in the instance of SQL Server that you are installing, enter the ___domain and group name in the format <DomainName>\<GroupName>, subject to the following guidelines:
- Domain groups can be global ___domain groups or local ___domain groups.
- Domain groups must be within the same ___domain as the machine accounts. For example, if the machine where SQL Server will be installed is in the SQLSVR ___domain which is a child of MYDOMAIN, you must specify a group in the SQLSVR ___domain. The SQLSVR ___domain may contain user accounts from MYDOMAIN.
- The user must be a direct member of the ___domain group, not a member via sub-groups. Setup will not follow sub-group memberships to validate that the user account is in the ___domain group.
- The ___domain and ___domain group names must already exist at the time Setup is run. If necessary, ask your ___domain administrator for the names of existing ___domain groups, or to create ___domain groups for your failover cluster. If ___domain groups are created immediately prior to running Setup, allow time for changes to propagate through a corporate network.
- The ___domain groups should have the appropriate service accounts added to them. If the service accounts are not members of the appropriate ___domain groups at the time Setup is run, Setup will attempt to add them. In this case, the account under which Setup is running must have adequate privileges to add accounts to the ___domain groups. If SQL Server Setup is run under an account that does not have permission to add users to the ___domain groups, the users must already be members of the appropriate group.
- Each service should use a different ___domain group. However, you can use the same ___domain group and the same account for all SQL Server services, you can use the same ___domain group and different accounts for each SQL Server service, or you can use a different ___domain group and a different account for each SQL Server service. To maintain the most granular control over permissions, use a different account and different ___domain group for each SQL Server service and for each virtual server in your ___domain.
- The SQL Server ___domain groups should not be shared with any other application.
Note that in order to troubleshoot ___domain group issues, you must have access to the ___domain controller.
SQL Server accounts will not be removed from the ___domain groups if SQL Server is uninstalled or if the accounts are changed. A ___domain administrator must ensure that all unwanted accounts are removed following removal of SQL Server.
See Also
Concepts
Before Installing Failover Clustering
Help and Information
Getting SQL Server 2005 Assistance
Change History
Release | History |
---|---|
12 December 2006 |
|