Windows 10 Servicing (Part Two): Or How I Learned to Stop Worrying and Love Microsoft (For changing things a lot).

So, a couple of posts ago I mentioned that I was happy about finally figuring out how Windows 10 should be updated, and I tried to decode how all the Windows 10 versions were named. Microsoft must have heard that I figured it out because they decided to change it again.

Bye Bye CB and CBB…

So they did away with the “Current Branch” and “Current Branch for Business” nomenclature, and are instead calling the new Windows 10 servicing model the “Semi Annual” Channel. To add additional confusion, they still are separating the new Semi Annual Channel into two “releases”.

Preview Release

There will still be preview releases of Windows 10 as the software is being developed

Hello Semi Annual Channel

When a version of Windows 10 is widely released, it will be known as “Semi Annual (Pilot).” During this time Microsoft recommends that you have some appropriate people testing the release so you can fix any issues with how it works in your environment. After a couple of months, it will become “Semi Annual (broad).” At this time Microsoft is assuming that you have tested sufficiently and are ready to deploy the software to the masses.

What’s With The Long Term Servicing Channel?

The Long Term Servicing Channel (formerly Long Term Servicing Branch) still exists in this model, but it is still should only really be used in static environments. It still will not support new technologies when they are released, and exists so that environments that absolutely can not update (the example that is always given is Hospitals, who are installing on computers that control large diagnostic equipment that can’t be taken offline to update, or might cost a ton of money to certify with a new OS).

The User Environment

Here is a run down of how our environment stacks up with each of the releases. (now that Microsoft has changed the names.)

  1. I think one of our network guys runs the Preview Releaseof Windows 10 on one of his machines. Maybe. We largely ignore Preview Releases of Windows 10. Sorry Microsoft.
  2. For our company we allow the infrastructure team to install Semi Annual (Pilot) on their primary machine. They do not have access to the Service Desk for support (though they also generally do not need it.)
  3. We are currently deploying Semi Annual (Broad) to all of our machines that get Windows 10. That number is not very large right now. We moved to Windows 10 on all of our Surface Pros because of the ability to work with multiple resolutions was much more advanced than Windows 8.1. We are also testing a few users with Windows 10 so that we can try to get ahead of the 2020 deadline for the removal of Windows 7.
  4. Long Term Servicing channel doesn’t support our needs at all. We don’t use it. Unless you have mission critical machines that can’t/don’t ever need to change over the next 7 years, you shouldn’t be using it either.

Here’s an outline of how we are doing Windows 10 servicing in our user environment.

