Document Details
Automation Dsc Cd Chocolatey
This page contains Windows bias
About This Page
This page is part of the Azure documentation. It contains code examples and configuration instructions for working with Azure services.
Bias Analysis
Detected Bias Types
powershell_heavy
windows_first
missing_linux_example
windows_tools
Summary
The documentation is heavily biased towards Windows environments. All examples, tooling, and workflows are specific to Windows, PowerShell, and Windows-centric package management (Chocolatey, DSC). Linux is only mentioned in passing, and no Linux equivalents or examples are provided. The documentation assumes the user is deploying to Windows VMs and using Windows-specific tools, with no guidance for Linux users.
Recommendations
- Provide equivalent Linux examples using native Linux package managers (e.g., apt, yum) and configuration management tools (e.g., Ansible, Chef, Puppet, or Azure Automation State Configuration for Linux if available).
- Include a section or parallel workflow for setting up continuous deployment for Linux VMs, including scripts and configuration files.
- Mention and demonstrate cross-platform tools and approaches where possible, or explicitly state the Windows-only scope at the beginning.
- If Azure Automation State Configuration for Linux is deprecated or unavailable, provide clear alternatives or migration guidance for Linux users.
- Balance the mention of package managers by giving Linux tools equal prominence and not relegating them to a single sentence.
- Where PowerShell is used, provide Bash or shell script equivalents for Linux scenarios.
Create Pull Request
Scan History
| Date | Scan | Status | Result |
|---|---|---|---|
| 2026-01-14 00:00 | #250 | in_progress |
Biased
|
| 2026-01-13 00:00 | #246 | completed |
Biased
|
| 2026-01-12 00:00 | #243 | cancelled |
Biased
|
| 2026-01-11 00:00 | #240 | completed |
Biased
|
| 2026-01-10 00:00 | #237 | completed |
Biased
|
| 2026-01-09 00:34 | #234 | completed |
Biased
|
| 2026-01-08 00:53 | #231 | completed |
 Clean
|
| 2026-01-06 18:15 | #225 | cancelled |
Clean
|
| 2025-08-17 00:01 | #83 | cancelled |
Clean
|
| 2025-07-13 21:37 | #48 | completed |
Biased
|
| 2025-07-09 13:09 | #3 | cancelled |
Clean
|
| 2025-07-08 04:23 | #2 | cancelled |
Biased
|
Flagged Code Snippets
This step takes a few minutes while the pull server is set up.
You can create your Automation account in any of the following Azure regions:
- East US 2
- South Central US
- US Gov Virginia
- West Europe
- Southeast Asia
- Japan East
- Central India
- Australia Southeast
- Canada Central
- North Europe
## Step 2: Make VM extension tweaks to the Resource Manager template
Details for VM registration (using the PowerShell DSC VM extension) provided in this
[Azure Quickstart Template][12]. This step registers your new VM with the pull server in the list of
State Configuration Nodes. Part of this registration is specifying the node configuration to be
applied to the node. This node configuration doesn't have to exist yet in the pull server, but you
need to choose the name of the node and the name of the configuration. For this example, the node is
`isvbox` and the configuration name is `ISVBoxConfig`. The node configuration name you specify in
`DeploymentTemplate.json` is `ISVBoxConfig.isvbox`.
## Step 3: Add required DSC resources to the pull server
The PowerShell Gallery can install DSC resources into your Azure Automation account. Navigate to the
resource you want and select **Deploy to Azure Automation**.
![PowerShell Gallery example][03]
Another technique recently added to the Azure portal allows you to pull in new modules or update
existing modules. The select the **Browse Gallery** icon to see the list of modules in the gallery,
drill into details, and import into your Automation account. You can use this process to keep your
modules up to date. Also, the import feature checks dependencies with other modules to ensure
nothing gets out of sync.
There's also a manual approach, used only once per resource, unless you want to upgrade it later.
For more information on authoring PowerShell integration modules, see
[Authoring Integration Modules for Azure Automation][11].
>[!NOTE]
> The folder structure of a PowerShell integration module for a Windows computer is a little
> different from the folder structure expected by the Azure Automation.
1. Install [Windows Management Framework v5][10] (not needed for Windows 10).
2. Install the integration module.
3. Copy the module folder from `C:\Program Files\WindowsPowerShell\Modules\MODULE-NAME` to a temporary folder. 4. Delete samples and documentation from the main folder. 5. Zip the main folder, naming the ZIP file with the name of the folder. 6. Put the ZIP file into a reachable HTTP location, such as blob storage in an Azure Storage account. 7. Run the following command.
The following `New-ConfigurationScript.ps1` script was modified to use the Az PowerShell module:
The included example implements these steps for cChoco and xNetworking. ## Step 4: Add the node configuration to the pull server There's nothing special about the first time you import your configuration into the pull server and compile. All later imports or compilations of the same configuration look exactly the same. Each time you update your package and need to push it out to production you do this step after ensuring the configuration file is correct - including the new version of your package. Here's the configuration file `ISVBoxConfig.ps1`: