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.

Content Replication from Site to DPs should be a frustration free Process or SCCM Admins. Unfortunately, I know no customer without smaller or bigger issues in this area.
Here is an uncomplete list of some issues I´ve noticed:
• Content Eval - Scheduled Task lost
o SCCM does not check if the schedule task got lost/deleted
o Suggested Solution: SCCM should verify the Scheduled Task on Service Startup
• Content Eval - Hash mismatch/Eval fails for package
o When content Eval fails for a package, the admin must manually redistribute it / take care of the error
o There should be an option in SCCM to automatically fix packages where Content Eval fails
• Content Eval - Immediately validate content after distribution
o When an invalid package gets send to a DP, it can happen that it goes into the state "Successfully distributed content"
o However, to content is invalid. If you run a content validation immediately will go to "Could not validate…"
o Makes troubleshooting much harder, as you must verify every package before it is "really" OK
o Suggested Solution: Immediately validate content after distribution
• Content Eval - Failed to retrieve the package list on the DP
o If DP has this error, it never gets fixed automatically
o If WMI Entry is missing and .INI file is there, smsdpmon.log does not tell which package is affected
o Content Eval Task does just use package list in local WMI (SMS_PackagesInContLib), but it should verify all packages assigned to it.
o WMI/INI fix script (eg: here, but many scripts like this exist on the internet) can fix the error, but will cause other issues.
o Suggested Solution: When Content Eval runs, the DP should download a list of Packages to verify (PkgServers Table?)


• Waiting for Content - Content did not arrive from CAS
o Content available (and verified) on Primaries - however some Secondary Sites have the status "Waiting for Content from CAS”
o Workaround: Reset Status in DB for Primary and Secondary and Redistribute
• DP and Pull DP - Handle Empty Packages
o SCCM DPs cannot handle Packages without content
o Scenario 1: Deployment Packages get empty automatically, because Updates expire
o Scenario 2: Create Package with content and deploy to DPs – Remove “this package has source files” checkbox
o Content Validation on DP will fail - DP will go to warning state
o Workaround: Detect and remove empty packages
o Suggested Solution1: DPs should be able to handle empty packages
o Suggested Solution2: SCCM should detect empty packages and remove them from all DPs
• DP and Pull DP - Redistribute does not fix .INI file issues
o If Content of INI file in PkgLib is invalid, a redistribute does not fix it
o Suggested Solution: Always rewrite INI File on redistribution


• Database - PkgServers, ContentDPMap and PkgStatus not in Sync
o Content is distributed and verified successfully to DPs
o Content is not written correctly to ContentDPMap Table (can happen if status message gets lost)
o PullDPs and Clients can´t download the Package
o Workaround: Redistribute affected Package
o Suggested Solution: If Content is OK on a DP, the ContentDPMap+PkgStatus should reflect this => When Package is successfully validated on a DP, all needed Tables should get checked/updated

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.

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.

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.

ConfigMgr Team, your best practice document regarding the set up of boundary groups actually breaks peer caching.

https://docs.microsoft.com/en-us/sccm/core/servers/deploy/configure/define-site-boundaries-and-boundary-groups

To quote: "it is a best practice to create a separate set of boundary groups to use only for site assignment."

This is good advise, and I use this also for Management Points and Software Update Points so that if I add or remove a site system, I only have to modify 1-2 boundary groups instead of 150.

Since Peer Caching is now based on Boundary Groups, if you have implemented this best practice, then effectively every client in a site that has Peer Caching enabled is within the same boundary group, and therefore any client at any site across the world can search for and download content from any client at any site across the world. (We are experiencing this right now, as a matter of fact.)

In order to better control where clients can and cannot use Peer Caching, I would suggest that a setting be added to the boundary groups that the clients can read that would tell them whether or not they can use Peer Caching when inside this boundary. Since the client setting controls who can be a SuperPeer and who cannot, this setting will be good to ensure that the clients stay within their actual physical boundaries and only select SuperPeers within that boundary.

As a bonus, if you designate a Distribution Point to a boundary that is enabled for Peer Caching, then that will be the first DP that the clients reach out to if there is no content available on a SuperPeer within the boundary.

When you have a Site System Server with both Management Point and Distribution Point roles and you want to link it to a boundary group, it would be great/usefull to select the role you want to link.
For example, in our environment, we have 2 servers. 1 with MP/SUP/DP for Wan access, 1 with only DP for LAN (Customers office) access. If I want that all Customers Offices workstations connect to MP, I must add both server to boundary group and the result is that Office's workstations will have the possibility to select both DP (using the WAN link). I currently use the Slow Connection option but it can be dangerous.

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