Monday 6 February 2012

Installing SQL 2008 R2 from a remote share after .Net Framework 4.0

I built a new fully patched VM template the other day for use in my lab and for deploying to private clouds in my System Center lab environment, but noticed some strange behaviour after deploying a new VM based on the template and trying to install SQL 2008 R2.

Every time I tried to run the setup I kept getting the following message:

Managed SQL Server Landing Page has stopped working

Doing a search online for similar issues around setup and landingpage.exe didn't yield a great deal of solutions.

Back tracking I decided to narrow down some of the changes I had made to the image, specifically around the installed updates.

After uninstalling .Net Framework 4.0 SQL setup appeared to work without a hitch, but putting .Net 4.0 back on yielded the same result.

After a bit more searching, I came across a TechNet forum post that pointed me in the direction of this blog post about using CasPol to fully trust a share:

It turns out that when trying to install SQL 2008 R2 from a file share with .Net 4.0 installed will result in this landingpage.exe error so the choices are:
  1. Install SQL 2008 R2 from a CD/DVD/ISO
  2. Copy the SQL 2008 R2 install files locally and install
  3. Use CasPol to trust the share
I choose to use the CasPol method as I have all my install files stored in my DSL used by MDT & ConfigMgr so would rather use this than digging out disks or mounting ISO's.

The command I used was:
CasPol.exe -m -ag 1.2 -url file://\\<Server>/<Share>/* FullTrust

Run this from C:\Windows\Microsoft.NET\Framework64\v4.0.30319

This worked on one of my servers, however, another one I tried started throwing errors then about FixSQLRegistryKey during the pre-req checks.

The same forum post also mentions a more permanent fix, so I took the plunge and added/changed the following line to the listed config files in the source files for SQL:

   <legacyCasPolicy enabled="false" />
   <loadFromRemoteSources enabled="true"/>

  • setup.exe.config
  • setup100.exe.config
  • fixsqlregistrykey_ia64.exe.config
  • fixsqlregistrykey_x64.exe.config
  • fixsqlregistrykey_x86.exe.config
  • landingpage.exe.config

This basically has the effect of ignoring the CAS policies introduced with .Net 4.0 and enabling the use of remote shares.

Not pretty, but worked for me ;)

Original Forum Post:

Thanks Min Keng!

Interestingly, this issue has been highlighted to Microsoft via Connect as far back as July 2010 and still has no official fix other than to uninstall .Net or run from the local machine.

1 comment:

CBT said...

I don't have any issues when I install SQL 2008R2 and then install SP1 separately. However, when I use a slipstreamed install (, I do get this error.