Servicing Plan for Windows 10

  1. During Operating System Deployment (OSD), the newest version of Semi Annual (Broad) will always be installed. (currently this is the 1703 version.)
  2. Monthly patches will be provided through our “normal” monthly patching process.
  3. When support expiration is announced for a specific version, two branches of Semi Annual (Broad) will become available in Software Center for users of the expiring version. (Example, when 1703 expiration is announced, the two active CBB versions (1709 and 1803 will be made available)
  4. When support expiration is reached, if the user has not updated their computer they will be required to install the newest of the two CBB Branches. (Example, when 1703 expiration is reached, users will be required to update to 1803 rather than 1709, which is the older version.) Jumping them ahead a version should make it so the user will need to update the computer less frequently.

How we are making it happen

  1. We will create device collections in ConfigMgr that include machines with each of the Windows versions. (Example: machines with 1607 Pro and Ent, 1703 Pro and Ent, 1709 Pro and Ent, 1803 Pro and Ent)
  2. We will create upgrade task sequences in ConfigMgr for each Windows 10 version as they are released by Microsoft.
  3. Those Upgrade task sequences will become available in Software Center for members of the Windows 10 device collections as versions become Semi Annual (Broad). Example: when 1709 becomes Semi Annual (Broad), it will be an available update for members of the 1703 and 1607 device collections.
  4. Task sequences will become required as branches reach End Of Life so that computers will not be unpatched in the environment. Example: When 1607 becomes EOL, the 1709 Upgrade Task Sequence will become a required install for computers in the 1607 device collection.

So I think this is all correct. With the Semi Annual channels, Microsoft is promising two releases a year in March and September. It will be interesting to see if they can keep up with the pace, and what happens if they run into a big bug right before the release of one of the semi annual updates. Do they keep the name the same and just release it a bit late, or will they feel obligated to call it 1811 if the release comes out in November rather than September as promised. Time will tell.

 

 

Using Task Sequences Outside of OSD

One of the most useful tools that exists within SCCM is the Task Sequence. Often when we first use ConfigMgr we think of Task Sequences as being used in Operating System Deployment, and don’t get much further than that. At least I didn’t. However, the truth is that Task Sequences can go way beyond Operating System Deployments, can be deployed to any computer and can do some great things that can’t be done other ways.

So Why would I want to do that?

  1. So that you can link things together that normally can’t be linked together. Think about all of the things the Task Sequence is doing in an OSD scenario. Even the most basic OSD Task Sequences format the hard drive of your machine, install an OS, load drivers, and install applications. That is a huge variety of things that can normally not be linked together in ConfigMgr. Sure, It is possible to have an application install be dependent on another install. For example you can tell SCCM to install Salesforce for Outlook, but before it does that, make sure that the required C++ versions are installed. However that will only work if both your Salesforce for Outlook and C++ installs have been created as Applications (or Packages.) If for some reason one of your required apps installs better as a package, and your other installer is an application, they can not be linked together. However, if you create a task sequence, you can have it first install the required package, and then after that install the application you needed in the first place. It’s as simple as creating a two step task sequence one step for the package, and one step for the application.Screen Shot 2017-07-07 at 1.25.13 PMThe above screen shot uninstalls Java using a Package, and then installs Java using an Application.
  2. Do you have two applications (or an application and a package) that need to be run, but you need a reboot between the applications? Task Sequences can reboot a machine, and then continue on with the task sequence and with the steps that are following. We often use this when we are removing an older version of software (like say Office 2010) before installing the new version (Office 365) when the installer doesn’t clean up the old version. In this example our task sequence looks like this. We run the uninstaller app and restart, and when the computer comes back up it will run the installer application. Screen Shot 2017-07-07 at 1.26.03 PM
  3. Other more complex Task Sequence “things”. I will describe this in more detail in an upcoming blog post, but we also use task sequences to update the BIOS/UEFI on our machines quarterly. In this scenario, we run a task sequence step to disable Bitlocker on our laptops and Surface Pros, run the bios update software, reboot, and then reenable Bitlocker after the machine comes back up. Screen Shot 2017-07-07 at 1.27.16 PM

There are a couple of things to note about using Task Sequences in this way.

  1. Task Sequences, just like pretty much everything else that can be deployed in ConfigMgr, can be made to be available, or to be required. You can have them show up in Software Center to be run, or you can hide them from software center. They will show up as they are running with the “running task sequence” dialog box.
  2. Task sequences have a cool feature that allows you to download all of the task sequence steps before beginning. That means it won’t download the software from each step as needs it, it will cache it beforehand. This will be extremely helpful if the machines that are being installed to are on slower connections.
  3. As of ConfigMgr 1703, Task Sequences can only be assigned to computers or collections of computers. They can not be assigned to users or user groups. So remember it may take a little while for the Task Sequence to show up in the Software Center window.

That’s it for now, I will get into some of the nitty gritty of how we have done things like enabling Bitlocker remotely on laptops using a Task Sequence, and how we uninstalled Office 2010 and installed Office 365 on all of our user machines using a task sequence but that will have to be in an upcoming post.

Windows 10 Servicing: Or How I Learned to Stop Worrying and Love Windows 10.

How Windows 10 versions should be updated was something I had a ton of trouble understanding from an enterprise perspective. On one level as master of my own machine, I could install every new version when it was released. That would have been the original install in July 2015 (version number 1507), and upgrades in November 2015 (1511) , July 2016 (1607), and March 2017 (1703).

But then we started installing Windows 10 in our user environment. We gave those machines to our Executives, on Surface Pros. Suddenly it became more important to figure out how we were going to upgrade machines when versions of Windows 10 became end of life. Oh yes, versions of Windows 10 become end of life, and after that they won’t be getting any further security updates. No pressure right?

Check with Microsoft?

Microsoft has a lot of information out there on how the different “rings” and “branches” work on their website. Feel free to search for it and take a look. However, when I was done I was still confused how it all worked together and what the different branches of Windows 10 even meant.

Eureka!

The real answer of what to do with Windows 10 servicing came when I officially comprehended (at the Midwest Management Summit of all places) that each of these “Branches” of Windows 10, is really the same version, just at a different place in its support lifespan! No wonder I couldn’t find the Current Branch for Business release anywhere on the Volume Licensing site. Suddenly thinking about how to do Windows 10 Servicing with ConfigMgr became much easier

Background on Windows 10 Branches

Each Windows 10 release has 18 months from street date to end of life. During that time the releases go through different “branches” or their life.

As of today, Windows 10 has four different branches. They are:

  1. Preview Release: This is not part of the 18 months of Street Date to EOL. Microsoft would love for you to install this on one or two machines so they can be assured that it’s working correctly. Only ever put it on a machine that is not critical, and can be completely reimaged if necessary.
  2. Current Branch: This is what Windows 10 is considered immediately after it is released, and it remains until the day Microsoft removes it from support.
  3. Current Branch for Business: After Current Branch has been released for approximately three months or so, Microsoft considers that it is ready for Enterprise customers, and adds the version to what is called Current Branch for Business. There will always be two releases of Windows 10 that are considered Current Branch for Business, and it is possible that there will be three at some times.
  4. Long Term Servicing Branch: This branch is for very specific machines, and Microsoft recommends that it is only used for very specific needs. In this branch, the actual features of the OS will never change. Microsoft will provide security updates, but that is the extent of the support. Don’t use this in a real world environment unless you know you need it. Don’t do it. Someone will want to bring a new machine into your environment in a couple of years and it won’t work, because it won’t support new features.

So the real question is how do all of these fit into an actual working user environment?

The User Environment

Here is a run down of how our environment stacks up with each of the releases.

  1. I think one of our network guys runs the Preview Release of Windows 10 on one of his machines. Maybe. We largely ignore Preview Releases of Windows 10. Sorry Microsoft.
  2. For our company we allow the infrastructure team to install Current Branch on their primary machine. They do not have access to the Service Desk for support (though they also generally do not need it.)
  3. We are currently deploying Current Branch for Business to all of our machines that get Windows 10. That number is not very large right now. We moved to Windows 10 on all of our Surface Pros because of the ability to work with multiple resolutions was much more advanced than Windows 8.1. We are also testing a few users with Windows 10 so that we can try to get ahead of the 2020 deadline for the removal of Windows 7.
  4. Long Term Servicing Branch doesn’t support our needs at all. We don’t use it. Unless you have mission critical machines that can’t/don’t ever need to change over the next 7 years, you shouldn’t be using it either.

Here’s an outline of how we are doing Windows 10 servicing in our user environment.

Servicing Plan for Windows 10

  1. During Operating System Deployment (OSD), the newest version of Current Branch for Business will always be installed. (currently this is the 1607 version.)
  2. Monthly patches will be provided through our “normal” monthly patching process.
  3. When support expiration is announced for a specific version, two branches of CBB will become available in Software Center for users of the expiring version. (Example, when 1507 expiration is announced, the two active CBB versions (1511 and 1607) will be made available)
  4. When support expiration is reached, if the user has not updated their computer they will be required to install the newest of the two CBB Branches. (Example, when 1507 expiration is reached, users will be required to update to 1607 rather than 1511, which is the older version.) Jumping them ahead a version should make it so the user will need to update the computer less frequently.

How we are making it happen

  1. We will create device collections in ConfigMgr that include machines with each of the Windows versions. (Example: machines with 1507 Pro and Ent, 1511 Pro and Ent, 1607 Pro and Ent, 1703 Pro and Ent)
  2. We will create upgrade task sequences in ConfigMgr for each Windows 10 version as they are released by Microsoft.
  3. Those Upgrade task sequences will become available in Software Center for members of the Windows 10 device collections as versions become Current Branch for Business. Example: when 1703 becomes CBB, it will be an available update for members of the 1511 and 1607 device collections.
  4. Task sequences will become required as branches reach End Of Life so that computers will not be unpatched in the environment. Example: When 1507 becomes EOL, the 1607 Upgrade Task Sequence will become a required install for computers in the 1507 device collection.

So that’s how I was able to get my head around the servicing of Windows 10 with ConfigMgr… hopefully this helps you think about it as well.

First blog post, like a first photo.

Hey everyone,

Welcome to my new Blog, ConfigMgr Everyday. This is officially the first Blog post, which seems to me to be a lot like the first picture taken on a camera. You take it out of the box, play around with the new features (and in my case the new lenses) and finally, you are ready to take the first picture. Hopefully it turns out.

The purpose of ConfigMgr Everyday is to document one person’s use of Microsoft System Center Configuration Manager (ConfigMgr, or SCCM) to get every day, normal, maybe even boring, tasks done. There are many blogs out there that can tell you how to tweak this or that so that your task sequence will finish 10 seconds faster, or what the most exciting upcoming feature of the preview release of ConfigMgr. I love reading that stuff, but sometimes I just need to know how someone created collections determined by which ConfigMgr Client is installed on every machine in our environment. And you can be guaranteed I am going to copy and paste the SQL query if I find it. To steal a phrase from the past that is almost completely irrelevant in this day and age, “SQL is not my bag, baby.”

So the picture at the top of this page is the very first picture taken with my new Olympus Digital camera. It was an early Father’s Day present. After moving from a 10 year old DSLR, it’s like a night and day difference in using this new camera. The camera took a pretty good picture.

There, I am finished with my first blog post, and it’s time to unleash the blog to the world. Hopefully it turns out.

Marty