Skip to content

anchor - #34

Merged
Barbara Kess (barbkess) merged 1 commit into
microsoft:masterfrom
CarlRabeler:readme2
May 12, 2016
Merged

Barbara Kess (barbkess) merged 1 commit into
microsoft:masterfrom
CarlRabeler:readme2

Conversation

@CarlRabeler

Copy link
Copy Markdown
Contributor

No description provided.

@CarlRabeler

Copy link
Copy Markdown
Contributor Author

@barbkess
Barbara Kess (barbkess) merged commit 7208219 into microsoft:master May 12, 2016
Umachandar Jayachandran (uc-msft) pushed a commit that referenced this pull request Aug 31, 2026
'az sql vm update' has no --no-wait option and blocks for roughly two minutes
per VM, so SQL virtual machines were the one Azure resource type that ignored
the async-by-default behaviour introduced with -WaitForCompletion.

Update-AzSqlVM advertises -NoWait and -AsJob but both are broken in
Az.SqlVirtualMachine 2.4.0: -NoWait forwards the bound parameter into
Get-AzSqlVM, which rejects it, and -AsJob throws a NullReferenceException.

Add Invoke-SqlVmLicenseUpdate, which submits the change to ARM directly by
reading the resource and writing it back with only sqlServerLicenseType
changed. ARM accepts the request and returns an Azure-AsyncOperation header
without waiting, so the call completes in seconds. The synchronous CLI path is
retained for -WaitForCompletion and as an automatic fallback on failure.

Verified live against rajpoTest: default run reported RequestSubmitted in
49.7s and the change was confirmed in Azure; -WaitForCompletion reported
Updated in 189.3s. Re-synced the embedded orchestrator copy and corrected the
README behaviour matrix and TESTPLAN case #34, which wrongly recorded the SQL
VM limitation as unavoidable.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants