Skip to content

integration-services-service-ssis-service.md

Latest commit

 

History

History
434 lines (266 loc) · 35.5 KB

integration-services-service-ssis-service.md

File metadata and controls

434 lines (266 loc) · 35.5 KB
title Integration Services Service (SSIS Service)
description Integration Services Service (SSIS Service)
author chugugrace
ms.author chugu
ms.date 03/14/2017
ms.service sql
ms.subservice integration-services
ms.topic concept-article
f1_keywords
sql13.ssiseditserverregistration.connectionproperties.f1
sql13.swb.connecttodts.connectionproperties.f1
sql13.swb.connection.login.dtsserver.f1
sql13.swb.connecttodts.login.f1
sql13.swb.connecttodtsserver.login.f1
helpviewer_keywords
Integration Services service, about Integration Services service
SQL Server Integration Services service
service [Integration Services],about Integration Services service
service [Integration Services]
SQL Server Integration Services, service

Integration Services Service (SSIS Service)

[!INCLUDEsqlserver-ssis]

The topics in this section discuss the [!INCLUDEssISnoversion] service, a Windows service for managing [!INCLUDEssISnoversion] packages. This service is not required to create, save, and run Integration Services packages. [!INCLUDEssSQL11] supports the [!INCLUDEssISnoversion] service for backward compatibility with earlier releases of [!INCLUDEssISnoversion].

Starting in [!INCLUDEssSQL11], [!INCLUDEssISnoversion] stores objects, settings, and operational data in the SSISDB database for projects that you've deployed to the [!INCLUDEssISnoversion] server using the project deployment model. The [!INCLUDEssISnoversion] server, which is an instance of the [!INCLUDEssNoVersion] Database Engine, hosts the database. For more information about the database, see SSIS Catalog. For more information about deploying projects to the [!INCLUDEssISnoversion] server, see Deploy Integration Services (SSIS) Projects and Packages.

Management capabilities

The [!INCLUDEssISnoversion] service is a Windows service for managing [!INCLUDEssISnoversion] packages. The [!INCLUDEssISnoversion] service is available only in [!INCLUDEssManStudioFull].

Running the [!INCLUDEssISnoversion] service provides the following management capabilities:

  • Starting remote and locally stored packages

  • Stopping remote and locally running packages

  • Monitoring remote and locally running packages

  • Importing and exporting packages

  • Managing package storage

  • Customizing storage folders

  • Stopping running packages when the service is stopped

  • Viewing the Windows Event log

  • Connecting to multiple [!INCLUDEssISnoversion] servers

Startup type

The [!INCLUDEssISnoversion] service is installed when you install the [!INCLUDEssISnoversion] component of [!INCLUDEssNoVersion]. By default, the [!INCLUDEssISnoversion] service is started and the startup type of the service is set to automatic. The service must be running to monitor the packages that are stored in the [!INCLUDEssIS] Package Store. The [!INCLUDEssIS] Package Store can be either the msdb database in an instance of [!INCLUDEssNoVersion] or the designated folders in the file system.

The [!INCLUDEssISnoversion] service is not required if you only want to design and execute [!INCLUDEssISnoversion] packages. However, the service is required to list and monitor packages using [!INCLUDEssManStudioFull].

Manage the service

When you install the [!INCLUDEssISnoversion] component of [!INCLUDEssNoVersion], the [!INCLUDEssISnoversion] service is also installed. By default, the [!INCLUDEssISnoversion] service is started and the startup type of the service is set to automatic. However, you must also install [!INCLUDEssManStudioFull] to use the service to manage stored and running [!INCLUDEssISnoversion] packages.

Note

To connect directly to an instance of the legacy Integration Services Service, you have to use the version of SQL Server Management Studio (SSMS) aligned with the version of SQL Server on which the Integration Services Service is running. For example, to connect to the legacy Integration Services Service running on an instance of SQL Server 2016, you have to use the version of SSMS released for SQL Server 2016. For more information, see Release history for SQL Server Management Studio.

In the SSMS Connect to Server dialog box, you cannot enter the name of a server on which an earlier version of the [!INCLUDEssISnoversion] service is running. However, to manage packages that are stored on a remote server, you do not have to connect to the instance of the [!INCLUDEssISnoversion] service on that remote server. Instead, edit the configuration file for the [!INCLUDEssISnoversion] service so that [!INCLUDEssManStudioFull] displays the packages that are stored on the remote server.

