XOAPBaselineModuleDSC is a core component of the Configuration Management module. By using XOAPBaselineModuleDSC in configurations, you gain functionality to install applications, monitor the compliance state of your nodes, and more.

Current version

Current version of the module is 0.1.14

Required update

The updated DSC Baseline module includes minor bug fixes and compatibility improvements.

This version (0.1.15) is now required for all XOAP deployments to ensure consistent baseline configuration behavior.

You can download the baseline module zip file from this link.

How to update

Download the baseline module and upload it to your XOAP Workspace.

In Configuration Management, Modules, click the New Module button.
 

Upload the module and click Confirm. The module will be ready to use after approximately 10-15 minutes.

Now recompile your configuration.

Go to Configuration Management, Configurations and find your configuration.

In the Actions menu, click Recompile.

For XOAP Baseline Module, select version 0.1.15 and click Save.

The last step is to edit your Configuration Group. Change the version to the new one and click Save.

Your configuration will be ready in 10-15 minutes.

Important note:
No manual changes are required on your nodes. Updates will be applied automatically.

The post About XOAP Baseline Module appeared first on XOAP.

This serves as an introduction to Configuration Management, outlining its purpose, advantages and important features.

Configuration Management (Configuration Management) is an extended implementation of Microsoft PowerShell Desired State Configuration (DSC), an essential part of the configuration, management and maintenance of Windows and Linux nodes. It allows specifying the configuration of a node using a declarative model in a simple and standardized way that is easy to maintain and understand.

With Configuration Management, infrastructure is defined as code, ensuring a consistent configuration, versioning and testability. Servers and clients managed by Configuration Management are continuously evaluated against their desired state. Furthermore, Configuration Management takes care of configuration drifts and ensures that they’re corrected automatically and that all configured configuration changes are applied wherever they’re assigned.

It doesn’t matter if you’re using DSC on servers or on your workstations.

: Watch our YouTube video for a visual walkthrough

Caractéristiques principales

• Create and ensure standardized configurations and assign them to groups or individual hosts
• The desired state is continuously evaluated and corrected as needed – to allow a consistent configuration
• Customizable code for flexibility – create your own configurations or modules and apply them where needed
• Painless migration and management by integrating the solution in a small scope of hosts side by side and moving further at your own pace
• Replicate the code base and assign it to multiple infrastructures to design a repeatable and immutable infrastructure. You can assign the same set of configurations to your on-premises nodes or nodes running in public clouds
• Implement code testing tools to automatically test the outcome of your configurations
• Replace manual infrastructure configuration and provisioning by using the desired state configuration language; it’s designed to be human-readable and easy to understand, write and extend
• Enable cloud adoption by leveraging the cloud’s on-demand infrastructure with a robust and easy-to-use configuration management system. The infrastructure automatically scales with your progress of integrating more hosts into the solution
• On-premises support – it doesn’t matter if you have your own data center or if you’re running your workloads completely in the cloud. We support many environments that are reachable by network

Use cases

• Complete configuration management of Microsoft Windows infrastructure services
• Uncomplicated configuration management of Windows clients and desktops
• Replace group policies and configure VMs without Active Directory connection (e.g. DMZ VMs)
• Install and configure Windows features
• Use our intuitive frontend to deliver PowerShell DSC to your IT staff
• Run package installations during configuration management runs (with Application Management based on PowerShell App Deployment Toolkit)

Top benefits

• Simplify infrastructure tasks by configuring one or more nodes automatically
• Configure all nodes within a role identically
• Avoid drift of configurations over time
• Automate the deployment on demand or “en masse”, fully automated and independent of the location of a node

The post About Configuration Management appeared first on XOAP.

Configuration Management

PowerShell

All nodes that will be used to author or receive configurations are running WMF version 5.1 or later. Authoring nodes that are used to write configurations locally need to have internet connectivity to download new DSC-related resources.

Remote management

WS-Management (WS-MAN) traffic is permitted on the network. It will be enabled by default on nodes that have PowerShell version 5 installed, but you must ensure it’s not being blocked by firewalls or other network elements. Read further for more information.

Communication with our backend

In order to communicate with our backend, the following ports need to be open: https://api.dev.xoap.io on port 443.

Proxy configuration for nodes

