ARM 1.0 :: -Profile parameter is missing

[pcgeek86]

The -Profile parameter seems to be missing from all ARM PowerShell commands, except for a couple of profile management commands. What happened to it?

PS C:\Windows\system32> Get-Command -Module *azure* -ParameterName Profile | Format-Table -AutoSize

CommandType Name                  Version Source         
----------- ----                  ------- ------         
Cmdlet      Save-AzureRmProfile   1.0.0   AzureRM.Profile
Cmdlet      Select-AzureRmProfile 1.0.0   AzureRM.Profile

Cheers,
Trevor Sullivan
Microsoft MVP PowerShell
http://trevorsullivan.net
http://twitter.com/pcgeek86

[markcowl]

@pcgeek86 given that there is a new profile created in every session, and there was no longer a need for creating new profiles, we decided to remove the -Profile parameter in favor of Select-AzureRmProfile (which can be used to select a disk profile, or a profile saved in variable). If there is enough interest in this parameter, we will likely revive it.

[jodoglevy]

+1! Here's my reasoning on why this is needed ( @markcowl already sent you this, just putting it here so its tracked along with the issue):

I think the problem is that the profile is still singular, it’s just now been moved from being in a file to being in memory. If script A is running against subscription A, and another script B comes along and overwrites the in memory profile using Add-AzureRMAccount so it can run against subscription B, the rest of the commands in script A that haven’t executed yet will now be running against subscription B, when they should be running against subscription A. Stateless profiles that allow passing a profile directly to a cmdlet via a parameter, would prevent this.

In addition to the above, we also need stateless profiles because in Azure Automation, jobs may be suspended and resumed on completely different machines, so we can’t depend on any profiles saved to the file system via Save-AzureRMProfile being there when a job is resumed. Rather than a user having to remember to reauthenticate after every possible suspension point, it would be good if they could just have the profile saved as a variable in their script and that variable passed to each AzureRM cmdlet.

[pcgeek86]

Thanks for your input, Joe. To build on that a little bit, it kind of goes back to the old Switch-AzureMode days. Remember when he had to "switch" between module contexts? It was painful. In a similar vein, I think that users shouldn't be required, but still have the option of, switching Azure subscription contexts.

The nice thing about using the -Profile parameter universally on AzureRM commands, is that you can specify all of the required parameters in a single command call, and not be affected by "the environment." It's more predictable that way, and easier to debug if something goes wrong.

[bvirkler]

Any timeline on fixing this? This issue makes the use case of processing multiple subscriptions in parallel from Azure Automation impossible.

[SamirFarhat]

Hello all,
Is this 'bug' still alive? How do you expect customers to use Automation if isolation is not possible?

[huberthk]

+1

This is very desirable functionality. The use case here is CSP customer executing Azure Automation runbooks against the tenants' (separate) subscriptions.

[markcowl]

The fix for this is scheduled in #2728 Closing in favor of the more detailed issue scheduled for this sprint.

[evergreen435]

Hi,

It looks like this issue is nominated as fixed by the fix for the following issue https://github.com/Azure/azure-powershell/issues/3656.

Could someone please explain how we can get multiple runbooks in the same automation account running at the same time against different subscriptions. We are having the issue above where if the subscription is changed in one runbook, then it changes for all operating runbooks, so we get errors. This also occurs if we are running parallel workflows on different subscriptions with the same runbook.

Many Thanks

[eamonoreilly]

In Azure Automation runbooks, you should now pass in the -AzureRMContext for each Azure cmdlet call. For example, you would set up a variable to hold the subscription you want to work against like below:

$SubscriptionA = Set-AzureRmContext -SubscriptionId

You would then pass this subscription context in every cmdlet call to ensure it is always working against the correct subscription.

$Result = Get-AzureRM -AzureRmContext $SubscriptionA