Modules

Quick guide #

A Module is a packaged set of DSC resources that provides the building blocks used to create and compile XOAP Configurations. Modules define which resources are available in the Configuration Wizard and which settings can be enforced on managed nodes.

Upload a new Module #

1. Go to Configuration Management → Modules.
2. Click Upload modules.
3. Upload the module package (supported formats: .zip or .nupkg).
4. Enable Allow overwrite if already exists if you want to replace an existing module/version.
5. Click Next, review/edit details if needed, and complete the upload.

Edit a Module #

1. Click the Action menu (⋮) next to a module and select Details.
2. Review module information such as name, version, description, and release notes, and manage tags if required.
3. Use Download in the details view to download the selected module version.

Delete a Module #

1. Click the Action menu (⋮) next to a module and select Delete.
2. Confirm the deletion.

Additional useful information #

Supported module package formats #

Modules can be uploaded as .zip or .nupkg packages.

Uploading modules for missing resources #

If a required resource is not available in the Configuration Wizard, upload the corresponding module in Configuration Management → Modules.

Module versions #

Multiple versions of the same module can exist in XOAP, allowing configurations to be compiled against specific module versions.

Module dependencies #

If a module has prerequisites (dependencies) on other modules, all required modules must be uploaded for the resources to be available and usable.

Module compilation time #

When you upload a module, allow 10–15 minutes for it to compile in the background before it can be used in Configuration Wizard.

Technical documentation #

A Module is a versioned package of DSC resources that provides the building blocks for XOAP Configurations. Modules determine which resources appear in the Configuration Wizard, which parameters can be configured, and which settings can be enforced on managed nodes.

Technically, a module is a standard PowerShell module that contains one or more DSC resources. Each resource represents a “unit of enforcement” (for example, registry, service, file, or feature) and exposes parameters that describe the desired state. XOAP reads the module metadata to identify:

• Which resources are included in the module
• Which parameters are required vs. optional
• Parameter types, allowed values, and defaults (if defined)

Module versions and compatibility #

Modules are versioned, and the selected module version directly impacts:

• Which resources are available
• Which parameters exist (new versions may add, rename, or remove parameters)
• Resource behavior (bug fixes and changes to enforcement logic)

Because of this, configuration compilation is tied to the module version used at compile time. If you upload a newer module version, you typically re-compile configurations to ensure the generated output aligns with the updated resource definitions.

Dependencies (prerequisites) #

Some modules depend on other modules (for example, helper libraries or shared DSC resources). If a required dependency is missing:

• XOAP may not be able to compile the configuration successfully, and/or
• The affected resources may not be available or usable in the wizard

Best practice is to upload the full dependency chain (all prerequisite modules) before building or recompiling configurations.

What XOAP requires from a module #

For a module to be usable in XOAP Configuration Management, it must be packaged in a supported format and contain valid DSC resources. In practical terms, this means:

• The module can be imported by PowerShell/DSC tooling
• The resources can be discovered (resource schema/metadata is present)
• Any required dependencies are available
• The module version is compatible with the target nodes (Windows PowerShell 5.1 / DSC 1.1)

Operational considerations #

• Breaking changes: New module versions can introduce breaking changes (for example, parameter renames). Treat module updates like software updates—validate in a pilot configuration first.
• Reproducibility: Pin configurations to a known module version for predictable outcomes, and only move to a newer version when validated.
• Troubleshooting: If a resource is not visible in the wizard or compilation fails, the most common causes are missing dependencies, incompatible module structure, or unsupported resource requirements.

In practice, XOAP consumes modules in standard PowerShell packaging formats (most commonly .nupkg). When a module is uploaded to Configuration Management → Modules, its resources become available for selection in the Configuration Wizard (module/version → resource → parameters).

Download a module #

You can download modules for offline review or to reuse the same package in another environment:

• In Configuration Management → Modules, open the module Action menu (⋮) and select Download, or
• Open Details and use Download from the module details view.

Where to find community modules #

Most community DSC modules are published via the PowerShell Gallery. A common workflow is:

1. Locate the module on PowerShell Gallery.
2. Download the raw .nupkg file (Manual Download).
3. Upload the .nupkg into XOAP → Configuration Management → Modules.

Module prerequisites (dependencies) #

If a module has prerequisites (dependencies) on other modules, all required modules must be uploaded. Otherwise, some resources may not be available or usable during configuration creation/compilation.

Creating a custom module #

XOAP supports custom modules the same way it supports community modules—by uploading the resulting package into Configuration Management → Modules.