Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

MS VS redist security update issue


8 replies to this topic

RobIsUpside

RobIsUpside
  • Full Members
  • 10 posts

Posted 04 September 2009 - 19:11

Is anyone else experiencing or can help explain why it appears the recent MS security update 971090 which replaces merge modules in visual studio with updated ATL components appears to be causing the following error on minor upgrade (when upgrading from a setup built prior to the security update to one built after which includes the new ATL MSM):

MSI (s) (FC:D4) [16:38:02:640]: SELMGR: ComponentId '{9B2CAF3C-B0AB-11EC-B01F-C8B3B9A1E18E}' is registered to feature 'Document_Server', but is not present in the Component table. Removal of components from a feature is not supported!
MSI (s) (FC:D4) [16:38:02:640]: SELMGR: Removal of a component from a feature is not supported

The component ID in this error is for the ATL crt component included to support a 3rd party OEM COM component in our setup. Version of this component under x86 went from 4052 to 4053 (I believe).

WiLogUtl.exe msi log analysis shows feature installed state = "Advertise" instead of Local and Request - Action each = "Reinstall". All Component installed state = "Local" and Request - Action each = "Null" (which explained why no files were updated to new version).

The package version updates properly in the registry and errors are not presented to the user running setup (only visual confirmation of the dlls did we find this).

My question is, considering we didn't change the merge module association within the setup project, why is the version of the merge module being installed causing the SELMGR component removed from error feature? Is this something we should have anticipated, when a newer versioned msm is included in a setup project we have to change the product code and restrict minor upgradeability?

Is there more happening here that we can understand to help avoid this in the future as well as to help us explain to our clients why MS security update * causes our installers minor upgrade to fail for the feature with runtime library components affected by their security update?

Thanks for taking a look at this, please let me know if you'd like more info or have any questions. I hope to post this at installsite as well in effort to help others who might have similar issues.

Cheers,


Rob

Attached Images

  • snag_34.png


Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 07 September 2009 - 16:57

Is the component {9B2CAF3C-B0AB-11EC-B01F-C8B3B9A1E18E} included in (the old version of) the ATL.msm? (If it was, could you please send me the old and new .msm because I don't have VS 2005)
Or how did it get into your project? It looks like this component was removed from your setup, which is not allowed in a small or minor update. The other problems are a result of this.

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 12 September 2009 - 01:37

I looked at the modules and indeed they removed some components. For details see http://msmvps.com/bl...er-updates.aspx

I think the best solution would be to do a Major Upgrade.

RobIsUpside

RobIsUpside
  • Full Members
  • 10 posts

Posted 18 September 2009 - 01:16

Thanks Stefan.

We initiated an MS partnership support incident ticket and so far they haven't acknowledged the issue despite my logs etc. They even suggested to use the vcredist instead (which is totally off topic in the context of the minor up).

Will update once I have more info from them.

Thanks again,


Rob

RobIsUpside

RobIsUpside
  • Full Members
  • 10 posts

Posted 24 September 2009 - 18:08

Hi Stefan,

MS support incident ticket response is similar to your blog posting referring to proposed workarounds, using vcredist instead or the old msms (brilliant, use vulnerable files in our setups, sure the clients would like that).

I've requested a fix to the merge module, isn't this something that could occur in your opinion?

More info when I recieve it.


Rob

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 25 September 2009 - 07:03

That would be the proper solution in my opinion. Apparently they never tested the impact of the merge module patch. Makes me wonder if Microsoft is using these merge modules internally.

Please keep us updated...

Zweitze

Zweitze
  • Full Members
  • 522 posts

Posted 25 September 2009 - 14:17

I thought that the general drill was to avoid Merge Modules, if there is any chance that that Merge Module may be updated.

This was a lesson learnt from MSDE, a light version of SQL Server 2000. MSDE was generally used by software vendors, as a default database server. MSDE was distributed as a number of Merge Modules, so these vendors could include them in their setups. Later some updates to SQL Server 2000 appeared, SP1, SP2 and SP3. Along these updates came updated MSMs, for vendors that required the latest updates.

Now SP3 had an unusual fix, a security update. Users were urged to install SP3. All users that obtained MSDE indirectly from a vendor, and was installed with those MSMs, should contact that vendor for a patch with the latest MSMs.
That wasn't as easy as you may think. Some vendors needed time to prepare that patch. Other vendors had also updated their own software, and charged money to get the latest version. Others had abandoned their product, or went out of business.

So, a lot of systems could not be secured, because a patch was never released. Then the calendar turned January 25, 2003.

After evaluations the Merge Module principle got the blame, everything installed through a Merge Module can only be updated by the installer of the product that contained the old Merge Module.

All in all, if you ever wonder why Merge Modules for MDAC, .NET Framework, SQL Express 2005 etc. do not exist, this is why. In fact, I'm surprised that the C runtime libs are distributed like this.


RobIsUpside

RobIsUpside
  • Full Members
  • 10 posts

Posted 23 October 2009 - 16:52

Well several email discussions and a live meeting with members of the MS product groups for MSI and C++ and the result is a recommendation to leave the broken merge module in the package and chain via custom bootstrapper the updated vcredist c++ components setup to overwrite any bad ATL components pushed out by the merge module.

Basically it came down to not being able maintain legacy component guids within the merge module though I'm still no quite sure why. The discussions suggested that if they maintained all the guids over the product lifecycle it would add 45 minutes to the installation for just the c++ runtime components which obviously would be unnaceptable.

The proposed solution will be limited to exceptional cases with only a few customers as we don't feel the proposed solution is a good fit for our main package solution.

Ultimately we hope to remove the requirement for com component support and become a purely .net product.

Cheers gang, happy installing smile.gif

Rob

p.s. thanks for taking a look at my post Stefan and all your input within the community.

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 24 October 2009 - 18:44

Rob, thanks for taking the work to discuss this with Microsoft, and for coming back and posting the results here.