Run .net application from network share
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:
Thanks for explanation. Download works fine!
Thanks for that. You just saved me from hours of pain!
Thanks James, but please make some clarification. On which machine do I install the MSI application? Should it be on the Server or all the machines? How about the Security Config? Should I replace the one already on the machines?
Hi Jose, sorry if you are having difficulties. The MSIs need to be installed on the client computers. If you want to run the application on the server as well then by all means you can install them on a Windows server. The MSIs basically contain the Security Config(s) so when you install the MSIs you are overwriting the existing Security Config(s) with those that I have prepared in the MSI.
If you cannot or do not want to deploy/install the MSIs then I have included the Security Config(s) above so that you can simply copy them over the existing Security Config(s) on clients.
Whether you decide to deploy (using Group Policy)/install the MSIs OR manually copy the Security Config(s) above over your existing Security Config(s) makes little difference. Both methods will allow you to run a .net application from a network share.
Some Network Administrators will find it easier to deploy the MSIs that I created, others will find it easier to use a startup script to copy my modified Security Config(s) over the top of existing Security Config(s) on clients. The choice is yours!
James, Thanks a lot for the explanation. The system is now working very well.
jj
had a similar problem to run a small app for the users here and had security problems. run the msi and voila working like a charm, whatsmore a little admin script checks if computer is running app for first time then runs the msi
you're the best
thanks a bunch
Excellent!!!!
I tried it and it worked just fine!
thanks.
Thanx,
Great article, works for me!!
Michel (netherlands)
Thanx
It helped a lot.
Do you perhaps have code to run this settings every time you run an application, so that this setting can be reset in runtime.
Hennie
Hi Hennie. Unfortunately I do not have any 'code' to modify the security settings on the fly. What you are suggesting would not work for applications being run from a network share because in order to change the security settings on a computer the application would already need to have the permissions to run.
You could write a program (to modify the 2 config files) that you could run locally. However I'm not sure why you would want to as Microsoft provide a .net framework configuration tool for each version of the framework.
Thanks for the feedback
I thought you could modify the settings while for eg. a splash screen is running. A form that have no connection linked to data still opens and do not require full trust. If you close the application the settings can be set back to the original settings. Just a thought!
I am trying to run my application using a Novell application. My application is stored on the server and we do not want to install the client on every pc. This is why the request as above, because what is the use of the novell application if i still have to install your application on every machine or reset every pc, most of which the users do not have administrator rights?
Hennie, I understand what you are saying now. You propose that when you open an application you have written it modifies the security configuration for each of the two frameworks (before doing anything else that the application was written for). The only problem I can see with this is that I am not sure if the security.config is checked every time you execute a command in your program or whether the security.config is read once by the application during startup. If it is the latter then after you run your application and it modifies the security.config it will make no difference because the old version has already been read and stored for later use by the application.
The only way I can see you getting round this situation is to run a startup script on every computer from within Novell that copies the two security.config files over the old versions that will not allow you to run the application from a network share.
Thanks
It seems that i dont have a choice but to follow your advise by running a startup script from within Novell. I thought i could keep this for a really last resort. Thanks anyway for the good feedback.
Hi James
Is it then possible to test the settings and if not on full trust change the settings (using for eg a splash screen ) and then close the application with a proper message to the user. So by running the application again it will open because the settings is on full trust now. Really need a solution, without having to use anything else but the application.
Hennie, this could be possible. You would need two programs. The first program that users run would copy the two security.config files over the top of the two security.config files on the existing computer and then call the second program (.exe) which would then be able to run from the network share. Then when users close the main program you could use that to delete the two security.config files returning each framework to it's default settings. You would need to test this as I am not sure what permissions users would need to delete these files and then copy files back into the same location. I am pretty sure that they would need administrator rights (the correct file permissions) to be able to delete anything from the C:\WINDOWS directory for obvious reasons.
JJ,
i have applied the settings as you mentioned to my local intranet but i still get the same error which is:
" request of permission type "systemdata.oledb.oledbpermission, system data, version 2.0.0.0, culture neutral, pulickeytocken = abcxyz' failed
is it because my application runs on a Access database and not a sql database?
thanks
Hi Abhishek,
When you say that you have applied the settings to your Intranet what do you mean? Do you mean you have applied them to an Intranet server? The installers need to be applied to every computer that wishes to run an application from a network share.
Hi James,
Can you share sources of the .net 2.0 MSI package ? I would like to add some other files to it and use it as the installation package for my small application.
Thanks
Glen,
The MSIs are available above. The files that the MSIs contain are also listed above. They are all available for download.
Thank you very much for making this msi!