You can only install a single instance of the [!INCLUDEssISnoversion] service on a computer. The service is not specific to a particular instance of the [!INCLUDEssDE]. You connect to the service by using the name of the computer on which it is running.

You can manage the [!INCLUDEssISnoversion] service by using one of the following Microsoft Management Console (MMC) snap-ins: SQL Server Configuration Manager or Services. Before you can manage packages in [!INCLUDEssManStudioFull], you must make sure that the service is started.

By default, the [!INCLUDEssISnoversion] service is configured to manage packages in the msdb database of the instance of the [!INCLUDEssDE] that is installed at the same time as [!INCLUDEssISnoversion]. If an instance of the [!INCLUDEssDE] is not installed at the same time, the [!INCLUDEssISnoversion] service is configured to manage packages in the msdb database of the local, default instance of the [!INCLUDEssDE]. To manage packages that are stored in a named or remote instance of the [!INCLUDEssDE], or in multiple instances of the [!INCLUDEssDE], you have to modify the configuration file for the service.

By default, the [!INCLUDEssISnoversion] service is configured to stop running packages when the service is stopped. However, the [!INCLUDEssISnoversion] service does not wait for packages to stop and some packages may continue running after the [!INCLUDEssISnoversion] service is stopped.

If the [!INCLUDEssISnoversion] service is stopped, you can continue to run packages using the [!INCLUDEssNoVersion] Import and Export Wizard, the [!INCLUDEssIS] Designer, the Execute Package Utility, and the dtexec command prompt utility (dtexec.exe). However, you cannot monitor the running packages.

By default, the [!INCLUDEssISnoversion] service runs in the context of the NETWORK SERVICE account. It is recommended to run the SQL Server Integration Services service under an account that has limited permissions such as the NETWORK SERVICE account. Running the SQL Server Integration Services service under a highly-privileged account represents a potential security risk.

The [!INCLUDEssISnoversion] service writes to the Windows event log. You can view service events in [!INCLUDEssManStudioFull]. You can also view service events by using the Windows Event Viewer.

Set the properties of the service

The [!INCLUDEssISnoversion] service manages and monitors packages in [!INCLUDEssManStudioFull]. When you first install [!INCLUDEssNoVersion] [!INCLUDEssISnoversion], the [!INCLUDEssISnoversion] service is started and the startup type of the service is set to automatic.

After the [!INCLUDEssISnoversion] service has been installed, you can set the properties of the service by using either SQL Server Configuration Manager or the Services MMC snap-in.

To configure other important features of the service, including the locations where it stores and manages packages, you must modify the configuration file of the service.

To set properties of the Integration Services service by using SQL Server Configuration Manager

  1. On the Start menu, point to All Programs, point to Microsoft SQL Server, point to Configuration Tools, and then click SQL Server Configuration Manager.

  2. In the SQL Server Configuration Manager snap-in, locate SQL Server Integration Services in the list of services, right-click SQL Server Integration Services, and then click Properties.

  3. In the SQL Server Integration Services Properties dialog box you can do the following:

    • Click the Log On tab to view the logon information such as the account name.

    • Click the Service tab to view information about the service such as the name of the host computer and to specify the start mode of [!INCLUDEssISnoversion] service.

      [!NOTE]
      The Advanced tab contains no information for [!INCLUDEssISnoversion] service.

  4. Click OK.

  5. On the File menu, click Exit to close the SQL Server Configuration Manager snap-in.

To set properties of the Integration Services service by using Services

  1. In Control Panel, if you are using Classic View, click Administrative Tools, or, if you are using Category View, click Performance and Maintenance and then click Administrative Tools.

  2. Click Services.

  3. In the Services snap-in, locate SQL Server Integration Services in the list of services, right-click SQL Server Integration Services, and then click Properties.

  4. In the SQL Server Integration Services Properties dialog box, you can do the following:

    • Click the General tab. To enable the service, select either the manual or automatic startup type. To disable the service, select Disable in the Startup type box. Selecting Disable does not stop the service if it is currently running.

      If the service is already enabled, you can click Stop to stop the service, or click Start to start the service.

    • Click the Log On tab to view or edit the logon information.

    • Click the Recovery tab to view the default computer responses to service failure. You can modify these options to suit your environment.

    • Click the Dependencies tab to view a list of dependent services. The [!INCLUDEssISnoversion] service has no dependencies.

  5. Click OK.

  6. Optionally, if the startup type is Manual or Automatic, you can right-click SQL Server Integration Services and click Start, Stop, or Restart.

  7. On the File menu, click Exit to close the Services snap-in.

