<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>SQL Server Managed Instance on SQLSurfer</title>
		<link>http://localhost:1313/tags/sql-server-managed-instance/</link>
		<description>Recent content in SQL Server Managed Instance on SQLSurfer</description>
		<generator>Hugo</generator>
		<language>en-us</language>
		
		
		
		
			<lastBuildDate>Tue, 18 Aug 2026 16:29:32 -0500</lastBuildDate>
		
			<atom:link href="http://localhost:1313/tags/sql-server-managed-instance/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>Using SQL Agent Jobs to Troubleshoot SQL Managed Instances</title>
				<link>http://localhost:1313/posts/using-scripts-to-troubleshoot-managed-instances/</link>
				<pubDate>Tue, 18 Aug 2026 16:29:32 -0500</pubDate>
				<guid>http://localhost:1313/posts/using-scripts-to-troubleshoot-managed-instances/</guid>
				<description>&lt;h2 id=&#34;sql-server-managed-instance-diagnostics&#34;&gt;SQL Server Managed Instance Diagnostics&lt;/h2&gt;&#xA;&lt;p&gt;The great thing about SQL Server Managed Instance (SQL MI) is that you don&amp;rsquo;t need to perform any maintenance or troubleshooting on the OS or SQL installation. In theory. If you&amp;rsquo;ve used SQL MI, you might find that this isn&amp;rsquo;t always the case. If you have issues, you&amp;rsquo;ll find that you have limited troubleshooting options on the server and your options for running scripts are constrained. Microsoft support doesn&amp;rsquo;t have unfettered access either. They have hard boundaries on what can be accessed on your servers and they need to escalate quite extensively to other internal teams when examining certain problems.&lt;/p&gt;</description>
			</item>
	</channel>
</rss>
