We are experiencing some strange issues with the K1000.

First problem :

- We publish a script in the end-user portal, which is only available to 'Windows XP computers' (Smart label) and 'Field Technicians' (label). The checkbox "Also restrict by Machine Label" is ticked.

- We publish a second script in the end-user portal, which is only available to 'Windows 7 computers' (Smart label) and 'Field Technicians' (label). The checkbox "Also restrict by Machine Label" is ticked.

- On a Windows XP computer, the first script appears, as it should. The second script does not appear. This is expected behaviour.

- On a Windows 7 computer, the second script appears, as it should. The first script does not appear. This is expected behaviour.

- These 2 tests confirm that when we can display different scripts for users with the "Field Technicians" user label, as they log on to different operating systems. Which is nice.

- Then, we perform a clean Windows 7 installation on the Windows XP computer. We install the KACE Agent on this system. When we look at the inventory, at that moment, a new KACE ID is generated for this system. Is this behaviour by design? Shouldn't it recover its old KACE ID (based on unique characteristics, such as a MAC address or BIOS SN)? Anyway, we could live with this behaviour, and the obsolete record would be scavenged after 30 days anyway... But then this happens:

- The computer still has the same IP and computer name at this moment (but another OS).  The inventory is updated with a "force update" and a "runkbot 4 0" to have the latest information.

- The old record for that computer remains "offline" in the KACE inventory.

- The new record for that computer is "online" with the correct inventory information

- The new record for that computer has the "Windows 7 Computers" smartlabel. It does not have the "Windows XP Computers" smartlabel.

- We log on to the end-user portal, and BOTH scripts appear for this system. According to the filtering, only the 'Win7' script should appear...

Then, we connect the computer to another subnet.

-> The 'XP' script disappears shortly after having run the inventory update

Then, we connect the computer to the original subnet, where it recovers its original IP again.

-> The 'XP' script appears again for this Windows 7 computer.

Then, I decided to delete the duplicate record from the KACE inventory (the same computer, with the same name, but the old KACE ID, and 'Windows XP', which is offline since we reinstalled the system with Windows 7)

After running an inventory update, the 'XP' script disappears for the Windows 7 system. 

So it seems that the software which is displayed in the KACE portal, is not being filtered based on the KACE ID criterium, but also on computername and/or IP? It seems as if KACE merged the information from the "old/deprecated" Windows XP KACE ID (which has the "windows XP computers" smart label only), and the new/current Windows 7 KACE ID for that system (which has the "windows 7 computers" smart label only). 


How do we efficiently avoid these duplicate IDs between OS reinstalls?

I already found this article, which is very interesting: http://www.kace.com/support/resources/kb/article/understanding-and-dealing-with-duplicate-machines-in-inventory

So now I'm running the same test-scenario over again, but this time I activated the "Disable Duplicate Machine Detection" option (ticked the checkbox, contrary to the default value) as recommended in the article. I'm not very optimistic about the results (which I will post here tomorrow), because disabling this option does not sound logical to me.


Then, there is this second minor problem which we also discovered :

- A script is configured in the Scripting tab with "Supported Operating Systems" : Windows 7 Professional x64 SP1. I think this means : only run the script on systems with this operating system.

- We publish this script to the end-user portal for all computers (Windows 7 and Windows XP), just as a test.

- We are able to download & run this script on an XP computer. Is this normal behaviour? I think that's a rather inconsistent behaviour between the scripts which are "pushed" via the Scripting tab in the Admin portal, and the scripts which are downloaded using the end-user portal.



At the same time, we are also still experiencing this issue:


In some aspects, it seems kind of related.

When I put all the pieces together (some big & smaller bugs that we are experiencing, most of them confirmed by Dell + missing features + "workarounds"), I'm feeling less and less confident to really go into production with the K1000 (currently we are still testing the product). I know that the product is still evolving rapidly, but we need a decent product rightnow, and not in a (near?) future.

2 Comments   [ + ] Show Comments


  • machines entries are based on the KUID in the registry not the mac or ip. You need to capture and reapply this KUID to keep the same entry
  • When you log on to the end-user portal on an end-user system, how is the relation between the computer and the KACE ID established? In other words : how does KACE know on which system I'm logged on, so it can display the software that I can access? Is Internet Explorer reading the registry key with the KACE ID?

    I find that _really_ hard to believe. I think that the portal evaluates the IP address that I'm using to establish the connection, to find the corresponding KACE ID in the inventory. This is confirmed by the fact that when I force IE to use our internal proxy server to connect to the KACE appliance, that the portal reports that "no client has been found for IP address <proxy IP>"

    Offcourse : the systems are usually configured to use a DIRECT connection to the appliance, I just wanted to test the behaviour of the portal to determine how it works and what's the cause of these problems.
Please log in to comment

There are no answers at this time


Answer this question or Comment on this question for clarity