Installation Wizard help

APPLIES TO: yesSQL Server noAzure SQL Database noAzure SQL Data Warehouse noParallel Data Warehouse

This article describes some of the configuration pages in the SQL Server Installation Wizard.

Instance Configuration page

Use the Instance Configuration page of the SQL Server Installation Wizard to specify whether to create a default instance or a named instance of SQL Server. If an instance of SQL Server isn't already installed, a default instance is created unless you specify a named instance.

Each instance of SQL Server consists of a distinct set of services that have specific settings for collations and other options. The directory structure, registry structure, and service names all reflect the instance name and a specific instance ID that were created during SQL Server Setup.

An instance is either the default instance or a named instance. The default instance name is MSSQLSERVER. The default name doesn't require a client to specify the name of the instance to make a connection. A named instance is determined by the user during Setup. You can install SQL Server as a named instance without installing the default instance first. Only one installation of SQL Server, no matter the version, can be the default instance at one time.

Note

With SQL Server SysPrep, you can specify the instance name when you complete a prepared instance on the Instance Configuration page. You can configure the prepared instance you're completing as a default instance if there is no existing default instance of SQL Server on the machine.

Multiple instances

SQL Server supports multiple instances of SQL Server on a single server or processor, but only one instance can be the default instance. All others must be named instances. A computer can run multiple instances of SQL Server concurrently, and each instance runs independently of the other instances.

For more information, see Maximum capacity specifications for SQL Server.

Options

Failover cluster instances only: Specify the SQL Server failover cluster network name. This name identifies the failover cluster instance on the network.

Decide between a default or a named instance: Consider the following information when you decide whether to install a default or named instance of SQL Server:

  • If you plan to install a single instance of SQL Server on a database server, it should be a default instance.

  • Use a named instance for situations where you plan to have multiple instances on the same computer. A server can host only one default instance.

  • Any application that installs SQL Server Express should install it as a named instance. This practice minimizes conflicts when multiple applications are installed on the same computer.

Default instance: Select this option to install a default instance of SQL Server. A computer can host only one default instance; all other instances must be named. However, if you have a default instance of SQL Server installed, you can add a default instance of Analysis Services to the same computer.

Named instance: Select this option to create a new named instance. Be aware of the following information when you name an instance of SQL Server:

  • Instance names aren't case-sensitive.

  • Instance names can't start or end with an underscore (_).

  • Instance names can't contain the term "Default" or other reserved keywords. If a reserved keyword is used in an instance name, a Setup error occurs. For more information, see Reserved keywords (Transact-SQL).

  • If you specify MSSQLSERVER for the instance name, a default instance is created.

  • An installation of Microsoft SQL Server 2016 Power Pivot for SharePoint is always installed as a named instance of "Power Pivot". You can't specify a different instance name for this feature role.

  • Instance names are limited to 16 characters.

  • The first character in the instance name must be a letter. Acceptable letters are the ones defined by the Unicode Standard 2.0. These letters include Latin characters a-z, A-Z, and letter characters from other languages.

  • Subsequent characters can be letters defined by the Unicode Standard 2.0, decimal numbers from Basic Latin or other national scripts, the dollar sign ($), or an underscore (_).

  • Embedded spaces or other special characters aren't allowed in instance names. The backslash (\), comma (,), colon (:), semicolon (;), single quotation mark ('), ampersand (&), hyphen (-), and at sign (@) also aren't allowed.

    Only characters that are valid in the current Windows code page can be used in SQL Server instance names. If an unsupported Unicode character is used, a Setup error occurs.

Detected instances and features: View a list of installed SQL Server instances and components on the computer where SQL Server Setup is running.

Instance ID: By default, the instance name is used as the instance ID. This ID is used to identify installation directories and registry keys for your instance of SQL Server. The same behavior occurs for default instances and named instances. For a default instance, the instance name and instance ID are MSSQLSERVER. To use a nondefault instance ID, specify it in the Instance ID field.

Important

With SQL Server SysPrep, the instance ID displayed on the Instance Configuration page is the instance ID you specified during the prepare image step of the SQL Server SysPrep process. You won't be able to specify a different instance ID during the complete image step.

Note

