There are multiple conversations that already explain this. Go read them.
Thank you ... but would you be so kind and suggest some key word to find those conversations or some links to, because my search with my "key words" have no results discovering a solution or an explanation to my problem <over and over same update suggested for install by Intel® Driver & Support Assistant >?
Could it be this :
- when I bought the stick it has been described with :
Version Bluetooth 4.0
Wireless 802.11 b/g/n
- the update is for :
Integrated Wireless‡ Intel® Wireless-AC 7265 + Bluetooth 4.2
for something my device don't have ????
Sorry, I answered the original query while mobile and where I couldn't efficiently look it up - but I am back on a real PC now and can answer properly.
The problem facing IDSA stems from the fact that a number of the Intel driver packages contain multiple drivers. For example, the Ethernet driver package has separate drivers to handle the various MAC and PHY components and combinations that might exist in a solution. Similarly, the Wireless and Bluetooth packages contain unique drivers for each hardware version available. Same goes for the Chipset Software package, but, in this case, it is the versions of the included INF files. Now, because their development occurred independently, each driver has its own unique version number, determined by the number of versions and revisions of that driver that were necessary to get it to a bug-free state. Separate from these version numbers, the overall package has its own version number, based upon the number of times that the package has had to be re-released to deliver fixes to one or more drivers. Here's the problem: when IDSA is detecting the updates necessary on a system, all it has to compare is the version of the driver in use. The problem is that there could be multiple versions of the package that contains this particular version of the driver.
Let's look at an example. Suppose you have a package X that has two drivers in it, A and B. In a particular release, call it X1, driver B is updated because an enhancement was made to it. Driver A stayed the same as in the previous package release, however, because no changes to it were necessary. If IDSA has only the driver version number to use for comparison, it sees driver A being the same in both the X and X1 releases. It consequently does not know which of these packages is present.
See the issue? With only package version numbers and driver version numbers (and them not matching), there is no way to determine which package is installed. A method for doing so needs to be identified and put into use. Until this occurs, the current solution is to say that the update is (again) necessary.
So, what do you do until this is addressed? Keep track of the versions of the packages that you are installing. Then, you can check and see whether a package being requested is one that you installed previously. If it is, then you can ignore it. Ugly? Yes, but there is no other choice.
While I am on the subject, I have an extra comment to make. A lot of people are asking why this tool is replacing the (in their minds) "perfectly good" Intel Driver Update Utility (IDUU). Well, the simple answer is, IDUU was NOT "perfectly good"; it was absolute crap. It had a *ton* of problems (including this same repeat install issue) and the work to correct these problems was deemed to be even more work than replacing it completely. Yes, IDSA is a work in progress and yes, it has a couple of really annoying issues (especially the browser cache issue), but it has the potential to eventually work properly and be maintainable where IDUU simply did not. Don't give up on it; keep reporting issues and it will improve as a result.