/build/static/layout/Breadcrumb_cap_w.png

Patching via K1000 Slow? Lots of Errors/Failures? Try Replication Shares

Please consider this as a follow-up to my earlier "blog" on patching:

LDAP, Patching & SQL Reports - Using All Three For Efficient & Managed Patching (And Other Cool Tricks)

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

Setting up patching as outlined here did work to an extent, but I kept running into a slew of errors, such as "error (Signature Download Failed)", "FAIL (206)" and "FAIL (18)".  There didn't seem to be any strong indication, except that machines in the same site as the K1000 were less likely to fail on patch runs. 

A greater issue was my network slowing to a crawl when a handful of clients would run their assigned patch schedules.  I typically have all of the workstations detect & deploy after hours to mitigate this, however I do separate detect runs and deploy runs during the day for my laptops and remote users, as working hours are the only time they are typically on the network.  Shutting down the K1000 would become necessary after a point, as the number of clients failing patching escalated and more machines choked the network.  Since I'm using the K1000 for lots of other things (including the ticket system), this was not ideal.

Fortunately, I found the answer to both errors and network sluggishness - replication shares.  I suspected that the errors may have been related to machines timing out on downloading patches and eventually throttling the network and/or K1000 in reconnection attempts, so (as a test) tried setting up a replication share at a smaller remote site where most of the machines were failing to patch.  Once the replication share was populated, the clients all patched sucessfully.  Same story for every remote site that has a populated replication share.  At this point, my plan is to *only* use the K1000 as a failover for patching and so far it is working well.

My network is pretty restricted as far as site bandwidth is concerned, so I'm going to copy the replication share folders to a USB drive and send off to the remote sites for initially populating the replication share folder.  But things have been going so well using this approach I thought I'd share my experiences.  As usual, hope this helps someone.

________________________________________

A couple of tips:

* if you are using Windows XP machines for replication shares (as I have to, due to a lack of servers at most remote sites), be sure to assign a label (machine group) with less than 10 computers.  This way the 10-client-connection-limit won't become an issue (although this can be "tweaked" via registry settings, I'm not sure if this is kosher or not - but I'm guessing "not").

* Pre-populate replication shares by copying the replication folder to target machines prior to setting up the replication share on the K1000.  For my really slow sites, I'll be sending a USB key with the files.

* Refer to my post on verifying if clients are pulling patches from the replication share machine or the KBOX:

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

* Refer to my post on creating a report for monitoring free space on replication share machines' targeted drive:

http://www.itninja.com/blog/view/k1000-report-to-list-free-hard-drive-space-on-replication-share-machines-targeted-drives

________________________________________

John

 


Comments

This post is locked
 
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