/bundles/itninjaweb/img/Breadcrumb_cap_w.png
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   [ - ] Hide 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.
Answer this question or Comment on this question for clarity

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

Share