dsc Archives | XOAP

Why use custom DSC modules?

Mario — Fri, 09 May 2025 11:44:42 +0000

<\/path><\/svg>"},"no_headings_message":"No headings were found on this page.","minimize_box":"yes","minimized_on":"tablet","hierarchical_view":"yes","min_height":{"unit":"px","size":"","sizes":[]},"min_height_tablet":{"unit":"px","size":"","sizes":[]},"min_height_mobile":{"unit":"px","size":"","sizes":[]}}" data-widget_type="table-of-contents.default">

If you’re working in IT or just getting started with automation using PowerShell, you’ve probably come across Desired State Configuration (DSC). It’s a tool that helps you set up your systems exactly how you want them and then keeps them that way.

With DSC, you can tell a server how it should be configured. Things like which programs should be installed, what services should be running, or how security settings should be applied. Microsoft gives you a lot of built-in resources to do this, but sometimes they don’t cover everything you need.

That’s where custom DSC modules come in. Let’s walk through what they are, why they matter, and how they can help make your life easier when managing systems.

What is a DSC module, in simple terms

A DSC (Desired State Configuration) module is like a set of instructions grouped together to manage a specific part of your system, for example, making sure a Windows service is always running.

A custom module means you (or your team) created your own set of instructions. Maybe you need to manage a company-specific app, apply a setting that Microsoft’s resources don’t cover, or make something work in a very specific way. Instead of working around those limitations every time, you build a custom module once and use it whenever you need it.

Solving real problems when built-in resources fall short

Microsoft’s built-in DSC resources are great for common tasks, like turning on Windows features or setting firewall rules. But most IT environments have unique needs.

Maybe your company has in-house software that needs special setup steps. Or maybe your security team requires settings that aren’t included in the default resources. With custom modules, you can write exactly what you need, so your configuration works the way your environment demands.

Keeping your configurations clean and organized

As your configuration scripts grow, they can get long and hard to manage, especially if you’re copying the same code over and over across different files.

With custom DSC modules, you can move that repeated logic into its own package. This keeps your main configuration scripts shorter and cleaner. It also makes updates easier, since you only need to change the logic in one place, not in ten different files.

Handling different environments and setups

Not all systems are the same. A web server in production might need one setup, while a test server or a server in a different country might need something slightly different.

Custom modules make that easier. You can build logic into the module to decide how it should behave based on things like location, server role, or environment. That way, you don’t have to create completely different configurations for every scenario.

Helping your team work better together

When teams manage systems manually or use different scripts, things can get messy fast. One person might do something slightly different from another, which can lead to confusion or broken systems.

Using shared custom modules helps everyone follow the same process. Teams can use the same building blocks, so configurations are more consistent and easier to understand. You can also store these modules in a version control system like Git, which keeps track of changes and helps teams collaborate.

Fitting into DevOps and automated workflows

If you’re using DevOps tools or working with CI/CD (Continuous Integration/Continuous Deployment), automation is crucial. Custom DSC modules are great for this because they work well in pipelines.

You can include them in your deployment process to make sure systems are set up the right way every time. You can also test them before rolling them out, which helps catch mistakes early. This kind of repeatable automation is a big step toward treating your infrastructure like code.

Making it easier to find and fix issues

Troubleshooting big configuration scripts can be frustrating. If something breaks, it’s hard to figure out where the problem is.

With custom modules, it’s easier to narrow things down. You can add custom logging to show what’s happening inside the module. If something goes wrong, you’ll have a better idea of what failed and why, without digging through a huge script line by line.

Growing with your infrastructure over time

When you’re just managing a few machines, you might not feel the need for custom modules. But as your environment grows, things can quickly become unmanageable.

Custom DSC modules help you scale more easily. You’re building your setup in a way that can grow with your team, your servers, and your company. Instead of starting from scratch every time, you’re reusing tested, reliable tools you’ve already built.

Getting started with your first custom module

If you’re new to this, don’t worry, you don’t have to build something complicated right away. Start with a small task, like creating a module to make sure a file exists or a setting is applied. You can use PowerShell tools like New-DscResource to help you get started.

Keep your code simple and readable. As you get more comfortable, you can add more features, use parameters, and handle more advanced logic.

How to create a PowerShell DSC module:

This video may not load due to your cookie preferences. Adjust your cookie settings or watch it directly on YouTube.

Why custom modules are worth it

Custom DSC modules help you go beyond the basics. They let you solve real-world problems, make your code cleaner, and manage systems more reliably. Whether you’re working alone or with a team, they make your setup more consistent, more scalable, and easier to troubleshoot.

For beginners, they might seem like extra work at first but they actually save you time in the long run.

You can take your custom DSC modules even further by integrating them with XOAP, which helps you manage, version, and deploy your configurations at scale with ease. XOAP makes it simple to organize and apply your DSC logic across environments through a user-friendly platform built for automation.

You may also be interested in:
→ Tutorial: How to troubleshoot DSC compliance?
→ Convert Group Policy into DSC
→ A modular approach to dynamic DSC configurations
→ Secure your Windows environment with XOAP Windows LAPS DSC

Apply DSC logic across environments

The post Why use custom DSC modules? appeared first on XOAP.

Tutorial: How to troubleshoot DSC compliance?

