When installing updates via software centre, some updates may fail initially, once other updates have completed installation, software centre doesn't retry these updates but prompts for the reboot. Once the user reboots updates may try installation again which then means another reboot for the user. When initiating the install again manually it usually results in the failed updates installing correctly.

Software Cenre should retry the 'failed' updates at least once - before offering a reboot to the user as in most cases this should result in all updates being applied and the user only needing to reboot once.

Also better failure messages within Software Centre would be appriciated, i.e rather than just failed. is it because of 'low disk space' or 'another installation in progress' or 'download failed' etc

When a software updates package is created, the given path is cleared of any existing content. This is very destructive if an incorrect path is given. One of several things should happen:
1. Restrict the location of software updates packages if another package is using the same folder or any folder below.
2. Warn if additional content is detected in the given path for a software updates package.
3. Not clear additional content from software updates packages source locations.

We recently ran into this with a co-worker making documentation and put in the root path for all of our packages (software updates, osd, apps, etc) and all of our source folders were deleted.

Example: source for package A is \\cm01\packages\PackageA and source for a new software update package was set to \\cm01\packages, results are PackageA folder is gone as well as any other folders.

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.

1. When creating new ADR only published Dell updates are searchable to be added, any updates that are not published won’t be shown in the search results. Since publish updates means having updates downloaded first, we have to manually publish the updates we need before creating the ADR selectively, which brings up issue #2;
2. Since in issue #1 we need to publish updates first before we can create new ADRs, can we group Dell updates by models, say all Dell updates for 9020, since we want to filter Dell updates only with the models we have, then we create a folder and add all of them in, then select all to publish them, then add them all to the new ADR.

Office 365 Proofing Tools language Selection:

In SCCM, we cannot select the Office 365 Proofing Tools Languages along with the Office 365 Client Update. But, if we choose the Office 365 languages then the respective Office 365 Proofing tools language will be selected.

Office 365 language size will have ~400-500MB and the Proofing tools language size will have 30-150MB. So, if we select ONE language, then it will be around ~450-650MB. Here most of the users will not have Office 365 language Pack, but they will use Office 365 Proofing Tools languages for Grammer, Spell check, etc.

As per the current configuration, if we need to choose 10+ Proofing Tools languages for global support, then the size of the updates will be increased, and the respective Office 365 language pack files(400-500MB) will not be in use.

So, it would be better if Microsoft places an separate option in SCCM to select the Proofing tool languages as like Office 365 languages, where we can ignore the Office 365 language pack files there. Here, we will get more space as we are not including the language pack files(~400-500MB) there.

It would make sense to have the ability to deploy software update groups to user collections. We have a few different user collections for "pilot" users. When we want to test new software we deploy to these "waves" of pilot users. This gives us the ability to not have to worry about maintaining the users primary device in a device based collection. We have device based affinity within client settings enabled. So if the user ever replaces their pc it gets updated within 48 hrs of system use. This will dynamically keep our pilot list updated. It's a PIA trying to maintain a device collection pilot list because people receive new laptops with new pc names all the time and when they do the pc name in the collection is no longer relevant.

I would like to make the double notification optional when deploying Office 365 updates from SCCM. When the deployment has a deadline, SCCM client seems to be adding a reg key that is recognized by Office 365 client. Couple hours before the deadline, there is a notification coming from Office 365 C2R. If an user shutdown the machine before deadline, the user will see multiple notification from both O365 or SCCM next day. The order is kind of random. Worst case the Office 365 update reminder still shows after the update being applied by SCCM, because it passed the deadline already.

This is a pop up notification from Office 365 client, not the in-app yellow notification below menu bar.

Applications have the Install Behaviour tab so that any applications which need to be stopped before the application updates can do so, in order to ensure a smoother installation.

In some cases for Software Updates, we've seen the SUP procedure break some applications because the services that those applications run were still running whilst an update installed.

We would like the option for an Install Behaviour for Software Updates, so that when an update is scheduled a user would receive a prompt to ensure that the applications are closed before performing the install, and/or for it to be automatically closed when the software updates task runs so as not to get in the way.