3 Replies Latest reply on Aug 11, 2017 2:41 PM by Peter Massa

    How is everyone handling Windows 10 Deployment Rings?

    GJHorn Apprentice

      Just trying to get my bearings with Windows 10 feature update patching in relation to setting Semi-Annual Channels. In other words, do we set semi-annual channels - broad and targeted through GPO? Can we set the semi-annual channels through AD security groups?

       

      What tells Ivanti endpoint patch manager that a computer is in a certain semi-annual channel mode - targeted or broad?

       

      Would anyone like to describe how they perform these feature updates or quality updates? I need a little of the nuts and bolts.

       

      I'm running IEM 2017.1.

       

      Thanks.

        • 1. Re: How is everyone handling Windows 10 Deployment Rings?
          Peter Massa Expert

          Hi GjHorn,

           

          How do I perform the feature upgrade?

           

          There are three primary methods to do the upgrades:

          1. Patch delivery via the Patch and Compliance definition of the feature upgrade

               - This content is provided right after the feature update is released by Microsoft as a standard patch.  You simply stage the ISO on the share, detect, then deploy.  This performs a generic upgrade with no customizations.

          2. Software package deployment of the upgrade

               - This method allows more customization of the deployment of the feature upgrades by allowing you to call a script to do "pre" work, then call the setup.exe to perform the upgrade, while passing in the setupcomplete.cmd option to then run a "post" work script.

          3. Provisioning template deployment of the upgrade

               - This would be a full step by step deployment of the upgrade where you may want to go beyond the basic ability to run 1 pre upgrade and 1 post upgrade script, and instead want to chain many steps together with more detailed reporting.

           

          Comparatively in SCCM they offer the exact same 3 options almost exactly via Windows 10 Servicing (option 1), Windows Upgrade Package (Option 3), or Custom Package deployment (Option 2).  So deployment feature wise, you have everything in your tool kit ready to go.

           

           

          So what are Windows Servicing Rings?

           

          Microsoft releases iterations of their Operating Systems and Office Suite in periodic feature "upgrades".  You can subscribe to a ring to get the feature update on a specific schedule.  Not all updates make it through every ring, as may do not make it past the internal Microsoft rings or the insider preview ring.  Once a build has been deemed "stable" then it gets released to the Current Branch.  These are typically every 6 months for the "Current Branch" releases.

           

          Once a build has been released into a branch (aka ring), it will receive only Quality and Security updates until it reaches its End of Life.  Hence why it is called a branch, it extends until it ends, while the main tree continues to grow (new features).

           

          There are many rings or branches:
          Microsoft Internal Rings -> Insider Preview Ring Fast -> Insider Preview Ring Slow -> Current Branch -> Current Branch For Business -> Old Branch -> EOL

           

          What is recommended?  Microsoft has stated that businesses should create their own internal rings modeled after the above.  I have seen where they recommend the following:

          1% of systems on Insider Preview

          20% of systems on Current Branch (RedStone II)

          79% of systems on Current Branch for Business (Current Branch - 1; RedStone I)

           

          This means it is up to you to decide the actual breakdown % wise of what rings you want your systems to be in and deploy accordingly.

           

          How should I configure rings?

           

          So traditionally via the GPO setting you would tag 20% of your systems for "CB" and 80% of your systems for "CBFB" then let the tool automatically deploy when times comes.

           

          SCCM, WSUS, and Windows Patch for Business however have logic built into their scanners to look at the GPO setting that you are talking about to decide when to install the feature updates if you specifically use the "Windows 10 Servicing" option in them.  IEM/LDMS however does not look at that setting natively so setting it would not benefit you.  Being that it is just a registry key - you could possibly request Ivanti to add custom code into the feature update scripts that they provide to look at the registry settings that get set and "honor" them, but currently they do not.

           

          What we did in order to get the same capability is set up a specific Registry key that signifies one of these three options: Fast, Normal, Slow.  By default if the key does not exist, systems are added to the Normal ring.  We then setup in our inventory scanner settings to capture this registry key value into inventory so that we can do queries off of them.  We then provide a script via the portal manager to allow users to "opt-in" to the ring that they want - which simply sets the registry key for them.

           

          We only deploy insider preview with-in our internal IT dept so that is taken care of by its self and doesn't really need managed.  The focus is on the 20% CB and 80% CBFB split.  That being said we know that it will never stay at that %, it will ebb and flow as systems upgrade versions.  So we actually don't split our systems into "2" rings, instead we control the speed of the feature deployment using the above 3 selects.  We create a query that targets systems that have opt'ed in to the Fast ring and some of the Normal ring, using the first character of the Device ID guid to randomize them (e.g. {0), these are systems that will get the upgrade targeted to them first.  Then we create a few queries that target just the Normal ring, again randomized by the guid's first character, so that there are 6 equal groups.  Then lastly a query of the Slow ring.

           

          We then schedule the deployments of the upgrade (using any of the 3 above methods) to start at future dates automatically spread out by these queries.  This can be done with a rollout project.

           

          Basically its not a fine science, and its completely up to you on how you want to handle them.  Microsoft just provides examples.

           

          Hope this helps,
          Peter

          1 of 1 people found this helpful
          • 2. Re: How is everyone handling Windows 10 Deployment Rings?
            GJHorn Apprentice

            Thank you, Peter for the great response! This is very helpful. One question though on your sentence here "We create a query that targets systems that have opt'ed in to the Fast ring and some of the Normal ring, using the first character of the Device ID guid to randomize them (e.g. {0), these are systems that will get the upgrade targeted to them first." What in inventory are you targeting in the query showing the device is in the Fast Ring or Normal Ring?

             

            Thanks, again.

            • 3. Re: How is everyone handling Windows 10 Deployment Rings?
              Peter Massa Expert

              We have scripts that end users can pick from as to what branch they want to be part of that are listed in our Portal Manager/Workspaces:

              This then stores a value in the registry:

              hklm\software\customdata\OSBranch - with the value of fast, normal, or slow.

               

              We then configure IEM/LDMS to import this value into inventory by going to:

               

              In our case - we actually extended our schema to have a branch of inventory called "ImageInfo" with different details under it.  If you do not want to do that, you can just add the value to the normal custom data location.

               

              Then a query would look something like this:

              IEM breaks down systems into 16 even groups of Device IDs {0 through {f.  We can use these to evenly split up deployments and randomize them since IEM does this for us automatically.

              The above query means:

              1. No Servers.

              2. Devices that are not a server and have a Device ID starting with {0 (so exactly 1/16th of your systems) that are also in the "normal" ring.

                  (remember normal ring is either the lack of any setting or the user specifically set it to "normal" so we have to check for both possibilities)

              3. Any device that is not a server and chose "fast".

               

              This means that all of your "fast" ring are in this query and 1/16th-ish of your normal ring.  So you could target these systems first for upgrade since you know that the users opted in to get updates first and you randomly add a portion of the normal ring.

               

              Then you can do a second query like:

              Which would mean:

              1. No Servers.

              2. Devices that are not a server and have a Device ID start with {1-3 (so exactly 3/16th of your systems in the normal ring) and are in the normal ring.

               

              Then you could keep going - do 4-6, etc then end with your "slow" ring.  You can size them to meet your needs and then schedule them via a rollout project to deploy on your schedule or just manually schedule the deployments.

               

              Hope this helps,
              Peter