Ante — Mon, 02 Dec 2024 15:29:51 +0000

Troubleshooting DSC compliance can feel like a real challenge, especially when things don’t seem to be working the way they should. But don’t worry—by keeping things simple and following a few key steps, you can get things back on track.

It’s all about simplifying your configurations, automating testing, improving your logging, doing regular audits, and maintaining documentation. With a methodical approach, many of the common compliance issues can be tackled and resolved. In this blog, we’ll show you how to troubleshoot DSC compliance easily.

Why troubleshooting DSC compliance is so challenging

Troubleshooting DSC compliance can be complex due to several reasons:

Extensive environments

The complexity of DSC configuration files is a significant challenge, particularly in extensive environments with numerous nodes and a myriad of configurations. As the system grows and becomes more multifaceted, identifying the root cause of issues becomes increasingly difficult. The interdependencies between different configurations can obscure the source of the problem, complicating efforts to maintain compliance.

Another challenge arises from the potential for systems to slip into an inconsistent state. This can occur due to configuration drift or unsuccessful application of configurations. When the actual state of the system diverges from the desired state, discrepancies emerge that can reduce effectiveness and reliability.

Error diagnostics and network issues

Error diagnostics add another layer of difficulty to troubleshooting DSC compliance. The error messages provided by DSC can often be cryptic or insufficiently detailed, making it challenging to determine the precise cause of an issue. Without clear diagnostics, addressing and resolving the problem becomes significantly more challenging.

Network and connectivity issues also play a critical role in compliance challenges. Since DSC relies on network connectivity to access configurations from a central repository, problems such as network latency or disconnections can hinder proper application of configurations. These issues can cause systems to fall out of compliance if they cannot access the necessary configuration data.

Resource conflicts and host-specific issues

Resource conflicts present another challenge. DSC configurations may include resources that conflict with each other—for example, two resources might attempt to set the same property of a system setting in different ways. This can lead to unpredictable system behavior and complicate compliance efforts.

Host-specific issues further complicate the troubleshooting process. Variations in target node environments, such as differing operating system versions or installed software, can result in different outcomes from identical configurations. This specificity requires extra attention to ensure consistency across all nodes.

Versioning and logging

Changes in versioning and updates, such as those involving PowerShell or DSC module versions, can also introduce challenges. Such changes may bring compatibility issues or bugs that disrupt compliance. Staying up-to-date while maintaining stability can become a balancing act that requires careful management.

Finally, the challenge of insufficient logging complicates deeper analysis. Although DSC provides some logging capabilities, diagnosing complex issues often requires more detailed logs. Without additional configuration to enhance logging detail, these issues can be difficult to detect and resolve.

How to troubleshoot DSC compliance

Before we show you how to troubleshoot DSC compliance, create your own XOAP workspace. XOAP’s module, config.XO (Configuration Management), helps you create, organize, and apply your DSC configurations. Using config.XO, you can easily create DSC configurations with GUI and make versions of the created configurations.

This tutorial is also available as a YouTube video:

This video may not load due to your cookie preferences. Adjust your cookie settings or watch it directly on YouTube.

Step 1

To use the Configuration Wizard, click on Configuration Management, and then Configuration. Here, you can create a new configuration or you can edit an existing one.

Step 2

Here you can configure your DSC configuration and create a version for every change that you did.

Step 3

Using Configuration Management Group, you can apply different versions to your Nodes. Just apply the desired version to the group and assign nodes:

Step 4

Using these XOAP options enables you to simplify the creation of DSC, create versions, and control which nodes should get specific versions of the configuration.

If you check the Groups table, you can see how many nodes are compliant in your group:

More information about the specific state of the node can be found under Configuration Management nodes.

There are 3 states of node status:

Compliant: Node is compliant with all DSC resources applied to it
Non-compliant: At least one DSC resource is not applied to the node
Running: DSC configuration is currently applying

Step 5

Using the Last activity information, you can check that the communication between XOAP and your node is working.

Clicking on the Compliant state, you can see the compilation history.

Step 6

Here you can see all compilation status changes in the last 14 days. With the status, you can see which configuration and which version is applied at a specific time.

By clicking on Compliant status, you’ll be able to see the status of applied DSC resources:

In case of non-compliant status, you can also check logs:

Another way to check the status is to open the node details:

Under Powershell DSC you can check for all compliance issues:

In case of communication issues between XOAP and your servers, make sure that you allow communication with API.XOAP.IO by port 443 and that you whitelisted our IP addresses on your firewall. Information about IPs and API can be found on the dashboard:

Why use XOAP to troubleshoot DSC compliance

XOAP’s config.XO module provides a user-friendly way for creating, organizing, and applying DSC configurations through a graphical interface. This intuitive approach allows users to easily generate configurations and manage different versions, addressing the complexities and potential errors stemming from manual scripting. By using the Configuration Wizard, users are empowered to create and modify configurations, so changes are well-documented and easily reversible.

The ability to apply different configuration versions to specific nodes or groups of nodes offers significant flexibility. This helps manage resource conflicts and host-specific issues by ensuring that the right configurations are applied to the appropriate nodes. By organizing nodes into groups and assigning configurations accordingly, XOAP simplifies the management of large environments and improves consistency across deployments.

