This could be a config thing and if it is I'm sorry, I cannot find where.

Last month I grabbed all updates that have a required > 1 and deployed them (to test first of course). Now, several days (and more accurately, several maintenance windows) after they were deployed I have some updates that in the console show in monitoring\deployments\my deployment\error tab and on the client show as "past due - will be installed". The only way I know to fix these is to manually log into each server, possibly reboot them, then manually click on the retry button for the updates.

Many of my servers must be patched after Midnight. I work 9-5. They have maintenance windows from Midnight to 0500 every day. It would be great if they would retry installing the updates each maintenance window instead of me having to pull all-nighters.

Currently, the WSUS servers connect to the URLs (both HTTP and HTTPS) to download the updates, as mentioned in this link: https://docs.microsoft.com/en-us/sccm/sum/plan-design/plan-for-software-updates#BKMK_ConfigureFirewalls

This means allowing HTTP traffic to come down to internal servers (by creating exceptions in the proxy settings), causing serious audit failures and security concerns.

Also, a lot of proxy solutions also have a capability to block the content from whitelisted HTTP URLs if the file size is too large, thinking that it might be malicious content. This again causes problems when Windows 10 Feature and Express Updates are downloaded!

Hence, it would be great to publish all the updates on both HTTP and HTTPS URLs and in ConfigMgr, have a feature to allow SUP and WSUS external connections and content download over HTTPS only, improving security and audit compliance.

When building software update packages in SCCM we run into having to build a deployment package to see what size the updates are. The issue we are having is managing the size of these packages which are frequently getting into the multiple GB range. One we ran recently hit almost 6 GB.

This information is on the Windows Update Catalog site, but it doesn't appear to be in SCCM or WSUS. I'm guessing that it isn't in the data that is available to WSUS and as a result SCCM doesn't get it either. It would be very useful if we could see the update size in the All Updates view, in Update Groups and in the Update Packages views as well.

There are many benefits to having one deployment for all of our workstations. We have an ADR that approves our patches and deploys them to a singular collection. Our update schedule is segmented so that not all locations go at once. Since we only have one deployment, this assignment is carried through by maintenance windows. We would love a setting that allows the workstations to wait for their maintenance window after our approval, but as soon as it has missed one window "and is now a deferred update" then enforce outside of maint. windows. We know we could go back in and change the deployment setting to ignore windows after our windows have passed, but that's a user initiated action. And we would prefer the deployment kicked in immediately when they get online after they have missed their maintenance window. A setting in the deployment itself that says, "enforce deferred updates outside of maintenance windows" (deferred updates=any update that has been approved and missed one maintenance window.) This would be very useful setting.

At the moment when creating a service plan in SCCM e.g. for Windows 10 Fall Creators Update (1709) there are several versions downloaded. Like the x86, x64, consumer and business files. So if you need the update only for Win 10 x64 Enterprise EN, you will still get all 4 versions: the x86, x64, consumer updates (Win 10 Home) and business updates. That results in pretty much wasted disk space which would not be necessary since the x64 business files would suffice.

It would be great if we can define the search better so you can choose what files will be downloaded/used for the service plan.
E.g. a checkbox for x64, business, all, and so on.

Sometimes (one time per week) we have a failed automatic deployment rule (ADR).

Error Code:
SMS_RULE_ENGINE
Message ID: 8706
Decription:
Content download failed.
Message: Failed to download one or more content files.
Source: SMS Rule Engine.

Most of the time it is the one of the Windows Defender Definition updates. If I Re-run (Run Now) the ADR it works perfectly. Maybe there is not enough time between sync sup and run ADR. I don't know. After I click "Run Now" it's always success.

It would be great if you can add an option "Re-run failed ADR, after X minutes, try it X times" something like that.

Now that Surface drivers and firmware are available to download as software updates it would be great to be able to deploy them without worrying about Bitlocker and having our users locked out.

So far it seems that we have to do a lot of testing to see whether or not a driver or firmware will lockout bitlocker, and then give up and deploy them using a TS, so we can suspend Bitlocker, update, reboot and reenabled bitlocker.

Could all drivers/firmware from the Surface update category automatically have bitlocker suspended when deployed as an update? or give us a tick box in the deployment options to suspend for x number of reboots (some of the firmware reboots a few times).