/build/static/layout/Breadcrumb_cap_w.png

Trying to set up a Custom Machine Action off a Custom Inventory Rule, and RegistryValueReturn returns "0"

We recently updated to 5.4.70402, and I was really excited to discover the Machine Action feature that was added in.  I have Ninite, Explorer, and RDP working great.

I am trying to add Teamviewer 8 to that list, and to do that, I need to pull the Client ID from the registry.  All of our machines are 64-bit, and when I browse from 32-bit RegEdit, they location is HKLM\SOFTWARE\Wow6432Node\Teamviewer\Version8\ClientID.

Everything seems to be set up correctly.  I created the Custom Inventory item, restricted it to 64-bit Win7, and I'm even getting results from agent check-ins.  The problem is that the resulting value is "0", even though I can manually check the value and see a REG_DWORD, a hex number, and the correct Client ID in parantheses, in decimal.

My understanding is that the agent is 32-bit, and I've played around with the path, trying "HKLM64\SOFTWARE\Teamviewer\Version8" and a few other permutations, but it either can't find the key, or it returns 0.

Anyone know what's up?  I've done simple operations in the registry before, but this 32-bit vs 64-bit stuff is new to me, so feel free to throw out the obvious suggestions in case I missed something.

 

Edit:  Okay, so I tried checking another registry value in the same location.  "LicenseDisplayName" produces the correct value when I change the third parameter from NUMBER to TEXT.  For this reason, I believe HKLM\SOFTWARE\WOW6432Node\TeamViewer\Version8 is the correct path.

However, it does not solve my issue.  Is it possible that I'm getting a value of 0 because it's in hex, or because it's a very large number?  The documentation for RegistryValueReturn lists the data types as "NUMBER", "DATE", or "TEXT", and that NUMBER is specifically an integer, but doesn't put any kind of limit on the value.

Edit 2: The plot thickens.  I have 6 machines running Teamviewer 8 (most are running Teamviewer 7), and three of them are pulling the correct value, while three of them have garbage returns.  It's worth noting that I had to set the last parameter in RegistryValueReturn to TEXT.  The values returned from the error devices appear to be extended ASCII characters.  I would include them, but the forum appears to reinterpret the characters into different symbols when I try to save the page.

One of the error machines is my laptop, the other two are desktops of varying models.  The three working machines are laptops.  Any ideas?  The failed programmer in me is wondering if there is an issue with the data type being used to store the result of the RegistryValueReturn command, but that would be odd to see in a String.


0 Comments   [ + ] Show comments

Answers (2)

Answer Summary:
Posted by: tcdclark 10 years ago
White Belt
1

Just noticed that this issue was still listed as open.  It turned out to be an issue with the KACE agent being out of date.  When we upgraded our K1100 server, we did not realize that it turned off automatic KACE agent updates.

 

Once I updated the agent on the machines in question, the registry key pulled down correctly.

Posted by: AbhayR 11 years ago
Red Belt
0

Try HKLM\Teamviewer\Version8\ClientID


Comments:
  • Both HKLM\Teamviewer\Version8\ClientID and HKLM64\Teamviewer\Version8\ClientID cause the Inventory rule to return zero computers, where there were four before.

    I'm testing using my workstation. Does anyone know if there's a way to kick the agent in the butt and get it to report in faster? - tcdclark 11 years ago
  • Run the command "Kdeploy.exe -ci"from the install directory of the agent to run the Custom Inventory rule - AbhayR 11 years ago
    • Thank you, that will make testing different keys much faster! - tcdclark 11 years ago

Don't be a Stranger!

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

Sign up! or login

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