XOAP also provides monitoring capabilities, allowing administrators to track compliance status among nodes. Moreover, the platform’s logging and compilation history features offer valuable insights into past activities and changes, helping users diagnose and resolve issues promptly.

Communication between XOAP and the nodes is crucial for maintaining compliance, and the Last Activity information guarantees this connectivity remains intact. Also, detailed logs and node details offer deep insights into specific compliance issues, enabling administrators to take targeted actions to rectify problems and secure optimal system performance.

Stuck trying to troubleshoot DSC compliance? Just use XOAP
Need more help? Contact us here

Troubleshoot DSC compliance now

The post Tutorial: How to troubleshoot DSC compliance? appeared first on XOAP.

Convert Group Policy into DSC

Sinisa — Fri, 15 Nov 2024 11:06:58 +0000

As organizations move towards more modern IT infrastructure management approaches, there’s a growing need to transition from traditional Group Policy Objects (GPOs) to more scalable and flexible solutions like PowerShell Desired State Configuration (DSC). DSC provides a declarative, infrastructure as code approach to managing configuration, which is essential for cloud-based environments, hybrid models, and DevOps-driven operations.

One of the most efficient ways to convert and manage Group Policy settings in DSC is by using the BaselineManagement module. This module simplifies the process of migrating Group Policy into DSC, enabling administrators to more easily enforce configuration compliance and extend policies to environments outside of Active Directory.

In this blog post, we’ll walk through the process of converting Group Policy into DSC using the BaselineManagement module, discussing the benefits of the transition and providing a step-by-step guide.

Why migrate from Group Policy to DSC?

Group Policy has been a standard for Windows management, but as infrastructure scales and becomes more distributed, relying on AD-based GPOs can become a limitation. Here’s why converting to DSC makes sense:

Cloud and hybrid support: DSC is more cloud-friendly and supports managing configurations across on-premises, hybrid, and cloud environments like Azure and AWS.
Automation and infrastructure as code (IaC): With DSC, you can store configurations as code, integrate them into CI/CD pipelines, and version them for better change management.
Cross-platform capabilities: DSC provides support for Linux and macOS environments (full support with DSC v3 soon), whereas Group Policy is strictly limited to Windows.
Enforcement and monitoring: DSC’s idempotent nature ensures that configurations are regularly checked and reapplied if changes are detected, making it more robust than Group Policy for ensuring compliance.

What is the BaselineManagement Module?

The BaselineManagement module is a PowerShell module designed to help manage and apply security baselines in Windows environments. Furthermore, it’s particularly useful for converting Group Policy settings into DSC configurations by allowing administrators to export Group Policy Objects (GPOs) and convert them into PowerShell DSC scripts, simplifying the migration process.

Prerequisites

First, make sure you have the following:

PowerShell 5.1 or later: DSC is built into PowerShell, so you’ll need an updated version installed on the system.
BaselineManagement Module: Install this module from the PowerShell Gallery using the following command:

				
					
Install-Module -Name BaselineManagement -Repository PSGallery -Force

Administrator Access: You’ll need administrative rights to export Group Policies and apply DSC configurations.

Step-by-step guide: Convert Group Policy to DSC

Step 1: Export Group Policy settings

Start by identifying the Group Policies you want to convert to DSC. Use the BaselineManagement module to export your existing Group Policy settings into a baseline that DSC can work with.

Open PowerShell as an Administrator
Export your GPO to a folder for review:

				
					Backup-Gpo -Name 'Your-GPO-Name' -Path C:\GPOExport -Comment "DSC backup"

This command exports the selected GPO’s settings to the specified path. You can export multiple GPOs or just a single one, depending on your migration strategy.

Step 2: Review the exported Baseline

Once the Group Policy settings have been exported, review the content in the C:\GPOExport folder. The exported baseline will contain files representing the policies that were applied through GPO. This is useful for validation purposes before converting the settings to DSC.

Step 3: Convert Group Policy Baseline to DSC configuration

Next, use the BaselineManagement module to convert the exported baseline into a DSC configuration file. This automates much of the heavy lifting involved in translating Group Policy settings into DSC.

Run the following command to generate the DSC configuration:

				
					ConvertFrom-GPO -Path 'C:\GPOExport' -OutputPath 'C:\DSCConfigurations'

This command converts the exported GPO baseline into a DSC configuration script that you can use for managing the same settings through PowerShell DSC. The generated DSC configuration file will be saved in the C:\DSCConfigurations directory.

Step 4: Review and customize the DSC configuration

Now that you have a DSC configuration generated from the GPO, it’s time to review and, if necessary, customize it. The generated configuration will map the Group Policy settings to appropriate DSC resources.

Here’s an example of what a DSC configuration might look like after the conversion:

				
					
Configuration GPOConvertedConfig {
    Import-DscResource -ModuleName PSDscResources
    
    Node 'localhost' {
        # Example: Account Lockout Policy
        AccountPolicy {
            LockoutThreshold          = 5
            LockoutDuration           = 30
            LockoutObservationWindow  = 30
        }
# Example: Password Policy
        UserRightsAssignment SetPasswordPolicy {
            Ensure              = 'Present'
            MinPasswordLength   = 8
            MaxPasswordAge      = 90
            PasswordComplexity  = $true
        }
    }
}

