Windows Updates Failed through deployment.

[nhottinger]

I have just started pushing out updates via SCCM 2012. I downloaded the updates into a separate WSUS folder, created a deployment package and software update group and deployed the updates. When I look on the system, it shows the updates are there, but all of them failed. When I click retry in software center, they install just fine. What am I missing that these install manually but not automatically like the deployment was setup to do?

 

**Update** Some of the pc's received the updates just fine, others did not. Not sure what the difference is yet, but I'll keep looking into it. I do see a bunch of "errors" in the UpdatesDeployment.log which state:

Update (Site_xxxxx) not actionable, no attempt required." What does that mean?

[Edenost]

It mind sound silly, but have you tried rebooting? It could be that it needs to reboot to complete the other updates before doing the others?

[nhottinger]

Yes, I rebooted multiple times thinking the same thing, but they still come up as Failed.

[nhottinger]

Is there a way to monitor how much bandwidth is used by these updates. Now that we are pushing them out, I am getting all kinds of calls for slow computers.

[Peter33]

It takes the same bandwith as normal applications/packages in SCCM depending on the number of the required updates for the Client. The Client will only download the required updates, even if the update package cotains all updates for a product. This should have no Impact on your Clients Performance at all, except you have set some insanely short schedules for scan and retry.

 

A different Story is, when you just have activated SUP on your Environment, and the clients start to compile all the policies for the published updates. This may take a while and indeed affect the disk IO on clients for several minutes. Every single published update represents a single policy which has to compiled and registered. You can actually see it in the logs. We have like 5000 published updates and a fresh Client takes like 20-30 minutes, until all policies are avaluated. That's a lot of overhead on the Client even without debug logging activated.

Anyways, i doubt that your problem is related to it.

 

Do you have Branch Cache activated on your clients?

[nhottinger]

Can you help me find that setting?

[Peter33]

In SCCM Packages, ADRs etc, you find the Setting in the "download settings" tab. (Allow Clients to share Content with other Clients on the same subnet)

For your Windows Clients it's most likely configured via group policies (Computer Configuration -> Administrative Templates -> Network - >Branch Cache). You can check on your Clients by using the RSOP or GPRESULT commands.

[nhottinger]

ok thanks. On the packages we push out, I do select the "Allow Clients to share Content..." but we do not have a policy that sets the BranchCache automatically. Maybe I'll have to set that.