The '-DefaultProfile' parameter are not supported by some cmdlets but are presented

[dolauli]

Description

Cmdlets are generated by autorest.powershell provides the parameter -DefaultProfile, which actually are not functional actually. And below are some workarounds.

1. You use may set-azcontext to switch the context instead of using -DefaultProfile.
2. If you just need to specify the subscription. you may use the -SubscriptionId parameters, which are supported by those autogen cmdlets.

Steps that will be taken considering removing those un-functional -DefaultProfile are breaking changes even if they are not functional

1. Add a warning message when -DefaultProfile is used to tell users the parameter is not functional and will be removed
2. Remove those -DefaultProfile
3. Add them back if -DefaultProfile is supported by the generator autorest.powershell.

Link to the feature request in autorest.powershell.

Issue script & Debug output

None

Environment data

None

Module versions

The bug happens in all generated cmdlets.

Error output

None

[kwill-MSFT]

Removing -DefaultProfile should not be the solution. Of the 2 workarounds offered:

1. Set-AzContext is not thread safe. If you run Az cmdlets in multi-threaded environments (Azure Functions or Powershell runspaces) then you cannot use Set-AzContext
2. Using -SubscriptionId parameter doesn't help with tenants. -DefaultProfile allows passing in contexts associated with different tenants.

Multi-subscription and multi-tenant management at scale is becoming more common among the largest Azure customers, and removing -DefaultProfile will effectively eliminate Az cmdlets as a potential option in these types of infrastructures.

[invisibleaxm]

I agree with @kwill-MSFT , removing the "defaultProfile" or AzContext as a parameter is NOT a solution. We run our code in azure functions, and we need to be able to pass the right context as a parameter for functions that fan-out and do work. With recent changes to the Azure Policy and the use of autorest , our code broke, not because of the new "output" from some cmdlets which was expected/announced but rather because some cmdlets like Get-AzPolicyAssignment no longer support the DefaultProfile/AzContext parameter (it's useless/ignored).

In the past, where we ran into issues with set-azcontext for multi-tenant environments and azure functions, Microsoft explicitly asked us to always pass the context to each az cmdlet , so please take into consideration this and bring this back as this is the only reliable way of handling multi-tenant environments where is imperative we ensure we perform the action with the right context when running code in azure functions.