KACE Product Support

I'm in the middle of this now. The reason we want to use the kbox patching, it covers a lot of the common NON MS stuff. Part of the drive behind this are those critical adobe reader patches coming out. I could just script something and push it out via GPO or Loginscript, but we decided to go with the kbox instead for standardized reporting. One of the things we did not want to have to do, was create 40 different replication shares in the kbox, when I all ready have a MS DFS setup that covers all my physical locations perfectly. I'm currently working with KACE support to help fix some issues around this.

As far as just WSUS vs KBOX, I think the biggest thing for us was the reporting. Our AD is not small, 3-4k computer objects. We have around 10 technicians spread around geographically. We image a LOT of PC's. 20-50 a day on non roll outs. As a result, our AD ends up with a lot of stale objects. This throws the WSUS reporting off quite a bit.

There are a few advantages and disadvantages to each in my opinion.
Obviously WSUS only handles Microsofts patches. Kbox handles other vendors, but sometimes can be slower to release some patches (sometimes, not always). WSUS has some capabilities such as rollup reporting that are not available on KBOX for orgs with multiple independant sites this could be a big deal. KBOX's interface is much simpler for some tasks and a migration to their patch system reduces the number of servers a guy has to maintain. If using KBOX you need to make sure to configure an updating GPO properly so users don't get notifications of thing Microsoft thinks you should have [but have been declined by you in KBOX]. If using WSUS you've probably already done this though.

As I said there are advantages and disadvantages to each- I think each network is a bit different. I'm still on WSUS due to lack of time or pressing need to switch, but will eventually. Functionally, for MS patches, I think both are equal on patching. It's more of an interface preference, and if you need some of the more obscure features only available from WSUS. If you haven't implemented anything, and you have a KBOX it's an easy choice.

60% of Vulnerabilities today come from applications, not the OS. WSUS only care about Microsoft OS. How many users have Adobe reader/Acrobat or firefox? Planning on using just WSUS is like getting a burglar alarm and leaving the back door open.

Also if there is any Mac's in the environment you will want to have something that looks at those.

WSUS is a good option if you dont have dollars to spend but another good option with the KBOX is the OVAL feeds which give you the vulnerability scanning to show you where the vulnerabilities are coming from.

In the past, we've always used KBOX deployment for third party updates/upgrades. It's not as if we only update MS products because we use WSUS. We've decided to stick with WSUS and KBOX Deployments for third-party applications. OVAL is great, but we already have OpenVAS for vulnerability scanning - which is free. OVAL scanning in the KBOX requires the purchase of an add-on module.

I believe the patching mechanism used by KBOX is Patchlink. They perform testing of patches before approving them in their database, so the KBOX patch database may take a few days or even weeks to receive a new patch - based on how long it takes Patchlink to approve the patch in their database.

I'd love to go to KBOX for MS patching, but WSUS works great and we don't care if it blows up (takes no time at all to build a new WSUS server). We patch remote users with our WSUS server in the DMZ... This is really why we aren't using KBOX for patching - we have very important license and other asset information in our database that we do not want exposed to the outside world.

Jiddle -There are multiple resources at kace.com as well as the KKE series; this is also included in the JumpStart training. If you need videos from KKE's please feel free to contact me directly.

My two cents worth: It's not either/or, it's both. Let WSUS handle the Microsoft patches for Windows; let the KBOX handle application patches for Windows and Mac OS X.

Why? Because if you support a few versions of each operating system and have both Macs and PCs, you're going to find the KBOX doesn't have enough physical disk space to store all patches for both. By removing the WSUS-delivered patches (using the feature called Limit Patch Subscription), you eliminate about 85% of the patches, saving a lot of disk space.

To save even more disk space, we're looking into setting up our own Apple Updates server, at which point the K1000 will deliver only application patches to both platforms.

Also, we see a real speed difference: WSUS has always delivered all the patches, to about 1200 machines, with no noticeable slowdowns, on either the clients or the server. Though we have spread machines across multiple KBOX patching schedules, we are struggling with KBOX patching being very slow, bringing clients to a crawl at some times. In my own informal testing, WSUS delivers a set of patches in about 1/10 the time it would take the KBOX to deliver the same patches. Maybe our K1000 is trying to do too many things at once?