To force PowerShell DSC nodes to use a proxy server to communicate with the cloud-hosted backend, some adjustments to the node configuration must be made before registering the node. DSC does not communicate in a user context and therefore uses the SYSTEM context.

For DSC to connect successfully and register the node, adjust the following lines inside the machine.config in your .NET installation directory.

You should find the file in these locations:

32-bit
**%windir%\Microsoft.NET\Framework\[version]\config\machine.config**
64-bit
**%windir%\Microsoft.NET\Framework64\[version]\config\machine.config**
[version] should be equal to v1.0.3705, v1.1.4322, v2.0.50727 or v4.0.30319. v3.0 and v3.5 just contain additional assemblies to v2.0.50727 so there should be no config\machine.config. v4.5.x and v4.6.x are stored inside v4.0.30319.
Then add the following lines:
<defaultProxy>  <proxy autoDetect="false" bypassonlocal="false" proxyaddress="http://127.0.0.1:8888" /> </defaultProxy></system.net>

Firewalls

SSL decryption can get you into trouble when clients inside your corporate network try to communicate with the cloud backend.

DEP

We’ve seen some Virus Scanners with DEP enabled to prevent users from logging into the cloud backend successfully.

TLS

Enable TLS 1.2 wherever possible. Not doing so will keep Configurations Management from working successfully.

Set it via PowerShell:

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWordSet-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWordSet-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v2.0.50727' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12

The post Prerequisites appeared first on XOAP.

The device types overview gives you a quick overview of the different device types in your environment. You can see the number of devices per model and manufacturer.

Systèmes d'exploitation

The operating systems overview gives you a quick overview of the different operating systems in your environment. You can see the number of nodes per operating system.

Configurations

The Configurations overview gives you a quick overview of the different configurations in your environment. You can see the number of nodes assigned to the configuration.

Runtimes (daily)

This is a quick overview of the different average runtimes per configuration per day.

Runtimes (monthly)

This is a quick overview of the different average runtimes per configuration per month.

Node Status

This is a quick overview of the different node statuses in your environment. You can see the number of nodes per status (Compliant, Non-Compliant, Running).

Dynamic links

Below you see an example of dynamic links in the console. They are shortcuts inside the data tables to the corresponding areas – in this case to Configurations and Policies. With these, you can navigate easily to the area to continue the working process.

Module statistics

The widgets on the right show the following data:

• number of connected nodes
• number of created DSC configurations
• number of integrated DSC modules
• number of created LCM policies

Wizards

The wizards are the main entry points to the Configuration Management module. They guide you through the process of creating and uploading a DSC configuration.

The post Overview appeared first on XOAP.

Quick guide

Nodes are devices that are registered in your XOAP workspace when a configuration is assigned to them. Once registered, they are visible in XOAP and can be managed and monitored through Desired State Configuration configurations.

Add a Node

1. To add (register) a node to your workspace, use the Configuration Group registration command/script.
2. Aller à Configuration Management → Configuration Groups.
3. Select a configuration group (for example, XOAP Unassigned) and open the Action menu (⋮).
4. Sélectionner Copy registration command to copy the command to your clipboard.
5. On the target device, open PowerShell as Administrator and paste the command.
6. Run the command to register the device. The node will be added to your XOAP workspace in the corresponding group.

Update a Node

1. Click the Action menu (⋮) next to the node.
2. Sélectionner Details to view the full system inventory.
3. On the Details page, you can update Tags and review Hardware, Software, and Compliance information.

Delete a Node

1. Click the Action menu (⋮) et sélectionnez Supprimer.
2. Confirm the deletion by clicking Supprimer.

Additional useful information

Windows and Linux devices:

Nodes can be Windows devices. Linux devices are managed via the XOAP Connector and are listed under the Inventaire module. Windows devices can also have the XOAP Connector installed and appear under the Inventaire module, while still being managed through Configuration Management in parallel.

Configuration Group:

Nodes can be assigned to only one Configuration group, and change can be done under Configuration Group area

PowerShell support:

Node registration and management is currently limited to PowerShell 5.1 only. PowerShell Core is not supported.

Technical documentation

Nodes are devices that are registered in your XOAP workspace when a configuration is applied to them. Once registered, they are visible in XOAP and can be centrally managed and monitored through their assigned configurations, including inventory and compliance status, configuration run results, and operational health. This enables consistent enforcement of configuration standards across the environment and provides clear visibility into each device’s current state and configuration drift.

