Document Details

You can also use the PowerShell Gallery as an aid in finding details about modules that are
publicly available. The following example lists the modules that are built into new Automation
Accounts and contain DSC resources.

The configuration requires you to have the **xWebAdministration** module version 1.19.0.0 and the
module **PSDesiredStateConfiguration**.

### Test content in Azure machine configuration

To evaluate whether you can use your content from Azure Automation State Configuration for machine
configuration, follow the step-by-step tutorial in
[How to create custom machine configuration package artifacts][05].

When you reach the step [Author a configuration][06], the configuration script that generates a MOF
file should be one of the scripts you exported from Azure Automation State Configuration. You must
have the required PowerShell modules installed in your environment before you can compile the
configuration to a MOF file and create a machine configuration package.

#### What if a module doesn't work with machine configuration?

Some modules might have compatibility issues with machine configuration. The most common problems
are related to .NET framework vs .NET core. Detailed technical information is available on the page,
[Differences between Windows PowerShell 5.1 and PowerShell 7.x][16].

To resolve compatibility issues, you can run commands in Windows PowerShell from within a
module imported in PowerShell 7, by running `powershell.exe`. You can review a sample module
that uses this technique in the Azure-Policy repository where it's used to audit the state of
[Windows DSC Configuration][17].

The example also illustrates a small proof of concept.

Install-Module -Name Az.Automation

Finally, export each configuration to a local script file using the command
`Export-AzAutomationDscConfiguration`. The resulting filename uses the pattern
`\ConfigurationName.ps1`.

#### Export configurations using the PowerShell pipeline

You can export all your configurations to a local folder on your machine. To automate this process,
pipe the output of each command in the earlier examples to the next command.

The following example exports five configurations. The output pattern is the only indicator of
success.

#### Consider decomposing complex configuration files

Machine configuration can manage more than one configuration per machine. Many configurations
written for Azure Automation State Configuration assumed the limitation of managing a single
configuration per machine. To take advantage of the expanded capabilities offered by machine
configuration, you can divide large configuration files into many smaller configurations where each
handles a specific scenario.

There's no orchestration in machine configuration to control the order of how configurations are
sorted. Keep steps in a configuration together in one package if they're required to happen
sequentially.

### Modules

It isn't possible to export modules from Azure Automation or automatically correlate which
configurations require which modules and versions. You must have the modules in your local
environment to create a new machine configuration package. To create a list of modules you need for
migration, use PowerShell to query Azure Automation for the name and version of modules.

If you're using modules that are custom authored and only exist in your private development
environment, it isn't possible to export them from Azure Automation.

If you're missing a module required for a configuration and in the account, you can't compile the
configuration. Therefore, you can't migrate the configuration.

#### List modules imported in Azure Automation

To retrieve a list of all modules installed in your automation account, use the
`Get-AzAutomationModule` command. The property **IsGlobal** tells you if the module is built into
Azure Automation always, or if it was published to the account.

For example, to create a list of all modules published to any of your accounts.

#### Download modules from PowerShell Gallery or a PowerShellGet repository

If the modules were imported from the PowerShell Gallery, you can pipe the output from
`Find-Module` directly to `Install-Module`. Piping the output across commands provides a solution
to load a developer environment with all modules currently in an Automation Account if they're
available in the PowerShell Gallery.

You can use the same approach to pull modules from a custom NuGet feed. You must register the feed
in your local environment as a [PowerShellGet repository][16].

The `Find-Module` command in this example doesn't suppress errors, meaning any modules not found in
the gallery return an error message.

#### Inspecting configuration scripts for module requirements

After you export configuration scripts from Azure Automation, you can review the contents for
details about which modules are required to compile each configuration to a MOF file. This approach
is only needed if you find configurations in your Automation Accounts that are missing modules. The
configurations would no longer be useful for machines, but they might still be in the account.

Towards the top of each file, look for a line that includes `Import-DscResource`. This command is
only applicable inside a configuration, and it's used to load modules at the time of compilation.

For example, the `WindowsIISServerConfig` configuration in the PowerShell Gallery has the lines in
this example.