Calculate the upload byte count from the right managed-disk source

Source facts

For a local VHD upload, Microsoft’s PowerShell workflow takes the file’s length in bytes for UploadSizeInBytes. When copying an existing Azure managed disk, its reported byte count omits the footer, so the destination calculation must add 512 bytes; otherwise the copy fails. For an OS disk, the destination configuration must also specify the appropriate Hyper-V generation. Finishing data transfer alone does not make the upload disk attachable: its SAS must be revoked. Microsoft Learn.

Applicability

Apply this distinction when adapting a direct-upload script into a region-copy or recovery workflow. Review the origin of every size value and the intended OS-disk generation before creating a target resource.

DSE recommendation

Record whether the size input came from a local file or an Azure managed-disk resource. Have the operator annotate the size calculation with its source and units. Keep local-file and managed-resource paths explicit in automation, and compare the resulting request with the corresponding official example. Do not repair a failed copy by repeatedly changing capacity without explaining the discrepancy.

Verification

Use a disposable representative disk to check the calculated upload size, destination generation when relevant, and transfer result. Complete the documented access-revocation step before checking attachment in an authorized test VM. Preserve the source resource ID, calculated byte count, and sanitized result without recording the SAS. Resolve unexplained size differences before using the workflow for recovery.

Official references

Microsoft Learn: Upload a VHD or copy a managed disk with Azure PowerShell. Source reviewed September 9, 2026.