Conversation
|
@nyanhp : Thanks for your contribution! The author(s) and reviewer(s) have been notified to review your proposed change. |
prmerger-automator
bot
added
azure-arc-sql-server/subsvc
Change sent to author
sql/svc
labels
|
Learn Build status updates of commit 393b936: ✅ Validation status: passed
For more details, please refer to the build report. |
|
Can you review the proposed changes? IMPORTANT: When the changes are ready for publication, adding a #label:"aq-pr-triaged" |
prmerger-automator
bot
added
the
aq-pr-triaged
There was a problem hiding this comment.
Pull request overview
Adds an IMPORTANT troubleshooting callout to help readers diagnose delayed SQL Server inventory visibility after moving Azure Arc-enabled SQL Server resources.
Changes:
- Added an IMPORTANT note describing what to check if SQL instances/databases don’t appear after a move.
- Suggested verifying the Azure Connected Machine agent status and upgrading the SQL Server extension to trigger inventory refresh.
|
|
||
| > [!IMPORTANT] | ||
| > | ||
| > If the SQL instances or databases associated with the moved virtual machines do not show up after up to three hours, |
There was a problem hiding this comment.
Wording is awkward/ambiguous: “do not show up after up to three hours” reads like both a delay and a maximum. Consider rephrasing to “don’t show up within three hours” (or specify the expected propagation window more directly).
| > If the SQL instances or databases associated with the moved virtual machines do not show up after up to three hours, | |
| > If the SQL instances or databases associated with the moved virtual machines don't appear in the portal within three hours, |
| > If the SQL instances or databases associated with the moved virtual machines do not show up after up to three hours, | ||
| > ensure that the Azure Connected Machine Agent is still running and connected to Azure Arc. | ||
| > | ||
| > Upgrading the `WindowsAgent.SqlServer` extension on the virtual machine will also trigger a refresh of the |
There was a problem hiding this comment.
This article applies to Arc-enabled machines (virtual or physical), but the new IMPORTANT note refers to “moved virtual machines”. Consider changing to “moved machines/servers” to avoid implying this only applies to VMs.
| > If the SQL instances or databases associated with the moved virtual machines do not show up after up to three hours, | |
| > ensure that the Azure Connected Machine Agent is still running and connected to Azure Arc. | |
| > | |
| > Upgrading the `WindowsAgent.SqlServer` extension on the virtual machine will also trigger a refresh of the | |
| > If the SQL instances or databases associated with the moved machines do not show up after up to three hours, | |
| > ensure that the Azure Connected Machine Agent is still running and connected to Azure Arc. | |
| > | |
| > Upgrading the `WindowsAgent.SqlServer` extension on the machine will also trigger a refresh of the |
| > [!IMPORTANT] | ||
| > | ||
| > If the SQL instances or databases associated with the moved virtual machines do not show up after up to three hours, | ||
| > ensure that the Azure Connected Machine Agent is still running and connected to Azure Arc. |
There was a problem hiding this comment.
For consistency with other Azure Arc docs and the product name, use “Azure Connected Machine agent” (lowercase “agent”) rather than “Azure Connected Machine Agent”. Consider linking “Azure Connected Machine agent” to the agent overview if helpful.
| > ensure that the Azure Connected Machine Agent is still running and connected to Azure Arc. | |
| > ensure that the Azure Connected Machine agent is still running and connected to Azure Arc. |
| > If the SQL instances or databases associated with the moved virtual machines do not show up after up to three hours, | ||
| > ensure that the Azure Connected Machine Agent is still running and connected to Azure Arc. | ||
| > | ||
| > Upgrading the `WindowsAgent.SqlServer` extension on the virtual machine will also trigger a refresh of the | ||
| > SQL instance and database inventory. |
There was a problem hiding this comment.
The note calls out upgrading the WindowsAgent.SqlServer extension on the “virtual machine”. This is Windows-specific and VM-specific; Arc-enabled SQL Server can also be on Linux/physical machines (for Linux it’s LinuxAgent.SqlServer). Consider referring generically to “the Azure extension for SQL Server” (and, if you include the extension name, mention both Windows and Linux) and adding a link to the existing extension upgrade instructions so the guidance is actionable.
| > If the SQL instances or databases associated with the moved virtual machines do not show up after up to three hours, | |
| > ensure that the Azure Connected Machine Agent is still running and connected to Azure Arc. | |
| > | |
| > Upgrading the `WindowsAgent.SqlServer` extension on the virtual machine will also trigger a refresh of the | |
| > SQL instance and database inventory. | |
| > If the SQL instances or databases associated with the moved servers do not show up after up to three hours, | |
| > ensure that the Azure Connected Machine Agent is still running and connected to Azure Arc. | |
| > | |
| > Upgrading the Azure extension for SQL Server (for example, `WindowsAgent.SqlServer` or `LinuxAgent.SqlServer`) will also trigger a refresh of the SQL instance and database inventory. For upgrade steps, see [Upgrade Azure extension for SQL Server](upgrade-azure-extension-sql-server.md). |
After going through support case 2603190050001974, the outcome was that more troubleshooting information would have helped. I've documented the necessary steps in a concise info box. In our specific case, upgrading the VM extension proved to be the simplest way as all SQL extensions were not yet auto-upgraded. Restarting the agent would likely also have helped.