>I can't give a specific explanation - but I would venture a guess that there are parts of SSMS that use CLR integration that are tied to the earlier framework. Any time Microsoft releases a newer version of Product A that's tied to Product B, it's not a given that the "tethering" to product B is based on the newest version of B.
>
>Just in general, this is an issue that many I.T. managers face - the fact that a version of SQL Server (or SharePoint, where this also occurs) is tied to older versions of the .NET framework or older versions of database drivers. The lag can drive people nuts.
>
>This won't make you feel any better, but the other day I got stuck trying to install the newest release of SharePoint and Windows Server on a VM, because a particular function in SharePoint required a much older version of a SQL Server database driver - so old in fact, that it's "retired" from the MS website, requiring extra digging to find it.
>
>
>So again, I can't give a specific reason. But what you're encountering is (sadly) more common than you might think.
>
>In cases where I've had to install an older version of the framework (like 3.5) even though I already had 4.0, I don't think it "broke" anything, at least not for me. Anything that was previously expecting 4.0 would still use 4.0. That's the one blessing, that these products often work by looking at version numbers.

Thank you, this is very valuable information. I have adapted our procedures to only install SSMS on app servers and not web servers.