Installing SQL Server 2008 R2 or SQL Cumulative Update 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 behavior 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:


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s