Node status in XOAP indicates the current configuration state of a device based on the latest configuration evaluation and execution results. The following statuses are used:

• Compliant: The node matches the assigned configuration. All required settings are applied and the last evaluation completed successfully with no deviations detected.
• Non-compliant: The node does not match the assigned configuration. One or more required settings are missing, incorrect, or failed to apply during the last run.
• Running: A configuration run is currently in progress on the node. XOAP is actively applying or evaluating the configuration and the final compliance result is not yet available.

You can check compliance history in two ways:

• Click the Compliance status icon.
• Ouvrir le Action menu (⋮) et sélectionnez Compliance History.

Both methods open the same slide-out view showing compliance information for the last 14 days. By clicking the status entry again, you can view details for a specific configuration application run. Detailed logs are available for resources that are not in the desired state.

To view full node details, click the Node name or open the Action menu (⋮) et sélectionnez Details.

Le Details view provides a deep dive into the node’s current state across several categories:

• Hardware: BIOS, Processors, Devices, and Volumes.
• Networking: Full interface details and network configurations.
• Operating System: Real-time lists of Services, Scheduled Tasks, and Local Users.
• Maintenance & Policy: Installed Updates and DSC (Desired State Configuration) status.

The post Nodes appeared first on XOAP.

Quick guide

A Configuration Group is a logical container in XOAP that assigns a specific configuration a Policy and optionally an Rôle de l'application to a set of nodes.

Create a new Configuration Group

1. In the upper-right corner, click + Create Group.
2. Enter the Group name and select/add Tags.
3. From the dropdown menu at the top, select the desired Rôle de l'application.
4. Move nodes from Available nodes to Selected nodes to assign them to this group.
5. Select configuration and configuration version
6. Select Policy
7. Cliquez sur Créer to finish.

Edit a Configuration Group

1. Click the Menu d'action (⋮) and select Editer.
2. Update the Name, Policy, Application Role, Tags or modify the assigned Configurations.
3. Cliquez sur Économiser to apply any changes.

Delete a Configuration Group

1. Click the Menu d'action (⋮) and select Supprimer.
2. Confirm the deletion by clicking Supprimer.

Additional useful information

Configuration Groups and Nodes:

In Configuration Groups, you can add only nodes (Available Nodes) that are not already assigned to another Configuration Group. Nodes can be removed in the details of the Configuration Group.

To register a new node (a node that is not yet available in your XOAP workspace), run the registration script or registration command in PowerShell on the node. A Configuration Group can have only one Configuration and one Application Role assigned.

Technical documentation

A Configuration Group is a logical container in XOAP that assigns a specific Configuration—and optionally an Rôle de l'application et Policy—to a set of nodes. Nodes registered through the group inherit these assignments, and the group view provides an overview of how many nodes are compliant, non-compliant, or currently running the configuration.

To register nodes in your workspace, run the registration script (or registration command) on the target node using Windows PowerShell 5.1 as Administrator.

You can find the registration script/command in the Action menu (⋮):

1. Click the Action menu (⋮) et sélectionnez Download registration script ou Copy registration command.
2. On the target system (node), open Windows PowerShell 5.1 as Administrator, and either:
   • Run the downloaded script, or
   • Paste the registration command and run it.
3. The specified configuration will be applied to the node. If an Rôle de l'application is defined, the assigned applications will also be installed.
4. The node will appear in the Nœuds table under Configuration Management.

Both methods apply the same configuration and produce the same result.

Mass registration (deploy to multiple nodes)

To register many nodes at once, distribute the registration command/script using your existing software deployment or policy tooling. The registration must run in an elevated context (Administrator/SYSTEM).

Option 1: Group Policy (GPO) – Scheduled Task or Startup Script

Use a domain GPO to run the registration on target machines:

• Scheduled Task (recommended): Create a GPO Scheduled Task that runs at startup as SYSTEM and executes the registration command/script.
• Startup Script: Assign a startup script that runs during boot (computer scope).
  This approach is simple, works well for large fleets, and ensures the command runs with the required privileges.

Option 2: Microsoft SCCM / MECM

Deploy the registration as an SCCM package/application:

• Run the registration command/script as Local System.
• Target a device collection (for example, a pilot group first, then broader rollout).
  This provides reporting, retry logic, and controlled rollout.

