May 2016 Surface Pro drivers WTF? SurfacePro4_Win10_160901_1

OK so Microsoft have released another set of firmware updates which are always welcome. I’ll admit I installed them and haven’t noticed a great deal of difference although possibly there maybe an improvement in battery life. Jury’s out on that but it’s a definite possibility. I am a heavy user with several VMs regularly running under Hyper-V in the background, usually a DC plus an SCCM server with all the roles installed and maybe a workstation client too. I am used to bad battery life and I think it may have improved.

I digress. I’m sure there’s plenty of extra stability goodness included in the new update but I am here (unapologetically) for a moan. This post is really an update on my previous Surface post (http://www.simonbond.net/?p=226) regarding the Samsung SSD. If you’ve not read it already then I suggest you do but the crux of it is this: the Surface 4 usually comes with a Samsung SSD which by default has fairly slow write times. When I say slow, up to 150 MB/s. For an SSD on a laptop type device this is rubbish. I explain in the linked post that this can be fixed with a driver update (and I have published a new link to this driver as it no longer seems to be accessible from the Samsung site).  In any case here is my issue:  The new update pack (May 2016) seems to revert the write speeds back to default , ie sub 150 MB/s.

Not sure what’s going on here but if you re-run the firmware update we’re back in business. Might be something to think about testing for all future firmware releases.

SQL Server AlwaysOn Availability Groups, SCCM and MultiSubnetFailover

EDIT: The issue below has finally been addressed in version 1906:

https://docs.microsoft.com/en-gb/sccm/core/plan-design/changes/whats-new-in-version-1906#improvements-to-support-for-sql-always-on

——————————————————————————————————-

At the time of writing there appear to be very little on the internet about this particular configuration.

In short, we needed to use the MultiSubnetFailover option string with our SQL AOAG making up the CM2016 back end. We have two SQL DBs, one in London and one in Slough. As one might typically expect, these exist on separate subnets.  After hunting around the internet to try to ensure the supportability of this configuration it quickly became clear that a call to Premier Support was required to confirm. In particular, we were interested to know whether the ODBC System DSN driver should remain the same on the site server. By default this uses an old version which doesn’t have the MultiSubnetFailover checkbox available. We figured this might need changing to the newer 11.x native client when AOAG were used over separate subnets. There was an awful lot of to-and-fro between ourselves and Microsoft and it was clear this was an area where there was little clear knowledge. We did finally prize an answer out of them however and the following is an edited transcript of the outcome:

  1. We wish to know if SCCM 1511 and 1602 should be able to talk to such a multi-site SQL cluster OK?

ANS: Multi-site Cluster is supported but it`s a complex solution to implement. It is heavily dependent on the Hardware Supportability and Networking. Storage should also be carefully considered:https://blogs.technet.microsoft.com/meamcs/2013/11/09/microsoft-windows-multi-site-failover-cluster-best-practices/

Configurations for the SQL Server Site Databasehttps://technet.microsoft.com/en-us/library/gg682077.aspx#BKMK_SupConfigSQLDBconfig

  1. Should we make SCCM use the “SQL server native client V 11.0” ODBC connection “system DSN” connection which has a check box that seems to have “multisubnetfailover” option or the default SCCM installed “SQL driver” for ODBC connection?

ANS: We should not be making any changes to the default configuration made as part of the ConfigMgr installation. ConfigMgr does not support SQL Server Multi-subnet clustering.

  1. If we upgrade SCCM from 1511 to 1602  (or to a later version in future) will the upgrade make the site server use the “SQL driver ODBC” connection again, needing a manual change to SQL native client again?

ANS: We should not be altering the default configuration at ODBC

  1. [PS Engineer] wrote the following “…SCCM Components make use of dll’ (some components) andSQL Server native Client both.  Native Client will get updated as per SCCM need, and we can leave sqlsvr32.dll’ as its default version.”

Our response: But slqsvr32.dll, does it have the multisubnetfailover option? We cannot see this. Where and how do we configure ALL the components to use multisubnetfailover on primary site server and other component servers as appropriate?

ANS: SQL Server Multi Subnet cluster is not supported.

Always On Availability Groups in SCCM 1511

There has been a lot of talk about the use of SQL AlwaysOn Availability Groups (AOAGs) from SCCM 2012 onward but it wasn’t available in any iteration of this version and promises were made by Microsoft to include this is as a feature in 1511. Indeed it seems to have been planned and implemented in the Technical Previews but evidently didn’t make it into the final official release of 1511. Given that officially* you need to go via 1511 to install 1602 this is very annoying for anyone wishing to use this feature as a number of extra steps are required. Below I try to clear up much of the contradictory information available at present (May 2016) on the internet.

A number of websites run by respected MVP’s continue to suggest availability in several 1511 versions:

https://4sysops.com/archives/system-center-configuration-manager-2016-tp3/ which suggests it is available in TP3.
And this from another fairly well respected site:
https://www.systemcenterdudes.com/sccm-1511-new-features/

In a nutshell, it seems AOAGs are supported only on 1511 Tech Preview 4 and above but to confuse matters, the following from Microsoft explains this definition:
https://technet.microsoft.com/en-us/library/mt595861 (snippet below)

Technical Preview 1511 – This version is also known as the Configuration Manager Technical Preview 4. It represents a baseline for Technical Previews that begin with the release of the current branch for System Center Configuration Manager, version 1511…

This is where it gets interesting because Technical Preview 4 covers a number of separate releases which flank the ‘official’ 1511 release on Dec 8th 2015:
https://buildnumbers.wordpress.com/sccm/
Well that that clears it up then.

After filtering through a good deal of contradictory information, it appears that SQL AOAGs made it into the 1512 TP4 version and that 1602 is the first official CB release to have full support.
So to be clear, when installing 1602 and above from scratch, install 1511 first by pointing to the single DB instance then change to AOAGs later via the procedure below.

https://blogs.technet.microsoft.com/arnabm/2016/05/14/step-by-step-configuration-manager-site-database-hosted-on-sql-server-alwayson-availability-group/

If you don’t, and you are using the Dec 8th (official) release of 1511 then when adding the AV Listener you’ll see the following error message:

AVG_1511

And nobody likes to see that 🙂

 

* I hesitate to say this but it is perfectly possible to install 1602 direct from certain media sources** for 1602. This is not supported and therefore not recommended, I am informed one of the side effects of doing this is that you’ll not be able to update in future. There may be other, undocumented side effects too.

** Media I obtained came from an unconfirmed source although it is possible it may have been from CD.Latest (I didn’t originally source it so can’t confirm for definite). Basically don’t do it if you want a supported environment!