Advice to the reader
This posting is part of a series of articles. In order to get a full grasp of it, I strongly advise you to start at the beginning of it.
Other postings in the same series:
01 – Kickoff
03 – SCOrch
04 – SCDPM
05 – SCSM
06 – SCVMM
07 – SCOM
In the second posting of this series I’ll write about how SCCM relates to Microsoft’s Mobile First – Cloud First strategy. Reason why I start with SCCM is because this component is quite special compared to the other System Center stack components. For a long time already it has it’s own space, even outside the regular SC stack. There is much to tell, so let’s start.
Big dollars
First of all SCCM is still BIG business for Microsoft. We all know that Microsoft makes a lot of money so when something is BIG business to them, think BIG as well 
Even though SCCM still has System Center in it’s name, it’s being pushed outside the regular System Center stack more and more. And yes, I do see (and respect) the suspected reasons behind it all.
Current Branch (CB)
For some time now SCCM has introduced a new approach to software maintenance. As such SCCM no longer adheres to the well known ‘Mainstream Support & Extended Support’ end date model which is still in place for the other components of the System Center stack.
Instead SCCM is updated on an almost quarterly basis, meaning SCCM gets about 4(!) updates per year! Which is quite impressive. However, with this new approach new branding is required AND a new support model. Even for a company like Microsoft it’s undoable to support a plethora of SCCM versions for many years.
So instead of using a year branding like SCOM 2016, a new kind of boiler plate was invented, titled Current Branch (CB) release. Now the CB releases of SCCM are made up like SCCM YYMM. Some examples: SCCM 1610, SCCM 1702 and so on. So SCCM 1702 is the CB release of 2017 (17) and the second month (02) of that year.
And not just that, but there are even CB releases with a MONTHLY cycle. However, those CB releases are kept inside a small circle existing out of Microsoft itself and some special customers and SCCM MVPs. The details are unknown to me since Microsoft doesn’t talk much about it. Only CB releases which are deemed good and stable enough are pushed out to the public, which happens once per 4 months in general.
Sometimes some these ‘in between’ CB releases are made available under TP, Technical Preview. Not meant for production (nor supported!!!), but meant for testing. At this moment SCCM 1704 is TP.
Why CB?
There are plenty reasons for the CB approach, like supporting the latest version of Windows 10 which also adheres to a CB based release cycle. So whenever new functionality is introduced with the latest release of Windows 10, the most current CB release of SCCM supports it 100%.
Another reason is that customer feedback is incorporated many times faster, compared to the old approach where – if lucky – once per 1.5 years an update was released. Now instead, just a few months later customer requests and feedback are incorporated directly into the latest CB release.
And yes, there is also another reason…
CB and the cloud: SCCM as SaaS!
Sure, with every latest CB release of SCCM, you’ll notice that SCCM is tied more and more into the cloud. This doesn’t end with deeper integration with Windows Intune but also with Azure in general. So step by step SCCM is growing into a Software as a Service (SaaS) cloud delivery model.
And the proof of it is already there. Because updating SCCM can be quite a challenge. Microsoft has addressed this issue quite good and with every CB release the upgrade process and experience is improved even further.
Since CB saw the light, SCCM can be upgraded quite easily, all powered by Azure. Sure as a SCCM admin you still have some work to do, but the upgrade process has become quite solid and safe. Just follow the guide lines setout by SCCM itself, and you’ll be okay in most cases. No more Russian roulette here!
How about support for CB releases?
Good question. Like I already stated CB releases adhere to a new support model as well. And those new support models don’t last years like we see for the rest of the System Center stack, but MONTHS! Which is quite understandable. Instead of Mainstream / Extended Support, SCCM CB adheres to two so called Servicing Phases:
- Security & Critical Updates Servicing Phase;
- Security Updates Servicing Phase.
The names of the servicing phases are quite self explanatory so no need to repeat it here I hope
How it works? Let’s take a look at today’s situation. SCCM 1702 is the most current CB release. As such it adheres to the first servicing phase (Security & Critical Updates). Meaning, it’s fully supported by Microsoft. Security and critical updates will be released for it.
SCCM 1610 is the CB-1 release now. So this CB release adheres to the second servicing phase (Security Updates). So this CB release doesn’t have Microsoft’s full support. Instead it will only receive security updates and that’s it.
Suppose a new SCCM CB release becomes publicly available, let’s say SCCM 1706. Everything will move one rung down the servicing phase ladder:
- SCCM 1706 will adhere to the first servicing phase (Security & Critical Updates);
- SCCM 1702 will adhere to the second servicing phase (Security Updates);
- SCCM 1610 won’t be supported anymore.
Sure, it forces companies to follow the CB flow as much as possible. But with every new CB release life is made easier because SCCM is growing into SaaS, making the upgrade easier every time.
!!!Spoiler alert!!! CB isn’t just a boiler plate
Please keep this in the back of your mind – at least for this series of blog postings – CB is way much more than just a new boiler plate!
As you can see with SCCM, CB encompasses not only a whole new support model (aka Servicing Phases) but also the development cycle is totally different. The way customer feedback is being processed, and decided upon whether or not to incorporate it into a future CB release or not. The way SCCM is being tied more and more into the cloud, growing to a SaaS delivery model. How SCCM is upgraded from one CB to another.
And so on. And yes, introducing and maintaining and growing the CB model costs money and resources. Which are available for SCCM without any doubt. As you’ll see in the future postings of this series however, this kind of funding and resources is kind of different for the other components of the System Center stack.
Verdict for SCCM and it’s future
Without a doubt, the future for SCCM is okay. For sure more and more SCCM will be tied into the cloud. But that’s not bad at all. Also with every CB release SCCM will grow even more into a SaaS delivery model, enabling you the administrator to focus on the FUNCTIONALITY of SCCM instead of working hard to keep it just running…
SCCM adheres for a full 100% Microsoft’s Mobile First – Cloud First strategy. And not just that, but also enables it by the functionality it offers. So whenever you’re working with SCCM, rest assured.
Many changes are ahead for it, but SCCM is in it for the long run, stepping away more and more from the System Center stack as a whole and as such, creating it’s own space within the Microsoft cloud port folio and service offerings.
SCCM is safe and sound and will give you full ROI for many years to come. Simply keep up with the CB pace and you’ll be just fine.
Coming up next
In the third posting of this series I’ll write the epitaph for Orchestrator - SCOrch (I am sorry to bring the bad news but why lie about it?). See you all next time.
No comments:
Post a Comment