Version 3160 of Patches for Windows ended up getting published without any of the usual fxf files associated with that site. This means deployments that gathered this version won’t see any Patches for Windows Fixlets in their deployments.
Version 3161 of Patches for Windows is being propagated right now and should be out in the world shortly that should resolve this problem.
We’re currently investigating the root cause of this incident. As soon as we know more we’ll update this post.
Version of 3161 just got published. It should have all of the Enterprise Security content restored.
Showing fixlets again with 3161. Is there going to be the normal release announcement (assuming there was changes)?
Worked with manual gather as well, crushing the system though, fillDB maxed out. Possibly it does that every time, maybe I just done notice it?
@patchingout we’ll do a normal announcement of what changed in the original 3160 version of Enterprise Security. Right now we’re working on the Out of Band Microsoft security release, so I think we’ll just do one announcement that covers all of it (we’ll point out specifically the stuff that was in 3160 though)…
Was hoping this release would include those. Thanks for the updates.
It is likely that the removal of the fixlets and then being added back in caused clients to reevaluate everything, which would have caused a one time report of larger than normal size from every client. Not as bad as a full report, but much bigger than would normally occur from a patch release. It would also cause a one time longer evaluation loop for the client than normal. This would not likely cause a flood of reports from clients that are relying on command polling because those would be spread out over time nicely, but those that do get UDP notifications of changes would all get the change quickly, and end up sending up their larger than normal reports around a similar time, so in some ways this means bigfix is working too well to notify of changes on the relay and client side. You can limit the speed at which UDP goes out from the relays which would help with this a bit.
Same goes for the traffic from Relays to Clients. Preceding the reports mentioned above, there would have been a 1 time update of site content to the clients that was bigger than normal, which might be noticeable in network traffic from Relays to Clients, but the situations where this traffic is most likely to have impact is situations in which UDP doesn’t work because there is too much distance between Relay and Client, in which case command polling or gather interval would have spread this load out over time enough to help mitigate potential impact.
This topic was automatically closed after 30 days. New replies are no longer allowed.