Situations where maintenance mode is useful/needed:
1. When the system (hardware) is in transit from the location where it was installed to the site where it is to be used in production.
2. When the system is down for other maintenance (software patching and updates, OS configuration changes, hardware reconfiguration and other external factors causing planned or unplanned downtime).
The above outlined method for installing new DPs to remote locations is widely used for various reasons (For example to have a dedicated team at one location install machine and to avoid having to copy a large content library across WAN links). During the time in transit (which is usually between 1 day and 2-3 weeks), the ConfigMgr site server will only know that the DP server is unreachable on the network.

Advantages with a maintenance mode option:
- The status system should/will mark the system as being in the fully expected maintenance mode state (no error condition).
- The log files for components actively working with the DPs will not be cluttered with information about attempts to work on packages targeted to the off-line DP.
- We will not have various error status messages generated regarding the distribution points and its packages during the planned off-line time.
- The Distribution Manager (DistMgr) / Package Transfer Manager (PkgXferMgr) pipe will not be burdened with and slowed down by requests for systems known to be offline.
- Packages targeted to systems that are in the maintenance mode state will not be labeled as failed after the retries are used up, but rather that they are in a “waiting” (for the DP to get out of maintenance mode) state.

The change requested:
The primary ask here is to let DistMgr and PkgXferMgr know that they should not need to work any request targeted to DPs that are in maintenance mode. If they are currently working on such requests, they should stop doing so and postpone the request until the DPs status changes.
It will also be good, if DP systems in the maintenance mode state are not considered when clients make content location requests.

CURRENT FUNCTIONALITY

When a new Distribution Point (DP) whether it is a normal DP or a Pull DP is installed to a ConfigMgr 2012 R2 site, the priority assigned to this new DP is always the same by default.

REQUEST FOR CHANGE

It is often desired that Pull DPs are by default assigned lower priority than the normal DPs.

MORE INFORMATION

When operating a site with many (hundreds of) DPs installed, the normal DPs serve as source distribution points for the Pull DPs. It is therefore desired, that those normal DPs will have the new package files copied over before the Pull DPs are given instructions to try retrieve the content from those source DPs. Or at least it is expected that the file copy jobs for the source DPs will be created before the instructions to retrieve the files are created for the Pull DPs. This could be accomplished by letting Pull DPs by default have lower priority than normal DPs.

Another way to accomplish an "intelligent" default priority would be to look at dependencies such that a DP that is configured to retrieve the contents from one or more other DPs will by default have lower priority than those DPs.

When a package fails to distribute to a DP, the only option right now is to 'Redistribute' the package to the DP. This is inefficient for large packages since 'Redistribute' transfers all package content to the DP even if some content may have already been transferred prior to the failure. For large packages, this not only takes a lot of time but consumes more network bandwidth than necessary.

When a package is 'added' to the DP, only the missing files are copied to the DP however there is no way to simulate an 'add' action from the UI.

Having the ability to trigger an 'add' action for a Package/DP will help remediate content transfer issues a lot quicker as it will only require copying the content that's actually missing on the DP instead of 'redistributing' all content.

Whereas:
A Cloud DP is not a valid source for a Pull DP due to lack of a SIS content library.

Whereas:
PDPs use a source DP's intranet name to obtain content.

Whereas:
Configuration Manager Current Branch fully supports an Azure infrastructure implementation as well as DPs facing the Internet.

Whereas:
Although using a public IP internally for a source DP would allow a PDP to find an Internet IP, it would also have potential to cause other communications issues for the primary site, domain controllers, etc..

Whereas:
The PDP's hosts file could redirect the source DP intranet name to its Internet IP, managing such a solution would require custom automation (baseline/CI with remediation scripts).

Whereas:
In many customer scenarios, the PDP in a remote location does have Internet access, especially large scale retail operations.

Please resolve:
To add a 'check box' on the DP - PDP properties tab source DPs list called 'Use Internet Name' and/or make available as part of PowerShell Set-CMDistributionPoint parameters.

