I've been following this post since the beginning. You want to talk about not seeing the forest for the trees? This is getting into not seeing a tree because of the weeds.

I look at that the use of xp_cmdshell as a production DBA as a simple need. There are some things that can be achieved through CLR or PS, but take about 15 steps to the three needed to use xp_cmdshell.

A little background on my thought processes. In eleventh grade I was taking two programming classes. One was BASIC (not VB) and the other was assembler. My senior year was Pascal and COBOL. From my touching COBOL, I determined I'd starve on the street before I would program in it.

So now more than twenty years forward in time, I'm watching this argument and laughing at it. If you have someone that is at the sysadmin level and can use xp_cmdshell and can't find a way to beat the audit log then they deserve to be caught. If the SQL service account has any raised domain level permissions then you didn't set up it up right in the first place.

This was like my last company. The auditors demanded that we have a regular user account and then use a separate admin account for doing the admin work. We would login into our computers as our regular account then had a batch file to launch everything else as an admin privilege with an input put parameter for the password. Why? Because we realized the stupidity.

The argument over whether xp_cmdshell is a threat means that someone, with decent knowledge, is already so far in it doesn't matter. Now I catch a programmer doing that crap, I'm going to bust his butt. But the usual end-user using an application is not going to be the danger. So trying to guard against the normal edge is good. But going to paranoiac extremes generally makes no sense.