GPOConvertedConfig -OutputPath ‘C:\DSCConfigurations’

You can further modify this configuration to suit your environment, add additional nodes, or adjust settings based on specific requirements.

Step 5: Apply the DSC configuration

After reviewing the configuration, you can apply it to your environment. Use the Start-DscConfiguration cmdlet to apply the DSC configuration to your target nodes:

				
					
Start-DscConfiguration -Path 'C:\DSCConfigurations' -Wait -Verbose

This will apply the configurations to the local machine or a set of target nodes if you are managing a larger environment.

Step 6: Monitor & maintain the configuration

One of the benefits of using DSC is its ability to continually monitor and enforce the configuration. You can use the Get-DscConfiguration and Test-DscConfiguration cmdlets to check the current state and ensure your settings are correctly applied:

				
					

# Check the current configuration
Get-DscConfiguration

# Test if the system is in the desired state
Test-DscConfiguration

If the system drifts from the desired state, DSC will automatically correct it, so your policies are always enforced.

Additional considerations

Versioning and documentation

Because DSC is written as code, you should treat it like any other source code. Use version control systems like Git to track changes and ensure that your configuration is always versioned and documented. This also helps with collaboration across teams and environments.

Transition planning

Converting from Group Policy to DSC may require a phased approach. You might start with non-critical systems or a small set of policies and gradually expand to the entire environment. This ensures minimal disruption and allows you to fine-tune the process.

Continuous monitoring

Additionally, DSC provides built-in mechanisms for continuous monitoring of your system’s configuration state. Regularly check the state of your configurations and logs to ensure that systems remain compliant with your desired policies.

Integration with XOAP's config.XO

By converting Group Policies to DSC, you’re setting yourself up for smooth integration with XOAP’s Configuration Management module (config.XO).

With XOAP, you can centrally manage and automate your DSC scripts across both cloud and on-prem environments, keeping all your systems—whether on Azure, AWS, GCP or on-prem—aligned with your organization’s standards.

This way, you get better visibility, control, and peace of mind knowing your infrastructure is always configured just the way you want it, without the manual burden.

Shift to modern configuration management

It’s clear that implementing DSC can greatly improve control over your configuration management process, making it easier to automate, monitor, and enforce desired states on your systems.

Using the Baseline Management module and its conversion commands, you can quickly transition from GPO-based management to a modern DSC approach.

If you’re curious to see how you can make your configuration management even better, explore our wizard-assisted DSC module (for free!). It’s an easy-to-use solution for continuous configuration delivery – development and integration.

Get in touch with us to find out more or peek at our documentation to get started with config.XO.

Until next time, happy converting!

Try our wizard-assisted DSC module

Image by Freepik

The post Convert Group Policy into DSC appeared first on XOAP.

Create a PowerShell DSC module | Online training

Dora — Tue, 01 Oct 2024 15:17:51 +0000

Create a PowerShell DSC module | Online training

October 16th | 3:30pm

Learn how to automate the entire delivery chain. Join XOAP training events!

After tackling security and compliance issues in our first online training event, we are eager to show you more about automation, the easy way.

In the upcoming training session with XOAP’s engineers, we will cover the creation of PowerShell DSC modules.

Haven’t worked with PowerShell or Desired State Configuration before? Don’t worry, we’ll take you through it step by step.

This live event has ended.

Upcoming & past events

All about XOAP Connector

Ep. 05 with Sinisa Sokolic (XOAP) | Watch now

The AWS European Sovereign Cloud

Ep. 06 with Tobias Tomandl (Ingram Micro) | Watch now

BLINK 2025 | How XOAP simplifies hybrid IT automation

November 28, 2025 | Bielefeld, DE | Hosted by blucue

Automation as an investment, not an expense

Ep. 04 with Luis Amaro (Onventis) | Watch now

Automated IT Infrastructure with XOAP | bluecue online impuls

June 25, 2025 | Online | Hosted by bluecue

What’s changed in IT automation and what has… not

Ep. 03 with Mathias Kowalkowski (SVA) | Watch now

The post Create a PowerShell DSC module | Online training appeared first on XOAP.

A modular approach to dynamic DSC configurations

Ante — Fri, 21 Jun 2024 13:20:09 +0000

PowerShell DSC is a management platform in PowerShell that enables you to manage your IT and development infrastructure as configuration as code. As DSC uses a declarative syntax and PowerShell as a base, it quickly became one of the most popular configuration as code platforms.

With the increase in community-built modules that enhance functionality, some limitations and challenges were introduced. The biggest are probably the complexity of large configurations and the versioning of DSC modules and configurations.

To deploy DSC configurations and maintain them on hundreds of systems if you are an enterprise company, or to reuse the same baseline configurations for different customers if you are an MSP, you should develop some baseline processes.

How can XOAP help you?

By combining different features, you can solve these challenges through three simple steps:

Create a baseline DSC module using our DSC module template with all the settings you want to deploy as a baseline.
Create configurations by combining baseline DSC resources and specific configurations for different departments or customers.
Deploy configurations and install applications by combining configuration groups and application roles, and register your system (node) to the specific group.

Before we explain how to configure everything with XOAP, please check the following schema that displays the logic and relationships between the baseline module and configurations:

