JJClements.co.uk

I used to work in a Secondary School and whilst I was there I developed an application using VB.net for students to run checks on and upload e-portfolios to a shared resource before submission to the examination board. The application worked fine so I packaged it into an MSI and deployed it. Everything was ok until the e-portfolio criteria was changed. I had to modify the application and redeploy the MSI.

This proved a headache and I immediately thought that I should be running the application from a network share. The problem I had was that the .net framework abides by a security policy and subsequently the default security settings allow the application to run from a network share but do not allow the user to perform basic tasks like using the application to browse for an e-portfolio folder in this case.

I started looking at ways of modifying the security policy. It turns out that .net versions 1.1 and 2.0 each have their own security policy and have to be configured separately. It appears that .net 3.0 contains some extensions but still uses the .net 2.0 compilers and executables governed by the .net 2.0 security policy. Therefore any changes made to the .net 2.0 security policy should affect .net 3.0.

To make changes to either the .net 1.1 or 2.0 security policy you can access each framework’s respective configuration tool the following way:

Start -> Control Panel -> Administrative Tools

and either:
Microsoft .NET Framework 1.1 Configuration or
Microsoft .NET Framework 2.0 Configuration

You will have to install the .net 2.0 SDK before its configuration tool is available, although the 1.1 configuration tool is supplied with the framework installer.

The configuration tools are virtually identical, but to make changes to the .net 2.0 framework you have to expand ‘My Computer’ in the view in the left pane when the tool is run.

To allow each framework’s security policy to run an application from a share you have a couple of options available. You can allow a specific application to run from a specific location or you can ‘Fully Trust’ your local Intranet zone which will allow all .net applications to run from any share on your local network (albeit at a greater security risk). Being a school I can see there being a need to run applications from shares quite frequently, and so I wanted to change the ‘Local Intranet’ policy from a level of almost full trust to full trust. The Microsoft explanations of each setting are as follows:

Nearly Full Trust (this is the default setting)
Programs might not be able to access most protected resources such as the registry or security policy settings, or access your local file system without user interaction. Programs will be able to connect back to their site of origin, resolve domain names, and use all windowing resources.

Full Trust
Security checks are not performed and programs can access and use all resources on your machine. Avoid this setting unless you are certain that no potentially harmful or error-prone programs can execute from the selected zone.

Now I can see why my application didn’t like to browse for files when it was run from a share! To change the security policy for the ‘Local Intranet’ zone you need to click on the ‘Runtime Security Policy’ icon in the tree view on the left pane. Then in the pane on the right click on ‘Adjust Zone Security’. When prompted click next to make changes to ‘this computer’. Click on the ‘Local Intranet’ icon and change the level of trust to ‘Full Trust’. Click next -> finish to exit. This has just changed the level of trust for the .net framework who’s configuration tool you ran. I repeated this for the other version of the .net framework so that both fully trusted the local Intranet zone. I was then able to run my VB.net application from a network share without any problems.

My next issue was going to be how to achieve this on over 500 computers. Luckily, each .net configuration tool is able to create an MSI that can be deployed over a network via Group Policy. To create an MSI for this you need to open each .net frameworks configuration tool, click on the ‘Runtime Security Policy’ icon in the tree view on the left pane, and then click ‘Create Deployment Package’ on the right hand pane that appears. If you decide to make your own MSI to distribute, when you attempt to use the deployment package tool you should select ‘Machine’ security level when you are prompted.

I initially created two MSIs, one for each .net version that would change the local Intranet zone to fully trusted. After testing these MSIs it appears that they don’t appear in Add Remove Programs, and that when they are uninstalled they do not set the policy back to its original settings. So I started looking at exactly what happens when you manually change the local Intranet zone’s security level. Each .net framework saves its settings in a file called ’security.config’ located:

.net 1.1
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\CONFIG

.net 2.0
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG

I made the changes to the local Intranet security policy for both frameworks and copied the files out. They are available here:

.net 1.1 security.config Download

.net 2.0 security.config Download

I have included a condition in my MSIs (I ended up authoring my own custom MSIs) to make sure that each framework is installed before the installation proceeds. I have also tested them to make sure that when they are removed, the settings return back to the default values, and that they appear in ‘Add Remove Programs’. They can be downloaded here:

.net 1.1 MSI Download

.net 2.0 MSI Download