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.
Answer Summary:
Cancel
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Community Chosen Answer

3
try using HKLM64\SOFTWARE\Microsoft\Windows\CurrentVersion\Run on the 64 bit machines
Answered 03/23/2015 by: SMal.tmcc
Red Belt

  • looks that we all ran into the same problem ;-) (http://www.itninja.com/question/registryvaluereturn-don-t-work-if-registry-key-changes)
  • 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
  • HKLM64 did the trick. Thank You very much

    adding 64 at the end of the other keys works too
Please log in to comment

Answers

2
Answered 03/23/2015 by: SMal.tmcc
Red Belt

  • 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.
    • 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
    • also added my vote.
Please log in to comment
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


Answered 11/23/2015 by: bens401
Orange Senior Belt

Please log in to comment
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


Answered 11/23/2015 by: bens401
Orange Senior Belt

Please log in to comment
Answer this question or Comment on this question for clarity