This is out of the box since SQL Server 2005 when they introduced the Surface Area Customizer to make SQL Server more secure by default. Since then, this tool has retired, but you can still control 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 wrote about this many years ago .)
The reason is that this is a potential security hole. If you allow SQL Server to run xp_cmdshell , then they theoretically can send any command to the operating system, bypassing any security that you thought about. This is especially problematic when the SQL Server service account and / or proxy account are upgraded to a system administrator or other levels, because it is easier than directly identifying only the exact things that they need to do.
Instead of turning it on and off to support command line interaction, a popular way to expose the functionality of an operating system, although it controls 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 the CLR (however, if you search around you will find much more modern and comprehensive approaches).