BRAVO TECHNOLOGY CENTER

First Published: Jan 2014
Last Revised: Nov 2015

The following is a definitive guide re: the "mysterious" failure of Dotnet 3.5 install on certain Win8.1 systems, complete with backstory, roadmap, explication, strategies and recipe, in a concise structured format, for IT professionals, not end-users.

Synopsis:

• Microsoft Dotnet Framework is a platform required by many applications.
• each generation of Dotnet has unique architecture & APIs: 
  • Dotnet 4.x will not support applications written for 3.x
  • Similarly, Dotnet 3.x will not support applications written for 2.x. 
  • Multiple parallel installations might be required
  • Each platform is loaded & initialized at boot time, with intensive scheduled optimization, regardless of whether you have programs using it or not
• Windows 8.1 RTM come bundled w/ Dotnet 4.5 pre-installed (4.6.1 is current),
  • Dotnet 3.5 SP1 is cached to hard drive (in SxS), but not pre-installed.
  • attempts to activate & install this via control panel will likely fail**
  • download "redistributabe package" for offline install will also fail
    • also applies to "disc install" using application vendor's bundle, which is essentially their MS download
  • "web install" method will fail shortly after the "stub" launches
• all cases in the field I encountered involved Windows 8.1 and Server 2012 R2***, but this doesn't rule out Windows 8 and Server 2012 also being affected.

• certain critical updates released by Microsoft for Windows 8.1, instituted security policies, and modified system settings, to the point where above mentioned normal methods of Dotnet 3.5 SP1 package installation will fail.
  • known culprits include: KB2966826 KB2966827 KB2966828 
  • there are also "roll-up" updates which incorporated these patches
  • many 3rd-party software vendors also integrate (not include) them (along with other "offending" patches) within their installer CAB/MSI/exe
• why some systems are "inexplicably" unaffected
  • the offending patches impedes installation of dotnet 3.5, as SxS, or standalone package... but it does not harm the operations of dotnet 3.5, if pre-existing.
  • upgraded from Windows 7 to Windows 8/8.1 with Dotnet 3.5 SP1 previously installed and working, it will be preserved:  no need to install = no failure
  • those installing fresh copy of Windows 8.1, absolutely unpatched and with zero 3rd-party packages (applications or system utilities) would be able to install & activate without blockage, using standard consumer procedure

1. hunt down and uninstall all offending patches, then install and activate the Dotnet 3.5 SP1 module previously pre-copied into SxS during OS install, and finally--reapply those uninstalled patches. Note: brute-force method!
2. surgerically undo each and every pertinent system security policy, group policy and miscellaneous registry settings, that were fortified by those "offending" patches. Again: brute-force method!
3.   RECOMMENDED:   use Microsoft Deployment Image Servicing and Management (DISM), with Window 8.1 installation DVD disc, via elevated CMD Prompt:
     DISM /online /enable-feature /featurename:NetFX3 /All /Source:Q:\sources\sxs /LimitAccess  Must be entered exactly, without line-break. Change Q: to your actual drive letter!
   • For consumer PCs without installation media, obtain ISO image  and mount it (now a built-in OS feature!)
   • Ultrabooks without optical drive: mount ISO image
   • If no ISO image available, create one from physical DVD (use imgburn, etc.)
   • advanced tip: instead of uploading entire 4 GB DVD image, just extract the q:\source\sxs folder, totaling 287 MB, compressed down to a very manageable 39 MB, if you use the most advanced techniques.
4. in-place Win8.1 reinstall via OEM DVD, which effectively revert 99% of all Microsoft executables and DLLs back to factory default (pre-patch/update) condition, likely rendering some applications inoperable, triggering need to reinstall them afterward.
5. As always, virtualization is a candidate workaround, and an effective one in this case. 
   • run the new application requiring dotnet 3.5 as isolated virtual instance
6. eliminate the need to install Dotnet 3.5
   1. select alternate product written for Dotnet 4.x platform, or
   2. stick with Windows 7 

• solution #1 & #2 above are extremely unlikely to be ultimately successful, and therefore is "highly discouraged."
• #4 is "banned" for all DIFAs under Bravo IT jurisdiction.
  • Explicit exception override (with justifications) required.
  • If you're an outside consultant, or represent the application software vendor: let it be known that it is considered harmful, unacceptable, and needless (due to readily available alternative: DISM method. Therefore: We decline & disapprove.
• of course, #5 implies all the ramifications of virtualization, including: isolation (pro or con?), guest OS license, user procedural training, potential USB pass-thru can-of-worm, etc.
• indiscriminately pre-install & activate Dotnet 3.5 at time of OS install, prior to patches, regardless of actual need, is unacceptable, as it violates 3 fundamental IT principles:  Security, Reliability, and Performance