WinGet Configuration use case from a software developer and Windows enthusiast

[totkeks]

I'd like to share my envisaged personal use case and related thoughts as an input for the program management and as grounds for discussion with other users.

Background

As some borders for the discussion: I'm a software developer, both professionally and in my private life. I like to have the same setup on my desktop, my laptop and my work laptop, the latter usually having some restrictions via group policies.
I'm not a sysadmin, so I don't need to setup many machines at once or often, neither do I have the experience. Though I occasionally reinstall my Windows 11 due to being an Insider and/or having hardware problems.

Preamble

I started extending my dotfiles repo with PowerShell scripts (WIP gist) and an OOBE answers file to automate the setup process about half a year ago. Therefore, I was very happy to see the announcement of WinGet Configurations at Build 2023.

Use case details

Based on my requirements, there are already many DSC modules available to deal with them:

• Install apps via WinGet
• Change registry keys PSDesiredStateConfiguration/Registry
• Change powerplan options DSCR_PowerPlan/cPowerPlanSettings
• Change pagefile settings ComputerManagementDsc/VirtualMemory
• Change environment variables, including $PATH

Then there are also many items in my setup that require manual interaction with Windows, mostly the old control panel and the new Settings app, were I couldn't find any PowerShell modules or even registry keys to access those settings:

• Enabling hibernate in power menu
• Changing power button behavior to sleep
• Settings default terminal application (from terminal to terminal preview for example)
• Changing windows update options
• Changing sign-in options (save restartable apps option)
• Installing (Nerd)fonts from an online source (maybe via winget?)
• Configuring explorer settings and libraries
• Configure virtual desktops (though there is a PowerShell module available, so that could be used for a DSC module)

Then it would also be helpful to ascertain certain states based on parameters. I already saw in the configuration schema, that were an, yet undocumented, parameters property. I don't know what the plans for this are, but I would for example like to install apps based on the hardware in the system, used as a parameter:
For example, if I have a Nvidia GPU I want to install the Geforce Experience, with an AMD GPU I want to install the Radeon tooling. Or with a Kingston SSD, I want their disk health tool. Or with a Surface device, I want the surface app.
So, in the parameters section I would check for those, similar to an assertion, and then in the resources section I can use those parameters as dependencies, if that resource is considered or not.

And lastly the ability to set/restore configurations for apps I'm using, which would be pretty cool as not many applications provide settings sync, like VS Code or Vivaldi browser.
This requirement of mine seems to have an overlap with the newly introduced Windows 11 backup and restore app/features. Maybe there is a way to reuse this app or access it via an API, to bring configurations and app settings together.

Thanks for reading! What do you think about this? How does your configuration use case look like? Have you already played around with the configuration files?

[rlabrecquefsg]

Changing sign-in options (save restartable apps option)

This is what I ended up with:

    - resource: "xPSDesiredStateConfiguration/xRegistry"
      directives:
        description: "Settings > Accounts > Sign-in options > Automatically save my restartable apps and restart them when I sign back in [Enabled]"
      settings:
        Key: "HKCU:\\Software\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon"
        ValueName: "RestartApps"
        ValueData: "1"
        ValueType: "DWord"
        Force: true
        Ensure: "Present"

Configuring explorer settings and libraries

    - resource: "xPSDesiredStateConfiguration/xRegistry"
      directives:
        description: "Folder Options > General > Open File Explorer to [This PC]"
      settings:
        Key: "HKCU:\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Advanced"
        ValueName: "LaunchTo"
        ValueData: "1"
        ValueType: "DWord"
        Force: true
        Ensure: "Present"
    - resource: "xPSDesiredStateConfiguration/xRegistry"
      directives:
        description: "Folder Options > View > Launch folder windows in a seperate process [Enabled]"
      settings:
        Key: "HKCU:\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Advanced"
        ValueName: "SeparateProcess"
        ValueData: "1"
        ValueType: "DWord"
        Force: true
        Ensure: "Present"
    - resource: "xPSDesiredStateConfiguration/xRegistry"
      directives:
        description: "Folder Options > View > Restore previous folder windows at logon [Enabled]"
      settings:
        Key: "HKCU:\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Advanced"
        ValueName: "PersistBrowsers"
        ValueData: "1"
        ValueType: "DWord"
        Force: true
        Ensure: "Present"

[totkeks]

Cool 😎, thanks for sharing! Do you have your config in a public repo as well and wouldn't mind me looking for inspiration?

It would be really great if there were a public API for all those settings. I assume there is an internal one inside windows, no one would hardcode those registry keys. 😅

[denelon]

@totkeks it's been a while since you posted the discussion. I'm hoping you were able to get closer to what you wanted. We're doing a lot of work right now with DSC v3, and I think several of the challenges you were having have gotten some traction.

We published Microsoft.Windows.Settings as a v2 in the PowerShell gallery as a resource (source code over at https://github.com/microsoft/winget-dsc). It only contains a few settings today, but we'll be adding more. One of the huge challenges is the need for those registry keys to be documented. We're also looking at a native DSC v3 implementation for Windows Settings which solves a lot of additional pain, but there is no ETA.