Spawns a Windows command shell and passes in a string for execution. Any output is returned as rows of text.
Executing the following xp_cmdshell statement returns a directory listing of the current directory.
EXEC xp_cmdshell 'dir *.exe'; GO
The rows are returned in an nvarchar(255) column. If the no_output option is used, only the following will be returned:
The command(s) completed successfully.
The Windows process spawned by xp_cmdshell has the same security rights as the SQL Server service account.
xp_cmdshell operates synchronously. Control is not returned to the caller until the command-shell command is completed.
If xp_cmdshell is executed within a batch and returns an error, the batch will fail. This is a change of behavior. In earlier versions of MicrosoftSQL Server the batch would continue to execute.
xp_cmdshell Proxy Account
When it is called by a user that is not a member of the sysadmin fixed server role, xp_cmdshell connects to Windows by using the account name and password stored in the credential named ##xp_cmdshell_proxy_account##. If this proxy credential does not exist, xp_cmdshell will fail.
The proxy account credential can be created by executing sp_xp_cmdshell_proxy_account. As arguments, this stored procedure takes a Windows user name and password. For example, the following command creates a proxy credential for Windows domain user SHIPPING\KobeR that has the Windows password sdfh%dkc93vcMt0.
EXEC sp_xp_cmdshell_proxy_account 'SHIPPING\KobeR','sdfh%dkc93vcMt0'
For more information, see sp_xp_cmdshell_proxy_account (Transact-SQL).
Because malicious users sometimes attempt to elevate their privileges by using xp_cmdshell, xp_cmdshell is disabled by default. Use sp_configure or Policy Based Management to enable it. For more information, see xp_cmdshell Option.
When first enabled, xp_cmdshell requires CONTROL SERVER permission to execute and the Windows process created by xp_cmdshell has the same security context as the SQL Server service account. The SQL Server service account often has more permissions than are necessary for the work performed by the process created by xp_cmdshell. To enhance security, access to xp_cmdshell should be restricted to highly privileged users.
To allow non-administrators to use xp_cmdshell, and allow SQL Server to create child processes with the security token of a less-privileged account, follow these steps:
Create and customize a Windows local user account or a domain account with the least privileges that your processes require.
Use the sp_xp_cmdshell_proxy_account system procedure to configure xp_cmdshell to use that least-privileged account.
You can also configure this proxy account using SQL Server Management Studio by right-clicking Properties on your server name in Object Explorer, and looking on the Security tab for the Server proxy account section.
In Management Studio, using the master database, execute the GRANT exec ON xp_cmdshell TO '<somelogin>' statement to give specific non-sysadmin users the ability to execute xp_cmdshell. The specified login must be mapped to a user in the master database.
Now non-administrators can launch operating system processes with xp_cmdshell and those processes run with the permissions of the proxy account that you have configured. Users with CONTROL SERVER permission (members of the sysadmin fixed server role) will continue to receive the permissions of the SQL Server service account for child processes that are launched by xp_cmdshell.
To determine the Windows account being used by xp_cmdshell when launching operating system processes, execute the following statement:
To determine the security context for another login, execute the following:
EXECUTE AS LOGIN = '<other_login>' ; GO xp_cmdshell 'whoami.exe' ; REVERT ;
A. Returning a list of executable files
The following example shows the xp_cmdshell extended stored procedure executing a directory command.
EXEC master..xp_cmdshell 'dir *.exe'
B. Using Windows net commands
The following example shows the use of xp_cmdshell in a stored procedure. This example notifies users by using net send that an instance of SQL Server is about to be shut down, pauses the server by using net pause, and then shuts the server down by using net stop.
CREATE PROC shutdown10 AS EXEC xp_cmdshell 'net send /domain:SQL_USERS ''SQL Server shutting down in 10 minutes. No more connections allowed.', no_output EXEC xp_cmdshell 'net pause sqlserver' WAITFOR DELAY '00:05:00' EXEC xp_cmdshell 'net send /domain: SQL_USERS ''SQL Server shutting down in 5 minutes.', no_output WAITFOR DELAY '00:04:00' EXEC xp_cmdshell 'net send /domain:SQL_USERS ''SQL Server shutting down in 1 minute. Log off now.', no_output WAITFOR DELAY '00:01:00' EXEC xp_cmdshell 'net stop sqlserver', no_output
C. Returning no output
The following example uses xp_cmdshell to execute a command string without returning the output to the client.
USE master; EXEC xp_cmdshell 'copy c:\SQLbcks\AdvWorks.bck \\server2\backups\SQLbcks, NO_OUTPUT'; GO
D. Using return status
In the following example, the xp_cmdshell extended stored procedure also suggests return status. The return code value is stored in the variable @result.
DECLARE @result int EXEC @result = xp_cmdshell 'dir *.exe' IF (@result = 0) PRINT 'Success' ELSE PRINT 'Failure'
E. Writing variable contents to a file
The following example writes the contents of the @var variable to a file named var_out.txt in the current server directory.
DECLARE @cmd sysname, @var sysname SET @var = 'Hello world' SET @cmd = 'echo ' + @var + ' > var_out.txt' EXEC master..xp_cmdshell @cmd
F. Capturing the result of a command to a file
The following example writes the contents of the current directory to a file named dir_out.txt in the current server directory.
DECLARE @cmd sysname, @var sysname SET @var = 'dir/p' SET @cmd = @var + ' > dir_out.txt' EXEC master..xp_cmdshell @cmd