Two of our customers were sharing the same problem, which we solved meanwhile.
As I could imagine that others will face the same problem, here is what happened and how we solved it.
Symtoms:
- Definitions on some clients located on remote offices using GUPs did not get updated.
- Customers at remote locations moan about slower VPN link to headquater as usual.
Investigation:
By analyzing router monitoring we found out that massive SEP related downloads took place between GUPs on remote offices and SEPM server on headquater which never end.
The clients which did not get updated definitions on remote offices were those not running every day.
The "SharedUpdates" folder of the GUPs show a content file named "#content#<guid>#<number>#Full!zip. This file first was only a few bytes large, only containing a HTTP header. Then after about half an hour it suddenly grows to about 520 MB in size. Then a short time later the file disappeared. This procedure was repeated endless.
Our Assumtion:
As we were running the GUPs with default settings which include a cache size of 500 MB, the downloaded content file was deleted by the GUP's cleanup process as it's size was larger (520 MB) than that thresold, before the client was able to fetch the update. When the client then reconnects to fetch the update it was gone meanwhile and the whole procedure restarts, leading to endless GBs of useless downloads, which never lead to a successful definition update. Maybe in earlier days the full.zip content file was smaller that 500 MB and so it worked with the SEPM default values but it grows over time and stopped working.
How we fixed it:
Plain simple we changed the default and raised the GUPs cache size above the size of the full.zip and the problems dissapeared.
So be warned if you are running GUP with default settings as they seem to no longer work correctly.
If you have any comments or questions please let me know.