Search results matching tags 'Best Practices', 'DBA', 'PowerShell', and 'Documentation'http://sqlblog.com/search/SearchResults.aspx?o=DateDescending&tag=Best+Practices,DBA,PowerShell,Documentation&orTags=0Search results matching tags 'Best Practices', 'DBA', 'PowerShell', and 'Documentation'en-USCommunityServer 2.1 SP2 (Build: 61129.1)SQL Server Best Practices: Protect CmdExechttp://sqlblog.com/blogs/buck_woody/archive/2009/12/03/sql-server-best-practices-protect-cmdexec.aspxThu, 03 Dec 2009 15:49:34 GMT21093a07-8b3d-42db-8cbf-3350fcbf5496:19482BuckWoody<p>In SQL Server, there are times that you need to do things in the operating system, and to allow that there is a feature called CmdExec. This is not always a good thing –whenever you leave the confines of SQL Server and go out to the operating system, you can cause issues, not the least of which are security-related.</p> <p>This best practice is primarily aimed at SQL Server 2000 – in SQL Server 2005 and higher, you’ll have these as job step types in SQL Server Agent (or ActiveX). What you should to do is ensure that only the sysadmins role can run CmdExec job steps.</p> <p>In SQL Server 2005 and higher, you should use other methods to work with the operating system, such as SQL CLR or PowerShell to handle that with better safety and security. </p>