Wednesday, February 28, 2018

Disable upgrades in Win 10 (1607)

Disable upgrades in Windows 10 1607 (Anniversary Update)


Introduction - main concepts


     Why do you need to stay on an older, maybe even an obsolete version of Windows 10?
    First, Windows 10 Anniversary Update (1607) is not an obsolete version of Windows 10. For Windows 10 Enterprise and Education versions, the end of the mainstream support is October 9, 2018 (on Semi-Annual Channel) [1]. Windows 10 Enterprise, on Long-Term Servicing Channel (LTSC), will be supported up to October 13, 2026. On LTSC each Windows release is supported 10 years (five years standard support, five years extended support).
     Second and most imported, Windows 10 Anniversary Update is the best operating system from the point of view of the Bluetooth Low Energy (BLE) devices. It is the only operating system that supports the notify data transfer mechanism with a BLE device. The software used in this communication process was developed based on Windows 10 SDK – using Bluetoothapis API [2].
     Knowing all of these, the main idea is to stay as long as possible on Windows 10 Anniversary Update (1607) before Microsoft forces us to update our system to a newer release of Windows OS.
     Mainly the Windows OS pulls updates directly from Microsoft’s Windows Update servers. But, there are some options that a user can set to determine when and how updates are downloaded and applied.
     The Windows Update for Business is an option that makes it easier for a user to manage updates in Windows 10 Pro, Enterprise, and Education. You can use Group Policy to configure Windows Update for Business settings for your devices.
     In Windows 10 are three types of updates [3]:
  1. Feature Updates (previously referred to as upgrades) contain security, quality revisions, and significant feature additions and changes – they are released two times in a year.
  2. Quality Updates (previously referred as operating system updates) include security, critical, and driver updates. Windows Update for Business includes non-Windows updates, such as those for Microsoft Office or Visual Studio, as Quality Updates. The Quality Updates are typically released on the second Tuesday of each month.
  3. Non-deferrable updates: antimalware and antispyware Definition Updates. These updates cannot be deferred in any form.
    In Windows Update for Business, the Feature and Quality Updates can be deferred from deploying within a bounded range of time from when those updates are first made available on the Windows Update Service.

      For example, the [3]:
  • Feature Updates can be deferred from deploying with maximum: (a) 365 days for Windows 10, version 1703 or newer and (b) maximum 180 days for Windows 10, version 1511 to version 1607.
  • Quality Updates can be deferred from deploying with maximum 30 days.


    Defer feature updates


        So let's start to defer feature updates using Group Policy:
    1. Press Windows Key + R;
    2. Type gpedit.msc and hit Enter to open the Group Policy Editor (the Group Policy Editor is available only in the following Windows 10 editions: Professional, Enterprise or Education);
    3. Navigate to the following setting: Computer ConfigurationAdministrative TemplatesWindows ComponentsWindows UpdateDefer Windows Upgrades;
    4. Double-click on Select when Feature Updates are received;
    5. From the drop-down menu select Current Branch for Business and then the period for which you want to defer the updates: 180 days. So, using “Current Branch for Business” we will get feature updates more slowly. 
    6. You may select the Pause feature updates checkbox if you wish to. I’m not sure what exactly this option does. Maybe this will add an extra 60 days???? But I’m sure that [4]: “After 60 days has passed, pause functionality will automatically expire and the device will scan Windows Update for applicable Feature Updates. Following this scan, Feature Updates for the device can then be paused again”. So, I think it will not add 60 days extra.
    7. Select Apply.

        For Windows Update for Business to be active, the Diagnostic Data level of the operating system must be set to 1 (Basic) or higher [5]. If it is less than 1 – set to 0 (Security) – Windows Update for Business policies will have no effect. The Basic level gathers a limited set of data that are critical for understanding the configuration of the OS. This level also includes the Security level data which includes the Connected User Experiences and Telemetry component. The reason the telemetry policy must be set is that the information about successful or unsuccessful Windows Update operations is sent to Microsoft. So, Microsoft’s Windows Update service needs to know the state of your machines related to Windows updates to determine what updates and upgrades it must send.
        Set the Diagnostic data level using Group Policy
    1. Press Windows Key + R;
    2. Type gpedit.msc and hit Enter to open the Group Policy Editor;
    3. Go to: Computer ConfigurationAdministrative TemplatesWindows ComponentsData Collection and Preview Builds;
    4. Double-click on Allow Telemetry;
    5. In the Options box, select the level that you want to configure - at least 1;
    6. Then click OK.


    Disable Automatic Updates


        If you want to be informed before the updates are downloaded or applied disable Automatic Updates. 
        Based on the same Group Policy disable Automatic Updates:
    1. Press Windows Key + R;
    2. Type gpedit.msc and hit Enter to open the Group Policy Editor;
    3. Go to: Computer ConfigurationAdministrative TemplatesWindows ComponentsWindows Update;
    4. Double-click on Configure Automatic Updates;
    5. In the properties box which opens, select Enabled;
    6. From the drop-down menu select: Notify for download and notify for install (see the following figure);
    7. Then click OK.


    Applications to disable the feature update


        But sometimes even the ability to pause updates for 180 days isn’t quite enough. From such situations are several types of Windows 10 update blocking tools, such as:


    [1] C. Fitzgerald, Changes to Office and Windows servicing and support, online at

    [2] D.M. Dobrea, Windows Bluetooth system analysis – a SensorTag approach, online at

    [3] D. Halfin, J. Decker, N. Brower, B. Lich, Deploy updates using Windows Update for Business, online at

    [4] D. Halfin, J. Decker, N. Brower, B. Lich, Configure Windows Update for Business, online at

    Friday, February 23, 2018

    SensorTags errors

    Understanding and solving different SensorTag errors

          In this post, I present in a centralized place all the articles already published on this blog in which are presented the causes and the methods of solving of the various errors that occur in the connection, communication, and presentation of the information from the different SensorTag devices. 
    1. The problems generated by the Windows operating system: Windows Bluetooth system analysis – a SensorTag approach;
    2. The issues generated by the battery low level: Dealing with sensors communication errors.



    Tuesday, January 23, 2018

    Creating and triggering events

    Events and triggers are functionalities implemented starting with version of the blessTags application – but, only in the full version of this application.
    Events are things that happen within your blessTags app environment at which you might want to act in a specific way. Up to now, these events might be things like a specific value of a sensor (embedded on a SensorTag) that meet a condition or a series of conditions.
    Currently, the blessTags application supports events from the following providers: all the sensors information that is acquired and displayed, from a SensorTag, on the user interface.

    blessTags user interface

    Each active numeric data source, presented in black color on the blessTags user interface, can be a source of events. In the figure presented above, only the information from the pressure sensor cannot be used as a source of events - this only happens because the application user has not activated one of the data reading mechanisms (reading or notifying) from this sensor positioned in the SensorTag. For example, the z-channel acceleration or the humidity or the ambient temperature or, why not, the SensorTag’s battery power level, etc. can be considered as sources of events. 
    The events can be generated by the instantaneous value, the mean value or the variance value of the data flow from a specific sensor.
    To create and trigger events, you must double-click on a specific value associated with a specific sensor. As a result, the following window will appear.

    Setting events and specific triggers

    An event will be generated if the desired value (instantaneous, mean or the variance) is lower or higher than a threshold value or is inside or outside of a specific range of values. 
    If one of the specific conditions is meet a trigger will be generated. As a result, the user will receive a visual or an audible alert or a data saving process will be generated (previously configured by the user: specifying the saving channels and a data window length). You can also choose any combination of these triggers.
    If the trigger was a data saving process, from the moment when an event was generated, in the end, the user must additionally save all these data series manually to a file. 
    The user has the possibilities to display and delete all the triggering events globally. To do these the user must go into developer mode from where he/she has these possibilities using two specific buttons – see the figure from below.

    Developer user inter

    Monday, November 20, 2017

    Windows BLE analysis - a SensorTag approach

    Windows Bluetooth system analysis – a SensorTag approach

    D.M. Dobrea

         In the following, I will do an analysis of the Windows operating system (OS) from the point of view of communication with Bluetooth Low Energy devices – in our case with different types of SensorTags: Thunderboard React, Thunderboard Sense (both produced by Silicon Labs Company), CC2650STK and CC2541DK (both developed by Texas Instruments Company).
         I what follows, I will analyze Windows 7, Windows 8 and the following Windows 10 versions:
    • Anniversary Update - 1607 (released on August 2, 2016; end of support: April 10, 2018; end of additional servicing: October 9, 2018),
    • Creators Update - 1703  (released on April 5, 2017; end of support: October 9, 2018; end of additional servicing: April 9, 2019) and 
    • Fall Creators Update - 1709 (released on October 17, 2017; end of support: April 9, 2019; end of additional servicing: October 8, 2019). 
    The end of additional servincing period of time is only for Windows 10 Enterprise and Education [1].
      The analysis will be done from the following points of view:
      1. The ability of the operating system (OS) to pair with the SensorTag; 
      2. The ability to get Generic Access data (this is a mandatory service); 
      3. The ability to get Device Information (this service exposes manufacturer and/or vendor information related to a specific SensorTag);
      4. The ability to get the SensorTag's data using for this the reading approach and
      5. The ability to get the SensorTag's data using for this the notification approach.
      All the tests will be done using version of the blessTags application.
      The blessTags application was built having as support the Windows SDK – Bluetoothapis. Functions like BluetoothGATTGetCharacteristicValue, BluetoothGATTGetDescriptorValue, BluetoothGATTGetServices or BluetoothGATTSetCharacteristicValue were used.
      This application, blessTags (BLE SensorTags) application, can be downloaded from the Windows Store Apps: For more information, demo, practical applications, examples etc. please visit the following blog:

      Windows 10 - Anniversary Update - Version 1607

      This version of the Windows 10 operating system is the best one, from the point of view of Bluetooth Low Energy devices. It is able to pair without any problem with all SensorTags (regardless of the software version running on them), with which blessTags application knows how to work (CC2650STK, Thunderboard React, Thunderboard Sense and CC2541DK), and all the information from the Bluetooth’s Services Services Get Generic Access and Get Device Information is acquired without any problem.
      Analyzing the data acquisition speed (for CC2650STK and CC2541DK devices) using notifying and reading mechanism of data transfer, we can observe the following:
      1. through the notification mechanism, we can get data from all sensors (eight) from 150 [ms] to 150 [ms] without any problems;
      2. instead, when we set the acquisition time to 150 [ms] and we use the reading mechanism - in the happiest situation, we get 713 [ms] and in the worst case, we get 840 ms.
      If we will analyze Thunderboard React and Thunderboard Sense we will get the equivalent results – they work without any problem in the Windows 10 Anniversary Update environment.
      In fact, all the presentation movies of the blessTags application main functions and of the different specific features (like Gadgets) have been made with the support of the Windows 10 Anniversary Update.
      A small demonstration and a proof of the above statements in the following movie:


             Windows 10 - Creators Update - Version 1703

      The Creators Update version of Windows 10 is the worst operating system from the point of view of Bluetooth Low Energy devices. 

      Almost nothing is working. Microsoft acknowledged that the Creators Update breaks Bluetooth Low Energy (reference1 and reference2). The Microsoft company promised a hotfix as soon as possible. But since then they have released an updated version of Windows (Fall Creators Update) and nothing has happened up to now within the Windows 10 Creators Update version, the Bluetooth Low Energy still does not work.
      There are a large number of posts on forums in which different peoples complains regarding different types of Bluetooth devices that stop working after upgrading to Creators Update (see here, see here, see here, see here etc.).
      The results, I'm going to show right away, were obtained after many tests: (1) on a desktop PC that had a CSR4.0 Bluetooth USB dongle (CSR8510 A10) and (2) on a Dell Inspiron P66F laptop with an integrated Bluetooth LE device. I know there are many solutions to fix several types of Bluetooth issues. I tried all, but nothing was working (update the Bluetooth driver, run Windows troubleshooter, disable and enable Bluetooth related services etc.)
      So, let’s present the results:
      1.      CC2650STK:
      a.         On the firmware version 1.40 pairing the SensorTag device with Windows is impossible (I repeated the process several times, at least 8-10 times, I turned on and off the Bluetooth and I tried again – the results were the same: it was impossible to add this device).
      b.           In the firmware version 1.20, the PC discovered the SensorTag and I was able to pair the SensorTag with the PC. 
          Also, I was able to get Generic Access data. But, at the Device Information service, from 9 characteristics only 6 responded and only from them it was possible to get data.
      Instead, I cannot set up the device and I cannot retrieve data from sensors either through the read mechanism or through the notifications.
      2.      Thunderboard React:
      The operating system has a strange behavior when the pairing process is initiated. In the list of discovered devices, the SensorTag appear and disappear (with a period of 1 … 1.5 s). Finally, when a mouse clicks succeed on the SensorTag, the pairing process accomplishes and the LEDs on the Thunderboard React (the blue and the green ones) have a period when they are flashing consecutively in an atypical mode.
      The reading of the characteristics of the Generic Access Service (0x1800) can be done without any problem, but the reading from Device Information Service (0x180A) fails on all four existing characteristics.
      Setting the sensors (embedded on SensorTag), the mode of acquiring data (on Thunderboard React you have only the following possibility: (1) to get data through the notification from 3 sensors and (2) to read data from the other four sensors) is impossible. Therefore, the impossibility of obtaining actual data from sensors results directly from here.
      3.      Thunderboard Sense:
      The same pulsating process, observed for Thunderboard React, was found to be also existing for Thunderboard Sense - when we want to achieve the pairing process. But here, things are even worse: after pairing the blessTagprogram cannot detect the SensorTag. So, no active device - no entity from where the blessTags application to acquire the data.
      4.      CC2541DK
      The behavior is identical with the behavior of CC2650STK (firmware version 1.40). At each connection attempt, you will get the following error message: "Try connecting your device again".
          So, in conclusion, within this version of Windows 10 (Creators Update), it is impossible to communicate with any of the four types of SensorTags point out above. Consequently, I mention (once again) that here I have used the same software version that I also used in all test made on Windows 10 Anniversary Update.


          Windows 10 - Fall Creators Update - Version 1709


           This version of Windows 10 (1709 – OS Build 16299.19) is a huge step forward, compared with Windows 10 Creators Update (were on BLE almost nothing is working), but still has a long way to get to the level of Windows 10 Anniversary Update (1607) operating system.

      But let's see why I made this statement:

      1.      CC2650STK (firmware version 1.40) & CC2541DK:

      I will treat these two devices here simultaneously because their behavior related to the Windows 10 (1709) operating system is similar.

      The pairing operation and the reading, from the Generic Access and the Device Information services, are working perfectly without any kind of problems.

      The problems only occur when we want to read information from the sensors. The data transfer mechanism through notifications does not work at all
      The only way to get data from the sensors, embedded in the SensorTag, is by means of the direct reading mechanism from the device. This approach has two issues: (1) lower data transfer speed (as we have shown above) (2) if all the sensors accept the two data transfer methods (through reading and notification), the buttons on the SensorTag can be interrogated only through the notification mechanism. Thanks to this "feature" of the Windows 10 (1709) OS, the blessTags application implements, starting with version, the reading method for data acquisition also.

      A problem appears with the CC2650STK SensorTag having the firmware version 1.20. If the process of pairing and data reading from Generic Access service works very well, the reading process from Device Information services is not possible. Moreover, the sensors reading (from this SensorTag) does not work through either one of the two possible mechanisms (reading or notification).

      2.      Thunderboard React

      In the same mode as in Windows 10 Creators Update, the SensorTag appear and disappear when we want to add a new Bluetooth device. The same behavior can be highlighted in the action center on Bluetooth’s quick action button were "Not connected" and "Thunderboard React" are displayed repeatedly (please see the following movie starting from the time index 5.14 s). Immediately we can conclude that Thunderboard React is guilty, mainly due to a flawed implementation of the advertising mechanism by Silicon Labs engineers. But, searching on the internet, we will notice that other users reported this problem to other BLE devices after installing the Fall Creators Update – e.g. view this movie on YouTube.

      After pairing the SensorTag, the blessTags application is not able to find the Thunderboard React device. So, at this point nothing is working:  Generic Access and the Device Information services or data acquisition from the sensors embedded on Thunderboard React SensorTag.

      3.      Thunderboard Sense

      The mode to behave is similar with the one of Thunderboard React, this Bluetooth device is displayed and disappear repeatedly. When the pairing process succeeded, it is possible to take data from Generic Access Service. But from this point, nothing is working anymore.

      As a conclusion, up now on Windows 10 Fall Creators Update (1709, build 16229.19) only the SensorTags produced by TI (CC2650STK and CC2541DK) are working. More, they are working only in reading mode. But attention! Only CC2650STK firmware version 1.40 will work in this mode. Unfortunately, when you buy a CC2650STK you have a very high chance of taking a device with firmware revision 1.20. So, to be able to communicate with a such a type of SensorTag an upgrade it is necessary at least to the firmware version 1.40.
      Below I present a movie that proves all these statements made above for Windows 10 Fall Creators Update.

            Since the first release of Windows 10 Fall Creators Update (build 16229.19), on October 17th, 2017, there have been no improvements or errors corrections related with Bluetooth LE up to KB4054517 (released on December 12th, 2017). In KB4054517 (OS Build 16299.125) there is a key change on Bluetooth LE (see here): “Addresses issue with personalized Bluetooth devices that don't support bonding”. Since this message is very cryptic, I've decided to resume all my analysis donned so far and to see if there are any improvements compared to the first release of Windows 10 Fall Creators Update (build 16229.19).  … and a little surprise, right now I am able to get: (1) data from Thunderboard Sense (from the sensors embedded on the SensorTag but only through the reading mechanism) and (2) all the information from Generic Access and Device Information services. There are no other improvements. 

           Windows 8

      As a first Microsoft OS with BLE support, the implementation is satisfactory, but it is far to be an excellent one. The only devices that work with this operating system are CC2650STK and CC2541DK.
      Setting the acquisition time to 150 [ms], for the CC2650STK, we can get the data (from all embedded sensors), complying the 150 [ms] sampling rate, through the notification mechanism without any problems. Unfortunately, using the CCC2650STK reading mechanism, we can get data (from all the sensors) with a period of 2 seconds.
      The situation is getting worse when we are talking about CC2541DK. Through the notification mechanism, the data is obtained with a period of 0.4 ... 0.6 seconds. While using the reading mechanism we can retrieve the data with a fluctuating period of 2.8 ... 3 seconds. The conditions are the same: acquisition period 150 [ms] from all the sensors embedded on the CC2541DK SensorTag.


           Windows 7

      The Microsoft company has added support for the Bluetooth Low Energy (BLE) stack starting with the Windows 8 operating system. They have provided an API which enables applications to access BLE devices.
      But the Microsoft has not ported the BLE API's to Windows 7. The Windows 7’s built-in stack supports only Bluetooth version 2.1/3.0, there is no support for BLE (4.0, 4.1 or 4.2). So, from the point a view of a developer it is impossible to communicate, in Windows 7, with a BLE device using Windows 7’s stack. 
      The TI company have a program called the BLE Device Monitor that is able: (1) to run on Windows 7 and (2) to communicate with a SensorTag. But you must use for these a special USB dongle (e.g. CC2540 Bluetooth Low Energy USB). If the source code for the USB dongle is free, the source code for the BLE Device Monitor is not available – it is only for the internal use of the TI company.


      The Windows 10 Anniversary Update (Version 1607) is the best Windows version ever made by Microsoft from the point a view of Bluetooth Low Energy (BLE) devices – SensorTags in our case. Obviously, this is also due to the considerable number of improvements that took place at the Bluetooth LE level in the following OS builds (see for more info: 14393.51, 14393.105, 14393.189, 14393.222, 14393.321, 14393.351, 14393.726 and 14393.1083.
      The blessTags (BLE SensorTags) application can be downloaded from the Windows Store Apps: For more information, demo, practical applications, examples etc. please visit the following blog:
      Synthesizing all of the above results we will get the table below.

      [1] Changes to Office and Windows servicing and support, on line at: