Additional SQL Server features and topics not covered by specific categories
Get-AzDataMigrationAssessment documents creation of a JSON assessment report, but it does not define a stable JSON schema, guarantee that all three target scenarios are combined into one file, or document HTML files as supported output; therefore, automation should not currently depend on those behaviors as a versioned contract.
What is officially documented
The cmdlet has two invocation modes:
-
-ConnectionString, optionally with-OutputFolderand-Overwrite -
-ConfigFilePath
The published examples show one report named SqlAssessmentReport.json, an event/error log directory, and a Boolean PowerShell return value. They do not provide a report schema or a multi-target sample. The documented syntax also has no HTML-related parameter.^1^
Consequently:
- Single JSON containing all three scenarios: Not guaranteed by the published cmdlet contract. The singular report in the examples does not establish how
AzureSQLDB,AzureSQLManagedInstanceDB, andSQLRunningOnVmAssessmentmust be grouped. - Official JSON schema/sample: None is published in the available cmdlet documentation.
- HTML generation: Not documented as an output of this cmdlet, including its trigger conditions or intended use. An HTML file appearing beside the JSON is therefore not sufficient to treat HTML generation as a supported cmdlet contract.
- PowerShell output:
-PassThrudoes not document returning the report model; the declared output type is Boolean.^1^
The absence of configuration-schema documentation has also been reported specifically for this command.^2^
Version 1.1.1
The published 1.1.1 release note says only that the authentication key was removed from console output. It does not announce a JSON-schema or HTML-generation change.^3^
Also note that view=azps-16.4.0 identifies the Az PowerShell documentation set, while your installed component is Az.DataMigration 1.1.1. Those are not the same version number.
Isolate the cross-system difference
The screenshot shows multiple numbered JSON files and per-database HTML files rather than the single SqlAssessmentReport.json shown in the official example. Before attributing every file to this cmdlet, reproduce into a new empty output directory and capture the loaded runtime—not merely the module present under C:\Program Files\WindowsPowerShell\Modules.
Run the following on each system:
$dir = 'C:\Assessment-Repro'
New-Item -ItemType Directory -Path $dir -Force | Out-Null
$PSVersionTable | Format-List *
Get-Module Az.DataMigration -ListAvailable |
Select-Object Name, Version, Path
Import-Module Az.DataMigration -RequiredVersion 1.1.1 -Force
Get-Module Az.DataMigration |
Select-Object Name, Version, Path
Get-AzDataMigrationAssessment `
-ConnectionString $connectionString `
-OutputFolder $dir -Overwrite -Verbose
Get-ChildItem $dir -Recurse |
Select-Object FullName, Length, LastWriteTime
Then compare:
- The loaded module path and version.
- Windows PowerShell versus PowerShell 7 details from
$PSVersionTable. - The exact command line or exact configuration file.
- Files present before and after execution.
- Console output and the reported event/error log directory.
- JSON root shape and property names without assuming a schema:
Get-ChildItem $dir -Filter *.json | ForEach-Object {
$data = Get-Content $_.FullName -Raw | ConvertFrom-Json
[pscustomobject]@{
File = $_.Name
RootType = $data.GetType().FullName
Properties = ($data.PSObject.Properties.Name -join ', ')
}
}
If HTML appears only with -ConfigFilePath, compare the configuration files byte-for-byte. The cmdlet officially accepts that mode, but its documented reference does not specify which configuration fields alter report layout or artifact generation.^1^
Recommended handling and escalation
For predictable processing:
- Pin the PowerShell edition/version,
Az.DataMigrationversion, invocation mode, and configuration file. - Process each JSON file independently and validate required properties instead of relying on file count, ordering, or one fixed root layout.
- Treat HTML as optional unless Microsoft publishes an explicit contract.
- Preserve the output directory and the cmdlet’s event/error logs from one affected and one unaffected system.
If identical clean-room executions still produce different artifacts, open an Azure PowerShell issue or Microsoft support request with the two environment captures, sanitized configuration files, representative sanitized JSON root structures, verbose output, and logs. Request confirmation of the report generator/version being invoked and a supported schema contract; the current public documentation does not provide enough information to determine the HTML trigger or guarantee identical serialization.
References