| Microsoft Data Access Components version 2.8 sp1 is the last stand alone redistributable of MDAC that Microsoft will ship. MDAC is a windows component: Upon shipping Windows 2000, Microsoft included Microsoft Data Access Controls (MDAC) within the operating system. This meant that MDAC timelines were dictated by operating system release timelines. Also in Windows 2000, Microsoft added System File Protection (SFP) , also known as Windows File Protection (WFP). The goal of SFP was to reign in how important components within the operating system get updated. This protection was particularly applied to components that were used by other components which shipped with the operating system (Like Display drivers, disk drivers, etc.). Just like outside, MDACs is heavily used within Microsoft. There are a number of components in the operating system that use MDAC. If we allow external components to update MDAC components we risk having heavily used operating system components fail. At the same time in past years we were adding enough features within MDAC that customers wanted to take a dependency on new versions of MDAC which would also work on older platforms. This drove us to continue to provide newer versions of MDAC as redistributables. The primary scenario here was that a software developer would take a dependency on a newer feature in MDAC. Upon deploying their application they would have to deploy MDAC as well. This means that an end user installs a new application, which in-turn installs a new version of MDAC and may cause some existing applications to stop working. The ability to install MDAC outside of the windows operating system install has caused a number of problems to customers. Having MDAC install as a redistributable circumvents a number of controls that the operating system has in place for components. It makes all of the operating system ways of delivering bits to the machine much more complex. In the past we have attempted to cautiously walk the line between providing developers the ability to ship new features and not causing severe impact on machines. For instance we have allowed users to install MDAC 2.7 sp1 redist on down level systems but not on systems that have a newer version of MDAC (say, on Windows XP installing MDAC 2.7 SP1 redist will just return without installing any thing as it has a newer version of MDAC installed.) Operating system service packs are preferred way of getting MDAC bits: The reasons that the version of MDAC that ships with the operating system is preferred are: - The operating system features that we can take advantage of if we know that we are running on a known OS. On the other hand, the redist has to run all the way down to Windows ME, so we have to code to that lower operating system infrastructure. Unfortunately these features can also impact security. So if we allowed the redist to overwrite the bits that are installed with the operating system service pack we could downgrade some security aspects of the operating system. - Allowing redist to overwrite operating system installed bits, means that we would have to test all of the different combinations of how MDAC got installed on the system means that we would have to test all of the different combinations of MDAC and how they got on the system. Allowing the operating system installed bits to take precedence means that we can test the entire operating system service pack as one unit of bits. This allows us to fully guarantee the operating system integrity. - The reality is that MDAC is a popular component used by a lot of applications. . This makes the MDAC components more vulnerable to security attacks. Having lot’s of different ways for MDAC bits to end up on the machine makes it that much harder to ensure the integrity of the MDAC stack. Once the MDAC stack becomes mixed it will likely crash the machine. In addition Windows Update may not correctly calculate the updates for that version of MDAC. MDAC Support Lifecycle: MDAC is still fully supported. Since we are still actively shipping versions of MDAC with Microsoft products MDAC is bound by Microsoft’s Support Lifecycle which you can read about here. We will also continue to make sure that shipping versions of MDAC that are covered by the above lifecycle policies are maintained and apply relevant security patches for these supported versions. We are certainly not actively putting a lot of feature work into MDAC at this point. We do maintain and support the code. Look for a post later discussing deprecation of components within MDAC. Conclusion: As a result we are now making MDAC an official component of the operating system. This means that MDAC 2.8 sp1 will be our last official redist of MDAC (KB-Article).We have already heard from some customers that lack of an MDAC redist creates issues. We realize that these decisions can make certain application scenarios tough. The reality is that we have to balance the impact on certain application scenarios against these other factors in maintaining the overall MDAC lifecycle. The decision to make MDAC 2.81 our final redist was made at higher levels within Microsoft and it was a tough decision but is one that we believe results in most benefit for all of our customers. It is a direction to which we are fully committed. The point of this post is to make sure that everyone has an understanding of where we are and how we got here.
Note: Oh yeah. You can get the MDAC component checker here. This will tell you the current status of your MDAC Bits on a machine. Brad Rhodes
Lead Program Manager
Data Access Technologies Disclaimer: This posting is provided "AS IS" with no warranties, and confers 
Original Link |