ConfigMgr Engineering Team Blog https://docs.microsoft.com/archive/blogs/configmgreng/feed.xml Random Ramblings from Djam, Director of Engineering, ConfigMgr Wed, 17 Apr 2019 03:25:28 GMT en-US hourly 1 User Voice updates for 1602 Production and 1603 Tech Preview https://docs.microsoft.com/archive/blogs/configmgreng/uvfor1602and1603tp Sat, 19 Mar 2016 01:52:58 GMT https://blogs.technet.microsoft.com/configmgreng/?p=111 User Voice and updated their status relative to last week's 1602 production build, and this week's 1603 tech preview build. Updated status due to last weeks 1602 production build:

Conditional Access for ConfigMgr

Patch O365 

Upgrade Site Server OS 

Client online status

Right click actions

WSUS 4.0 KB prereq

Refresh Policy from Software Center

Admin UI improvements for Touch

Disable SCEP scanning Network Drives

  Updated status due to today's 1603 tech preview release:

Tiles in Software Center

TFTP window size

Multi Select in Software Center

Hyperlink UI fix

  These updates free up over 2500 votes that you can now reuse to vote up your next favorite requests.    

]]> ConfigMgr Production builds vs. Technical Preview builds https://docs.microsoft.com/archive/blogs/configmgreng/prod_vs_tp Fri, 11 Mar 2016 16:59:06 GMT https://blogs.technet.microsoft.com/configmgreng/?p=73 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.      ]]> How Configuration Manager uses User Voice. https://docs.microsoft.com/archive/blogs/configmgreng/configmrguv Fri, 11 Mar 2016 14:47:08 GMT https://blogs.technet.microsoft.com/configmgreng/?p=63 User Voice. Let me give a little clarity in how we are using the status markings. Out of the box, UV doesn’t have the same status markings that we use for our internal work tracking tools.  For now, UV is limited to the following status values: “Noted”, “Planned”, “Started”, and “Completed”.   There are a couple others, but we are mostly sticking to those values.   One of the things we had to decide, is when to move UV Ideas from one state to another?  Those values are already quite vague and squishy.  Also, we want to be careful of falling into the trap of over-commitment features that are too far down the road.   So this is what we’ve decided:
  1. Noted – we understand the request, and it makes sense. We’ve added it onto our backlog somewhere.
  2. Planned – we’ve started coding for this, and expect it to show up in a tech preview build within the next couple of months
  3. Started – It is NOW in a tech preview. Go check it out, and give us feedback. Let us know if we are on the right track. You can even put the feedback in the comment section of the UV request, for others to see and comment on. We’ll read that and use the feedback to try to improve the feature.
  4. Completed – The first version of the feature is in a Production build. This doesn’t mean we are 100% done with the feature, and will no longer improve it. But it does mean that V1 of the features is in a production build, and you can start using it for real. We are making it completed because (1) we want you to know it is production ready, and (2) we want to give UV votes back so you can use them on other items. You can even file new DCRs to this feature to help us know the next most important improvement for this feature.
So there you have it… that’s our UV decoder ring.   A couple implications… most things will stay marked “Noted”, until they are 1-2 months from us being ready to show them to you.  Once they hit planned, they should probably go from Planned -> Started -> Completed fairly quickly. Given these definitions, I’ve updated the following UV items to be inline with these definitions:

Conditional Access for ConfigMgr

Patch O365 

Upgrade Site Server OS 

Non-OSD Task Sequences

Client online status

Right click actions

WSUS 4.0 KB

Cluster Patching 

HTTP image download 

Tiles in Software Center

Refresh Policy from Software Center

Extend 2008/R2 support for DPs

On-prem ConfigMgr

TFTP window size

]]> Hello World! https://docs.microsoft.com/archive/blogs/configmgreng/hello Tue, 26 Jan 2016 21:01:56 GMT https://blogs.technet.microsoft.com/configmgreng/?p=51 https://blogs.technet.com/b/configurationmgr/

https://blogs.technet.com/b/configmgrteam/

And Brad's blog will cover more strategic and more important issues:

https://blogs.technet.com/b/in_the_cloud/

So if those other blogs are more accurate, more real-time, more strategic and covering more important and news worthy issues - what's left for this blog? Mostly it will talk about ConfigMgr issues from the engineering team's point of view. Maybe a little 'inside baseball' on some design decisions (like "why did we create a CAS, if everyone says never use it?" Or "What's the future of metering?" Or "When are you going to bring back Logon Points?") Sometimes we'll discuss some of the engineering process, and how it's evolving and changing (like how the team is using uservoice, or we use telemetry.) And sometimes we'll just tell funny stories from the day to day engineering of the product (like the day I won this.) So Hello World! (I was going to go with a title more sms-centric, like "Capinst.exe!", or "Herm Me In!", or "net start Sitecomp.Blog"... but I didn't want to go too "inside baseball" on day 1.) -djam]]>