Configurations are declarative PowerShell scripts which define and configure resource instances.

Resources are the “make it so” part of DSC. They contain the code that puts and keeps the target of a configuration in the specified state.

In real-world situations, configurations can become long and complex, calling many different resources and setting a vast number of properties. To help address this complexity, you can use a Windows PowerShell Desired State Configuration (DSC) configuration as a resource for other configurations, so called DSC modules.

Modules combine multiple resources that can be dynamically integrated in different configurations.

The baseline module in the diagram defines resources that define specific settings for all customers or departments. These resources can be reused and separately integrated into different DSC configurations for specific use cases.

Using modules to create sets of specific resources for certain use cases makes those modules reusable and dynamically assignable to different DSC configurations that reference the module and the specific resource inside this module.

With this approach, we have versioning on a module level. How do we get this up and running with XOAP? Let’s go!

Step 1: Create a baseline DSC module

To create the baseline module, you can use our template available on GitHub.

Download the content, navigate to the download folder location, modify the following command with your values, and run:

.\New-CompositeResource.ps1 -Module ‘XOAPModuleTemplateDSC’ -Version ‘0.0.1’ -Resource ‘DSCResource’

This will create a folder structure like this:

XOAPModuleTemplate
|
|_0.0.1
|
|_DSCResources
| |_DSCResoursce
|
|_Examples

In the DSCResource you can find two files: DSCResoursce.psd1 and DSCResoursce.schema.psm1.

Modify DSCResoursce.schema.psm1. file and insert your DSC configuration code into it.

Example:

				
					Configuration 'XOAPRemoteDesktopServicesDSC'
{
	Import-DSCResource -Module 'XOAPRemoteDesktopServicesDSC' -Name 'XOAP_RDSQuickStartConfiguration' -ModuleVersion '0.0.1'

    param
        (
            [string[]]$ConnectionBrokerServerName = 'connectionbroker.domain.com'
            [string[]]$SessionHostServerName = 'sessionhost.domain.com'
            [string[]]$AllowedUserGroup = 'domain\group'
        )

	        Node'XOAPRemoteDesktopServicesDSC'
	        {
            XOAP_RDSQuickStartConfiguration 'Example'
            {
                ConnectionBrokerServerName = $ConnectionBrokerServerName
                SessionHostServerName = $$SessionHostServerName
                AllowedUserGroup = $$AllowedUserGroup
            }
	         }
	        }
XOAPRemoteDesktopServicesDSC -OutputPath 'C:\XOAPRemoteDesktopServicesDSC'

The Import-DSCResource command enables you to load specific settings from other modules by defining the module name, the resource name and the version of the module.

More information on how to write DSC composite resources can be found here.

Once created, you need to upload the module to your XOAP workspace. More information on how to do this can be found on our documentation page.

Step 2: Create configurations

Next, create configurations combining your baseline DSC resources and specific configurations for different departments or customers.

To create configurations, navigate to the Configuration Management module and click +.

Create a configuration for your department or customer using resources from the uploaded module and combine it with other modules.

In the Configuration Wizard, click “Add Resources”, select the module, version and resource. In “Create New Resource”, fill in the required data:

When you have filled in all the data, click Save to add the resource to the configuration.

To create a configuration, click Save and enter the version information. In the “Save Configuration” window, click Save when you’re ready.

More information on how to use the configuration wizard can be found in our docs.

Step 3: Assign configurations

To assign a configuration to multiple systems (nodes) use “Groups”. To create a new group, navigate to Configuration Management > Groups and click +.

In the “Add Group” window, enter the name of the group and select a “Configuration”, a specific “Version”, and a “Policy”. If you want to install applications on the systems, you can also select an “Application Role”.

By running the registration script or registration command on the nodes, you can add them to the group. The configuration will then be applied.

For more info visit this documentation page.

Keeping configurations up to date

How to keep configurations up to date, or better yet, how to maintain them?

If you need to update customer-related configurations, navigate to “Configurations”, locate the specific configuration, and click on the action menu to Edit it.

Every saved change to a configuration will create a new version. This version can be assigned to the groups you created earlier. As soon as you update the configuration version within the group, the assigned nodes will update their configurations based on the update interval specified in the assigned policy.

This enables you to assign specific versions of a configuration to a group and gives you control over which settings are applied. By creating different groups for test, acceptance and production you can create a process of delivering changes.

If you have updated your baseline module and uploaded a new version, navigate to the configuration and from the action menu, select Re-Compile.

This will open a “Re-Compile” window, where you can select the new version of your module.

Re-compiling will automatically save a new version of the configuration, integrating all updated resources from the module. Follow the steps described above to update the configuration version within your groups.

Improve your process today

XOAP enables you to create modular and dynamic configurations easily, combining resources from a baseline module with customer- or department-specific modules.

This minimizes human errors and enables a clear configuration management process with defined test procedures, as well as easy update and rollback capabilities.

If you want to learn more or need additional help getting started with specific use cases, you can book a demo.

Deliver dynamic DSC configurations with XOAP

The post A modular approach to dynamic DSC configurations appeared first on XOAP.

Secure your Windows environment with XOAP Windows LAPS DSC

Perica — Mon, 17 Jun 2024 12:55:30 +0000

