Since I am merely a user of the KACE K1000, and though there are tons of features that are great with K1000, I owe to you, the potential buyer, or fellow user to list the things that have been an absolute with the box. There are 2 sides to every product. Well, this is the not-so-pretty side of it.
Dell/KACE may or may not choose to take this as constructive criticism.

Now that the reason behind this article is stated, on some annoyances:

Smart Labels:

Level of Credibility: 100% confirmed from testing, and speaking with KACE support.

Perhaps it’s futile to beat a dead horse, but, I cannot bypass this topic in an article title containing “bad and unbearable”
Now before I continue with my gripes,  KACE support will undoubtedly claim that my requests are within a very low percentage of user requests, and most are completely satisfied with the current UI that the K1000 offers for creating smart labels. My opinion? I call BS.

First I’ll state the big problem: Smart Labels in KACE are a great feature, and can help targeting all sorts of different components (machines, patches, assets, software, etc), for this, I praise them. The problem with this, is that in order to group batches of items (be it computer objects, or others), and in order to make these groups viable for something like, patches, or a forced check in , etc … these groups need to be targeting small numbers of machines. Now, let’s say we have about 5000 machines on the network, and divide those (I’m being generous based on KACE’s recommendation of 50 machines to perform a task on) into groups of 200 machines. This is 25 labels right there. Now, create additional labels, based on that same division to target different types of tasks: Let’s face it, your labels are not going to fit every scenario. A label used to group a subnet for patching,  is not going to be the same as a label that targets a lab for software deployment, and not the same labels that target yet another grouping that may be needed for software metering or other tasks.

You get the point. Potentially, especially within a deployment phase, hundreds upon hundreds of hours are needed to create all these one agonizing label at a time. To make matters worse, creating a smart label isn’t as simple as creating the label itself. nope… you have to create an actual regular label, put the description, the type of objects in it, and make it a child of a parent label group, if needed, and THEN, create a smart label, and associate it with the label. Let’s multiply this process by a few hundred labels, coupled with the agonizing process of writing the MySql query code for each and every single one of these labels. Anyone hear an XML import function? CSV import, … ANYTHING….

