How to recursively configure a registry key for all user profiles in HKU

[matt6697]

DSCv3 Microsoft.Windows/Registry ressource works very well to configure registry keys in :

• HKLM when DSCv3 is executed with a system account
• HKCU when DSCv3 is executed with logged in user permissions.

However, how could we recursively apply a USER policy setting (ie: registry key), formelly applied by a USER Group Policy setting, to all user profiles listed in HKU without waiting for all users to log in ?

Use case is to use DSCv3 as a detection/remediation script in Intune to fill the gap between Intune and group Policies and migrate all registry USER Group Policy settings to Intune. Intune package provided in https://www.cyber.mil/stigs/gpo/ uses a DSCv2 (powershell) package to do this. We would like to to it with DSCv3

[krotname]

For already-loaded users, this is just HKEY_USERS\<sid>\.... For users who are not logged in, there is no live HKCU; you have to load that user's NTUSER.DAT hive, write the value, then unload it.

So I would not model this as one recursive Microsoft.Windows/Registry resource with a wildcard under HKU. The safer pattern for Intune remediation is:

1. Enumerate real local profiles, for example from Win32_UserProfile, excluding special/system profiles.
2. For each profile SID:
   • if HKU:\<sid> is already loaded, write the key there;
   • otherwise reg load HKU\Temp_<sid> C:\Users\...\NTUSER.DAT, write under HKU:\Temp_<sid>\..., then reg unload HKU\Temp_<sid>.
3. Handle locked/corrupt hives explicitly and log them as remediation failures.

Pseudo-flow:

Get-CimInstance Win32_UserProfile |
  Where-Object { -not $_.Special -and $_.LocalPath -and (Test-Path "$($_.LocalPath)\NTUSER.DAT") } |
  ForEach-Object {
    $sid = $_.SID
    $loadedPath = "Registry::HKEY_USERS\$sid"
    $tempName = "DSC_$($sid -replace '[^A-Za-z0-9]', '_')"
    $root = $loadedPath
    $loadedByScript = $false

    if (-not (Test-Path $loadedPath)) {
      reg.exe load "HKU\$tempName" "$($_.LocalPath)\NTUSER.DAT" | Out-Null
      $root = "Registry::HKEY_USERS\$tempName"
      $loadedByScript = $true
    }

    try {
      New-Item -Path "$root\Software\Policies\Vendor\Product" -Force | Out-Null
      New-ItemProperty -Path "$root\Software\Policies\Vendor\Product" -Name SomeValue -Value 1 -PropertyType DWord -Force | Out-Null
    }
    finally {
      if ($loadedByScript) {
        [gc]::Collect()
        reg.exe unload "HKU\$tempName" | Out-Null
      }
    }
  }

If you want this to stay in a DSCv3 design, I would wrap that enumeration/load/unload logic in a script/custom resource and keep Microsoft.Windows/Registry for fixed HKLM/HKCU paths. For dynamic per-profile HKU writes, the hard part is profile hive lifecycle, not the registry value itself.

Also, if the setting has an Intune Settings Catalog / ADMX-backed equivalent, prefer that. Directly writing old user-policy keys is useful for migration gaps, but you are then responsible for targeting, removal, and deprovisioning behavior that Group Policy previously handled.