In today’s digital landscape, maintaining the security of your Windows infrastructure is paramount. One of the critical aspects of this security is managing local administrator passwords, which, if mishandled, can become a significant vulnerability.

Say hello to XOAP Windows LAPS DSC a robust solution designed to enhance your security posture by automating the management of local administrator passwords across your Windows environment.

What is XOAP Windows LAPS DSC?

XOAP Windows LAPS DSC is a powerful Desired State Configuration (DSC) module that leverages the capabilities of the Local Administrator Password Solution (LAPS) to manage and securely store local administrator passwords on domain-joined machines. By integrating with the DSC framework, XOAP Windows LAPS DSC allows for the automated deployment and configuration of LAPS policies, ensuring that local administrator passwords are unique, randomly generated and periodically updated.

Key features

1. Automated password management: XOAP Windows LAPS DSC automates the generation, storage, and updating of local administrator passwords, significantly reducing the risk of password-related breaches.

2. Centralized control: Manage and monitor password policies centrally using DSC, ensuring consistent security practices across your organization.

3. Seamless integration: Easily integrate with existing Active Directory infrastructures, making deployment straightforward and hassle-free.

4. Compliance and auditing: Meet compliance requirements with detailed auditing capabilities, ensuring password policies are enforced and tracked.

Why use XOAP Windows LAPS DSC?

Enhanced security

Local administrator accounts are often targeted by attackers looking to gain privileged access. By using XOAP Windows LAPS DSC, you make sure that each local administrator password is unique and regularly updated, drastically reducing the attack surface.

Operational efficiency

Manual password management is not only time-consuming but also prone to errors. Automating this process with XOAP Windows LAPS DSC frees up IT resources and ensures that password policies are consistently applied across all machines.

Compliance and auditing

Regulatory frameworks often require strict password management practices. XOAP Windows LAPS DSC helps organizations meet these requirements by providing detailed logs and reports on password policy enforcement and changes.

Simplified management

With DSC, administrators can define the desired state of their infrastructure using configuration files. XOAP Windows LAPS DSC extends this capability to local administrator passwords, allowing for easy deployment and management through familiar DSC tools.

Getting started with XOAP Windows LAPS DSC

Prerequisites

Windows PowerShell: Make sure you have Windows PowerShell 5.1 or later installed.

DSC: Familiarity with the Desired State Configuration is beneficial.

Active Directory:

Active Directory environment to manage domain-joined machines
- - - Update AD schema
    - Grant permissions
    - Check Domain Functional Level (DFL) prerequisites
    - Get started with Windows LAPS and Windows Server Active Directory

Entra ID (Azure AD ) environment to manage -joined machines
- - - Enable Local Administrator Password Solution (LAPS) setting
    - Windows Local Administrator Password Solution in Microsoft Entra ID

Installation

To install the XOAP Windows LAPS DSC module, you can navigate to our Github repo. As with all other DSC modules that we provide, this one is free to use in and outside of the XOAP universe.

Download the files in the releases section and extract the contents into one of your locations that are used for searching modules. The list of locations can be shown by checking the value of the “$env:PSModulePath” variable.

An example of the standard path is: $Env:programfiles/WindowsPowerShell/Modules.

When you’re extracting the files, please use the correct folder structure:

Configuration

For easier understanding how to use XOAPWinowsLAPSDSC module, below is documentation of used resources:

⭢ AzureADWindowsLAPSSettings

				
					 AzureADWindowsLAPSSettings [String] #ResourceName
	    {
	        [DependsOn = [String[]]]
	        [PsDscRunAsCredential = [PSCredential]]
	        [AdministratorAccountName = [String]]
	        [PasswordAgeDays = [Int32]]
	        [PasswordLength = [Int32]]
	        [PasswordComplexity = [Int32]]
	        [PostAuthenticationResetDelay = [Int32]]
	        [PostAuthenticationActions = [Int32]]
	    }

⭢ LocalADWindowsLAPSSettings

				
					LocalADWindowsLAPSSettings [String] #ResourceName
    {   
        [DependsOn = [String[]]]
        [PsDscRunAsCredential = [PSCredential]]
        [AdministratorAccountName = [String]]
        [PasswordAgeDays = [Int32]]
        [PasswordLength = [Int32]]
        [PasswordComplexity = [Int32]]
        [PasswordExpirationProtectionEnabled = [Boolean]]
        [ADPasswordEncryptionEnabled = [Boolean]]
        [ADPasswordEncryptionPrincipal = [String]]
        [ADEncryptedPasswordHistorySize = [Int32]]
        [ADBackupDSRMPassword = [Boolean]]
        [PostAuthenticationResetDelay = [Int32]]
        [PostAuthenticationActions = [Int32]]
    }

⭢ WindowsLAPSEmulationMode

				
					 WindowsLAPSEmulationMode [String] #ResourceName
 {
	[DependsOn = [String[]]]
	[PsDscRunAsCredential = [PSCredential]]
	[AdministratorAccountName = [String]]
	[PasswordAgeDays = [Int32]]
	[PasswordLength = [Int32]]
	[PasswordComplexity = [Int32]]
	[PasswordExpirationProtectionEnabled = [Boolean]]
	[AdministratorPasswordEnabled = [Boolean]]
 }

