Add Trusted Launch security type support to New-AzMigrateServerReplication

[shreyasmalims]

Description

This PR adds support for Trusted Launch security type for Azure Migrate server replication.

Changes made:

• Added TargetSecurityType parameter to specify security type for Azure VM (Standard or TrustedLaunch)
• Added TargetVMSecureBootEnabled parameter to control secure boot on target VM
• Implemented security profile configuration logic that automatically enables TPM when TrustedLaunch is selected
• Added validation to ensure SecureBoot is only used with TrustedLaunch security type
• Removed unnecessary Az.Compute module import that was redundant
• Removed disk encryption set configuration from data disks in DefaultUser mode

Design decisions:

• When TargetSecurityType is set to "TrustedLaunch" without explicitly setting TargetVMSecureBootEnabled, secure boot is automatically enabled (defaults to "true")
• TPM is automatically enabled when security type is TrustedLaunch
• SecureBoot parameter throws an error if used without TrustedLaunch security type

This implementation is based on the changes from AsrOneSdk/azure-powershell PR #37 which was never merged.

ChangeLog:

* Added support for Trusted Launch security type in New-AzMigrateServerReplication
  - Added TargetSecurityType parameter to specify VM security type (Standard or TrustedLaunch)
  - Added TargetVMSecureBootEnabled parameter to control secure boot setting

Checklist

• Check this box to confirm: I have read the Submitting Changes section of CONTRIBUTING.md and reviewed the following information:

• SHOULD select appropriate branch. Cmdlets from Autorest.PowerShell should go to generation branch.
• SHOULD make the title of PR clear and informative, and in the present imperative tense.
• SHOULD update ChangeLog.md file(s) appropriately
  • For any service, the ChangeLog.md file can be found at src/{{SERVICE}}/{{SERVICE}}/ChangeLog.md
  • A snippet outlining the change(s) made in the PR should be written under the ## Upcoming Release header in the past tense. Add changelog in description section if PR goes into generation branch.
  • Should not change ChangeLog.md if no new release is required, such as fixing test case only.
• SHOULD have approved design review for the changes in this repository (Microsoft internal only) with following situations
  • Create new module from scratch
  • Create new resource types which are not easy to conform to Azure PowerShell Design Guidelines
  • Create new resource type which name doesn't use module name as prefix
  • Have design question before implementation
• SHOULD regenerate markdown help files if there is cmdlet API change. Instruction
• SHOULD have proper test coverage for changes in pull request.
• SHOULD NOT introduce breaking changes in Az minor release except preview version.
• SHOULD NOT adjust version of module manually in pull request

[azure-client-tools-bot-prd]

Thanks for your contribution! The pull request validation has started. Please revisit this comment for updated status.

[isra-fel]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[shreyasmalims]

@microsoft-github-policy-service agree company="Microsoft"

[Copilot]

Pull request overview

This pull request adds support for Trusted Launch security type to the New-AzMigrateServerReplication cmdlet in the Azure Migrate module. The feature enables users to configure Azure VMs with enhanced security capabilities during migration, including TPM and Secure Boot settings.

Changes:

• Added two new parameters (TargetSecurityType and TargetVMSecureBootEnabled) to specify VM security configuration
• Implemented logic to automatically enable TPM and default Secure Boot to "true" when TrustedLaunch is selected
• Added validation to prevent using Secure Boot with non-TrustedLaunch security types

[Copilot]

The validation logic has a usability issue. If a user provides TargetVMSecureBootEnabled without providing any TargetSecurityType, they get an error "SecureBoot is supported only when security type is trusted launch virtual machine." This error message is misleading because it implies they provided the wrong security type, when in fact they didn't provide one at all. The error should distinguish between: 1) No security type provided (suggest providing TrustedLaunch), and 2) Wrong security type provided (e.g., Standard). Consider checking $HasTargetSecurityType and providing a more specific error message.