Of course, this is only one part of the problem. The second part of the problem, is the actual implementation of smart labels. There are only 4 fields in the UI for smart label creation, and the preview of that smart label, only gets database results while creating the label in the UI. Try to veer away from 4 criteria in that query (that’s the limit), and you are stuck creating a complex mySql query, to expand your smart label. Mind you, that MySql query cannot… that’s right, CANNOT be previewed while writing it. (you can potentially do so in MySql Workbench if you like), but then, the results will not be immediately the same in the KBOX because, even though the original preview in the UI gets results directly from the database, the MySql query , after being created, will only populate after a machine checks in at its regularly scheduled interval. That’s right, that means that if I have some 5000 machines on the K1000, my check in interval, cannot be any less than about 3 or 4 hours. This means that each machine, if not forced to check in manually — which, is only recommended for 50 machines at a time — (yup, these would also need labels.. or good luck, adding the machines one at a time), will check in only ever 3 or 4 hours. If the group is supposed to contain some 300 machines, you could potentially be waiting about 24 hours , just to get the full result of a smart label.  So be careful not to make a mistake, or you’ll have to do this all over again …. (Fortunately, the query engine in the KBOX will detect a syntax error, but will definitely not detect a logic error within your query. (i.e criteria grouping, IF statements, etc ..)

with 100 smart labels…

Furthermore, let’s assume that we were going to use the oh-so-convenient UI. What if I want to create a simple query that essentially says something like this:

Select * from MACHINE WHERE ((MACHINE.IP LIKE '192.168.1.%' OR MACHINE.IP LIKE '192.168.1.2%') AND (MACHINE.NAME NOT LIKE 'BOGUS%'))

You got that right! you CANNOT! and even though creating the basic query and editing it in MySql to fix the grouping, that would remove your ability to preview it. Stuck between a rock a hard place…

I plain refuse to believe that 90% of the KBOX users are happy with the current UI. If you know an ounce of MySql syntax, you will know that the above query is nothing out of the ordinary, and even the simplest user would have a need for something like during the course of their use of the K1000.(at least if they’re working with more than a couple hundred computers)

So at this point, I have nothing more to say about smart labels in the K1000 except that they are a big FAIL in their implementation. Just to make sure that this complaint is not timeless, I am writing it as I am running the K1000 version 5.2. 38773.  There are always feature requests, so it is possible that some of these issues are addressed in future releases.

Patching:

Level of Credibility: Based on my own testing. Not yet confirmed with support.

As I was working on implementing patching, I doing some pilot tests on one machine to see how these patch installations will run. I understand that patches need a reboot before additional patches can install.

To my dismay, it looks like any additional patches, after the first reboot, will not re-trigger the patching process  automatically on a particular machine, unless a “Deploy” patch schedule kicks in, that targets this machine.

So now, let’s look at this in the light of a practical example, where a company would have an energy efficiency expert encouraging everyone to turn off their machines when they go home, and, an IT department trying to keep machines up to date with security patches. Sounds familiar, right?

Now, let’s also assume that we convinced our energy efficiency expert, that we need one day a week to be called  “patch day”. Let’s pick Wednesday, after Microsoft’s patch Tuesday.

If I had ran a detect job on all machines, and everything is ready to deploy the patches, I will schedule the groups on Wednesday evening to deploy their patches, and force all machines to reboot whenever needed. Once the machine comes back up, the patching process needs to continue. However, it won’t, unless I re-trigger that patch job targeting that machine that just rebooted. If a machine has some 70 missing patches to remediate, and 4 reboots required in between, I would need at least 1 month of Wednesday all-nighter (even that would probably not be enough), to monitor and track which machines are waiting on a job to start to continue their patching.

Now, I have to disclaim that I am not sure that this is 100% how things are designed to work on the KBOX, as stated in the level of credibility, it is my experience with patching so far.

If that is in fact the case, then, patching is a simple nightmare to maintain, at least until all 5000 machines are 100% under patch control. which, we all know, in the real world, this will never happen, between machines that are failing for one reason or another,  and labs which have are in a frozen state, and others which happen to be constantly turned off on patch Wednesday for whatever reason.

Update: I had a chance to speak with support regarding this, and I was officially told that the patches will automatically continue upon the next agent check-in. However, that process may not start for another 4 , or 5 or 12 hours, depending on your check-in interval on your KBOX. So the patching process is still going to take a while, however, may not be as management intensive I had initially thought.

Level of Credibility: Based on my own testing.

Modifying the MySql code to extent the query on a smart label for a patch group is a nightmare. Some components are more or less simple, or the Impact, or Description. However, try to manually add a an OS criteria, or a language criteria, and you will get lost in the table links, and absurd IDs that you would have to reverse engineer to figure out where they go. Furthermore, if you were excited about having the database schema to help you with building your queries… don’t… the schema is missing quite a few tables. So, it’s either (1) KACE never created a full DB schema, or (2) they didn’t care to share the full schema with the users. Unfortunately, the table links that are required for building your MySql queries for Languages ID, are missing from the schema, I’m referring to KBSYS.PATHCLINK_PACKAGE_LANGUAGE_JT,  for instance.

Just so that I give an example of what a query would like in regards to languages, for instance. The following is a simple (UI Created) query that just choose patches that target Windows, Windows XP and Windows 7. No other criteria at all…. Ready ???


select UID from KBSYS.PATCHLINK_PATCH where
(((
(((1 in (select 1 from KBSYS.PATCHLINK_LST, KBSYS.PATCHLINK_LST_PATCH_JT
where KBSYS.PATCHLINK_PATCH.UID = KBSYS.PATCHLINK_LST_PATCH_JT.PATCHUID
and KBSYS.PATCHLINK_LST_PATCH_JT.LST_ID = KBSYS.PATCHLINK_LST.ID
and KBSYS.PATCHLINK_LST.ID in (201,203,205,204,206,207,208,209,215,217,214,211,212,100,301,303,305,304,306,307,308,309,315,317,314,311,312,101,3,4,6,7,9,17,18,19,20,21,22,23,25,27,28,29,30,31,32,33,34,36,37,38) )) )
and ((1 in (select 1 from KBSYS.PATCHLINK_LST, KBSYS.PATCHLINK_PACKAGE, KBSYS.PATCHLINK_PACKAGE_OS_TYPE_JT
where KBSYS.PATCHLINK_PATCH.UID = KBSYS.PATCHLINK_PACKAGE.PATCHUID
and KBSYS.PATCHLINK_PACKAGE.FILENAME = KBSYS.PATCHLINK_PACKAGE_OS_TYPE_JT.FILENAME
and KBSYS.PATCHLINK_PACKAGE_OS_TYPE_JT.OS_TYPE_ID = KBSYS.PATCHLINK_LST.OS_TYPE_ID
and KBSYS.PATCHLINK_LST.ID in (201,203,205,204,206,207,208,209,215,217,214,211,212,100,301,303,305,304,306,307,308,309,315,317,314,311,312,101,3,4,6,7,9,17,18,19,20,21,22,23,25,27,28,29,30,31,32,33,34,36,37,38) )) )))
OR (((1 in (select 1 from KBSYS.PATCHLINK_LST, KBSYS.PATCHLINK_LST_PATCH_JT
where KBSYS.PATCHLINK_PATCH.UID = KBSYS.PATCHLINK_LST_PATCH_JT.PATCHUID
and KBSYS.PATCHLINK_LST_PATCH_JT.LST_ID = KBSYS.PATCHLINK_LST.ID
and KBSYS.PATCHLINK_LST.ID in (201,203,205,204,206,207,208,209,215,217,214,211,212,100,301,303,305,304,306,307,308,309,315,317,314,311,312,101,32,33,36,38) )) )
and ((1 in (select 1 from KBSYS.PATCHLINK_LST, KBSYS.PATCHLINK_PACKAGE, KBSYS.PATCHLINK_PACKAGE_OS_TYPE_JT
where KBSYS.PATCHLINK_PATCH.UID = KBSYS.PATCHLINK_PACKAGE.PATCHUID
and KBSYS.PATCHLINK_PACKAGE.FILENAME = KBSYS.PATCHLINK_PACKAGE_OS_TYPE_JT.FILENAME
and KBSYS.PATCHLINK_PACKAGE_OS_TYPE_JT.OS_TYPE_ID = KBSYS.PATCHLINK_LST.OS_TYPE_ID
and KBSYS.PATCHLINK_LST.ID in (201,203,205,204,206,207,208,209,215,217,214,211,212,100,301,303,305,304,306,307,308,309,315,317,314,311,312,101,32,33,36,38) )) )))
OR (((1 in (select 1 from KBSYS.PATCHLINK_LST, KBSYS.PATCHLINK_LST_PATCH_JT
where KBSYS.PATCHLINK_PATCH.UID = KBSYS.PATCHLINK_LST_PATCH_JT.PATCHUID
and KBSYS.PATCHLINK_LST_PATCH_JT.LST_ID = KBSYS.PATCHLINK_LST.ID
and KBSYS.PATCHLINK_LST.ID in (201,203,205,204,206,207,208,209,215,217,214,211,212,100,301,303,305,304,306,307,308,309,315,317,314,311,312,101,3,17,23) )) )
and ((1 in (select 1 from KBSYS.PATCHLINK_LST, KBSYS.PATCHLINK_PACKAGE, KBSYS.PATCHLINK_PACKAGE_OS_TYPE_JT
where KBSYS.PATCHLINK_PATCH.UID = KBSYS.PATCHLINK_PACKAGE.PATCHUID
and KBSYS.PATCHLINK_PACKAGE.FILENAME = KBSYS.PATCHLINK_PACKAGE_OS_TYPE_JT.FILENAME
and KBSYS.PATCHLINK_PACKAGE_OS_TYPE_JT.OS_TYPE_ID = KBSYS.PATCHLINK_LST.OS_TYPE_ID
and KBSYS.PATCHLINK_LST.ID in (201,203,205,204,206,207,208,209,215,217,214,211,212,100,301,303,305,304,306,307,308,309,315,317,314,311,312,101,3,17,23) )) )))

Good luck making changes to this one, and adding criteria. Can only imagine what a query that includes some language criteria looks like.

So my warning to you is: If you were to write some custom queries, don’t rely fully on the schema, and instead, use MySql workbench, to reverse engineer the database, and figure out the table relationship. Right, it wasn’t hard enough with the schema available already …

Service Desk:

Level of Credibility: Confirmed from experience and KACE support.

The case of the KACE service desk, is very similar to the Smart Labels problem, with the claim that 90% of customers are completely ok with the out-of-the-box configuration of the service desk.

I have to say, that this part of the KBOX is well under-developed, and required a whole lot of additional UI to make it a viable solution for the regular user.

In working on my implementation, I was trying to create some custom business rules, things like:

  • Change the status of a ticket to “Responded” when a user replies to a ticket  OR
  • Closing a ticket at a user’s request , etc …

These, seemingly simple scenarios, required some pretty complex MySql queries, and UPDATE queries. For a regular user, creating a rule like this, and making a mistake on the Update query, could potentially brick the KBOX database.  There are no real safeguards that I know off to protect the user from making a major mistake.

Another simple scenario:

In the Service Desk, there is a canned rule that sends a user an email informing them of their recently closed ticket, and requests that they fill in the satisfaction survey– (which, by the way, isn’t that customizable either)

That canned rule works without a problem. There is another rule, however, which states that a user should receive a ticket update email, when the status of that ticket is closed. (these are CANNED rules, mind you…so you would think, they should work out of the box).

Well, both of those rules, work well, independently of each other. Now, if both are enabled, and a ticket is closed, the user is going to receive:

  1. An email informing them of the closure of the ticket, and requesting them to fill in the satisfaction survey. (Expected)
  2. An email after that previous closure email, stating that their ticket has been changed from a non-closed status , to closed (WTH!)

Would I want to spam the users with unnecessary emails informing them of the same thing. I could, of course, turn off the rule that notifies the user  that the ticket status has changed, but, then, they will no longer receive ANY ticket status change emails. Well, you would think that there is surely a middle ground for a such a simple –never-should’ve-existed-problem. Right? WRONG!

In order to address this, a completely custom –very complex– MySql query, and update is required to do this. One that, non other than a DBA who does this day in and day out will be able to write. KACE is aware of that, and requires a professional services engagement, to help fix a problem that should’ve never existed. Fair? I think not!

I am out of unbearable items for the time being, but, I haven’t even started Asset management, Software license metering, and Package deployment.

I honestly, am not writing this to bash KACE. I just believe that any potential user of the KBOX needs to be aware of these limitations, which are not apparent when you’re running a trial, simply, because you never get a chance to get into that much detail in 30 days… I feel a little cheated in a way, but I have to cope with the shortcomings, and hope that new versions will remediate some of these big problems.

Have you had any experience with the KBOX 1000? if so, do any of these problems sound familiar, and/or frustrating to you? please share in the comments!

 

 

Print Friendly
Subscribe By Email for Updates.