We like the fact that the KBOX patches from Lumension have already been tested, so we have more confidence in their deploying correctly. (Despite this, we find a problem every couple of months.) Sande

Interesting to see this thread becoming active, we are currently about to test KACE for server patching. There are some issues with scheduling that isnt ironed out, would be interesting to hear what others think. Ideally we want to have 1 group of test-servers doing the first run of MS patches, then 2-3 groups of prod-servers the consecutive days. Patching during nighttime with automatic tests to

WSUS can be within hours on a Patch Tuesday and patches deployed to the test-group tuesday night, prod-servers ready to be patched wednesday and thursday. This leaves a small time-window of unpatched servers.
With KACE you have to wait for Lumension to do their thing and release the patches, I am not aware of a time requirement when the patches are ready for us after they have been released by the vendor. This makes it more difficult to schedule, one solution is to sync patches every sunday and patch the test-servers sunday night. This increases the time window of unptached servers :(

Any thoughts or best practice out there?

ORIGINAL: snissen

...And if you look for the patch that is supposed to replace each of these, you won't always find one! (In other words, the Superseded field is not always marked correctly.) This is not common, but it does happen from time to time... Sande



Sande,

Howdy, Sande! I don't know if you remember me, but I've worked with you several times, while I was with KACE Support. About the issue you raised above: I believe instances of that happening should be limited to the lag between when a patch is marked as having been superseded, and when the replacement patch actually gets to your KBox (after being vetted by Lumension, etc.). r2

I think KACE has some unique advantages when compared directly to WSUS. Leaving out the 3rd party patching capabilities, you have a lot more flexibility with automating your approvals and deployment strategy for patching. For example, I have about 6 distinct regions that range from our test group all the way up through our production environment. The test group gets patches nearly immediately, and the production environment patches roughly once/month. With KACE, I can have different patching schedules for each of my regions that are in compliance with our patching policy that require little to no intervention on my part. I hope this helps.

I think KACE has some unique advantages when compared directly to WSUS. Leaving out the 3rd party patching capabilities, you have a lot more flexibility with automating your approvals and deployment strategy for patching. For example, I have about 6 distinct regions that range from our test group all the way up through our production environment. The test group gets patches nearly immediately, and the production environment patches roughly once/month. With KACE, I can have different patching schedules for each of my regions that are in compliance with our patching policy that require little to no intervention on my part. I hope this helps.

We use WSUS for Microsoft PC patching for historical reasons. We use KBOX for Mac patching (not Adobe) and PC third party software patching like Adobe (Reader, Flash and Shockwave), and Firefox.

We have stayed with WSUS, it works great in our environment as well. We tried using kbox patching for other products but were quickly turned off due to the fact that the products still looked at the vendor for updates. If Kbox patched software and automatically disabled its auto update then we would use this... We don't want to have to follow up on everything and turn the updater off. We just use deployment to update software.

dtuttle

I understand what you're saying. We ran into the same situation. Like Adobe Reader - we wanted reader to be updated automatically by KACE, but have it's updater and other junk turned off. So, what we do is allow KACE to install the full blown Reader version then allow KACE to turn off that junk either via MI or Scripting. We do this because even if we download Reader and customize it, some user will download it themselves and install the full blown version and all it's junk. At least with the scripts or MI KACE can search (with labels and filters)for the version and remediate the application. It works like a charm - hardly any touching or hand-holding.

Hope this helps,
Dave

I would love to see your scripts and MIs to remove the Reader extra baggage!

Thank you for all of the input everyone! We're going to stick with WSUS for now since we don't want to throw our KBOX into the DMZ to allow for remote updating on the internet - our WSUS server, on the other hand, already resides in the DMZ and there is no risk of exposing our inventory/help desk/asset data to the world.

After some testing we did we found that for a new XP SP3 machine, WSUS discovered 62 patches, while the KBOX discovered 58..

Digging into these we discovered that the 4 other patches were actually listed in the KBOX s application patches as they were linked to Outlook Express, IE 8, Flash player and Dot net 1.1. We didn't have application patching turned on so they didn't show up as active.

It took only 21 minutes and a single reboot to use WSUS and took 24 minutes with a single reboot for the KBOX to complete its patch cycle. The KBOX does do a patch verify cycle to make sure the patches have actually been applied.

The KBOX uses a fingerprint profile scan to verify that patches have been applied correctly which could account for the extra time. These tests were done on virtual machines so may vary in speeds compared to actual clients...

Well, before the KBox, we relied on good old Microsoft updates and end users to install patches and such. We never used WSUS. Needless to say, security was pretty bad on PCs. Yeah I know that sounds horrible but before I started here a year ago, there was only three guys in the IT department (Manger, Assistant manager, and the VoIP guy). They were defiantly undermanned as we still are. This is the reason we bought the KBox.

I have not had any problems with the KBox patching other then it being setup wrong initially. Every patch was set to go into a certain label. We were unaware of this and clicked on the box that said to download software installers. When the software installers downloaded, it actually put them in the label that we were using to deploy patches every Saturday. Well, when we came in Monday morning, every computer in the building had six different versions of Adobe, Citrix, Shockwave, Novell, iTunes, Firefox, Safari, VMware, and QuickTime installed on them. That was a nightmare! I turned off patching and started from scratch again because at the time we did not know why it did that. I will say however, good did come out of it. I really got to get my feet wet in scripting. I spent an entire week making uninstall scripts trying to uninstall all of that software. Therefore, in the end, it was a great learning experience and now I am pretty familiar with the scripting aspect of the KBox.

Other than that, I would have to say using the patching feature has really helped us out and we have not had any problems with it. The nice thing is that not only does it patch Microsoft software but it also patches other applications as well. With our small IT department, we do not have time to patch software. We did notice the other day that the KBox was not patching all the Microsoft vulnerabilities. It was showing completed while the Microsoft update still showed patches that needed to be installed. I am unsure why but that will be another project in the near future. We are just happy to get some patches out to the PCs.

The KBOX patch feed uses Lumensions (previously Patchlink) feed and prioritizes Microsoft critical security patches, and then critical security patches from other vendors - these should not now take more than a week to appear on a KBOX. Less critical security updates may take longer depending on the current volume of patch releases.

You know what they say "If it aint broke, don't fix it!"

Patching third party apps like Adobe Reader, Flash, Shockwave, Firefox, Quicktime, iTunes, Safari and all Macintosh patches are a breeze with KBOX once configured. Adobe patches on the Mac aren't quite right yet though.

I'm hoping Firefox 3.6 (PC) is included in tonight's download since our monthly day to push patches is tomorrow (February 5). It was released to the public January 21st, 2010 (http://www.mozilla.com/en-US/firefox/3.6/releasenotes/).

That's more than two weeks ago and it's still not in KBOX.

We're trying to transition from using WSUS to KBOX. It's not pleasant. I keep finding patches that don't deploy for some reason. For example, I just detected/deployed patches to a laptop yesterday. After it completed, fourteen patches remained 'NOTPATCHED'. I detected/deployed again, but they were still unpatched. I then patched using Windows Update. Now, after running detect/deploy again, only 3 remain unpatched. I don't understand why KBOX doesn't always deploy the patches. It seems very inconsistent. We may have to stick with WSUS for MS and KBOX for everything else. I'll keep investigating.

It would be nice if I could just pick up the phone and talk to someone at KACE, but it seem I always end up being asked to leave a message to create a ticket. Troubleshooting via email is very slow. I get a message from them, then I respond and it's at least the next day before I hear back from them. That's way too slow to resolve any issues. Dissappointing. Methinks KACE needs more tech support reps.

I have the same issue with our patches. It seems like the KBox does not deploy all the given patches like it should. We will run a detect/deploy multiple times and there will still be seven or so patches unpatched. When I look up the patches, they are not new ones. Some of them have been available to a year or longer. Not sure why this is doing this, but it beats not having, any patches installed. I just don’t have time to investigate why this is happening right now.

Also, you can submit a ticket and request Kace support to call you back. I have talked to Kace multiple times to solve issues. If I wasn’t around my phone, they would leave a voicemail with a number to call them back on. When I did, someone always answer for me. If the tech person was busy, he would call me right back.

Has anyone found a good tutorial for setting up Windows updates using the KBOX?

I'd like to add to this discussion. We like many of you had deployed our K1100 and expected it to take over 100% of our patching. We had everything going well until just recently when we started to notice things just weren't patching when it came to Microsoft patching. We had disabled our group policy for WSUS and were relying completely on KACE.

After a good bit of time with KACE Support. We finally found out that KACE does NOT patch any Microsoft patch that Lumensions/Patchlink considers non-critical. This is a complete and utter fail in my book. Especially based on the sales pitch we got about KACE Patch management.

I honestly think for complete patching something like Shavlik, is a better option considering they do patch everything.

Just curious if anyone else has similar opinions.

I guess my problem with that is that it's actually going to cause more administrative work than less, which is the goal of the KACE system. Now we would have to approve patches on 2 separate systems rather than on a single platform, supporting multiple platforms is never a good option with a small IT staff like ours. It'd also be nice to know this up front rather than the KACE sales team saying 'it'll do all your patches for you'.

I do agree with you that our short term solution is to use WSUS for Microsoft updates and KBOX for Adobe/Java/etc... updates. But I think the ultimate solution will be to drop the KBOX completely for a solution that's more complete. I've actually already been in contact with our Dell rep and KACE 'specialist' who doesn't seem to think this should be the case. But I've assured them this is what I was told. I'll also point them to this thread.

You're right in that there's some administration in two different environments, but each patch appears in only one of the environments, so we never touch any patch twice.

As for approvals, we're using a lot of automatic approvals. On our WSUS server, all critical and security patches are automatically approved, so I never have to touch those. I only have to approve the recommended patches, and that only once a month, on Patch Tuesday.

On our K1000 server, we do not individually review and approve patches--we just take them as they are. That's why the Lumension testing is so important. We find we only need to fiddle about once every few months, when one of the Lumension patches causes a problem (example: Adobe Shockwave on Mac OS X) and we need to disable it.

Trusting souls, aren't we? Sande

I am also after videos on how to add Microsoft patches as postinstallation task. The boys in the helpdesk connect to Windows Updates website for each machine they build which does not make sense to me.

Not sure whether the way round is to download all updates and create a batch file calling the updates with /passive /noreboot switches

Any help is much appreciated

I think we will try to use K1000 for patching clients and servers, the latest client seems a lot more stable. Also the time window when patches are available seems to be max 1-2 days, guess Dell had a few words. K1000 is a lot easier to work with, nicer reporting and configuration is easier than WSUS. We will use it for a bit and see if any critical MS patches have been stopped, then re-consider if we should use WSUS as a fallback or switch back to it.
One alternative is to run K1000 for patching and then have WSUS as a backup for any patches K1000 misses. Nasty and double-config, but possible.

I am betwixt and between ... wavering ... but almost ready to pull the plug on using the KBOX for Windows patching. Am considering moving back to WSUS and only using the KBOX to patch non-Microsoft products.

stephen.frost,

Can you elaborate on your reasons for potentially abandoning MS patching via your KBox? r2

ORIGINAL: ronco

stephen.frost,

Can you elaborate on your reasons for potentially abandoning MS patching via your KBox?  r2



One of my reasons for being sceptical is that Dell/Lumensions decides which patches is available and when. There is no fixed timeline for when a critical patch is available, or that it even will be available. In the past Dell/Lumensions have decided to not make a critical MS patch available with no real explanation.
This process is not open and transparent and the only reason I trust it (for now) is because of the Dell name.

we keep wsus, however we are using KACE to do targetted patching. Examples

adobe reader
Java

are updated via KACE. To disable autoupdating of these applications we push reg keys via GPO to client machines as well. We don't want adobe looking to the manufacturer every 1 month or so.

Our setup

1 - install adobe with a MI
2 - disable the autoupdates with Group policy
3 - use patch schedules to update the versions of this software when kace downloads them.

this allows us to get around the no users being local admin problems.

ORIGINAL: ronco

stephen.frost,

Can you elaborate on your reasons for potentially abandoning MS patching via your KBox?  r2



http://itninja.com/question/wrapping-an-.exe271

Interesting posts. We too are feeling the incredible burn of the Dell Sales pitch.
So this was the plan. Get this product setup and managing our systems, imaging, ect. Then we would have time to call DELL back and do a big DELL VMWare Infrastructure build…After all, KACE was going to free up extra time. Our plan now…Well, my manager will not allow me to call DELL. Have to call someone other than DELL for the VMWare project. If we ever find time to begin moving forward again.

Our intent was to use the system to perform all patching (MAC, Windows, and Apps). After downloading just the patches for Windows and Apps, we found out about the space problem. Now we’re finding out about the slowness. And we already knew about the Support problems. Not the answer to all problems that we were sold on. And the simple to use interface…Well, WSUS seemed to be pretty simple and can be set up in a day. How different can KACE be? I’ve been struggling with this for several days and it’s just been disappointing.

We will have to continue to use WSUS (simple, and simply works) for windows, and only use KACE for apps. We will use KACE to perform “patch catch-up” after all scripted installations. We can just leave it overnight, then let WSUS take care of missed patches later. We may also use KACE to report un-patched systems…not sure yet. There is no way this agent will be placed on the servers. Which removes another intended use.

I really want to like KACE, but at the moment, I’m very far from it…but trying.

Sorry for the negative post, but all of the sudden I didn’t feel alone, and was compelled to share.

To all in the thread,

I can offer a LOT of help with the patch disk space problem. Patch Smart Labels can be configured (and added to your Subscription Settings page) to cut out an absolute metric ton of patches that you don't actually need. Also, don't forget that we have two weekly KACE Kontinuing Education sessions. They are all recorded and posted on our KKE site for you to review, if you are unable to make it to the live presentation. We have several on patching, both past recorded sessions and upcoming live ones. r2

Yeah, we tried using labels to filter out un-needed patches. Here is the problem with that as I understand it. We are in the beginning stages of rolling out the agent. As those systems begin checking in, how can you predict what software they have installed?
After all systems have checked in, and a task ran against them to detect needed patches, then labels become an option.
In our case, we are not replacing an established patching system. We were depending on KACE to get us where we need to be. That may still be the case, but we will have to contend space issues until all systems are properly managed.
I would be great if KACE had something like a definition file defining all patches that patchlink knows about and can manage. Use that definition file for detection purposes. At that point, then you could use that information to build an intelligent labeling system to begin downloading patches.
If you know of a way to achieve that, I would LOVE to hear it.

I don't understand how to use labels to only download certain patches.

I deleted our entire patch database all 120Gb of it, then while testing I wanted to just have it download ONLY adobe patches, nothing else. The trouble is if you wipe the database and try and make a patch label, you can't actually filter any patches because there is no patches to filter on....

we ended up just downloading all 120Gb worth of patches. Probably not the best solution but it works. I don't want to download MS patches, because we have wsus for that already.

Also, how does the system determine what 'unused patches' are? on the patch settings screen there is 'delete unused patches' what does 'unused' mean and how is that determined?

dogfish182,

On the Security > Patching > Subscription Settings page, you can UN-check the Hide Disabled Patches on Patch Listing setting. Then, it doesn't matter if you have patches downloaded or not - you'll be able to "test" your patch labels as you build them. Delete Unused Patches is a combination of a few patch states. The largest quantity, though, is unsubscribed patches. For instance, if you unsubscribe from an OS on the Security > Patching > Subscription Settings, all of that OS's patches you've already downloaded will then be "unused", and you can delete them.

What Adobe apps (and versions!) do you need to patch? I'd be happy to tell you what criteria I'd use to build the patch label. r2

I leave it to ronco to provide support for your specific label(s) to limit patch subscriptions. I do strongly advise you to work with KACE support on this, because it's easy to mess it up.

I will note two things we learned:

1) Do not have any logic in your patch subscription queries about the Active/Inactive/Disabled status of the patches. It won't work.

2) Be very careful in your patch subscription queries about using the Superseded status of patches. If you use Advanced Search under Patch Listing, you will find there are patches marked Superseded that are still Active. And if you look for the patch that is supposed to replace each of these, you won't always find one! (In other words, the Superseded field is not always marked correctly.) This is not common, but it does happen from time to time. The result is, if you eliminate Superseded patches from your subscription, you may occasionally miss a patch. We encountered this first with Adobe Flash Player 10 patches for Windows. Sande

I would NOT use KACE for server patching. If a client machine reboots unexpectedly or something, eh, it'll just be hurt feelings. With the KACE track record of agent problems, you couldn't pay me enough to let KACE do server side patches. Also doesn't make much sense anyway, if you want complete patching of the systems to be done rather than just critical patches.

I want to reiterate that. KACE will not patch anything that Lumension does not consider critical.

Outside of this one area, KACE is a great product, but this patch ordeal has put an extremely bad taste in my mouth.