Option 3: Microsoft Intune (Proactive Remediations or Script Deployment)

For Entra ID / Intune-managed devices:

• Deploy the registration script as a device script, or use Proactive Remediations to run it once and verify the node is registered.
• Ensure the script runs in system context for required permissions.

Option 4: Remote execution (PowerShell Remoting)

If PowerShell Remoting is available:

• Use Invoke-Command to run the registration command on a list of target computers under an account with local admin rights.
  This is useful for quick onboarding of smaller batches or ad-hoc groups.

Practical tips for mass deployment

• Use a pilot group first to validate connectivity, permissions, and expected behavior.
• Ensure the environment allows outbound HTTPS (443) to the XOAP API endpoint.
• Avoid re-running on already registered nodes by using the appropriate targeting/exclusions in your deployment tool (e.g., SCCM collections or GPO scoping)

Prerequisites to register a node

• Windows device
• Run as Administrator
• 64-bit Windows PowerShell (not PowerShell ISE)
• Windows PowerShell 5.1 avec DSC (PSDesiredStateConfiguration) available
• WinRM / PowerShell Remoting can be enabled and restarted
• Outbound HTTPS (443) access (or a working proxy for SYSTEM access) to: https://api.dev.xoap.io

The post Groups appeared first on XOAP.

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. Aller à Configuration Management → Modules.
2. Cliquez sur Upload modules.
3. Upload the module package (supported formats: .zip ou .nupkg).
4. Enable Allow overwrite if already exists if you want to replace an existing module/version.
5. Cliquez sur Suivant, 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. Utilisation Télécharger in the details view to download the selected module version.

Delete a Module

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

Additional useful information

Supported module package formats

Modules can be uploaded as .zip ou .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:

• En Configuration Management → Modules, open the module Action menu (⋮) et sélectionnez Télécharger, or
• Open Details and use Télécharger 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.

The post Modules appeared first on XOAP.

Quick guide

A Policy defines how configurations are applied and maintained on nodes. It controls the DSC operational behavior, including configuration mode, execution cadence (frequencies), reboot handling, and optional proxy settings.

Create a new Policy

1. Aller à Configuration Management → Policies.
2. Cliquez sur + New Policy.
3. Enter a Nom.
4. Configure the required policy settings:
   • Action after Reboot
   • Configuration Mode
   • Configuration Mode Frequency (min)
   • Refresh Frequency (min)
   • Status Retention Time (d)
5. (Optional) Configure Proxy URL, Proxy Username, and Proxy Password, and/or add Tags.
6. Cliquez sur Confirmer to create the policy.

Edit a Policy

1. Dans le cadre de la Politiques table, click the Action menu (⋮) next to the policy.
2. Sélectionner Editer.
3. Update the required fields as needed.
4. Cliquez sur Confirmer to save changes.

Delete a Policy

1. Dans le cadre de la Politiques table, click the Action menu (⋮) next to the policy.
2. Sélectionner Supprimer.
3. Confirm the deletion.

Additional useful information

Policy changes:

Changes made to an XOAP Policy do not automatically update the policy settings on nodes.

Proxy settings:

Proxy settings: Configure proxy fields only if nodes require a proxy to reach XOAP; otherwise leave them empty.

Technical documentation

A Policy defines how DSC is executed and maintained on a node. It controls the node’s configuration execution behavior (configuration mode), how often the node evaluates and enforces configuration (Configuration Mode Frequency), how often it refreshes its configuration context (Refresh Frequency), and what should happen after a reboot. Policies can also store proxy settings to ensure nodes can reach XOAP services in restricted network environments.

Policy fields

Nom

A unique, human-readable name for the policy (for example, XOAP Desktops (no reboot)). Use a naming convention that reflects the target workload and reboot expectations.

Select the Action after Reboot

Defines what the node should do with configuration processing after a restart. In most environments this is set to ContinueConfiguration, meaning configuration execution continues and the node resumes applying/evaluating the assigned configuration after reboot.

Allow Module Overwrite

Controls whether module content used for configuration execution can be overwritten when a newer module version is introduced. This is typically used only when you intentionally want nodes to accept updated module versions without manual intervention.

Configuration Mode

Defines the DSC behavior on the node:

• ApplyOnly: Applies the configuration once; does not continuously monitor for drift.
• ApplyAndMonitor: Applies the configuration and reports drift, but does not auto-remediate.
• ApplyAndAutoCorrect: Applies the configuration and automatically attempts to remediate drift to return the node to the desired state.

