Using Desired State Configuration (DSC) v3 on Windows Server 2025
Microsoft Desired State Configuration v3 has some substantive changes compared to previous versions of the technology. Unlike PowerShell Desired State Configuration (PSDSC) v1.1 and v2, DSC v3 operates as a standalone command rather than a service, eliminating the need for a local configuration manager. This architectural change makes DSC v3 easier to use and scale, allowing any tool that can execute commands on Windows Server, such as Scheduled Tasks, to apply DSC configurations. You can install DSC using WinGet. Windows Server 2025 includes built-in support for WinGet, making the installation process more straightforward than on previous server versions. However, it's important to note that winget is only available for Windows Server 2025 with Desktop Experience and can’t be used with Server Core deployments. DSC v3 requires PowerShell 7.2 or later. As Windows Server 2025 comes with Windows PowerShell 5.1, you'll need to install PowerShell 7.x separately, which you can do manually or using WinGet from an elevated PowerShell session. winget install microsoft.powershell The PSDesiredStateConfiguration module specifies a minimum PowerShell version of 7.2 in its module manifest. WinGet provides the most straightforward installation experience with automatic updates: Open PowerShell with administrative privileges Install the stable version using: winget install Microsoft.DSC Alternatively, download the latest release from the PowerShell/DSC repository and add the folder containing the expanded archive contents to your PATH environment variable. Basic DSC v3 Commands To view all available commands in DSC v3, use: dsc --help The output will display available commands including: completer - Generate a shell completion script config - Apply a configuration document resource - Invoke a specific DSC resource schema - Get the JSON schema for a DSC type help - Display help information for commands To see the resources available for use in configurations: dsc resource list This command displays all DSC resources installed on your system that can be used in configuration documents. Creating DSC v3 Configurations DSC v3 configurations can be written in YAML format, which is more concise and readable than the MOF format used in previous versions. A DSC v3 configuration document must include: A reference to the DSC resource schema At least one resource definition with properties Creating a Basic Configuration Here's an example of a basic configuration in YAML format: $schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2023/08/config/document.json resources: - name: Force icon view in Control Panel type: Microsoft.Windows/Registry properties: keyPath: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer\ valueName: ForceClassicControlPanel valueData: DWord: 1 This configuration sets a registry value to force the Control Panel to display using the classic icon view. For compatibility with classic PowerShell resources, you can use the WindowsPowerShell resource type: $schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2024/04/config/document.json metadata: name: IIS-Configuration resources: - name: Use Windows PowerShell resources type: Microsoft.Windows/WindowsPowerShell properties: resources: - name: Web server install type: PSDesiredStateConfiguration/WindowsFeature properties: Name: Web-Server Ensure: Present This configuration uses the classic WindowsFeature resource from the PSDesiredStateConfiguration module to install IIS. Once you've created a configuration document, you can test and apply it using DSC v3 commands. To test a configuration to see what changes would be made (rather than shouting Cowabunga on production systems) run the following command: dsc config get -f .\iis-config.yaml This command assesses the current state without making changes, showing what would happen if you applied the configuration. To apply a configuration run a version of the command (with your yaml file specified): dsc config set -f .\iis-config.yaml This command applies the configuration defined in the YAML file to your system. You can find out more about DSC v3 at the following locations: https://devblogs.microsoft.com/powershell/get-started-with-dsc-v3/ https://github.com/PowerShell/PSDesiredStateConfiguration https://learn.microsoft.com/powershell/dsc/overview?view=dsc-3.0&preserveView=true https://learn.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-windows?view=powershell-7.5Stop hardcoding secrets! Now what?!
Yeah, we all know this right “STOP DOING THIS”, “STOP DOING THAT!” Yeah… that’s nice, but now what?! When you are already in the PowerShell field for some time and have created some scripts you might have been running into this topic; ‘How to deal with secrets’. There are of course solutions like KeyVault, SecureString and secret providers with API’s which help you to store the secrets you have in a secure environment. Things like this might look familiar; $password = "P@ssw0rd123!" $apiKey = "sk-1234567890abcdef" $connectionString = "Server=myserver;Database=mydb;User=admin;Password=SuperSecret123;" But what if I told you there’s a better way? A way that’s: Secure by default Cross-platform (Windows, Linux, macOS) Works with multiple backends (local, Azure Key Vault, HashiCorp Vault) Standardized across your entire team Built right into PowerShell 7+ (with some extra module support) That way forward is called ‘PowerShell SecretManagement”! What is SecretManagement? Think of PowerShell SecretManagement as the universal remote control for your secrets. With this remote control you can handle credentials for different systems while you just get one unified interface. It doesn’t matter if that secret is stored: In your local machine In an Azure KeyVault In HashiCorp Vault In KeePass, LastPass etc. The mindset remains the same ‘One remote control, to control them all’. The architecture behind it looks a bit like below; Explaination: SecretManagement “The interface where you code against” SecretStore “The default storage where your secrets live” Getting Started Let’s get started! Start PowerShell 7+ and run the code below Install-Module Microsoft.PowerShell.SecretManagement -Repository PSGallery -Force Install-Module Microsoft.PowerShell.SecretStore -Repository PSGallery -Force Now we have the required modules installed form the PowerShell Gallery it’s time to create our first vault. Register-SecretVault -name "LocalTestVault" It will ask you for the module. Enter the name “Microsoft.PowerShell.SecretStore”. (If you want you can also specify this value directly in the CMDLet by specifying the -ModuleName parameter. You should end up with something like below: First secrets Now we have the vault set-up it’s time to add some content to it. Follow the steps below to create the first secret in the vault Run the command below to create the first secret Set-Secret -Name "TestSecret" -Secret "SuperDuperSecureSecretString" If you haven’t specified the password it will now ask for one! You should end up with something like below; Cool right? On my personal blog I have the full post where I also show how to change, delete, and store complex objects. You can find it here: https://bartpasmans.tech/powershell-stop-hardcoding-secrets-now-what/ Happy scripting!
A little help please with Get-AzADObject
I am trying to write a PowerShell script that will list the users who hold specified Azure roles into a .csv file for security reviews. I'm new to PowerShell and I'm struggling with this for far too long on my own. Here's what I've got: I keep getting the error: Get-AzADObject: The term 'Get-AzADObject' is not recognized as a name of a cmdlet, function, script file, or executable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. I've already used: Get-Module AzureAD Install-Module AzureAD Import-Module AzureAD With no errors on any of those. What am I missing, please?PowerShell Colors for Operator & Parameter
Hi all I have some weird behavior here. When I work with PowerShell 7 over the Windows Console Host, the Operator and Parameter color are completely black, and I can't see them when I type an Operator or Parameter. When I work with PS7 over the Windows Terminal, the Operator and Parameter are visible. Both windows have the same background color (0c0c0c) and I copied the value from the Windows Console Host PS7, to make sure it has the same value as the window from the Windows Terminal PS7. Has anyone a fix/explanation for this? Thanks. 🙂