Grant permissions to the service

In previous versions of [!INCLUDEssNoVersion], by default when you installed [!INCLUDEssNoVersion] all users in the Users group in Local Users and Groups had access to the [!INCLUDEssISnoversion] service. When you install [!INCLUDEsssql16-md] and later versions, users do not have access to the [!INCLUDEssISnoversion] service. The service is secure by default. After [!INCLUDEssNoVersion] is installed, the administrator must grant access to the service.

To grant access to the Integration Services service

  1. Run Dcomcnfg.exe. Dcomcnfg.exe provides a user interface for modifying certain settings in the registry.

  2. In the Component Services dialog, expand the Component Services > Computers > My Computer > DCOM Config node.

  3. Right-click Microsoft SQL Server Integration Services 13.0, and then click Properties.

  4. On the Security tab, click Edit in the Launch and Activation Permissions area.

  5. Add users and assign appropriate permissions, and then click Ok.

  6. Repeat steps 4 - 5 for Access Permissions.

  7. Restart SQL Server Management Studio.

  8. Restart the [!INCLUDEssISnoversion] Service.

Event logged when permissions are missing

If the service account of the SQL Server Agent doesn't have the Integration Services DCOM [Launch and Activation Permissions], the following event is added to the system event logs when the SQL Server Agent executes the SSIS package jobs:

Log Name: System
Source: **Microsoft-Windows-DistributedCOM**
Date: 1/9/2019 5:42:13 PM
Event ID: **10016**
Task Category: None
Level: Error
Keywords: Classic
User: NT SERVICE\SQLSERVERAGENT
Computer: testmachine
Description:
The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID
{xxxxxxxxxxxxxxxxxxxxxxxxxxxxx}
and APPID
{xxxxxxxxxxxxxxxxxxxxxxxxxxxxx}
to the user NT SERVICE\SQLSERVERAGENT SID (S-1-5-80-344959196-2060754871-2302487193-2804545603-1466107430) from address LocalHost (Using LRPC) running in the application container Unavailable SID (Unavailable). This security permission can be modified using the Component Services administrative tool.

Configure the service

When you install [!INCLUDEssISnoversion], the setup process creates and installs the configuration file for the [!INCLUDEssISnoversion] service. This configuration file contains the following settings:

  • Packages are sent a stop command when the service stops.

  • The root folders to display for [!INCLUDEssISnoversion] in Object Explorer of [!INCLUDEssManStudioFull] are the MSDB and File System folders.

  • The packages in the file system that the [!INCLUDEssISnoversion] service manages are located in %ProgramFiles%\Microsoft SQL Server\130\DTS\Packages.

This configuration file also specifies which msdb database contains the packages that the [!INCLUDEssISnoversion] service will manage. By default, the [!INCLUDEssISnoversion] service is configured to manage packages in the msdb database of the instance of the [!INCLUDEssDE] that is installed at the same time as [!INCLUDEssISnoversion]. If an instance of the [!INCLUDEssDE] is not installed at the same time, the [!INCLUDEssISnoversion] service is configured to manage packages in the msdb database of the local, default instance of the [!INCLUDEssDE].

Default Configuration File Example

The following example shows a default configuration file that specifies the following settings:

  • Packages stop running when the [!INCLUDEssISnoversion] service stops.

  • The root folders for package storage in [!INCLUDEssISnoversion] are MSDB and File System.

  • The service manages packages that are stored in the msdb database of the local, default instance of [!INCLUDEssNoVersion].

  • The service manages packages that are stored in the file system in the Packages folder.

Example of a Default Configuration File

\<?xml version="1.0" encoding="utf-8"?>  
\<DtsServiceConfiguration xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">  
  <StopExecutingPackagesOnShutdown>true</StopExecutingPackagesOnShutdown>  
  <TopLevelFolders>  
    \<Folder xsi:type="SqlServerFolder">  
      <Name>MSDB</Name>  
      <ServerName>.</ServerName>  
    </Folder>  
    \<Folder xsi:type="FileSystemFolder">  
      <Name>File System</Name>  
      <StorePath>..\Packages</StorePath>  
    </Folder>  
  </TopLevelFolders>    