Suggested change

	} elseif ($HasTargetVMSecureBootEnabled) {
	throw "SecureBoot is supported only when security type is trusted launch virtual machine."
	} elseif ($HasTargetSecurityType -and $TargetSecurityType -eq "Standard" -and $HasTargetVMSecureBootEnabled) {
	throw "SecureBoot is not supported when security type is 'Standard'. Please specify a supported security type such as 'TrustedLaunch' when enabling SecureBoot."
	} elseif (-not $HasTargetSecurityType -and $HasTargetVMSecureBootEnabled) {
	throw "TargetSecurityType must be specified (for example, 'TrustedLaunch') when enabling SecureBoot."

[Copilot]

Using string type with ValidateSet for boolean values ("true"/"false") is not idiomatic PowerShell. PowerShell parameters should use [System.Boolean] or [switch] types for boolean values. String-based booleans can be confusing to users and require extra conversion logic. Consider changing this to [System.Boolean] type instead, which would accept $true/$false or allow implicit conversion from strings.

Suggested change

	[ValidateSet("true" , "false")]
	[ArgumentCompleter( { "true" , "false" })]
	[Microsoft.Azure.PowerShell.Cmdlets.Migrate.Category('Path')]
	[System.String]
	[Microsoft.Azure.PowerShell.Cmdlets.Migrate.Category('Path')]
	[System.Boolean]

[Copilot]

The new security type parameters (TargetSecurityType and TargetVMSecureBootEnabled) lack test coverage. The existing tests in New-AzMigrateServerReplication.Tests.ps1 are all marked as 'skip' and don't cover the new security type functionality. Consider adding test cases that verify: 1) TrustedLaunch with default SecureBoot (should be true), 2) TrustedLaunch with explicit SecureBoot=false, 3) Standard with SecureBoot (should error), 4) TPM auto-enablement for TrustedLaunch.

[Copilot]

The parameter name "TargetVMSecureBootEnabled" uses a string type with "true"/"false" values, which is inconsistent with the Azure Compute module's pattern. In the Compute module (e.g., New-AzVMConfig, Set-AzVMSecurityProfile), boolean flags like EnableSecureBoot and EnableVtpm are used as switch parameters or boolean types. Consider renaming to "EnableTargetVMSecureBoot" and using a [switch] parameter type for consistency with the rest of Azure PowerShell.

Suggested change

	[ValidateSet("true" , "false")]
	[ArgumentCompleter( { "true" , "false" })]
	[Microsoft.Azure.PowerShell.Cmdlets.Migrate.Category('Path')]
	[System.String]
	# Specifies if secure boot needs to be enabled on target VM.
	${TargetVMSecureBootEnabled},
	[Alias('TargetVMSecureBootEnabled')]
	[Microsoft.Azure.PowerShell.Cmdlets.Migrate.Category('Path')]
	[switch]
	# Specifies if secure boot needs to be enabled on target VM.
	${EnableTargetVMSecureBoot},

[Copilot]

Missing input validation: The code doesn't validate the scenario where TargetSecurityType is set to "Standard" and TargetVMSecureBootEnabled is provided. According to Azure documentation, SecureBoot is only valid for TrustedLaunch VMs. The validation on line 587 only triggers when HasTargetSecurityType is false OR TargetSecurityType equals "Standard", but the condition "HasTargetSecurityType -and TargetSecurityType -ne 'Standard'" on line 584 will be false for Standard, so the elseif on line 587 will trigger. However, this only happens if SecureBoot was specified. The error handling should explicitly check for the Standard + SecureBoot combination and provide a clear error message.

Suggested change

	$ProviderSpecificDetails.TargetVMSecurityProfileIsTargetVmtpmEnabled = $true
	$ProviderSpecificDetails.TargetVMSecurityProfileIsTargetVmtpmEnabled = $true
	} elseif ($HasTargetSecurityType -and $TargetSecurityType -eq "Standard" -and $HasTargetVMSecureBootEnabled) {
	throw "SecureBoot cannot be enabled when TargetSecurityType is 'Standard'. SecureBoot is supported only for TrustedLaunch virtual machines."

[Copilot]

The logic flow has an issue. Line 580 checks if TargetSecurityType equals "TrustedLaunch" without first checking if HasTargetSecurityType is true. This means that when TargetSecurityType is not provided (null or empty string), the comparison on line 580 will be checking null/empty against "TrustedLaunch", which will be false. However, this is not immediately obvious and could lead to confusion. Consider adding $HasTargetSecurityType check before line 580 for clarity and to match the pattern on line 584.

Suggested change

	} elseif ($TargetSecurityType -eq "TrustedLaunch") {
	} elseif ($HasTargetSecurityType -and $TargetSecurityType -eq "TrustedLaunch") {