Fix PublicEnvironments initialization when context is autosaved

[gsacavdm]

Description

Running Enable-AzureRmContextAutosave breaks support for sovereign clouds. After running that command, Get-AzureRmEnvironment returns no results and Login-AzureRmAccount -Environment AzureUSGovernment errors out with "Unable to find environment with name 'AzureUSGovernment'"

Script/Steps for Reproduction

# Show all environments. This works fine if ContextAutoSave is not enabled
Get-AzureRmEnvironment | ft

# Try to log in, this will prompt correctly, cancel out from this dialog
Login-AzureRmAccount -Environment AzureUSGovernment

# Now enable auto save
Enable-AzureRmContextAutosave

# No environments are show anymore
Get-AzureRmEnvironment | ft

# Login fails
Login-AzureRmAccount -Environment AzureUSGovernment

Module Version

5.4.1

Environment Data

Name	Value
PSVersion	5.1.16299.248
PSEdition	Desktop
PSCompatibleVersions	{1.0, 2.0, 3.0, 4.0...}
BuildVersion	10.0.16299.248
CLRVersion	4.0.30319.42000
WSManStackVersion	3.0
PSRemotingProtocolVersion	2.3
SerializationVersion	1.1.0.1

[markcowl]

@gsacavdm Good catch, it looks like environment initialization with built-in environments does not happen until you login once.

Note that you should be able to add the environments, or , if you have an azure login, you can work around this by:

• logging into Azure
• closing the session
• in the new session the get-environment cmdlet should work

[markcowl]

Fix: Ensure that public environments are properly copied into the context during first execution of the cmdlet

[gsacavdm]

Workaround worked awesome! Though so that other's that leverage sovereign clouds don't get stuck, it would be ideal to get this fixed. Is this relatively straight forward that you'll be able to address soon? Or maybe provide some guidance so that I can fix it? :)