</DtsServiceConfiguration>

Modify the configuration file

You can modify the configuration file to allow packages to continue running if the service stops, to display additional root folders in Object Explorer, or to specify a different folder or additional folders in the file system to be managed by [!INCLUDEssISnoversion] service. For example, you can create additional root folders of type, SqlServerFolder, to manage packages in the msdb databases of additional instances of [!INCLUDEssDE].

Note

Some characters are not valid in folder names. Valid characters for folder names are determined by the [!INCLUDEdnprdnshort] class System.IO.Path and the GetInvalidFilenameChars field. The GetInvalidFilenameChars field provides a platform-specific array of characters that cannot be specified in path string arguments passed to members of the Path class. The set of invalid characters can vary by file system. Typically, invalid characters are the quotation mark ("), less than (<) character, and pipe (|) character.

However, you will have to modify the configuration file to manage packages that are stored in a named instance or a remote instance of [!INCLUDEssDE]. If you do not update the configuration file, you cannot use Object Explorer in [!INCLUDEssManStudioFull] to view packages that are stored in the msdb database on the named instance or the remote instance. If you try to use Object Explorer to view these packages, you receive the following error message:

Failed to retrieve data for this request. (Microsoft.SqlServer.SmoEnum)

The SQL Server specified in Integration Services service configuration is not present or is not available. This might occur when there is no default instance of SQL Server on the computer. For more information, see the topic "Configuring the Integration Services Service" in SQL Server 2008 Books Online.

Login Timeout Expired

An error has occurred while establishing a connection to the server. When connecting to SQL Server 2008, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections.

Named Pipes Provider: Could not open a connection to SQL Server [2]. (MsDtsSvr).

To modify the configuration file for the [!INCLUDEssISnoversion] service, you use a text editor.

Important

After you modify the service configuration file, you must restart the service to use the updated service configuration.

Modified Configuration File Example

The following example shows a modified configuration file for [!INCLUDEssISnoversion]. This file is for a named instance of [!INCLUDEssNoVersion] called InstanceName on a server named ServerName.

Example of a Modified Configuration File for a Named Instance of SQL Server

\<?xml version="1.0" encoding="utf-8"?>  
\<DtsServiceConfiguration xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">  
  <StopExecutingPackagesOnShutdown>true</StopExecutingPackagesOnShutdown>  
  <TopLevelFolders>  
    \<Folder xsi:type="SqlServerFolder">  
      <Name>MSDB</Name>  
      <ServerName>ServerName\InstanceName</ServerName>  
    </Folder>  
    \<Folder xsi:type="FileSystemFolder">  
      <Name>File System</Name>  
      <StorePath>..\Packages</StorePath>  
    </Folder>  
  </TopLevelFolders>    
</DtsServiceConfiguration>

Modify the Configuration File Location

The Registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\130\SSIS\ServiceConfigFile specifies the location and name for the configuration file that [!INCLUDEssISnoversion] service uses. The default value of the Registry key is C:\Program Files\Microsoft SQL Server\130\DTS\Binn\MsDtsSrvr.ini.xml. You can update the value of the Registry key to use a different name and location for the configuration file. Note that the version number in the path (120 for SQL Server [!INCLUDEssSQL14_md], 130 for [!INCLUDEsssql16-md], etc.) will vary depending on the SQL Server version.

Caution

Incorrectly editing the Registry can cause serious problems that may require you to reinstall your operating system. [!INCLUDEmsCoName] cannot guarantee that problems resulting from editing the Registry incorrectly can be resolved. Before editing the Registry, back up any valuable data. For information about how to back up, restore, and edit the Registry, see the [!INCLUDEmsCoName] Knowledge Base article, Description of the Microsoft Windows registry.

The [!INCLUDEssISnoversion] service loads the configuration file when the service is started. Any changes to the Registry entry require that the service be restarted.

Connect to the local service

Before you connect to the [!INCLUDEssISnoversion] service, the administrator must grant you access to the service.

To connect to the Integration Services Service

  1. Open [!INCLUDEssManStudioFull].

  2. Click Object Explorer on the View menu.

  3. On the Object Explorer toolbar, click Connect, and then click Integration Services.

  4. In the Connect to Server dialog box, provide a server name. You can use a period (.), (local), or localhost to indicate the local server.

  5. Click Connect.

Connect to a remote SSIS server

Connecting to an instance of [!INCLUDEssISnoversion] on a remote server, from [!INCLUDEssManStudioFull] or another management application, requires a specific set of rights on the server for the users of the application.

Important

To connect directly to an instance of the legacy Integration Services Service, you have to use the version of SQL Server Management Studio (SSMS) aligned with the version of SQL Server on which the Integration Services Service is running. For example, to connect to the legacy Integration Services Service running on an instance of SQL Server 2016, you have to use the version of SSMS released for SQL Server 2016. For more information, see Release history for SQL Server Management Studio.

To manage packages that are stored on a remote server, you do not have to connect to the instance of the [!INCLUDEssISnoversion] service on that remote server. Instead, edit the configuration file for the [!INCLUDEssISnoversion] service so that [!INCLUDEssManStudioFull] displays the packages that are stored on the remote server.

Connecting to Integration Services on a Remote Server

To connect to Integration Services on a Remote Server

  1. Open [!INCLUDEssManStudioFull].

  2. Select File, Connect Object Explorer to display the Connect to Server dialog box.

  3. Select Integration Services in the Server type list.

  4. Type the name of a [!INCLUDEssNoVersion] [!INCLUDEssISnoversion] server in the Server name text box.

    [!NOTE]
    The [!INCLUDEssISnoversion] service is not instance-specific. You connect to the service by using the name of the computer on which the Integration Services service is running.

  5. Click Connect.

Note

The Browse for Servers dialog box does not display remote instances of [!INCLUDEssISnoversion]. In addition, the options available on the Connection Options tab of the Connect to Server dialog box, which is displayed by clicking the Options button, are not applicable to [!INCLUDEssISnoversion] connections.

Eliminating the "Access Is Denied" Error

When a user without sufficient rights attempts to connect to an instance of [!INCLUDEssISnoversion] on a remote server, the server responds with an "Access is denied" error message. You can avoid this error message by ensuring that users have the required DCOM permissions.

To configure rights for remote users on Windows Server 2003 or Windows XP

  1. If the user is not a member of the local Administrators group, add the user to the Distributed COM Users group. You can do this in the Computer Management MMC snap-in accessed from the Administrative Tools menu.

  2. Open Control Panel, double-click Administrative Tools, and then double-click Component Services to start the Component Services MMC snap-in.

  3. Expand the Component Services node in the left pane of the console. Expand the Computers node, expand My Computer, and then click the DCOM Config node.

  4. Select the DCOM Config node, and then select SQL Server Integration Services 11.0 in the list of applications that can be configured.

  5. Right-click on SQL Server Integration Services 11.0 and select Properties.

  6. In the SQL Server Integration Services 11.0 Properties dialog box, select the Security tab.

  7. Under Launch and Activation Permissions, select Customize, then click Edit to open the Launch Permission dialog box.

  8. In the Launch Permission dialog box, add or delete users, and assign the appropriate permissions to the appropriate users and groups. The available permissions are Local Launch, Remote Launch, Local Activation, and Remote Activation. The Launch rights grant or deny permission to start and stop the service; the Activation rights grant or deny permission to connect to the service.

  9. Click OK to close the dialog box.

  10. Under Access Permissions, repeat steps 7 and 8 to assign the appropriate permissions to the appropriate users and groups.

  11. Close the MMC snap-in.

  12. Restart the [!INCLUDEssISnoversion] service.

To configure rights for remote users on Windows 2000 with the latest service packs

  1. Run dcomcnfg.exe at the command prompt.

  2. On the Applications page of the Distributed COM Configuration Properties dialog box, select SQL Server Integration Services 11.0 and then click Properties.

  3. Select the Security page.

  4. Use the two separate dialog boxes to configure Access Permissions and Launch Permissions. You cannot distinguish between remote and local access - Access permissions include local and remote access, and Launch permissions include local and remote launch.

  5. Close the dialog boxes and dcomcnfg.exe.

  6. Restart the [!INCLUDEssISnoversion] service.

Connecting by using a Local Account

If you are working in a local Windows account on a client computer, you can connect to the [!INCLUDEssISnoversion] service on a remote computer only if a local account that has the same name and password and the appropriate rights exists on the remote computer.

SSIS Windows service doesn't support delegation

SSIS doesn't support the delegation of credentials, sometimes referred to as a double hop. In this scenario, you're working on a client computer, SSIS is installed on a second computer, and SQL Server is installed on a third computer. Although SSMS successfully passes your credentials from the client computer to the second computer (where SSIS is running), SSIS can't delegate your credentials from the second computer to the third computer (where SQL Server is running).

Configure the firewall

The Windows firewall system helps prevent unauthorized access to computer resources over a network connection. To access [!INCLUDEssISnoversion] through this firewall, you have to configure the firewall to enable access.

Important

To manage packages that are stored on a remote server, you do not have to connect to the instance of the [!INCLUDEssISnoversion] service on that remote server. Instead, edit the configuration file for the [!INCLUDEssISnoversion] service so that [!INCLUDEssManStudioFull] displays the packages that are stored on the remote server.

The [!INCLUDEssISnoversion] service uses the DCOM protocol.

There are many firewall systems available. If you are running a firewall other than Windows firewall, see your firewall documentation for information that is specific to the system you are using.

If the firewall supports application-level filtering, you can use the user interface that Windows provides to specify the exceptions that are allowed through the firewall, such as programs and services. Otherwise, you have to configure DCOM to use a limited set of TCP ports. The Microsoft website link previously provided includes information about how to specify the TCP ports to use.

The Integration Services service uses port 135, and the port cannot be changed. You have to open TCP port 135 for access to the service control manager (SCM). SCM performs tasks such as starting and stopping [!INCLUDEssISnoversion] services and transmitting control requests to the running service.

The information in the following section is specific to Windows firewall. You can configure the Windows firewall system by running a command at the command prompt, or by setting properties in the Windows firewall dialog box.

For more information about the default Windows firewall settings, and a description of the TCP ports that affect the Database Engine, Analysis Services, Reporting Services, and Integration Services, see Configure the Windows Firewall to Allow SQL Server Access.

Configuring a Windows firewall

You can use the following commands to open TCP port 135, add MsDtsSrvr.exe to the exception list, and specify the scope of unblocking for the firewall.

To configure a Windows firewall using the Command Prompt window

  1. Run the following command:

    netsh firewall add portopening protocol=TCP port=135 name="RPC (TCP/135)" mode=ENABLE scope=SUBNET

  2. Run the following command:

    netsh firewall add allowedprogram program="%ProgramFiles%\Microsoft SQL Server\100\DTS\Binn\MsDtsSrvr.exe" name="SSIS Service" scope=SUBNET

    [!NOTE]
    To open the firewall for all computers, and also for computers on the Internet, replace scope=SUBNET with scope=ALL.

The following procedure describes how to use the Windows user interface to open TCP port 135, add MsDtsSrvr.exe to the exception list, and specify the scope of unblocking for the firewall.

To configure a firewall using the Windows firewall dialog box

  1. In the Control Panel, double-click Windows Firewall.

  2. In the Windows Firewall dialog box, click the Exceptions tab and then click Add Program.

  3. In the Add a Program dialog box, click Browse, navigate to the Program Files\Microsoft SQL Server\100\DTS\Binn folder, click MsDtsSrvr.exe, and then click Open. Click OK to close the Add a Program dialog box.

  4. On the Exceptions tab, click Add Port.

  5. In the Add a Port dialog box, type RPC(TCP/135) or another descriptive name in the Name box, type 135 in the Port Number box, and then select TCP.

    [!IMPORTANT]
    [!INCLUDEssISnoversion] service always uses port 135. You cannot specify a different port.

  6. In the Add a Port dialog box, you can optionally click Change Scope to modify the default scope.

  7. In the Change Scope dialog box, select My network (subnet only) or type a custom list, and then click OK.

  8. To close the Add a Port dialog box, click OK.

  9. To close the Windows Firewall dialog box, click OK.

    [!NOTE]
    To configure the Windows firewall, this procedure uses the Windows Firewall item in Control Panel. The Windows Firewall item only configures the firewall for the current network location profile. However, you can also configure the Windows firewall by using the netsh command line tool or the [!INCLUDEmsCoName] Management Console (MMC) snap-in named Windows firewall with Advanced Security. For more information about these tools, see Configure the Windows Firewall to Allow SQL Server Access.