none
Issue with integer registry compliance settings

    Question

  • 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.

    Monday, October 8, 2012 10:54 AM

Answers

  • 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
    Monday, October 15, 2012 6:27 AM

All replies

  • 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
    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 ?

    Monday, October 22, 2012 1:18 AM
  • 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.

    Monday, October 22, 2012 6:17 AM
  • Thanks sebcou. will do.
    Monday, October 22, 2012 2:06 PM
  • 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?

    Tuesday, July 16, 2013 10:37 AM
  • 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.


    Jason | http://blog.configmgrftw.com

    • Proposed as answer by keller21 Friday, February 28, 2014 8:00 PM
    • Unproposed as answer by keller21 Friday, February 28, 2014 8:01 PM
    Tuesday, July 16, 2013 1:05 PM
  • 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.


    Jason | http://blog.configmgrftw.com

    Thanks Jason - I thought it had already been raised but obviously not :)
    • Proposed as answer by keller21 Friday, February 28, 2014 8:00 PM
    • Unproposed as answer by keller21 Friday, February 28, 2014 8:01 PM
    Tuesday, July 16, 2013 1:50 PM
  • 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!


    Thursday, May 1, 2014 2:58 PM
  • Can anyone explain the scripts above, or other methods to get around this, a little bit?  Im not super experienced in VB scripting and the scripts arent working for me.
    Monday, August 18, 2014 8:38 PM
  •  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.


    Thursday, January 15, 2015 1:53 AM
  • $? simply returns True or False value indicating whether previous command ended with an error or not.

    Jason | http://blog.configmgrftw.com | @jasonsandys

    Thursday, January 15, 2015 2:40 AM
  • 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 Wednesday, August 5, 2015 8:38 PM
    Wednesday, August 5, 2015 8:37 PM
  • Checking the "This registry value is associated with a 64-bit application" box didn't work for me.  

    So, just to expand on the script solution above for those that have tattooed their workstations with the QWORD value, the discovery script needs a little adjusting:

    # Discovery script
    $regKey = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"
    $name = "Test32"
    
    try
    {
        $regValue = (Get-ItemProperty $regKey -ErrorAction Stop).PSObject.Properties |
        ? {$_.Name -eq $name} | select Name, TypeNameOfValue, Value
        if ($regvalue -and
    	$regvalue.Value -and
           ($regvalue.TypeNameOfValue -match 'int32')) 
        {
    	return $regvalue.Value
        }
    }
    catch 
    { 
        #Reg key doesn't exist
    }
    
    return -1
    The only real difference here is that it includes the registry value type as part of the discovery.  So, if it doesn't find the DWORD value it will return -1.

    Monday, October 19, 2015 1:19 AM
  • FYI...1602 introduces an option for integer-based values in the Compliance setting called "Create the registry value as a REG_DWORD data type if remediated for noncompliant rules.

    Wasn't able to find this in the release notes, though.

    Thanks to Jason Sandys for pointing this one out!

    Monday, May 9, 2016 4:21 PM
  • This may seem obvious, but I tested it anyway.  Yes, your clients must be updated to at least 1602 in addition to the sever(s) before this functionality will work.  An older client will error applying the setting with 0x80041002
    Friday, July 29, 2016 2:54 PM
  • So I'm trying to set a Dword on a 64 bit machine to fix ms15-124.

    Is a qword value of 1 really different from a dword value of 1?

    in this case?

    https://technet.microsoft.com/library/security/MS15-124

    I'm guessing yes..

    Thursday, August 4, 2016 5:47 PM
  • This one works perfectly, thank you
    Tuesday, April 3, 2018 4:07 PM