<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Xp_cmdshell on SQL Server Scripts</title><link>https://www.sqlserver70.com/tags/xp_cmdshell/</link><description>Recent content in Xp_cmdshell on SQL Server Scripts</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>SQLServer70.com</copyright><lastBuildDate>Mon, 24 Aug 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://www.sqlserver70.com/tags/xp_cmdshell/index.xml" rel="self" type="application/rss+xml"/><item><title>Audit Server Configuration Drift with sys.configurations</title><link>https://www.sqlserver70.com/post/server-configuration-drift-sys-configurations/</link><pubDate>Mon, 24 Aug 2026 00:00:00 +0000</pubDate><guid>https://www.sqlserver70.com/post/server-configuration-drift-sys-configurations/</guid><description>
&lt;p&gt;Running &lt;code&gt;sp_configure&lt;/code&gt; and getting back a success message is not the same thing as a setting actually taking effect. Between the moment a value is changed and the moment &lt;a href="https://learn.microsoft.com/en-us/sql/sql-server/"&gt;SQL Server&lt;/a&gt; is actually running it sits a gap — one a busy DBA can close with a single &lt;code&gt;RECONFIGURE&lt;/code&gt;, or forget entirely until a restart months later flips a setting no one meant to touch yet. &lt;a href="https://learn.microsoft.com/en-us/sql/relational-databases/system-catalog-views/sys-configurations-transact-sql"&gt;sys.configurations&lt;/a&gt; is where that gap is visible: its &lt;code&gt;value&lt;/code&gt; and &lt;code&gt;value_in_use&lt;/code&gt; columns don't have to match, and when they don't, this script says exactly why not and what to do about it.&lt;/p&gt;</description></item></channel></rss>