Policy requests are made on computer level. When assigning an application to a computer we regularly trigger a machine policy request to speed up the installation. This is not possible when user assignment is used, as we don’t know which computer(s) the user is currently logged on to. We can guess by checking for example “Last logon User Name”, this is however not live data and thus not very accurate. If the client instead reported who’s logged on as part of the user policy request at log on, we would know. This would allow to trigger a User policy request on the computer(s) that are “online” and the user has been reported as logged on to.

Creating SCCM Collection Queries is an art, and like most art, some of us are more suited to stick-figures while others produce beautiful creations worthy of a place in the Louvre, featuring graceful sub-queries, artful tabbing and good code practices.

When creating a collection, it would be helpful to have an optional 'Community Collection Catalogue' to choose from, which could have a user-voice style 'Most useful' collections list.

Users could create collections here, possibly even having a community 'wish-list' area for those without skills to request from those who would like to share.

Contributions in the community catalog could be counted for MVP or other recognition, possibly displaying badges. Gamification elements could be added, including Facebook or Twitter links to individual contributions.

Problem:
• Current state of windows 10 servicing via upgrade sequence requires full media to take the client through setup.
o Full media is 2x the size of existing ESD (upgrade content)
o The Upgrade Operating System step does not allow the end user to defer the reboot nor does it warn the user of a reboot pending once setup has been kicked off

Change Request (Requirements)
I. The Upgrade Operating System step in the task sequence shall permit the administrator to reference windows 10 servicing content
II. The Upgrade Operating System step in the task sequence shall permit the administrator to define a notification to the end user
III. The Upgrade Operating System step in the task sequence shall permit the administrator to define if the user can defer the system reboot and for how long

Please, do you have an answer for the below questions? Or, can you point me to the Group that could answer these?

Customer wants to patch the Sharepoint farm through SCCM without manually intervening on the servers for this. I told him this is by design and that the Updates tagged with “farm deployment” are not listed in SCCM, because they specifically require User Intervention. The reason for not showing SharePoint Farm Updates in SCCM is due to the update behavior of Sharepoint. a farm update is installed on 1 of the servers and manually distributed over all other servers and databases https://technet.microsoft.com/en-us/library/ff806338.aspx

The customer wants to know:

1. What do companies with 10-100+ sharepoint servers do, to automate their update process? Creating packages for every update is a tedious process and requires a lot of manhours every month, for something that is really simple. It will also mean that when we've done this for a while (say, a year) and then deploys a new SharePoint server, it'll have to install all updates one by one, and the risk of it failing at some point is quite high.

2. Are anyone else using SCCM somehow? Could one perhaps alter the WSUS database, to mark all updates containing "farm-deployment" to InstallationCanRequestUserInput = 0, and in that way enable SCCM to import the updates, and then make a schedule that takes care of patching the farms in a proper way?

3. Are the content of the update without the farm-deployment tag identical to the one with the tag? So it's just a matter of how wsus and SCCM perceives the update, or is there in fact a difference in the content of the update?

In SCCM CB, only the BITS setting of version 1.5 is supported in the client settings.
These allow only restrictions to common day and make no difference between the workdays or maintenance days.

The support of a more recent bit version (eg 3.5 - Windows 7 or later) would allow more significant improvements to the content download of Agents and Pull DP:
1. Differentiation between working days and days off
2. Differentiation of bandwidths depending on the job priority
3. Set maintenance days

A large IT organization with about 1500 Pull DPs has successfully implemented the BITS 3.5 Settings via GPO:
1. The download of software packages to Pull DP could be accelerated considerably, because the weekend could be better used.
The download period increased from 75 hours to 105 hours (ca.50%). The bandwidth limitation of the pull DP is more comparable to a standard DP.

2. The installation duration over the weekend could be reduced to 25% until 5% depending on the package size.

3. Emergency deployments or system customizations are distributed with high package priority and can be installed without BITS restrictions.

Currently, these settings can only be implemented using AD-GPO or with a script.
Different BITS settings depend on the system role or system state are difficult and inconvenient.

Support for BITS version 3.5 in the client settings of System Center Configuration Manager would be much easier and safer.