ptg 264 CHAPTER 10 Client Installation and Configuration was introduced in SQL Server 2005 and was a key part of client configuration. The func- tionality made available in this tool has now been replaced with Policy-Based Management features and changes in the SQL Server Configuration Manager (SSCM) tool. For example, the option to allow Remote Connections that was available in SAC is no longer there. You should look to the SSCM tool and enable or disable the protocols for which you want to allow connections. The details of this change are discussed later in this chapter, and a full discussion of Policy-Based Management is provided in Chapter 22, “Administering Policy Based Management.” One last change in SQL Server 2008 Client Installation and Configuration that may rear its head relates to the BUILTIN\Administrator windows group. By default, this group is no longer included in the SQL Server sysadmin fixed server role on new SQL Server 2008 installations. So, by default, network administrators and administrators of the machine where SQL Server is running are not able to log in to SQL Server and administer it. In past versions of SQL Server, the BUILTIN\Administrator windows group was added to the sysadmin role. To grant administrators permission to SQL Server, you can manually add the BUILTIN\Administrator group to the sysadmin SQL Server role, or you can add each individual network administrator that needs to access SQL Server to that role. The change to the BUILTIN\Administrator windows group is in line with Microsoft’s strat- egy to “secure by design, secure by default, and secure in deployment.” This strategy relates to many aspects of SQL Server, including installation, security, and client installa- tion and configuration. The strategy is a good one but can cause you, as the administrator, some extra grief if you are not aware of the impact that these changes can have on you and your users. Client/Server Networking Considerations Before we delve into the features on the client side in SQL Server, it’s important to make note of a few server-side features. This information will help you gain an understanding of which networking features are initially configured on the server (after an installation or upgrade) as well as how incoming connections are dealt with. Such knowledge can be invaluable in diagnosing connectivity issues. If you’ve been following along chapter by chapter, you’ve learned how to install or upgrade an instance of SQL Server 2008. To get your clients up and running fast, you must be sure the Database Engine is listening for them. The following sections describe how to set up the server’s basic network configuration, including configuring it to accept remote connections, learning which protocols it supports, and understanding how it listens for and responds to client requests. Server Network Protocols The first and most basic step after a SQL Server installation or upgrade is to make sure the appropriate network protocols are configured on the server. Download from www.wowebook.com ptg 265 Client/Server Networking Considerations NOTE Note that the term server is used here to refer to an instance of the SQL Server 2008 Database Engine. The term client is used generally to mean any program that needs to communicate with a server. The server and client may reside on the same physical machine (especially when using SQL Server Mobile and Express Editions). First, you should ensure that the protocols your clients once used to connect to SQL Server 7, 2000 or 2005 (or that your clients would like to use) are still supported by SQL Server 2008 and configured. You might be surprised to learn that the following protocols that were supported in SQL Server 2000 are not supported by SQL Server 2005 or SQL Server 2008: . AppleTalk . Banyan VINES . Multiprotocol . NW Link IPX/SPX If you were using these protocols and you’ve upgraded from SQL Server 2000, your clients are no longer able to connect. Following are the only protocols that SQL Server 2008 supports: . Named pipes . Shared memory . TCP/IP . Virtual Interface Adapter (VIA) If you were using any of these protocols and you just upgraded, Setup copies your pre- upgrade settings over to SQL Server 2008, including the enabled state, IP addresses, TCP ports, pipe names, and so on. Clients can simply test their connections to be sure the upgrade was successful, and in most cases, no changes need to be made. NOTE The Shared memory protocol works only for connections both to and from the same machine hosting the Database Engine. Shared memory is used by client tools such as SQL Server Management Studio (SSMS) and SQLCMD, and it’s also a good choice for use by locally running custom applications because it is secure by design. (It is the default protocol used by local applications that do not specify otherwise.) All remote connections to SQL Server are thus disabled by default. Following is an extremely common client-side error message illustrating connection failure due to disabled remote connectivity: 10 Download from www.wowebook.com ptg 266 CHAPTER 10 Client Installation and Configuration FIGURE 10.1 Enabling remote connections over named pipes using SSCM. A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. The exact wording of this message varies slightly, depending on the particular client or connection method used. The same error also occurs when the Database Engine service is stopped. In SQL Server 2008, remote connections must be enabled for each network protocol on which you want the server to communicate. This is easily accomplished using the SQL Server Configuration Manager (SSCM). You launch SSCM from the SQL Server 2008 Configuration Tools menu group. In SSCM, you expand SQL Server Network Configuration and then select the Protocols entry for the SQL Server instance that you want to configure. In the Details pane, right-click on one of the available protocols (for example, Named Pipes) and select Enable to allow connections for this protocol (see Figure 10.1). SSCM serves many purposes and is discussed in detail later in this chapter. When the protocol is enabled, SQL Server is configured to listen for connections from clients using the same protocol. You must restart the SQL Server instance for the changes to take effect and for SQL Server to actually start listening for connections. You can verify that SQL Server is listening on the protocol that you have enabled by looking at the SQL Server error log. Each time the SQL Server instance is restarted, messages are written to the log indicating which protocols it is listening on. The following sample error log messages show what SQL Server is listening for: Server is listening on [ ‘any’ <ipv4> 1719]. Server named pipe provider is ready to accept connection on [ \\.\pipe\MSSQL$INST2008\sql\query ]. Download from www.wowebook.com ptg 267 Client/Server Networking Considerations 10 SQL Server listens on all configured protocols simultaneously, giving no preference or priority to any. This is in contrast to the explicitly prioritized manner in which clients attempt to connect via all configured protocols. The client configuration is discussed in detail later in this chapter. NOTE In SQL Server 2005, the Surface Area Configuration (SAC) tool also could be used to allow remote connections and to configure the protocols on which they communicate. The SAC tool has been removed in SQL Server 2008, so you need to look to the SSCM to configure your protocols. The Server Endpoint Layer A networking feature in SQL Server 2008 adds an additional layer to the client/server network structure: Tabular Data Stream (TDS) endpoints. When you install (or upgrade to) SQL Server 2008, a default system endpoint is created on the server for each available protocol on the server. These endpoints cannot be dropped, and they are created regard- less of whether the protocol is disabled or otherwise unavailable. NOTE The term endpoint in this context refers to the combination of a protocol selection, one or more IP addresses (or pipe names), and any associated port numbers. These are the default system endpoints: . TSQL Local Machine (for shared memory) . TSQL Named Pipes . TSQL Default TCP . TSQL Default VIA . Dedicated Admin Connection (also known as the DAC) You can view these endpoints and check their status by executing the following T-SQL statement: Use Master GO SELECT * FROM sys.endpoints WHERE principal_id = 1 By default, all users are granted access to these endpoints (except the DAC, which is only for members of the sysadmin role). Administrators can create new endpoints on the server to increase connection security by stopping (or disabling) the default system endpoints and then creating new user-defined endpoints that only specific clients can access. Download from www.wowebook.com ptg 268 (Creating a new system endpoint automatically revokes permission on the default endpoint of the same protocol to the public group.) NOTE Only one named pipe and one shared memory endpoint can exist per instance, but multiple VIA or TCP endpoints (with different port and address settings) can coexist. Each endpoint communicates with clients via TDS packets, which are formatted on the server side by SNAC and on the client side by SNAC or another of the net-libraries. Administrators have the option of stopping and starting endpoints while sessions are still active, preventing new connections from being made while still supporting existing ones. An administrator can grant or revoke endpoint access to specific users or groups (for example, preventing backdoor access through client tools). It is therefore important for clients to know that this structure exists and to learn how they receive permission to connect to endpoints through a server-side process known as provisioning. Client Access Provisioning There are three fairly straightforward rules of access provisioning. If any one of these rules is met by an incoming client, that client may access the endpoint. If none are met, the client is denied access. These are the rules: . If the client specifies an IP address and a TCP port that match those of a specific endpoint, the client may connect to it, if the client has permission to do so. . If only the TCP port specified by the client matches that of a specific endpoint, and the endpoint is configured to listen on all IP addresses, the client may connect to it, if the client has permission to do so. . If neither the TCP port nor IP address is specified, but the default endpoint for the protocol is enabled, the client may attempt to connect to the endpoint. NOTE If the endpoint to which access is successfully provisioned is currently stopped, or if the user does not have permission to connect to it, no further endpoints are tried and the client cannot continue. For example, let’s say a server has three TCP/IP endpoints defined: . The default (TSQL Default TCP), which listens on all IP addresses and Port 1433 (a default SQL Server 2008 instance) . A user-created endpoint called TCP_UserCreated 101_91, configured to listen on IP address 192.168.1.101 and Port 91 CHAPTER 10 Client Installation and Configuration Download from www.wowebook.com ptg 269 Client/Server Networking Considerations 10 . A second user-created endpoint, called TCP_UserCreated Any_91, which is config- ured to listen on all IP addresses and Port 91 A client attempts to connect specifically to 192.168.1.101:91. Because this is an exact address and port match, the client can try to connect to TCP_UserCreated 101_91. Having an exact address and port match meets the first provisioning rule. A second client attempts to connect to any IP address on Port 91. Because there is no exact address match, the client cannot attempt to connect to TCP_UserCreated 101_91. However, the client can attempt to connect to TCP_UserCreated Any_91 because it is configured to listen on all IP addresses. This meets the second provisioning rule. A third client attempts to connect on any port and any address. If TSQL Default TCP is started, the client is granted permission to attempt to connect. This meets the third provisioning rule. NOTE Settings such as IP addresses and TCP ports are used to implicitly connect to specific endpoints. These values are specified by clients in connection strings, data source names (DSNs), and server aliases, all of which are discussed later in this chapter in the “Client Configuration” section. TIP If, at any time, you want to discover which protocol and endpoint a connected client is currently using, you can run the following T-SQL to list the current connections and related protocols. The session_id identifies the server process ID (SPID), and an addi- tional WHERE clause can be added to the SELECT statement that selects only the SPID you are interested in: SELECT name, net_transport, session_id, e.endpoint_id FROM sys.dm_exec_connections d JOIN sys.endpoints e ON e.endpoint_id = d.endpoint_id go name net_transport session_id endpoint_id TSQL Local Machine Shared memory 53 2 Following is an example of the client-side error message that results if the TSQL Default TCP endpoint is stopped and you try to connect to it: A connection was successfully established with the server, but then an error occurred during the login process Download from www.wowebook.com ptg 270 Now that you know a bit about endpoints, let’s go a bit deeper and explore how client connections are facilitated on the server. The Role of SQL Browser You might be surprised to learn that when clients try to connect to SQL Server 2008, their first network access is made over UDP Port 1434 to the SQL Browser service. NOTE Regardless of the encryption status of the connection itself, login credentials are always encrypted when passed to SQL Server 2008 (to foil any malicious packet sniff- ing). If a certificate signed by an external authority (such as VeriSign) is not installed on the server, SQL Server automatically generates a self-signed certificate for use in encrypting login credentials. SQL Browser is the upgrade to the SQL Server Resolution Protocol (SSRP) and its job is to hand out instance names, version numbers, and connection information for each (nonhidden) instance of the Database Engine (and Analysis Services) residing on a server—not only for SQL Server 2008 instances, but for SQL Server 2000 and 2005 instances as well. When clients connect by name, SQL Browser searches for that name in its list and then hands out the connection data for that instance. It can also provide a list of available servers and help make connections to the correct server instance or to make a connection on the dedicated administrator connection (DAC). Ports, Pipes, and Instances Default instances of SQL Server 2008 are automatically configured (just as in previous editions) to listen on all IP addresses and TCP Port 1433. Named instances, on the other hand, are automatically configured to listen on all IP addresses, using dynamic TCP port numbers that change when the Database Engine is restarted. (Most often, these change only when the port number last used by the service is in use by a different application.) If the SQL Browser service is not running, the client might need to provide additional connection information to be able to connect to SQL Server. The additional connection information includes the specific port or pipe that the SQL Server instance may be listen- ing on. The only exception to this is if the server is listening on the default port of 1433. Otherwise, the client must specify the port when connecting with TCP/IP. When dynamic ports are used, the port number can change at any given time and cause your clients to have to change their port to match the new server port. SQL Browser, therefore, is configured to autostart on servers that contain one or more named instances so that clients can connect by simply providing the server name. The complexity associated with providing additional port or pipe information is avoided when CHAPTER 10 Client Installation and Configuration Download from www.wowebook.com ptg 271 Client Installation 10 the SQL Browser service is running. SQL Browser is also required for enumerating the server lists used to connect with client tools such as SMSS. NOTE If named instances have fixed port numbers known to clients, or if a pipe name is well known, SQL Browser is not required to connect. NOTE For named pipes, the default instance’s pipe name is \sql\query; for named instances, the pipe name is MSSQL$instancename\sql\query. When a link is made, endpoint provisioning kicks in to finalize (or reject) the connection. Client Installation Now that you have acquired some knowledge about the most important server-side networking considerations, it’s time to learn how to install and configure the client-side half of the equation. Installation Requirements All SQL Server 2008 installations (including client-tools-only or SNAC-only installations) require Windows Installer 4.5, which is freely downloadable from Microsoft. It can also be installed as part of the SQL Server Installation Wizard or manually installed from the SQL Server media. The location of the installer media varies depending on the media you are using but an example of the location is as follows: D:\English\SQL2008\Enterprise\X86\redist\Windows Installer\x86 The same operating system requirements for server installations apply to client tools and SNAC installations, with one exception: When you install SNAC by itself on top of Windows XP, only SP1 is required, and when you install SNAC on top of Windows Server 2003, SP1 is not required. You can review the complete list of requirements in Chapter 8, “Installing SQL Server 2008,” in the section “Installation Requirements.” Note that SNAC and the client tools both depend on the presence of the .NET Framework 3.5 SP1, and the client tools in turn depend on SNAC. Setup automatically installs both Framework 3.5 SP1 and SNAC, when required, on the target machine. If incompatible or beta versions exist that must be uninstalled first, Setup lets you know to use Installer 4.5. Installing the Client Tools To install the SQL Server 2008 client tools, you start Setup normally and follow the prompts as described in Chapter 8. When the Feature Selection screen appears, you check only the Client Tools Connectivity check box, as shown in Figure 10.2. Download from www.wowebook.com ptg 272 FIGURE 10.2 Performing a client-tools-only installation. The same kind of install can be done quietly from the command line (Setup doubles as a command-line application), using the following: driveletter:\Servers\Setup> Setup.exe /q /ACTION=Install /FEATURES=CONN /INSTANCENAME=INST2008 That’s all there is to it! You will be happy to learn that the SQL Server 2008 client tools can safely be installed side by side with your SQL Server 2000 or 2005 client tools. You can even access databases and other objects created in either edition (with a few notable exceptions, such as database diagrams) by using either toolset. The sections that follow describe how to install and use a few of the client tools for client configuration and testing. Installing SNAC This section shows how easy it is to install SNAC, the key net-library for SQL Server 2008 and beyond. As mentioned earlier, both the SQL Server 2008 Database Engine and the client tools depend on SNAC. SNAC is installed when you install the SQL Server connectivity tools, or you can simply launch it on its own from the SQL Server installation medium by running driveletter:\Servers\Setup\sqlncli.msi. Table 10.1 describes the files that the Microsoft Installer (MSI) package installs. CHAPTER 10 Client Installation and Configuration Download from www.wowebook.com ptg 273 TABLE 10.1 Files Installed by the SNAC MSI Package Filename Purpose Installed To Sqlncli.h C++ header file (replaces sqloledb.h) Program Files\Microsoft SQL Server\100\SDK sqlncli10.lib C++ library file for calling BCP functions (replaces odbcbcp.lib) Program Files\Microsoft SQL Server\100\SDK sqlncli10.dll Main library, containing both the ODBC driver and OLE DB provider (houses all functionality) WINDIR\system32 sqlnclir10.rll Resource file WINDIR\system32 s10ch_sqlncli.chm Compiled help file for creating data sources using SNAC WINDIR\system32 Client Installation 10 TIP For detailed information on how to write C++ code by using the header and library files included in the SNAC software development kit (SDK), see the Books Online topic “Using the SQL Native Client Header and Library Files.” The SNAC installer has two primary options (shown in Figure 10.3): . Install SNAC by itself . Install the SNAC SDK files along with it FIGURE 10.3 SNAC’s installation options. Download from www.wowebook.com . fixed server role on new SQL Server 2008 installations. So, by default, network administrators and administrators of the machine where SQL Server is running are not able to log in to SQL Server. in SQL Server 2008, so you need to look to the SSCM to configure your protocols. The Server Endpoint Layer A networking feature in SQL Server 2008 adds an additional layer to the client /server. net-library for SQL Server 2008 and beyond. As mentioned earlier, both the SQL Server 2008 Database Engine and the client tools depend on SNAC. SNAC is installed when you install the SQL Server connectivity