Which of these modules is not included in Azure PowerShell?
Answers
With the emphasis on developer tools (especially CLIs) in Azure, the Azure PowerShell team is experimenting with many improvements to the Azure PowerShell experience.
Experimentation methodology
To facilitate experimentation, we're creating new Azure PowerShell modules that implement existing Azure SDK functionality in new, easier to use ways. In most cases, the cmdlets exactly mirror existing cmdlets. However, the experimental cmdlets provide a shorthand notation and smarter default values that make it easier to create and manage Azure resources.
These modules can be installed side by side with existing Azure PowerShell modules. The cmdlet names have been shortened to provide shorter names and avoid name conflicts with existing, non-experimental cmdlets.
The experimental modules use the following naming convention: AzureRM.*.Experiments. This naming convention is similar to the naming of Preview modules: AzureRM.*.Preview. Preview modules differ from experimental modules. Preview modules implement new functionality of Azure services that is only available as a Preview offering. Preview modules replace existing Azure PowerShell modules and use the same cmdlet and parameter names.
How to install an experimental module
Experimental modules are published to the PowerShell Gallery just like the existing Azure PowerShell modules. To see a list of experimental modules, run the following command:
Azure PowerShell
Copy
Try It
Find-Module AzureRM.*.Experiments
output
Copy
Version Name Repository Description
------- ---- ---------- -----------
1.0.25 AzureRM.Compute.Experiments PSGallery Azure Compute experiments for VM creation
1.0.0 AzureRM.Websites.Experiments PSGallery Create and deploy web applications using Azure App Services.
To install the experimental module, use the following commands from an elevated PowerShell session:
Azure PowerShell
Copy
Try It
Install-Module AzureRM.Compute.Experiments
Install-Module AzureRM.Websites.Experiments
Documentation and support
Documentation is included in the install package and is accessed using the Get-Help cmdlet. No official documentation is published for experimental modules.
We encourage you to test these modules. Your feedback allows us to improve usability and respond to your needs. However, being experimental, support for these modules is limited. Questions or problem reports can be submitted by creating an issue in the GitHub repository.
Experiments and areas of improvement
These improvements were selected based on key differentiators in competing products. For example, Azure CLI 2.0 has made a point of basing commands on scenarios rather than API surface area. Azure CLI 2.0 use a number of smart defaults that make "getting started" scenarios easier for end users.
Core improvements
The core improvements are regarded as "common sense", and little experimentation is needed to move forward in implementing these updates.
Scenario-based Cmdlets - *All- cmdlets should be designed around scenarios, not the Azure REST service.
Shorter Names - Includes the names of cmdlets (for example, New-AzureRmVM => New-AzVm) and the names of parameters (for example, -ResourceGroupName => -Rg). Use aliases for compatibility with "old" cmdlets. Provide backwards compatible parameter sets.
Smart Defaults - Create smart defaults to fill in "required" information. For example:
Resource Group
Location
Dependent resources
Experimental improvements
The experimental improvements present a significant change that the team wants to validate via experimentation.
Simple types - Create scenarios should move away from complex types and config objects. Simplify the configuration down to one or two parameters.
"Smart Create" - All create scenarios implementing "Smart Create" would have no required parameters: all necessary information would be chosen by Azure PowerShell in an opinionated fashion.
Gray Parameters - In many cases, some parameters could be "gray" or semi-optional. If the parameter isn't specified, the user is asked if they want the parameter generated for them. It also makes sense for gray parameters to infer a value based on context with the user's consent. For example, it may make sense to have the gray parameter suggest the most recently used value.
-Auto Switch - The -Auto switch would provide an "opt-in" way for users to default all the things while maintaining the integrity of required parameters in the mainline path.
Feature-specific switches
For example, the "Create web app" scenario might have a -Git or -AddRemote switch that would automatically add an "azure" remote to an existing git repository.
Settable Defaults - Users should be able to set defaults for common parameters like -ResourceGroupName and -Location.
Answer:
Need to know options: Below are allowed as answer
Explanation:
Azure Profile Module
Azure Module
Azure Resource Manager Module etc.