This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Enable ‘xp_cmdshell’ SQL Server
When I run xp_cmdshell command in SQL Server 2012, I get the following message:
SQL Server blocked access to procedure 'sys.xp_cmdshell' of component 'xp_cmdshell'
because this component is turned off
as part of the security configuration for this server.
A system administrator can enable the use of 'xp_cmdshell'
by using sp_configure. For more information about enabling 'xp_cmdshell',
search for 'xp_cmdshell' in SQL Server Books Online.
But, in SQL Server 2000 this query is executed successfully.
This has been disabled out of the box starting with SQL Server 2005, when they introduced the Surface Area Configuration Tool, in an effort to make SQL Server more secure by default. That tool has since been retired, but you can still control the behavior using sp_configure. An example is shown on MSDN:
-- To allow advanced options to be changed.
EXEC sp_configure 'show advanced options', 1
GO
-- To update the currently configured value for advanced options.
RECONFIGURE
GO
-- To enable the feature.
EXEC sp_configure 'xp_cmdshell', 1
GO
-- To update the currently configured value for this feature.
RECONFIGURE
GO
(I also blogged about this many years ago.)
The reason is that this is a potential security hole. If you allow SQL Server to execute xp_cmdshell, then they can theoretically send any operating system command there, bypassing any and all security you thought you had. This is especially problematic when the SQL Server service account and/or the proxy account have been elevated to sysadmin or other levels because that's easier than explicitly defining only the exact things they should be able to do.
Rather than enable it and disable it to support command-line interaction, a popular way to expose operating system functionality while still having some control over security is to implement the OS-level functionality you need using SQL-CLR. Here is a good starting point for accessing the file system with CLR (however if you search around you will find much more modern and exhaustive approaches).
This is disable for sql server 2012.
But you can run the following command in sql server 2008..
EXEC sp_configure 'xp_cmdshell', 1
RECONFIGURE
Related
I have a SQL Server database project (sqlproj file) in which I have referenced an assembly containing a user-define aggregate function per https://learn.microsoft.com/en-us/sql/relational-databases/clr-integration-database-objects-user-defined-functions/clr-user-defined-functions?view=sql-server-2017
I was unable to deploy or use my function until I did this:
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'clr strict security', 0;
RECONFIGURE;
...and also:
EXEC sp_configure 'clr enabled' , '1';
RECONFIGURE;
Along the way, I tried signing the assembly (generated a self-signed cert in a pfx), but could not figure out how to get SQL Server to trust the certificate.
As best I understand it, what I've done is acceptable for a local development deployment, but this is not the right way to deploy to a live environment (or to push to an Azure database service).
I've seen advice which suggests deploying to an older version of SQL Server in order to extract a hash of the assembly to use in a command which will establish trust; this is not useful to me because I only have SQL Server 2017 and have no intention of installing something like 2008 just to extract a hash.
What is the sequence of steps I must perform to successfully deploy my custom assembly with my database and establish trust "the right way", and what exactly does each of those steps accomplish? Part of my problem is a lack of clarity around the need, purpose, side-effects, and "meaning" of each required step.
I have a very strange situation on SQL Server that I cannot fathom out.
Environment : SQL Server 2012 SP3 CU3 running on a 2 node Windows 2008 R2 cluster
In SQL Server Management Studio\Management\Maintenance Plans\ I am unable to create or edit existing plans.
I receive the error:
'Agent XPs' component is turned off as part of the security configuration for this server. A system administrator can enable the use of 'Agent XPs' by using sp_configure. For more information about enabling 'Agent XPs', see "Surface Area Configuration" in SQL Server Books Online. (ObjectExplorer)
Checking around that error I expected the following config was going to be required.
-- To allow advanced options to be changed.
EXEC sp_configure 'show advanced options', 1;
GO
-- To update the currently configured value for advanced options.
RECONFIGURE;
GO
-- To enable the feature.
EXEC sp_configure 'Agent XPs', 1;
GO
-- To update the currently configured value for this feature.
RECONFIGURE;
GO
However, I noticed that SQL Agent was already running so I thought I would also check existing config options for 'Agent XPs'
What was interesting was that config_value = 0, run_value = 1 where I was expecting config_value = 1, run_value = 1.
I thought I'd try the sp_configure solution to 'force' the config but when I ran it (step by step), the first RECONFIGURE statement just hung and indeed when it ran I could not even run an sp_who2 to see if it was blocking or being blocked.
The only way I could kill the RECONFIGURE was to close the query window which cancelled it. I therefore am unable to run EXEC sp_configure 'Agent XPs', 1 as the required RECONFIGURE cannot be run.
After a failover of the cluster, the config settings for 'Agent XPs'
remains at config_value = 0, run_value = 1.
Has anyone got any ideas as to how to fix it?
I stumbled across an internet post with a similar issue and that contained a nugget of information that allowed me to ultimately fix the issue.
I documented the case over at SQLServerCentral
https://www.sqlservercentral.com/Forums/1927277/SQL-Server-2012-tells-me-Agent-XPs-component-is-turned-off-but-SQL-Agent-is-running
I'm currently on a host(A), connecting to a MSSQL database on server(B).
When I do a System call, such as
EXEC xp_cmdshell 'Systeminfo' GO
from within MS SQL 2008 it always returns me system information from the client(A) I'm currently running my SQL management tool on.
Is there a possibility to run System calls that will return me information from the server(B)?
I have since asking this question rebooted, and tried all the steps again:
1. Turn off local server
2. Connect to external server
3. Turn on XP_CMDSHELL command for the external server using
-- To allow advanced options to be changed.
EXEC sp_configure 'show advanced options', 1;
GO
-- To update the currently configured value for advanced options.
RECONFIGURE;
GO
-- To enable the feature.
EXEC sp_configure 'xp_cmdshell', 1;
GO
-- To update the currently configured value for this feature.
RECONFIGURE;
GO
And then just run
EXEC xp_cmdshell 'Systeminfo';
GO
Weird that it works now,because I couldn't get it to work past weeks.
It might be very basic question for you friends, but how to allow multiple users on SQL Server installed on remote windows server 2012 machine.?
right now only two user can work at the same time if third one comes one of two who are active has to allow and get out himself.
we are building new server which will allow multiple user to work on the same time.
My question is once we install SQL server on windows server machine what configuration needs to be done to achieve our goal(Multiple user can work on same time) on server machine as well as what configuration needs to be done on computers of people who will be logging into it.
do we need same number of instance similar to how many people will be working on it? if yes it means that many number of same database on the server and more space will be occupied right?
Thanks.
EXEC sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
EXEC sp_configure 'user connections', 777;
GO
RECONFIGURE;
GO
Replace 777 with your limit of connections.
I have a Dataman high speed ID scanner which I need to communicate with a SQL Server 2008 database. There are a few different ways for it to communicate, but the only one that isn't an industrial protocol is Telnet. How can I have the database communicate with the scanner over Telnet?
If you have any other suggestions for how to communicate with it, I'd love to hear them too.
You will need to write an application which uses Telnet to talk to the scanner, and can then read/write from the database accordingly.
You could, for example, write something in C# (using Visual Studio) and use the following library for Telnet access:
http://www.codeproject.com/Articles/19071/Quick-tool-A-minimalistic-Telnet-library
If you really, really have to get the database to execute the code, then you might be able to write something in C# which is then picked up using CLR integration within SQL Server 2008. But I would recommend keeping your application separate from the database (for ease of development and testing purposes).
You can create a telnet client in a SQLCLR stored procedure and then call the CLR procedure from a regular TSQL stored procedue. SQLCLR is not very commonly used, but it is more robust than many people assume, and I've talked to teams that have had good success with it.
One thing to keep in mind is that, if you go the SQLCLR route, you'll be writing the same .NET code that you would have written if you had decided to take the advice of other answers to this question and implement an external utility that pushes data into SQL server. The only difference is that with SQLCLR the stored procedure can actively trigger the telnet interaction.
SQLCLR stored procedures require some special techniques, but Visual Studio database projects make it pretty easy to create one.
Well SQL Server can't do this natively, so you're going to have to go outside of your comfort zone a little in any event. Also by "on the server" do you mean on the same physical server where SQL Server is running, or do you mean "inside the SQL Server instance"?
You could certainly call a local PowerShell script from xp_cmdshell inside a stored procedure, or as part of a SQL Server Agent job step if you need it to be asynchronous (and if you're not running Express Edition, which doesn't have Agent). Here is a PowerShell script that wouldn't take ultimate PowerShell mastery to adapt to your needs:
Automating Telnet with PowerShell
In order to call this from within a stored procedure, you'll first need to be sure that xp_cmdshell is enabled:
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE WITH OVERRIDE;
GO
EXEC sp_configure 'xp_cmdshell', 1;
EXEC sp_configure 'show advanced options', 0;
RECONFIGURE WITH OVERRIDE;
GO
As a caution, a lot of people view exposing xp_cmdshell as a bird-flu-like pandemic. To me it's all about controlling access to the machine not about controlling what the machine can and can't do to fulfill your business requirements.
Here is a quick sample of consuming the output of whatever you send to xp_cmdhsell. This is just a standard command-line call, so you'll have to adapt it for calling PowerShell scripts, but it should work largely the same:
CREATE TABLE #tmp(i INT IDENTITY(1,1), x VARCHAR(2048));
INSERT #tmp(x) EXEC master..xp_cmdshell 'dir C:\Users\';
SELECT x FROM #tmp ORDER BY i;
DROP TABLE #tmp;
Results:
Volume in drive C has no label.
Volume Serial Number is 50D3-008B
NULL
Directory of C:\Users
NULL
01/10/2012 09:20 AM <DIR> .
01/10/2012 09:20 AM <DIR> ..
01/19/2011 11:54 PM 1,444 SomeFile.txt
.... other files...
3 File(s) 28,918,500 bytes
18 Dir(s) 19,367,292,416 bytes free
NULL
But once you've spent more than an hour messing with this to get it to work, I think you're really better off writing an application that either runs as a service or on an interval, checks a queue table for new telnet processing to, does the work, then writes the results to SQL Server. Your RDBMS shouldn't be treated like a batch scripting host IMHO.