Example

This is an example of a configuration that uses AzureADWindowsLAPSSettings:

				
						configuration 'TestConfigAzureAD_
	{
	    Import-DscResource -ModuleName 'XOAPWindowsLAPSDSC' -ModuleVersion '0.0.2'
	    
	    AzureADWindowsLAPSSettings 'TEST'
	    {
	        AdministratorAccountName = 'TestAdmin'
	        PasswordAgeDays = '14'
	        PasswordLength = '16'
	        PasswordComplexity = '4'
	        PostAuthenticationResetDelay = '2'
	        PostAuthenticationActions = '1'
	    }
	}
	TestConfigAzureAD

Instead of writing this configuration in a code editor locally, you can also use XOAP. Using our DSC configuration wizard, you can create a LAPS configuration by using our simple-to-use frontend, create different versions of the configuration every time you save a change and prepare everything to deploy LAPS to multiple customers and groups.

To create a new LAPS config you need to follow a few steps:

1. Navigate to the Configuration Management area, go to Configurations and click the + button to create a new configuration.

2. Define general settings like Name, Description and Tags and click “Add Resources”.

3. Select the “XOAPWindowsLAPSDSC” module, Version and Resource and configure the settings.

4. Once when all resources are configured, you can save the configuration and use it in Configuration Management groups to apply the settings to your nodes.

The good thing is, you don’t need to think about DSC syntax when you use XOAP to deploy LAPS configurations. The configuration wizard will guide you and it will allow you to input only valid types for parameters. Also, versioning of configurations allows you to easily change and deploy possible future changes of your LAPS configurations.

If you need more information about the Configuration Wizard, or how to apply configurations to your environments, please check our documentation.

Your next step

In a time where cybersecurity threats are ever-evolving, taking proactive steps to secure your Windows environment is crucial. XOAP Windows LAPS DSC offers a comprehensive solution for automating local administrator password management, enhancing security and ensuring compliance.

By integrating this module into your infrastructure, you can streamline password management processes, reduce risks and focus on other critical aspects of your IT operations.

Explore more about XOAP Windows LAPS DSC on its GitHub repository and take the first step towards a more secure Windows environment!

Deploy LAPS to multiple accounts or customers

The post Secure your Windows environment with XOAP Windows LAPS DSC appeared first on XOAP.

Offline Domain Join using XOAP and Azure Blob storage

Perica — Thu, 29 Feb 2024 12:27:02 +0000

Our module allows you to Domain Join a device that doesn’t have access to the Domain Controller (through the company network or via VPN). It’s an alternative to using Azure Hybrid Join.

While Azure Hybrid Join adds a device to Azure AD (Entra) and local AD, this option allows joining a device to local AD only. Meanwhile, Hybrid Join is limited regarding naming convention and only allows the defining of the prefix.

With this solution, it’s possible to define a prefix and to use a serial number of computers for the computer name.

Who is this for?

You can benefit from using this module whether you’re a XOAP user or not. Here’s how:

a) If you’re a XOAP user, simply set up Windows clients for use of Offline Domain Join via Azure Blob Storage using this module and XOAP console.

b) If you’re not a XOAP user, use this module in your own DSC environment, or use PowerShell scripts inside this module to create their own automation alternative for Offline Domain Join.

Want to experience everything XOAP has to offer? Create your free account here!

What does this module do?

To explain further, this module will rename the computer using the serial number and defined prefix. Afterwards, it’ll make an Offline Domain Join of the device via Azure Blob storage; if wanted.

The computer creates a request and posts it on a defined location on Azure Blob. Then, the Domain Controller will take that request and post a response on Azure Blob. This response file is then read by a computer – and the computer makes Offline Domain Join. Furthermore, the certificate will be imported from Azure Blob.

What do I need to know before I start?

To understand how to use it, knowledge of PowerShell, Active Directory and Azure Storage is needed along with these 3 components:

Server-side: modify Domain Controller to allow for Offline Domain Join
Azure Blob Storage: storage to host files needed for Offline Domain Join
XOAPOfflineDomainJoinViaBlobDSC: to set up Windows client to create request and fetch the answer for Offline Domain Join

List of prerequisites:

AzureAZ PowerShell Module (if not installed ‘Az.Accounts’ and ‘Az.Storage’ submodules are going to be installed while running this DSC module);
ComputerManagementDsc in version 8.5.0;
Azure Blob storage;
Local Active Directory;
PowerShell script that reads the request from Azure Blob Storage and sets response file and machine certificate to Azure Blob storage (example below).

				
					$WarningPreference = "SilentlyContinue" 
$Domain = "test.local.com" 
$OU = "OU=Notebooks,OU=Koeln,DC=test,DC=local,DC=com" 
 
$Tenant_ID = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" 
$Subscription_ID = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" 
$ResUsername = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" 
$SAccountname = 'xoapdeployments' 
$ContainerName = "adjoin" 
 
$FExt = ".blb" 
$BlobFolder ="adblob" 
$RequestFolder = "request" 
$JoinName ="" 
 
Set-Location C:\Scripts 
 
#SecPass.exe generetes password for Azure access 
$SecPassStr = cmd /c .\SecPass.exe $args 2`>`&1    
$cred = New-Object System.Management.Automation.Pscredential($ResUsername, (ConvertTo-SecureString -String $SecPassStr)) 
 
