/build/static/layout/Breadcrumb_cap_w.png

KACE Not Detecting Registry values

I am trying to write a script to detect a registry value and if it does run a batch file to change that registry values along with few others.   Unfortunately no matter how I search for the registry value it comes back with an error code saying it does not exist.

This is Windows 7 x64 for the most part but I do have some 32bit clients I would run this on too.

I currently have it set to look for a registry pattern with the following parameters

Verify
1. Verify a registry pattern match...
    Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
    Name: IgfxTray
    Value: C:\Windows\system32\igfxtray.exe
    Match: value

The Output log returns this

Running as: SYSTEM
Checking if registry 'value' matches pattern 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run!IgfxTray' = 'C:\Windows\system32\igfxtray.exe' did not succeed: (0)

I have also tried running as the local Administrator account and also as my domain account which is an admin.

KBOX is running the latest software build (6.3) and the clients are on the latest agent.    The value is a REG_SZ value and not a DWORD so I am not sure if that even matters.

0 Comments   [ + ] Show comments

Answers (4)

Answer Summary:
Posted by: SMal.tmcc 9 years ago
Red Belt
7
try using HKLM64\SOFTWARE\Microsoft\Windows\CurrentVersion\Run on the 64 bit machines

Comments:
  • looks that we all ran into the same problem ;-) (http://www.itninja.com/question/registryvaluereturn-don-t-work-if-registry-key-changes) - aragorn.2003 9 years ago
  • Thank You. I will try that as it sounds like it might work. I searched for related issues but came up empty. If it solves it I will mark this answered - bwilkerson 9 years ago
  • HKLM64 did the trick. Thank You very much

    adding 64 at the end of the other keys works too - bwilkerson 9 years ago
Posted by: SMal.tmcc 9 years ago
Red Belt
2

Comments:
  • I added my vote. It seems silly that they do not have a 64bit agent. Maybe my perception is wrong but most have moved onto the 64bit OSes as their primary OS. I think I have about 40 32bit machines left in my lot of 1100 or so and that is only because the school refuses on upgrading an old 16bit app designed for Windows98 in one of the computer labs. - bwilkerson 9 years ago
    • yea and the trouble is the client is 32 bit so calls are redirected by the OS to the client native 32 bit areas on the machine syswow64 in the registry and syswow6432node exe's for the file system. that is why MS added the hidden "sysnative" call to the file system. Google "sysnative" for more of why this occurs. http://www.samlogic.net/articles/sysnative-folder-64-bit-windows.htm. https://msdn.microsoft.com/en-us/library/windows/desktop/aa384187%28v=vs.85%29.aspx - SMal.tmcc 9 years ago
    • also added my vote. - aragorn.2003 9 years ago
Posted by: bens401 9 years ago
Purple Belt
0
I figured this out for my use case. I have a online kscript that checks the value of 1 registry key, if it's zero change it to 1, then runs a command to open a program with a switch. This wasn't working because I only have 64-bit Windows 7 Pro machines, no 32bit, so the script was failing on accessing the 64-bit registry.

I was working on a DDPE/Kace integration problem and came across the script in Kace server 6.4 called “K1000 Enable Detailed DDPE Inventory (Windows)”. It’s a script that checks the registry and makes a change if needed. To do this on 64-bit machines it does the following first:

# Relaunch ourselves on native PowerShell if we are in WoW64

if ($PSHOME -like "*syswow64*") {

    Write-Output "Relaunching"

    & (Join-Path ($PSHOME -replace "syswow64", "sysnative") powershell.exe) `

        -File $Script:MyInvocation.MyCommand.Path `

        @args

    Exit

}


So I added this to the beginning of my script, and it worked on a 64-bit machine. Here’s my full script now which is a dependency of an online kscript. Attached is a screenshot of the first and only line of my online kscript which uses the below powershell script as a dependency.


if ($PSHOME -like "*syswow64*") {

    Write-Output "Relaunching"

    & (Join-Path ($PSHOME -replace "syswow64", "sysnative") powershell.exe) `

        -File $Script:MyInvocation.MyCommand.Path `

        @args

    Exit

}

$userops = Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\OfficeSoftwareProtectionPlatform' -Name 'UserOperations'

if($userops.UserOperations -eq 0)

{

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\OfficeSoftwareProtectionPlatform' -Name 'UserOperations' -value 1

Get-Date > C:\userops.txt

echo "`nThe MS Office reg key was originally zero, it was changed to one:`nHKLM:\SOFTWARE\Microsoft\OfficeSoftwareProtectionPlatform\UserOperations" >> C:\userops.txt

cmd.exe /C 'C:\Program Files\Common Files\Microsoft Shared\OFFICE14\osaui.exe' /f

}

else {out-null}


-Ben


Posted by: bens401 9 years ago
Purple Belt
0
I figured this out for my use case. I have a online kscript that checks the value of 1 registry key, if it's zero change it to 1, then runs a command to open a program with a switch. This wasn't working because I only have 64-bit Windows 7 Pro machines, no 32bit, so the script was failing on accessing the 64-bit registry.

I was working on a DDPE/Kace integration problem and came across the script in Kace server 6.4 called “K1000 Enable Detailed DDPE Inventory (Windows)”. It’s a script that checks the registry and makes a change if needed. To do this on 64-bit machines it does the following first:

# Relaunch ourselves on native PowerShell if we are in WoW64

if ($PSHOME -like "*syswow64*") {

    Write-Output "Relaunching"

    & (Join-Path ($PSHOME -replace "syswow64", "sysnative") powershell.exe) `

        -File $Script:MyInvocation.MyCommand.Path `

        @args

    Exit

}


So I added this to the beginning of my script, and it worked on a 64-bit machine. Here’s my full script now which is a dependency of an online kscript. Attached is a screenshot of the first and only line of my online kscript which uses the below powershell script as a dependency.


if ($PSHOME -like "*syswow64*") {

    Write-Output "Relaunching"

    & (Join-Path ($PSHOME -replace "syswow64", "sysnative") powershell.exe) `

        -File $Script:MyInvocation.MyCommand.Path `

        @args

    Exit

}

$userops = Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\OfficeSoftwareProtectionPlatform' -Name 'UserOperations'

if($userops.UserOperations -eq 0)

{

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\OfficeSoftwareProtectionPlatform' -Name 'UserOperations' -value 1

Get-Date > C:\userops.txt

echo "`nThe MS Office reg key was originally zero, it was changed to one:`nHKLM:\SOFTWARE\Microsoft\OfficeSoftwareProtectionPlatform\UserOperations" >> C:\userops.txt

cmd.exe /C 'C:\Program Files\Common Files\Microsoft Shared\OFFICE14\osaui.exe' /f

}

else {out-null}


-Ben


Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

View more:

Share

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