By default (that am seeing) , clients under branch offices will not get proxy management info unless you add the boundaries of branches into boundary group with mp defined .
Lets take ex: I have lot of branch offices in location that has secondary site with MP,DP,SUP (a.ak. proxy MP) .So when i create boundary group for these branch office boundaries ,i do not specific the MP info in site system tab ,because i do not want my branch office clients to download the content from sec site which is DP and also MP. In this case ,i have not defined my MP info hence clients will always talk to primary site MP for policies etc and never be secondary site MP (proxy). To fix this ,i need to edit (though unsupported) mpgetproxymplistforsite stored procedure to get this fix. The default SP MPGetProxyMPListForSite will not work .

Can we get this MP_GetProxyMPListForSite changed for the next update release ?

Regards,
Eswar

Currently when disabling/modifying the Auditing Status Message filter rules such as "Write audit messages to the site database and specify the period after which the user can delete the messages.", a very generic message is posted to the Status Message log which is the exact same message for any change to any of the Status Message Filter Rules.

It would be more useful, especially "Audit" related filter rule changes, that the specific filter rule changed is specified in the status message, and a not just a generic message.

This will help better in monitoring a auditing hole where, in theory, SCCM audit logging could be disabled, and actions taken in the environment without then being audited.

At a customer I've updated the Primary Site Server to 1802, this went without problems. The customer has 7 sec.sites. From ConfigMgr Console I started the upgrade which failed. In ConfigMgrSetup.log it stated that the SQLSysClrTypes.msi failed to install (see attachment). This prerequisite was already installed on the server. Also the 'Microsoft SQL Server 2014 Management Object’ was already installed. Which eventually gave the same issue.
I've worked around the issue by removing the MSI Installer registrations of these 2 prereqs in the registry. The upgrade was now able to end successful.
Somehow the Upgrade sequence doesn't check if these 2 prereqs are allready installed, which IMO it should do.

Would like to see the product support moving from a 2012 hierarchy which is using custom ports for client communication and IIS bindings, into a CB hierarchy that is using default ports. My understanding is that both environments need to match exactly from a port perspective and we have over 400 remote DP's that will need to be removed manually from SCCM 2012, reimaged and then redeployed as remote DP in CB all over slow links. We have no internet connectivity options for a cloud DP scenario in these location (like China). This will significantly delay our migration globally to CB. Please consider providing support for multi-port migration scenarios.

The setup fails to configure SQL Broker during the setup and it is such a pain to cleanup everything after that. SQL broker port in use detection ( in case we install 2nd site in the hierarchy) should be part of pre-req itself. we manually specify the broker port in setup wizard and thus we should have a pre-req check in before we begin the actual setup process.

Setup fails with below error as we don't do it at the moment.

ConfigMgrSetupWizard Verbose: 1 : Received error [Setup failed to configure SQL Service Broker. Possible Cause: Each Configuration Manager site must have its own SQL Server instance. Verify that the selected SQL Server instance is not in use by another Configuration Manager site.] from native code.