ConfigMgr Production builds vs. Technical Preview builds

In the new ConfigMgr Current Branch model; there are two types of builds and it is imperative to understand the difference between them:

  1. Technical Preview builds – Lab only, highly restricted builds for seeing early previews of upcoming features
  2. Production builds – Builds that are 100% ready for production

Although these different build types are built out of the exact same codebase, they cannot be mixed in the customer environment. ConfigMgr Tech Preview (TP) builds can only upgrade to other Tech Preview builds, and can never upgrade to ConfigMgr Production builds.   ConfigMgr Production builds can only upgrade to other Production builds, and can never upgrade to ConfigMgr TP builds.   You will not be able to accidently upgrade to the wrong build type, the system will prevent it.  The upgrade experience is the same: New updates will show up in the “updates and serving” node.   If you have a Tech Preview build installed, you will only see other Tech Preview builds in the “updates and servicing” node.  If you have a production build installed, you will only see other production builds which you can upgrade to.

Why have two build types?

Tech Preview builds: We want to be able to iterate on customer feedback fast.  This means we want to build new features, and get previews of those features out to the customers as soon as possible – so we have time to listen to feedback, and apply the feedback before finalizing our implementation of the feature and shipping it to production.  There are two types of feedback: 1) Feature Usability, and 2) Feature Quality.   Getting feedback on the feature itself and its usability is more important to us to get early, than it is to get feedback on the quality.   This is why we have the tech preview model – so we can get feedback on the feature usability, as early as possible.  This means we do not do a lot of quality testing on the tech preview builds.  And we limit what testing we do on the builds in order to get them out quicker.  This is why tech preview builds do not support hierarchies, and are English only, and support less than 10 clients.  We also may limit which versions of windows or SQL they can work with.  The faster we can get the build out to you to see the features, the more time we have to collect and implement the feedback.  For the production builds, we have a multi-month endgame where we do thorough quality validation; which includes things like scale testing, language and international testing, SQL & OS version testing, multiple upgrade path testing, and validation of all features end to end.  But the goal of tech previews is for you to look at new features and tell us what’s right about them, and what’s wrong with them.  Since last May, we have shipped 8 tech preview builds (Ignite build in May, 1507TP in July, 1508TP in August, 1510TP, 1511TP (also called SC TP4), 1512TP, 1601TP, and 1602TP in February.)   1511TP or System Center TP4 was the last Tech Preview build that you could install from scratch.  All the other Tech Preview builds since TP4 can only be installed by upgrading from TP4 (i.e. install TP4, and then go to the “updates and servicing” node, and choose a build to update to.).  We’ve started calling builds like TP4 a “baseline build,” because it is a build you can install scratch; and then you can upgrade to later builds.

Production builds: These are the builds that are ready for production.  So far, we’ve only release System Center Configuration Manager 1511 (current branch) to production.  It is a baseline build, and you can install the build from scratch, or you can upgrade to it from ConfigMgr 2012 SP1, SP1, R2 or R2 SP1.   Very soon – we will release another production build (called “1602 production”, but it will be an update only build.  You can only get to it by upgrading to it from 1511 production.  To install it, you go to the “updates and servicing” node in a production 1511 installation, and you choose to upgrade to it from there.

So two build types – don’t confuse them.

What about other build types? What is an evaluation build?    An evaluation build is a production build that customer who do not own ConfigMgr licenses can install and try.  The purpose of this build is for customers to try in the real environment, and experience the real quality and features of ConfigMgr.  So this build is a production build (It is literally the same build as production, you just choose “eval” during the setup process.)   Don’t get Eval confused with Tech Preview.  They are completely different.

I have a Pre-Production Environment / Lab (PPE), shouldn’t I use a Tech Preview build? No!   Many customers have PPE environments, which purpose is to mimic exactly the way their full production deployment is configured.  They test configuration changes, patches, and upgrades in their PPE environment first, and it works – then they make the same changes in their real production environment.  If your goal is to test production changes safely in PPE environments, which model your production environment exactly – they you should use the same production build that you are running in production.   Tech previews are disposable builds with lower quality for early feature feedback – not builds designed to run at production level quality and to mimic exactly production deployments.

1602TP vs. 1602 Production

Let’s see if we can bring this concept home.   Last month, we shipped the 1602 TP (tech preview) build, available here.   On the same date that we compiled that build, we also built the 1602 production build that will release very soon.  We only spent a couple days testing the 1602TP build before we shipped it out.  We’ve spent more than two months testing the production build, and built the final build five weeks ago.  Since then we’ve continued testing and have deployed it to 1 million devices.  Hopefully that illustrates the engineering teams focus on the two different types of builds – Tech previews = a couple of days of testing, then get it out early to get feedback.  Production builds = months of testing, with production customer deployments to verify quality before releasing.  I know it is confusing that they are both called 1602, and that’s why I wrote this blog; but also why I always try to say 1602TP or 1602 Production.