Such a change will add a new capability for Azure IaaS source DPs provisioned in various regions to support PDPs more locally and avoid ALL content traffic on intranet WAN links for the remote locations.

Currently, if there are 100 jobs in DistributionJobs destined for a given Pull DP, and PkgXferMgr fails to connect to the DP for the first one, only that job is marked with a retry time 20 minutes (by default) in the future. We then move on to the next jobs, all destined for the same DP, and mark them individually for retry. In a very busy environment with lots of Pull DPs and jobs, having just 5 or 6 DPs that are offline, this looping prevents PkgXferMgr from scheduling most of the jobs that are destined to DPs that are online.

The ask is that the update to DistributionJobs set the retry time for *all* jobs destined to the unreachable DP (via DPID) to 20 minutes (or the current setting) into the future. This would align with Sender not trying to connect to a remote site that is offline for an hour and would allow jobs to online DPs to be actioned in a much more efficient fashion.

When a package is deleted from the console, the packages/apps are removed from the database. If for any reason a pull DP or DP is not available, or WMI has issues on those remotes site systems, the files on the remote SCCM content Lib are not removed. This creates orphaned files on the Content Lib and causes storage issues on the servers.
We are working with a customer that as a large number of PullDP's so we would like to suggest on the behalf of our customer, to have a retry mechanism in the console to delete the content from the PullDP/DP when they are available and/or the WMI issues are fixed.
This could help to minimize orphaned files and prevent storage issues in the customers DPs/PullDPs.

I would like to see Trusted Source locations to be added to ConfigMgr as a Node in Administration, and permission so that only Full Administrator or a specific RBA Role can manage these locations.

All ConfigMgr wizards that allow path data-entry will be changed to become a drop down list of approved Trusted Source locations. The User will be able to navigate into the folder structure of the Trusted Source location, creating new directories with a restriction on placing content on the root of the Trusted Source location, since this can induce data-loss if the sub-folder is not specified in rare conditions.

No new Source locations will be allowed to be entered, unless created by a Full Administrator or an Administrator with the appropriate Security Role.

This will remove A) free-styling of UNC paths B) Fat-fingering during data entry of paths C) Data loss due to placing content on the root of a location and aborting then cleaning up by deleting everything in the specified folder (root folder). Other MVP's have witnessed this condition occur, Trusted Source locations and a restriction on placing content in the root of a location will resolve this issue without any code-changes required in other areas of the product (to solve the deletions of other content by mistake) and finally D) invalid or inappropriate Content Source locations being configured on-the-fly (really fat fingering) by support teams with enough rights to do so.

Brian Mason added: I have this share out there already: \\Apps\apps$ and under that share is say Workstations and Servers and DCs. When I create the DC scope, I get to add the UNC Source I've named as DC. The DC team never has to enter the name of the share, but instead they browse to that share, see their root folder and pick a sub-folder. No UI ever lets them pick the root either. Anytime they make a package\app\etc., they browse to where I've limited them to and must pick a folder there.

Please add in suggestions to compliment this proposed solution, and vote it up to complete the Trusted Source Story. Being in complete control of our source locations should be on every administrators "I want that feature right now" list

The idea would be to have a setting (maybe Custom Client settings is a good place) where we can specify a specific order of priorities for network adapters from which SCCM takes the ipv4 address for content distribution and site assignment.

For example, we currently have the following settings in the network adapter configuration
1- wireless
2- LAN
3- Remote Access connections

For VPN clients this is a big issue if we have a boundary which conflicts with one of the internal ones, like 192.168.x.x since they'll use the local IP as a top priority instead of the VPN one.

If we have such a setting, we could specify for a specific "ServiceName" (in the wmi class of the network adapters) to have priority over the others it would be terrific! We would not have to change any network setting, we just instruct SCCM to override the default provider order so it can use the correct address.