Hello,

I want to use compliance settings to make sure a registry key has a specific value. I successfully created the configuration item and configuration baseline, tested the deployment on a test collection and verified the setting is enforced.

My issue is with the way the registry value gets created if it doesn't exist. I configured a data type of 'Integer' and the value gets created as a REG_QWORD on 64-bits machines. What I want is a REG_DWORD otherwise the software using this value doesn't work as expected. I don't know if the issue is the same on 32-bits machines (I don't have one to test at the moment).

I played with the various data types available for registry values but I can't seem to find how to achieve my goal.

Thank you for your help.

Hi,

After extended research I came to conclusion that remediating 32 bits integer values is not implemented in SCCM 2012. I checked CI settings related tables in the database (settings definitions and settings data types in particular) and found that the only defined integer value is Int64.

The only way I found to remediate 32 bits values is by using scripts instead of registry.

Hope this will help someone else.

• Marked as answer by sebcou Monday, October 15, 2012 6:27 AM

Hi Sebcou,

I'm having the same issue with you.Do you have the Scripts  to remediate the REG_Dword ?

Hi Jacky,

Here are the scripts. I haven't tested them extensively and I think there's room for improvment...

# Discovery script
$regKey = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"
$name = "Test32"

$regValue = Get-ItemProperty $regKey $name -ErrorAction SilentlyContinue

if(($? -and ($regValue -ne $null)))
{
$regValue.$name
}
else
{
# SCCM doesn't like when we return NULL values...
-1
}


# Remediation script
$regKey = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"
$name = "Test32"
$val = "5"
$type = "DWORD"

New-Item -Path $regKey
New-ItemProperty $regKey -Name $name -Value $val -PropertyType $type -Force

Hope it will help you. Feel free to improve the code and post it here !

Best regards.

Does anyone know if this bug will be fixed in a CU at any point?

Using the script method here for now to "get around it", but CU1 and now CU2 release and no fix as yet?

To my knowledge, no. Although do note that it is not for the reason stated above -- compliance settings uses the default format for the OS architecture. Thus, for 64-bit OSes, it creates QWORDs and on 32-bit it creates DWORDs.

I'm going to file a bug on connect later today.

To my knowledge, no. Although do note that it is not for the reason stated above -- compliance settings uses the default format for the OS architecture. Thus, for 64-bit OSes, it creates QWORDs and on 32-bit it creates DWORDs.

I'm going to file a bug on connect later

I have to laugh at this one. It stopped us dead in our tracks today and what makes it worse is Q and D look alot like the same enough that we didn't catch it right away. 

Anyways awful bug, thanks for explaining, hope they fix it soon!

• Edited by Eric Weintraub Thursday, May 01, 2014 2:58 PM spelling

 Discovery script
$regKey = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"
$name = "Test32"

$regValue = Get-ItemProperty $regKey $name -ErrorAction SilentlyContinue

if(($? -and ($regValue -ne $null)))
{
$regValue.$name
}
else
{
# SCCM doesn't like when we return NULL values...
-1
}

The Above script is a Powershell script.

Quick Breakdown:

$ precedes a variable, $regKey is a variable you set to the registry path of the Registry Key.

$name is the name of the value you are looking for.

$regValue is being set to the result of Get-ItemProperty $regKey $name -ErrorAction SilentlyContinue
Get-ItemProperty is a powershell command that can return many different item types including registry values.  $regKey provides the path, $name provides the value, -ErrorAction allows it to continue on error (the value doesn't exist for instance).

The condition statement I'm not 100% sure on because I'm not familiar with $? as a variable, it appears to be a boolean, maybe representing whether it exists but I don't see why it would be necessary.

Did not see anything posted that looked like an answer as to using the remediation native so I thought I would share my experience.

If you want REG_DWORD values remediated, then you must check the box "This registry value is associated with a 64-bit application"

Very misleading but by checking that box, you will successfully remediate REG_DWORD values.

• Proposed as answer by rick.lawson 11 hours 13 minutes ago