In XOAP, ApplyAndAutoCorrect is typically used for security baselines and hardening, while ApplyOnly is more suitable for one-time provisioning scenarios.

Configuration Mode Frequency (min)

Controls how often the node performs a consistency check based on the selected Configuration Mode (especially relevant for ApplyAndMonitor et ApplyAndAutoCorrect). This is the main “enforcement cadence” that determines how quickly XOAP/DSC detects drift and (when enabled) auto-corrects it.

Key guidance

• Lower values = faster drift detection and quicker remediation, but higher endpoint load.
• Higher values = less frequent checks, lower load, slower drift detection.

Recommended usage

• Desktops: 30–60 minutes (typical)
• Servers: 60+ minutes (typical), unless strict enforcement is required

Refresh Frequency (min)

Controls how often the node refreshes its configuration context and checks for updated configuration content. This influences how quickly changes in XOAP (new configuration version, updated resources, etc.) are picked up by the node.

Key guidance

• Lower values = nodes pick up changes faster, but more frequent polling.
• Higher values = slower pickup of changes, reduced polling overhead.

Recommended usage

• Desktops: 180 minutes (typical)
• Servers: 360 minutes (typical), unless you need faster propagation

Status Retention Time (d)

Defines how long XOAP retains node run/status history for reporting and troubleshooting (for example, compliance history). Higher values retain more history but may increase storage/retention footprint.

Proxy URL / Proxy Username / Proxy Password

Optional proxy settings used when nodes must access XOAP endpoints through a proxy.

• Proxy URL: The proxy endpoint (for example, http://proxy.company.local:8080)
• Proxy Username / Proxy Password: Credentials if the proxy requires authentication
  Utilisation Choose Existing to reuse stored values in Paramètres consistently.

Reboot Node

Controls whether a node restart is allowed/triggered as part of configuration execution (where applicable). Enable this only if reboots are acceptable for the target systems and your operational policies allow it.

Tags

Optional metadata used for filtering and organization (for example, Server, Desktop, RebootAllowed, PoC).

Configuration Mode Frequency vs. Refresh Frequency (how they work together)

These two values serve different purposes and should not be treated as duplicates:

• Configuration Mode Frequency = how often the node evaluates/enforces the desired state (drift detection and remediation cadence).
• Refresh Frequency = how often the node checks for updated configuration content (how quickly configuration changes propagate).

Practical example

• If you set Configuration Mode Frequency = 15 min et Refresh Frequency = 360 min, the node will enforce the current configuration every 15 minutes, but it may take up to ~6 hours to start using a newly updated configuration version (until it refreshes).

Minimum values and practical limits

XOAP enforces minimum values (depending on implementation and policy). Current limits are:

• Configuration Mode Frequency: minimum 15 minutes
• Refresh Frequency: minimum 30 minutes

As a safe best practice:

• Avoid very low values unless you have a strict need and have tested endpoint impact. (Values below the minimums are not supported and will be rejected.)
• Keep Refresh Frequency  higher than Configuration Mode Frequency  to reduce unnecessary refresh/polling.
• A common approach is Configuration Mode Frequency = 15 min et Refresh Frequency = 60–360 min, depending on how quickly you need nodes to pick up changes.

The post Policies appeared first on XOAP.

Securing configurations

All uploaded configurations are automatically signed with our code signing certificate. So you do not have to take care of securing your configurations.

During client registration, an additional certificate is installed on the client to identify requests from trusted nodes.

Securing the Pull Server

Our DSC implementation does not run on a web server. We are running containers behind an API gateway with user authentication.

Configure for Strong Cryptography

How to configure .NET Framework to support strong cryptography. Set the SchUseStrongCrypto registry setting to DWORD:00000001. This value disables the RC4 stream cipher and requires a restart. For more information about this setting, see Microsoft Security Advisory 296038.

Make sure to set the following registry keys on any computer that communicates across the network with a TLS 1.2-enabled system. For example, configuration manager clients, remote site system roles not installed on the site server, and the site server itself.

For 32-bit applications that are running on 32-bit OSs and for 64-bit applications that are running on 64-bit OSs, update the following sub-key values:

Registry

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727]
      "SystemDefaultTlsVersions" = dword:00000001
      "SchUseStrongCrypto" = dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
      "SystemDefaultTlsVersions" = dword:00000001
      "SchUseStrongCrypto" = dword:00000001

