I have some computers scheduled to detect patches one day and then deploy patches the next; once a week. If a deploy fails (fail (80)) and is set for 3 tries, has it already tried 3 times, will it try the next 2 checkins or wait until the schedule the following week? On one computer that had the fail (80) error I was able to run it manually from c:\windows\temp.

0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Answers

0

Looks like it may be an error while detecting patches.  One thing you might want to review is the AV usage.  Per this post I did a while ago:

http://www.itninja.com/question/possible-virus-scan-conflict

I ran into the same thing after upgrading to the 5.3.47173 agents with WinXP SP3 running Eset NOD32 (v3) and Win7 x64 SP1 running Eset NOD32 (v4).  Particularly noticeable during patch runs, although invenories were also slower.  I created exclusions in the AV config for the following directories and things behaved better afterwards. XP C:\Documents and Settings\All Users\Dell\KACE\*.* C:\Program Files\Dell\KACE\*.* Win7 C:\Program Files (x86)\Dell\KACE\*.* C:\ProgramData\Dell\KACE\*.* I also excluded the IP address of my KBOX in the AV's Web access protection section.

If that's not the answer, the next thing I'd look at is how many patches you are including in your Detect list.  If you don't have your patch groups filtered and are scanning for "All Patches" on multiple machines, errors are common due to the number of patches being scanned for.  For a write-up on patch groups, see this post (just disregard the LDAP stuff, unless it might be useful to you):

http://www.itninja.com/question/ldap-patching-sql-reports-using-all-three-for-efficient-managed-patching-and-other-cool-tric

Also, please note that I've changed the smart label strategy I outlined in the LDAP... post.  That approach potentially missed older patches outside of the target date range, required maintenance (updating the date range, etc), and resulted in a good number of inactive patches being downloaded.  I have revised this and currently use the current criteria for my patch smart labels:

Type:  (specify - OS, App)

Operating System:  (specify - i.e. XP SP3, Win7 x64 SP1, etc)

Level:  Critical

Status: Active

Another thing you could do is run a Detect test against a handful of local machines and see if you encounter the same errors.  If they do fine, your setup just may need tweaking (i.e. focused a bit).

Hope that helps!

John

Answered 06/23/2012 by: jverbosk
Red Belt

Please log in to comment
0

I just locked at the file kpatch.out and it says, "puid={0F226BA9-7D79-4FE8-8934-5032B2CF407E}
detect_result=1
error=0
plpFilename=FA9969AB-2663-424E-AFDA-F6DA5856D469.plp"

What does that mean?

Answered 06/21/2012 by: jfrasier
Seventh Degree Black Belt

Please log in to comment
0

I ran into these errors a lot when I was first setting up patching, particularly for machines at branch sites.  Turns out the culprit was network congestion (i.e. KBOX bogged down by client connections during patch runs, patches not making it to clients, connections timing out, etc).  I solved all of these issues by setting up replication shares and now my patching system is running almost flawlessly (aside from infrequent local client issues, i.e. machines that have issues that prevent patches from installing regardless of the method - MS Update site, manual install, etc). 

See if this might help:

http://www.itninja.com/blog/view/patching-via-k1000-slow-lots-of-errors-failures-try-replication-shares

Related:

http://www.itninja.com/blog/view/determining-if-patches-pulled-from-replication-share-or-k1000

Hope that helps!

John

Answered 06/22/2012 by: jverbosk
Red Belt

Please log in to comment
Answer this question or Comment on this question for clarity