After being told the same thing again and again, Turn patch management off. Turn it back on again.
I decided to dig deeper into what the actual problem with Patch Management was. (Well, at least what problems I was having)

After some testing I was able to trace the problem back to the Contend Delivery Network (CDN) used by the LanGuard to distribute the updates.

So when lnsupdate.gfi.com gets resolved it actually points multiple IP’s, but only 1 of those IP’s are actually used.

Pinging cdn.software.gfi.com.c.footprint.net [8.253.43.126] with 32 bytes of data:

So all subsequent lookups will point to that same IP until the DNS cache times out.

Non-authoritative answer:
Name:    cdn.software.gfi.com.c.footprint.net
Addresses:  8.254.246.254
          8.12.217.126
          8.26.198.253
Aliases:  lnsupdate.gfi.com

But if we look at all the possible IP’s we have got then we start to build a list of servers that are supposed to be serving the LanGuard Updates.
The built in LanGuard Updater will follow the same as the ping and just use whichever server it happens to resolve to first, but if the file is unavailable or there is transit issues routing to that IP then the updates will never be downloaded. Also, when you add a Site-Concentrator into the mix that can cause issues if the wrong/corrupt files are cached.

During my research I found the list of files required by LanGuard and how to verify them.
Combined this with some crafty HTTP requests I was able to write an updater that queries each of the CDN servers for the file and find’s one that is up to date and can actually connect to. Once its verified all the hashes it runs the Updater to process the downloaded updates.

Download Here

Please note: This is not an Official tool and will no way be supported by GFI or LogicNow. Use at your own risk!.

This has fixed the issue on a number of machines for me, so give it a try and let me know how it goes for you.

As always, if you would like to buy me a beer you can do so using this link.