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.

For most companies, Configuration Manager is becoming a mission critical service the requires less and less downtime. Upgrading large environments/DBs can take up to 5 hours for the CAS, and 4-5 hours for primary sites. Also, most customers want to get the latest hotfixes installed right after performing an upgrade. In some cases, the hotfixes take just a long to complete as the original upgrade. Overall, this can require long outages (sometimes 2 days) to get current.

Potential Solutions:

1. The ability to upgrade directly to the latest hotfix as noted here:
https://configurationmanager.uservoice.com/forums/300492-ideas/suggestions/33166225-upgrade-sccm-directly-to-rollup-version

2. Reduce the time needed to regenerate DRS sprocs and reporting views. These two steps seem to take about 80% of the overall upgrade time.

Now that Configuration Manager vNext Build 1511 has been released, we have 12 months to decommission any SCCM site servers running on Windows 2008 and Windows 2008 R2.

All the details can be found here - https://technet.microsoft.com/en-us/library/mt210917.aspx

I'm working in a large organization and our SCCM infrastructure is made of 1 central site, 4 primaries and 622 Distribution Points running the Windows 2008 R2 OS...and we can not migrate as many servers in just one year...especially in the middle of the fiscal year where the IT budget has already been reviewed numerous times and approved by our management several months ago.

I can not ask the creation of an unexpected project of several millions $ in the middle of the FY and even if I do it, we can not migrate 622 servers spread out accross the globe in just 12 months.

All our attention and resources are currently focused on the migration to SCCM vNext and to the deployment of the new Windows 10 OS.

Also, there is no point in paying an expensive "Windows 2008 Extended Support" if, on the other hand, we are forced to migrate to Windows 2012 for product compatibility reasons.

Because of the above reasons, I filled a DCR (Design Change Request) to ask Microsoft to extend their support of Windows 2008 and Windows 2008 R2 SCCM site servers up to 24 months after ConfigMgr vNext was released (instead of 12 months)

Please vote if you agree with this proposal or if you are in the same situation than me.

Thanks in advance !

Configuration Manager Current Branch (1602) Supports SQL Always On Availability Groups, however it only in a Synchronous-commit replicas.

From TechNet:
Asynchronous-commit mode. This availability mode is a disaster-recovery solution that works well when the availability replicas are distributed over considerable distances.

Synchronous-commit mode. This availability mode emphasizes high availability and data protection over performance, at the cost of increased transaction latency. A given availability group can support up to three synchronous-commit availability replicas, including the current primary replica.

This means that Configuration Manager can only support 3 secondary replicas in a SQL AO AG and they need to be in the same datacenter. Without the ability to support Asynchronous-commit replicas we cannot have replica groups that are Geo redundant and offer a more complete disaster-recovery solution. For many customers who use a different datacenter for the disaster recovery model the Synchronous-commit does not offer any improvement in recovery as a database would still need to be restored and a ConfigMgr Site Recovery still done. Having the option for an Asynchronous-commit can help to reduce the recovery time of Configuration Manager in the event of a disaster.

Another option would be to support Distributed Availability Groups for SQL 2016.

ConfigMgr 1511 CB's Service Connection Point came out of the box with a pretty cool ability to support Offline \ On-Demand updates even for those without internet access to their ConfigMgr environment through the Service Connection Tool. However for those in environments who have to content with Proxy this becomes an issue. While you can configure the site server system with proxy information that is only good for the system housing the Service Connection point, this post is requesting a change to add a switch and code base to support the switch to the Service Connection Tool to allow the use of proxy configuration as well as it is not a currently viable situation. Reference Links: https://technet.microsoft.com/en-us/library/mt691532.aspx and https://technet.microsoft.com/en-us/library/mt622757.aspx.

Right now we're having an environment with a CAS and two PRI with 165,000 clients. The hardware is "old" and has to be replaced.
Everything is running on SCCM 2012 R2 SP1, SQL 2012 and windows server 2008 R2. Now we're planning an upgrade to SCCM 1606 or higher, SQL 2016 and windows server 2016 on different hardware. So far we found some TechNet pages telling us that there are issues with SCCM 1511 and SQL 2016, but SCCM 1606 and SQL 2016 ought to work (There is right now no information about the supportability of windows server 2016 with SCCM 2012 R2 SP1 or 1511).
If there were a direct upgrade possibility to SCCM 1606 (and not via 1511) it would be much easier for us to upgrade.