I have recently created a custom inventory rules entry using the RegistryKeyExists and RegistryValueReturn functions. These are working fine on x86 clients (Windows XP SP3, Vista Enterprise SP2 x86, and Windows 7 Enterprise x86. They are not reporting anything for x64 clients.

Here is an example of the two rules:
RegistryKeyExists(HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Symantec Endpoint Protection\SMC\SYLINK\SyLink)
RegistryValueReturn(HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Symantec Endpoint Protection\SMC\SYLINK\SyLink,CurrentGroup,TEXT)

We just updated to KBOX 5.3.53053 on the server and agent version 5.3.53177. We were having the same issue with the earlier 5.3.47927 server/5.3.47657 client combination.

We have a few other custom rules which are also exhibiting the same behavior. I have NOT selected any OS's in the 'Supported Operating Systems' dialog box. I was going to try that if the rule didn't work at all. Just found it odd that it's the 64-bit OS's which are being a pain.
Answer Summary:
Cancel
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
64 bit machines redirect their software entries to the WOW6432NODE.

I think this might be tripping you up.
Answered 02/22/2012 by: dchristian
Red Belt

Please log in to comment
0
32-bit software keys are in HKLM\SOFTWARE\Wow6432Node on 64-bit systems. You'll need to change your rules to something like this:

RegistryKeyExists(HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Symantec Endpoint Protection\SMC\SYLINK\SyLink) OR RegistryKeyExists(HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Symantec\Symantec Endpoint Protection\SMC\SYLINK\SyLink)
Answered 02/22/2012 by: airwolf
Tenth Degree Black Belt

Please log in to comment
0
I'm experiencing this across ALL operating systems. The bug ID for this issue is K1-8544
Answered 02/22/2012 by: LanhamA
Yellow Belt

Please log in to comment
0
Well there you go.

3 response in 30 seconds, not too bad gentleman.
Answered 02/22/2012 by: dchristian
Red Belt

Please log in to comment
0
ORIGINAL: LanhamA

I'm experiencing this across ALL operating systems. The bug ID for this issue is K1-8544

I don't think this is quite the same thing. Custom inventory rules work how you program them. There may be a bug related to detection of software on 64-bit systems, but that isn't directly related to this particular issue.
Answered 02/22/2012 by: airwolf
Tenth Degree Black Belt

Please log in to comment
0
Are you deploying the x64 version of Symantec?

I ask because the current kbox agent is 32-bit, and seems to have trouble pulling x64 registry values. I needed the x64 values because they relate to our printer drivers, so I spoke with support about it, and the suggestion that had was to use:

ShellCommandTextReturn("c:\windows\sysnative\reg.exe query HKLM\Software\Xerox\PrinterDriver\V5.0\Configuration /v RepositoryUNCPath")

Which was successful.

Casey
Answered 02/22/2012 by: cmccracken
Orange Senior Belt

Please log in to comment
0
EDIT: Nevermind, I misunderstood previous poster.
Answered 02/22/2012 by: airwolf
Tenth Degree Black Belt

Please log in to comment
0
If I open regedit and check under Wow6432Node Xerox doesn't have an entry.

I could be wrong, but based on http://support.microsoft.com/kb/896459 and the blurb:

"32-bit programs run in WOW64 mode and access keys and values that are stored in the following registry sub key:

HKEY_LOCAL_MACHINE\Software\WOW6432node"

my interpretation has been that if a 32 bit program (such as the kbox agent) accesses the registry its entries will be under WOW6432node. However, if a true 64 bit program is installed it will use the "regular" registry. The catch comes when a 32 bit program tries to access a 64 bit entry. The 32 bit program can't "escape" WOW64, so it can't get to any of the 64 bit entries.

Casey
Answered 02/22/2012 by: cmccracken
Orange Senior Belt

Please log in to comment
0
Casey, I misunderstood your post and edited my response accordingly. If the agent isn't picking up 64-bit entries in a 64-bit registry, then that is most certainly a bug.
Answered 02/22/2012 by: airwolf
Tenth Degree Black Belt

Please log in to comment
0
Casey,

We are using the separate x86 and x64 versions of Symantec Endpoint Protection 11.0.6300. It appears that the particular value I am wanting to read 'CurrentGroup' is not present in the WOW6432Node section of the registry. I'm going to try your suggestion to create a separate x64 variant of this CustomInventory rule to use the ShellCommandTextReturn option to query the native 64-bit portion of the registry....fingers crossed.

JBC
Answered 02/22/2012 by: joncutler
Blue Belt

Please log in to comment
0
So you are running the x86 version on x86 systems only, and the x64 version on x64 systems only? If so, I believe you are in the same boat as Casey - and you guys are both affected by the bug.

I apologize. I misunderstood your original post as the more common issue of x86 entries on an x64 system.
Answered 02/22/2012 by: airwolf
Tenth Degree Black Belt

Please log in to comment
0
OK, the plot thickens: I can run the following command in a CMD.exe window on an x64 client:

[font="Courier New"]reg query "HKLM\SOFTWARE\Symantec\Symantec Endpoint Protection\SMC\SYLINK\SyLink" /v CurrentGroup

Which produces the following output:
[font="Courier New"]
HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Symantec Endpoint Protection\SMC\SYLINK\SyLink
CurrentGroup REG_SZ My Company\Test-Fac-Staff

But when I use the command on the KBOX in the following Custom Inventory rule:
[font="Courier New"]ShellCommandTextReturn("c:\windows\sysWOW64\reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Symantec\Symantec Endpoint Protection\SMC\SYLINK\SyLink" /v CurrentGroup)

...the only resulting clients are Apple iMac (Mac OS) clients...really strange, I know.

The particular Symantec Endpoint Protection (SEP) registry value I am trying to read is apparently not mirrored/stored in the HKEY_LOCAL_MACHINE\Software\WOW6432node branch of the registry. (For those of you familiar with SEP that would be as follows:

[font="Courier New"]HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Symantec\Symantec Endpoint Protection\SMC
...there is no Sylink\Sylink /v CurrentGroup portion.

I may have to go back to the whiteboard and come up with another way to ask the question(s) thru KACE Custom Inventory:
1) Is this client a Symantec Endpoint Protection (SEP) managed client (that answer is 'yes' if they have a 'CurrentGroup' value in the /Sylink branch of the registry; and
2) WHAT SEPM (management console) group is the client currently assigned to? (this is the value data typically stored in the 'CurrentGroup' value).
Answered 02/22/2012 by: joncutler
Blue Belt

Please log in to comment
0
Hey Jon,

You can emulate what the KBOX is doing by opening up a 32 bit command prompt (C:\Windows\SysWOW64\cmd.exe) and executing your reg query command. I had to do something similar to create a MI that would set registry values for x64.

I just tried out C:\Windows\sysWOW64 vs C:\Windows\sysnative and for me, sysnative returned the value I expected, but sysWOW64 reported it couldn't find the specified key.

Casey
Answered 02/22/2012 by: cmccracken
Orange Senior Belt

Please log in to comment
0

Try calling the command interperter explicitly instead of implicitly as you have in the past as per this article. 

 

http://www.kace.com/support/resources/kb/solutiondetail?sol=SOL114642

Answered 10/08/2013 by: jdornan
Red Belt

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