$ARMA = Add-AzureRmAccount -ServicePrincipal -Credential $cred -TenantId $Tenant_ID -Subscription $Subscription_ID 
$ARMA 
 
$storageContainer = Get-AzureRmStorageAccount | where {$_.StorageAccountName -eq $SAccountname} | Get-AzureStorageContainer 
 
$ComputerFiles = $storageContainer | Get-AzureStorageBlob | where {$_.Name.Contains($RequestFolder) -and !($_.Name.Contains("flag.flg"))}  | Select-Object "Name" ,"LastModified" 
 
# $ComputerFiles 
 
if($ComputerFiles) { 
    foreach($Computerfile in $ComputerFiles) { 
        $JoinName = $ComputerFile.Name.Replace("/","\") 
        # $JoinName 
        $storageContainer | Remove-AzureStorageBlob -Container $ContainerName -Blob ($JoinName) -Force 
        $JoinName = $JoinName.SubString(8) 
        $ADblobfile = $Computername + ".blob" -f $computer 
        $BlobName = ".\" + $JoinName + $FExt 
        # $BlobName 
        $run = "djoin.exe /provision /domain {0} /MachineOU {1} /machine {2} /savefile {3} /reuse /rootcacerts" -f $Domain, $OU, $JoinName, $BlobName 
        # $run 
        Invoke-Expression $run 
        $StorageBlob = $BlobFolder + "\" + $JoinName + $FExt 
        # $Storage 
        $storageContainer | Set-AzureStorageBlobContent –File $BlobName -Blob $StorageBlob -Properties @{"ContentType" = "text/plain"} 
        $storageContainer | Remove-AzureStorageBlob -Blob ($RequestFolder + "\" + $JoinName) -Force 
        Remove-Item -Path $BlobName 
    } 
} 
Remove-AzureRmAccount -Username $ResUsername

Available resources and syntax

				
					OfflineDomainJoinViaBlob [String] #ResourceName 
{ 
    [DependsOn = [String[]]] 
    [PsDscRunAsCredential = [PSCredential]] 
    Tenant_ID = [String] 
    Subscription_ID = [String] 
    Username = [String] 
    Password = [String] 
    SAccountname = [String] 
    ContainerName = [String] 
    RequestFolder = [String] 
    BlobFolder = [String] 
    CertFolder = [String] 
    [TimeoutInMinutes = [Int32]] 
    [RenameComputerUsingSerial = [Boolean]] 
    [ComputerNamePrefix = [String]] 
    [RebootAfterDomainJoin = [Boolean]] 
}

Saccountname = Storage Account Name

Ready to get started? Download this module below!

Download Offline Domain Join

The post Offline Domain Join using XOAP and Azure Blob storage appeared first on XOAP.

dsc Archives | XOAP

Why use custom DSC modules?

Table of contents

What is a DSC module, in simple terms

Solving real problems when built-in resources fall short

Handling different environments and setups

Helping your team work better together

Fitting into DevOps and automated workflows

Making it easier to find and fix issues

Growing with your infrastructure over time

Getting started with your first custom module

Why custom modules are worth it

Tutorial: How to troubleshoot DSC compliance?

Table of contents

Why troubleshooting DSC compliance is so challenging

Extensive environments

Error diagnostics and network issues

Resource conflicts and host-specific issues

Versioning and logging

How to troubleshoot DSC compliance

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Why use XOAP to troubleshoot DSC compliance

Convert Group Policy into DSC

Table of contents

Why migrate from Group Policy to DSC?

What is the BaselineManagement Module?

Prerequisites

Step-by-step guide: Convert Group Policy to DSC

Step 1: Export Group Policy settings

Step 2: Review the exported Baseline

Step 3: Convert Group Policy Baseline to DSC configuration

Step 4: Review and customize the DSC configuration

Step 5: Apply the DSC configuration

Step 6: Monitor & maintain the configuration

Additional considerations

Versioning and documentation

Transition planning

Continuous monitoring

Integration with XOAP's config.XO

Shift to modern configuration management

Create a PowerShell DSC module | Online training

Create a PowerShell DSC module | Online training

Learn how to automate the entire delivery chain. Join XOAP training events!

After tackling security and compliance issues in our first online training event, we are eager to show you more about automation, the easy way.

Upcoming & past events

A modular approach to dynamic DSC configurations

Table of contents

How can XOAP help you?

Step 1: Create a baseline DSC module

Step 2: Create configurations

Step 3: Assign configurations

Keeping configurations up to date

Improve your process today

Secure your Windows environment with XOAP Windows LAPS DSC

Table of contents

What is XOAP Windows LAPS DSC?

Key features

Why use XOAP Windows LAPS DSC?

Enhanced security

Operational efficiency

Compliance and auditing

Simplified management

Getting started with XOAP Windows LAPS DSC

Prerequisites

Installation

Configuration

⭢ AzureADWindowsLAPSSettings

⭢ LocalADWindowsLAPSSettings

⭢ WindowsLAPSEmulationMode

Example

Your next step

Offline Domain Join using XOAP and Azure Blob storage

Who is this for?

What does this module do?

What do I need to know before I start?