Configuration Manager is becoming more mission critical every day. The ability to Cluster the Site Server role (Inboxes & SMS Provider) is more and more important as that is the single point of failure for a Primary Site.

If the Site Server role goes down the Primary Site is down no matter how many Management Points or SMS Provider etc. exist.

If we could Cluster the Site Server or at least have 2 systems share that role for High Availability then this would no longer be an issue.

Even though we can designate multiple SMS Providers, if the site system itself goes down, consoles will not connect to ANY of these other providers. That’s because the console ALWAYS collects to the Site Server for a list of the SMS Providers every time a console is opened, so it’s not true SMS Provider redundancy if the Site Server goes down, no new consoles can connect.

As we know, 'Required' deployments download content to client cache as soon as possible assuming content is available and req's are met. A common scenario is setting a deadline off in the future which essentially stages or pre-downloads the content to the client cache so it's available as soon as the user hits install, or the deadline is reached.

We'd like an option, per deployment, to pre-download content in a similar fashion for 'Available' deployments.

Understood that available deployments may never get executed, but there are several scenarios (poorly connected, remote offices w/no DP) where this would be extremely desirable. (With the proper client cache size/mgmt.)

Even with Branch Cache, at a minimum the first client to request content for an available deployment still needs to wait for the download from a DP. In some cases this can be very slow, and some scenarios can't afford for users to wait at all.

Lastly, faking this by using required deployments with deadlines years in the future does get the content staged, however it introduces other user experience issues in Software Center related to a required deployment such as confusing status and the inability to use the uninstall button.

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.

While testing some new functionality in SCCM 1602 current branch I inadvertently searched for a possible new variable using the 'set dynamic variable' step.

Unfortunately that doesn't list read only variables in the 'existing variables' list (read only variables begin with _). It would be awesome if this gui would list all built-in variables (including read-only ones) as this would make searching for a particular variable easier than having to google or bing it.

Secondly, how about the option to list all custom defined variables in this gui, along with their values (if any). today we get the following headings Name, Description, how about adding one more, Value.

The reasons I think this is important is

* saving time searching for new variables on Technet
* as ConfigMgr changes version often, being able to list all current variables available to that product version would be great
* debugging task sequences to see what custom variables values are set to what value

cheers
niall