Instance IDs that begin with an underscore (_) or that contain the number sign (#) or the dollar sign ($) aren't supported.

For more information about directories, file locations, and instance ID naming, see File locations for default and named instances of SQL Server.

All components of a given instance of SQL Server are managed as a unit. All SQL Server service packs and upgrades apply to every component of an instance of SQL Server.

All components of SQL Server that share the same instance name must meet the following criteria:

  • Same version
  • Same edition
  • Same language settings
  • Same clustered state
  • Same operating system

Note

Reporting Services isn't cluster-aware.

Analysis Services Configuration - Account Provisioning page

Use this page to set the server mode and to grant administrative permissions to users or services that require unrestricted access to Analysis Services. Setup doesn't automatically add the local Windows group BUILTIN\Administrators to the Analysis Services server administrator role of the instance you're installing. If you want to add the local Administrators group to the server administrator role, you must explicitly specify that group.

If you're installing Power Pivot for SharePoint, be sure to grant administrative permissions to SharePoint farm administrators or service administrators who are responsible for a Power Pivot server deployment in a SharePoint Server 2010 farm.

Options

Server Mode: The server mode specifies the type of Analysis Services databases that can be deployed to the server. Server modes are determined during Setup and can't be modified later. Each mode is mutually exclusive, which means that you need two instances of Analysis Services, each configured for a different mode, to support both classic online analytical processing (OLAP) and tabular model solutions.

Specify Administrators: You must specify at least one server administrator for the instance of SQL Server. The users or groups that you specify become members of the server administrator role of the Analysis Services instance you're installing. These members must have Windows domain user accounts in the same domain as the computer on which you're installing the software.

Note

User Account Control (UAC) is a Windows security feature that requires an administrator to specifically approve administrative actions or applications before they're allowed to run. Because UAC is on by default, you'll be prompted to allow specific operations that require elevated privileges. You can configure UAC to change the default behavior or you can customize UAC for specific programs. For more information about UAC and UAC configuration, see the User Account Control step-by-step guide and User Account Control (Wikipedia).

See also

Analysis Services Configuration - Data Directories page

The default directories in the following table are user-configurable during SQL Server Setup. Permission to access these files is granted to local administrators and to members of the SQLServerMSASUser$<instance> security group that's created and provisioned during Setup.

UIElement list

Description Default directory Recommendations
Data root directory <Drive:>\Program Files\Microsoft SQL Server\MSASnn.<InstanceID>\OLAP\Data\ Ensure that the \Program files\Microsoft SQL Server\ folder is protected with limited permissions. Analysis Services performance depends, in many configurations, on the performance of the storage on which the data directory is located. Place this directory on the highest-performing storage that is attached to the system. For failover cluster installations, ensure that data directories are placed on the shared disk.
Log file directory <Drive:>\Program Files\Microsoft SQL Server\MSASnn.<InstanceID>\OLAP\Log\ This directory is for Analysis Services log files, and it includes the FlightRecorder log. If you increase the flight recorder duration, ensure that the log directory has adequate space.
Temp directory <Drive:>\Program Files\Microsoft SQL Server\MSASnn.<InstanceID>\OLAP\Temp\ Place the Temp directory on a high-performance storage subsystem.
Backup directory <Drive:>\Program Files\Microsoft SQL Server\MSASnn.<InstanceID>\OLAP\Backup\ This directory is for Analysis Services default backup files. For Power Pivot for SharePoint installations, this directory is also where the Power Pivot System Services caches Power Pivot data files.

Ensure appropriate permissions are set to prevent data loss, and that the user group for Analysis Services has adequate permissions to write to the backup directory. Using a mapped drive for backup directories isn't supported.

Considerations

  • When Analysis Services instances are deployed on a SharePoint farm, they store application files, data files, and properties in content databases and service-application databases.

  • When you add features to an existing installation, you can't change the location of a previously installed feature, nor can you specify the location for a new feature.

  • You might need to configure scanning software, such as antivirus and antispyware applications, to exclude SQL Server folders and file types. Review this support article for more information: Antivirus software on computers running SQL Server.

  • If you specify nondefault installation directories, ensure that the installation folders are unique to this instance of SQL Server. Don't share directories in this dialog box with directories from other instances of SQL Server. Also install the Database Engine and Analysis Services components within an instance of SQL Server to separate directories.

  • Program files and data files can't be installed in the following situations:

    • On a removable disk drive
    • On a file system that uses compression
    • To a directory where system files are located

See also

For more information about directories, file locations, and instance ID naming, see File locations for default and named instances of SQL Server.

Analysis Services Configuration - Data Directories page

The default directories in the following table are user-configurable during SQL Server Setup. Permission to access these files is granted to local administrators and to members of the SQLServerMSASUser$<instance> security group that's created and provisioned during Setup.

UIElement list

Description Default directory Recommendations
Data root directory <Drive:>\Program Files\Microsoft SQL Server\MSASnn.<InstanceID>\OLAP\Data Ensure that the \Program files\Microsoft SQL Server\ folder is protected with limited permissions. Analysis Services performance depends, in many configurations, on the performance of the storage on which the data directory is located. Place this directory on the highest-performing storage that's attached to the system. For failover cluster installations, ensure that the data directories are placed on the shared disk.
Log file directory <Drive:>\Program Files\Microsoft SQL Server\MSASnn.<InstanceID>\OLAP\Log This directory is for Analysis Services log files, and it includes the FlightRecorder log. If you increase the flight-recorder duration, ensure that the log directory has adequate space.
Temp directory <Drive:>\Program Files\Microsoft SQL Server\MSASnn.<InstanceID>\OLAP\Temp Place the Temp directory on a high-performance storage subsystem.
Backup directory <Drive:>\Program Files\Microsoft SQL Server\MSASnn.<InstanceID>\OLAP\Backup This directory is for Analysis Services default backup files. For Power Pivot for SharePoint installations, it's also where the Power Pivot System Services caches Power Pivot data files.

Ensure appropriate permissions are set to prevent data loss, and that the user group for the Analysis Services service has adequate permissions to write to the backup directory. Using a mapped drive for backup directories isn't supported.

Considerations

  • When Analysis Services instances are deployed on a SharePoint farm, they store application files, data files, and properties in content databases and service-application databases.

  • When you add features to an existing installation, you can't change the location of a previously installed feature, nor can you specify the location for a new feature.

  • You might need to configure scanning software, such as antivirus and antispyware applications, to exclude SQL Server folders and file types. For more information, see Antivirus software on computers running SQL Server.

  • If you specify nondefault installation directories, ensure that the installation folders are unique to this instance of SQL Server. Don't share the directories in this dialog box with directories from other instances of SQL Server. Also install the Database Engine and Analysis Services components within an instance of SQL Server to separate directories.

  • Program files and data files can't be installed in the following situations:

    • On a removable disk drive
    • On a file system that uses compression
    • To a directory where system files are located

See also

Database Engine Configuration - Server Configuration page

Use this page to set the SQL Server security mode and to add Windows users or groups as administrators of the SQL Server Database Engine.

Considerations for running SQL Server 2017

In previous versions of SQL Server, the BUILTIN\Administrators group was provisioned as a login in the Database Engine and members of the local Administrators group could log in by using their Administrator credentials. However, using elevated permissions isn't a best practice.

In SQL Server 2017, the BUILTIN\Administrators group isn't provisioned as a login. Make sure you create a SQL Server login for each administrative user, and add that login to the sysadmin fixed server role during the installation of a new instance of SQL Server 2017. Do the same for Windows accounts that run SQL Server agent jobs, including replication agent jobs.

Options

Security Mode: Select Windows Authentication or Mixed Mode Authentication for your installation.

Windows Principal Provisioning: In previous versions of SQL Server, the Windows BUILTIN\Administrators local group was placed into the SQL Server sysadmin server role, effectively granting Windows administrators access to the instance of SQL Server. In SQL Server 2017, the BUILTIN\Administrators group isn't provisioned in the sysadmin server role. Instead, you should explicitly provision SQL Server administrators for new installations during Setup.

Important

You must explicitly provision SQL Server administrators for new installations during Setup. Setup won't allow you to continue until you complete this step.

Specify SQL Server Administrators: You must specify at least one Windows principal for the instance of SQL Server. To add the account under which SQL Server Setup is running, select the Add Current User button. To add or remove accounts from the list of system administrators, select Add or Remove, and then edit the list of users, groups, or computers that will have administrator privileges for the instance of SQL Server.

When you're finished editing the list, select OK, then verify the list of administrators in the configuration dialog box. If the list is complete, select Next.

If you select Mixed Mode Authentication, you must provide login credentials for the built-in SQL Server system administrator (sa) account.

Important

Do not use a blank password. Use a strong password.

Windows Authentication Mode: When a user connects through a Windows user account, SQL Server validates the account name and password by using the Windows principal token in the operating system. Windows authentication is the default authentication mode, and it's much more secure than mixed mode authentication. Windows authentication uses the Kerberos security protocol, provides password-policy enforcement in terms of complexity validation for strong passwords, provides support for account lockout, and supports password expiration.

Important

When possible, use Windows authentication.

Important

Do not use a blank password. Use a strong password. Never set a blank or weak sa password.

Mixed Mode (Windows Authentication or SQL Server Authentication): Allows users to connect by using Windows authentication or SQL Server authentication. Users who connect through a Windows user account can use trusted connections that are validated by Windows.

If you must choose mixed mode authentication and you need to use SQL logins to accommodate legacy applications, you must set strong passwords for all SQL Server accounts.

Note

SQL Server authentication is provided for backward compatibility only. When possible, use Windows authentication.

Enter Password: Enter and confirm the system administrator (sa) login. Passwords are the first line of defense against intruders, so setting strong passwords is essential to the security of your system. Never set a blank or weak sa password.

Note

SQL Server passwords can contain from 1 to 128 characters, including any combination of letters, symbols, and numbers. If you choose mixed mode authentication, you must enter a strong sa password before you can continue to the next page of the Installation Wizard.

Strong password guidelines

Strong passwords aren't readily guessed by a person and aren't easily hacked by using a computer program. Strong passwords can't use prohibited conditions or terms, including:

  • A blank or NULL condition
  • "Password"
  • "Admin"
  • "Administrator"
  • "sa"
  • "sysadmin"

A strong password can't be the following terms associated with the installation computer:

  • The name of the user currently logged into the machine
  • The computer name

A strong password must be more than 8 characters in length and satisfy at least three of the following four criteria:

  • It must contain uppercase letters.
  • It must contain lowercase letters.
  • It must contain numbers.
  • It must contain non-alphanumeric characters; for example, #, %, or ^.

Passwords entered on this page must meet strong-password-policy requirements. If you have any automation that uses SQL Server authentication, ensure that the password meets strong-password-policy requirements.

See also

For more information about choosing Windows authentication versus SQL Server authentication, see Choose an authentication mode.

For more information about choosing an account to run the SQL Server Database Engine, see Configure Windows service accounts and permissions.

Database Engine Configuration - Data Directories page

Use this page to specify the installation location for the SQL Server Database Engine program and data files. Based on the type of installation, the supported storage may include local disk, shared storage, or an SMB file server.

To specify an SMB file share as a directory, you must manually type the supported UNC path. Browsing to an SMB file share isn't supported. The following example shows the supported UNC path format of an SMB file share:

\\<ServerName>\<ShareName>\...

Standalone instance of SQL Server

For a standalone instance of SQL Server, the following table lists the supported storage types and the default directories that you can configure during SQL Server Setup:

UIElement list

Description Supported storage types Default directory Recommendations
Data root directory Local disk, SMB file server, shared storage* <Drive:>\Program Files\Microsoft SQL Server\ SQL Server Setup configures access control lists (ACLs) for SQL Server directories and breaks inheritance as part of configuration.
User database directory Local disk, SMB file server, shared storage* <Drive:>\Program Files\Microsoft SQL Server\MSSQLnn.<InstanceID>\MSSQL\Data Best practices for user data directories depend on workload and performance requirements.
User database log directory Local disk, SMB file server, shared storage* <Drive:>\Program Files\Microsoft SQL Server\MSSQLnn.<InstanceID>\MSSQL\Data Ensure that the log directory has adequate space.
Backup directory Local disk, SMB file server, shared storage* <Drive:>\Program Files\Microsoft SQL Server\MSSQLnn.<InstanceID>\MSSQL\Backup Set appropriate permissions to prevent data loss, and ensure that the user account for the SQL Server service has adequate permissions to write to the backup directory. Using a mapped drive for backup directories isn't supported.

* Although shared disks are supported, we don't recommend their use for a standalone instance of SQL Server.

Failover cluster instance of SQL Server

For a failover cluster instance of SQL Server, the following table lists the supported storage types and the default directories that you can configure during SQL Server Setup.

Description Supported storage types Default directory Recommendations
Data root directory Shared storage, SMB file server <Drive:>\Program Files\Microsoft SQL Server\

Tip: If you select shared disk on the Cluster Disk Selection page, the default is the first shared disk. This field defaults to blank if you don't make a selection on the Cluster Disk Selection page.
SQL Server Setup configures ACLs for SQL Server directories and breaks inheritance as part of configuration.
User database directory Shared storage, SMB file server <Drive:>Program Files\Microsoft SQL Server\MSSQLnn.<InstanceID>\MSSQL\Data

Tip: If you select shared disk on the Cluster Disk Selection page, the default is the first shared disk. This field defaults to blank if you don't make a selection on the Cluster Disk Selection page.
Best practices for user data directories depend on workload and performance requirements.
User database log directory Shared storage, SMB file server <Drive:>\Program Files\Microsoft SQL Server\MSSQLnn.<InstanceID>\MSSQL\Data

Tip: If you select shared disk on the Cluster Disk Selection page, the default is the first shared disk. This field defaults to blank if you don't make a selection on the Cluster Disk Selection page.
Ensure that the log directory has adequate space.
Backup directory Local disk, shared storage, SMB file server <Drive:>\Program Files\Microsoft SQL Server\MSSQLnn.<InstanceID>\MSSQL\Backup

Tip: If you select shared disk on the Cluster Disk Selection page, the default is the first shared disk. This field defaults to blank if you don't make a selection on the Cluster Disk Selection page.
Set appropriate permissions to prevent data loss, and ensure that the user account for the SQL Server service has adequate permissions to write to the backup directory. Using a mapped drive for backup directories isn't supported.

Security considerations

Setup will configure ACLs for SQL Server directories and break inheritance as part of configuration.

The following recommendations apply to SMB file servers:

  • The SQL Server service account must be a domain account if an SMB file server is used.

  • The account used to install SQL Server should have Full Control NTFS permissions on the SMB file share folder used as the data directory.

  • The account used to install SQL Server should be granted SeSecurityPrivilege privileges on the SMB file server. To grant this privilege, use the Local Security Policy console on the file server to add the SQL Server setup account to the Manage auditing and security log policy. This setting is in the User Rights Assignments section under Local Policies in the Local Security Policy console.

Considerations

  • When adding features to an existing installation, you can't change the location of a previously installed feature, nor can you specify the location for a new feature.

  • If you specify nondefault installation directories, ensure that the installation folders are unique to this instance of SQL Server. Don't share the directories in this dialog box with directories from other instances of SQL Server. Also install the Database Engine and Analysis Services components within an instance of SQL Server to separate directories.

  • Program files and data files can't be installed in the following situations:

    • On a removable disk drive
    • On a file system that uses compression
    • To a directory where system files are located
    • On a mapped network drive on a failover cluster instance

Database Engine Configuration - TempDB page

Use this page to specify the tempdb data and log file location, size, growth settings, and number of files for SQL Server Database Engine. Based on the type of installation, the supported storage may include local disk, shared storage, or an SMB file server.

To specify an SMB file share as a directory, you must manually type the supported UNC path. Browsing to an SMB file share isn't supported. The following example shows the supported UNC path format of an SMB file share:

\\<ServerName>\<ShareName>\....

Data and log directories for a standalone instance of SQL Server

For standalone instances of SQL Server, the following table lists the supported storage types and default directories that you can configure during setup.

Description Supported storage type Default directory Recommendations
Data directories Local disk, SMB file server, shared storage* <Drive:>\Program Files\Microsoft SQL Server\MSSQLnn.<InstanceID>\MSSQL\Data SQL Server Setup configures ACLs for SQL Server directories and breaks inheritance as part of configuration.

Best practices for the tempdb directories depend on workload and performance requirements. To spread the data files across several volumes, specify multiple folders or drives.
Log directory Local disk, SMB file server, shared storage* <Drive:>\Program Files\Microsoft SQL Server\MSSQLnn.<InstanceID>\MSSQL\Data Ensure that the log directory has adequate space.

* Although shared disks are supported, we don't recommend their use for a standalone instance of SQL Server.

Data and log directories for a failover cluster instance of SQL Server

For a failover cluster instance of SQL Server, the following table lists the supported storage types and the default directories that you can configure during SQL Server Setup.

Description Supported storage type Default directory Recommendations
tempdb data directory Local disk, shared storage, SMB file server <Drive:>\Program Files\Microsoft SQL Server\MSSQLnn.<InstanceID>\Data

Tip: If you select shared disk on the Cluster Disk Selection page, the default is the first shared disk. This field defaults to blank if you don't make a selection on the Cluster Disk Selection page.
SQL Server Setup configures ACLs for SQL Server directories and breaks inheritance as part of configuration.

Ensure that the specified directory or directories (if multiple files are specified) are valid for all the cluster nodes. During failover, if the tempdb directories aren't available on the failover target node, the SQL Server resource fails to come online.
tempdb log directory Local disk, shared storage, SMB file server <Drive:>\Program Files\Microsoft SQL Server\MSSQLnn.<InstanceID>\MSSQL\Data

Tip: If you select shared disk on the Cluster Disk Selection page, the default is the first shared disk. This field defaults to blank if you don't make a selection on the Cluster Disk Selection page.
Best practices for user data directories depend on workload and performance requirements.

Ensure that the specified directory is valid for all the cluster nodes. During failover, if the tempdb directories aren't available on the failover target node, the SQL Server resource fails to come online.

Ensure that the log directory has adequate space.

UIElement list

Configure the settings for tempdb according to your workload and requirements. The following settings apply to tempdb data files:

  • Number of files is the total number of data files for tempdb. The default value is the lower of 8 or the number of logical cores detected by Setup. As a general rule, if the number of logical processors is less than or equal to 8, use the same number of data files as logical processors. If the number of logical processors is greater than 8, use 8 data files. If contention occurs, increase the number of data files by multiples of 4 (up to the number of logical processors) until contention falls to acceptable levels, or make changes to the workload or code.

  • Initial size (MB) is the initial size in megabytes for each tempdb data file. The default value is 8 MB (or 4 MB for SQL Server Express). SQL Server 2017 (14.x) introduces a maximum initial file size of 262,144 MB (256 GB). SQL Server 2016 (13.x) has a maximum initial file size of 1024 MB. All tempdb data files are the same initial size. Because tempdb is re-created every time SQL Server starts or fails over, specify a size that's close to the size required by your workload for normal operation. To further optimize the creation of tempdb during startup, enable database instant file initialization.

  • Total initial size (MB) is the cumulative size of all the tempdb data files.

  • Autogrowth (MB) is the amount of space in megabytes that each tempdb data file automatically grows by when it runs out of space. In SQL Server 2016 (13.x) and later, all data files grow at the same time by the amount specified in this setting.

  • Total autogrowth (MB) is the cumulative size of each autogrowth event.

  • Data directories shows all the directories that hold tempdb data files. When there are multiple directories, data files are placed in directories in a round-robin manner. For example, if you create 3 directories and specify 8 data files, data files 1, 4, and 7 are created in the first directory. Data files 2, 5, and 8 are created in the second directory. Data files 3 and 6 are in the third directory.

  • To add directories, select Add....

  • To remove a directory, select the directory, and select Remove.

Tempdb log file is the name of the log file. This file is created automatically. The following settings apply only to tempdb log files:

  • Initial size (MB) is the initial size of the tempdb log file. The default value is 8 MB (or 4 MB for SQL Server Express). SQL Server 2017 (14.x) introduces a maximum initial file size of 262,144 MB (256 GB). SQL Server 2016 (13.x) has a maximum initial file size of 1024 MB. Because tempdb is re-created every time SQL Server starts or fails over, specify a size that's close to the size required by your workload for normal operation. To further optimize the creation of tempdb during startup, enable database instant file initialization.

    Note

    Tempdb uses minimal logging. The tempdb log file can't be backed up. It is re-created every time SQL Server starts or when a cluster instance fails over.

  • Autogrowth (MB) is the growth increment of the tempdb log in megabytes. The default value of 64 MB creates the optimal number of virtual log files during initialization.

    Note

    Tempdb log files don't use database instant file initialization.

  • Log directory is the directory where tempdb log files are created. There's only one tempdb log directory.

Security considerations

Setup configures ACLs for SQL Server directories and breaks inheritance as part of configuration.

The following recommendations apply to the SMB file server:

  • The SQL Server service account must be a domain account if an SMB file server is used.

  • The account used to install SQL Server should have Full Control NTFS permissions on the SMB file share folder used as the data directory.

  • The account used to install SQL Server should be granted SeSecurityPrivilege privileges on the SMB file server. To grant this privilege, use the Local Security Policy console on the file server to add the SQL Server setup account to the Manage auditing and security log policy. This setting is in the User Rights Assignments section under Local Policies in the Local Security Policy console.

Note

If you specify nondefault installation directories, ensure that the installation folders are unique to this instance of SQL Server. None of the directories in this dialog box should be shared with directories from other instances of SQL Server. The Database Engine and Analysis Services components within an instance of SQL Server should also be installed to separate directories.

See also

Database Engine Configuration - MaxDOP page

Max degree of parallelism (MaxDOP) determines the maximum number of processors that a single statement can use. SQL Server 2019 introduces the ability to configure this option during installation. SQL Server 2019 also automatically detects the recommended MaxDOP setting for the server based on the number of cores. The default maximum value is 8.

You can manually configure this setting on this page, and you can modify this setting after installation. For more information, see Max degree of parallelism.

Database Engine Configuration - FILESTREAM page

Use this page to enable FILESTREAM for this installation of SQL Server 2017. FILESTREAM integrates the SQL Server Database Engine with an NTFS file system by storing varbinary(max) binary large object (BLOB) data as files in the file system. Transact-SQL statements can insert, update, query, search, and back up FILESTREAM data. Microsoft Win32 file-system interfaces provide streaming access to the data.

UIElement list

Enable FILESTREAM for Transact-SQL access: Select to enable FILESTREAM for Transact-SQL access. This check box must be selected before the other options will be available.

Enable FILESTREAM for file I/O streaming access: Select to enable Win32 streaming access for FILESTREAM.

Windows share name: Enter the name of the Windows share in which the FILESTREAM data will be stored.

Allow remote clients to have streaming access to FILESTREAM data: Select this check box to allow remote clients to access the FILESTREAM data on this server.

See also

Database Engine Configuration - User Instance page

Use the User Instance page to:

  • Generate a separate instance of the Database Engine for users without administrator permissions.
  • Add users to the administrator role.

Options

Enable User Instances: The default is on. To turn off the ability to enable user instances, clear the check box.

The user instance, also known as a child or client instance, is an instance of SQL Server that is generated by the parent instance (the primary instance that runs as a service, like SQL Server Express) on behalf of a user. The user instance runs as a user process under the security context of that user. The user instance is isolated from the parent instance and any other user instances that are running on the computer. The user instance feature is also referred to as "run as normal user" (RANU).

Note

Logins provisioned as members of the sysadmin fixed server role during Setup are provisioned as administrators in the template database. They're members of the sysadmin fixed server role on the user instance unless they're removed.

Add user to the SQL Server Administrator role: Default is off. To add the current Setup user to the SQL Server Administrator role, select the check box.

Windows Vista users that are members of BUILTIN\Administrators aren't automatically added to the sysadmin fixed server role when they connect to SQL Server Express. Only Windows Vista users who have been explicitly added to a server-level administrator role can administer SQL Server Express. Members of the Built-In\Users group can connect to the SQL Server Express instance, but they'll have limited permissions to do database tasks. For this reason, users whose SQL Server Express privileges are inherited from BUILTIN\Administrators and Built-In\Users in previous releases of Windows must be explicitly granted administrative privileges in instances of SQL Server Express that are running on Windows Vista.

To make changes to the user roles after the installation program ends, use SQL Server Management Studio or Transact-SQL.