For 32-bit applications that are running on 64-bit OSs, update the following subkey:

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727]
      "SystemDefaultTlsVersions" = dword:00000001
      "SchUseStrongCrypto" = dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
      "SystemDefaultTlsVersions" = dword:00000001
      "SchUseStrongCrypto" = dword:00000001

The SchUseStrongCrypto setting allows .NET to use TLS 1.1 and TLS 1.2. The SystemDefaultTlsVersions setting allows .NET to use the OS configuration. For more information, see TLS best practices with .NET Framework.

Proxy configuration for nodes

In order for PowerShell DSC nodes to be forced to use a proxy server to communicate with the cloud-hosted backend, some adjustments to the node configuration must be done before registering the node.

DSC does not communicate in a user context and therefore uses the SYSTEM context.

For DSC to connect successfully and register the node, adjust the following lines inside the machine.config in your .NET installation directory. You should find the file in these locations:

32-bit

**%windir%\Microsoft.NET\Framework\[version]\config\machine.config** copy

64-bit

**%windir%\Microsoft.NET\Framework64\[version]\config\machine.config** copy

[version] should be equal to v1.0.3705, v1.1.4322, v2.0.50727 or v4.0.30319. v3.0 and v3.5 just contain additional assemblies to v2.0.50727 so there should be no config\machine.config. v4.5.x and v4.6.x are stored inside v4.0.30319.

Then add the following lines: <defaultProxy> <proxy autoDetect="false" bypassonlocal="false" proxyaddress="http://127.0.0.1:8888" /> </defaultProxy> </system.net> copy

PowerShell DSC configuration encryption

PowerShell DSC configurations that are uploaded while adding the configuration are going to be encrypted by using a certificate that is provided by XOAP.

This happens in two cases:

• Adding a configuration by manually uploading configuration files (as ps1) with the upload wizard
• Adding a configuration by using the DSC Configuration Wizard

After the file is encrypted, it is converted to base64 string and pushed to a dedicated backend storage location.

If you are uploading a compiled mof file, it will not be encrypted.

The post Security appeared first on XOAP.

In order to write PowerShell DSC Configurations, you need some tools to get you started.

WMF 5.1

If it’s not already installed, you should install the Windows Management Framework 5.1.

If you’re running Windows 10 or Windows Server 2016 and above, it should already be installed.

PowerShell Get

Run the following commands as administrator on your Windows machine:

Install-Module -Name PowerShellGet -Force

Learn more about PowerShell Get.

Code editors

You’ll need a suitable source code editor, so we recommend one of the following.

Visual Studio Code

Visual Studio Code is our preferred code editor for all PowerShell-related topics. It can be downloaded ici. You can install it for a user or as a system installer. Choose the installer that fits your needs.

IntelliJ IDEA

If you’re not a fan of Visual Studio Code, you can use IntelliJ IDEA as an alternative. It can be downloaded ici.

PowerShell ISE

PowerShell ISE is another code editor you can use to edit your DSC configurations, but we strongly recommend one of the two above.

Additional DSC Resources

Additional DSC Resources can be downloaded from PowerShell Gallery. The modules you need to download depend on the configuration you want to create. Browse through the PowerShell Gallery to find the resources you need.

If the resources are not there yet, feel free to write your own.

They are installed via PowerShell:

Install-Module -Name xWindowsUpdate

Naming conventions

Follow the guidelines below to ensure the correct processing:

• Standard names may only contain letters (a-z, A-Z), numbers (0-9), and underscore (_)
• The name may not be null (0), empty ( ) or written with hyphen (-), and should start with a letter (a-z, A-Z)

Valid naming examples

“XOAP_Any_Apps_And_Monitoring”

“xoap_any_apps_and_monitoring_0_1_9”

“XOAP_Hp_Dl380_Baseline_Configuration”

“xoap_hp_dl380_baseline_configuration”

Invalid naming example

“XOAP-W10-20H2-Citrix-Optimizer”

“01 XOAP W10 20H2 Citrix Optimizer”

Commands and actions

Desired State Configuration (DSC) cmdlets for everyday usage

Debugging (DSC) cmdlets

The post Best practices appeared first on XOAP.