Home > Software, Windows Vista, Windows XP > Run .net application from network share

Run .net application from network share

January 21st, 2008 Leave a comment Go to comments

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

  1. R. Terveer
    March 7th, 2008 at 14:21 | #1

    Thanks for explanation. Download works fine!

  2. Daniel
    March 17th, 2008 at 13:30 | #2

    Thanks for that. You just saved me from hours of pain!

  3. Jose
    June 10th, 2008 at 12:56 | #3

    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?

  4. James Clements
    June 10th, 2008 at 20:00 | #4

    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!

  5. Jose
    June 13th, 2008 at 13:47 | #5

    James, Thanks a lot for the explanation. The system is now working very well.

  6. tom
    June 16th, 2008 at 14:45 | #6

    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

  7. Hugo Polanco
    August 20th, 2008 at 03:51 | #7

    Excellent!!!!

    I tried it and it worked just fine!

    thanks.

  8. Michel
    October 20th, 2008 at 09:45 | #8

    Thanx,

    Great article, works for me!!

    Michel (netherlands)

  9. hennie
    October 24th, 2008 at 09:45 | #9

    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

  10. James Clements
    October 24th, 2008 at 15:10 | #10

    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.

  11. hennie
    October 27th, 2008 at 20:23 | #11

    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?

  12. James Clements
    October 27th, 2008 at 21:38 | #12

    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.

  13. hennie
    October 27th, 2008 at 22:01 | #13

    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.

  14. hennie
    October 27th, 2008 at 22:17 | #14

    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.

  15. James Clements
    October 28th, 2008 at 10:50 | #15

    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.

  16. Abhishek
    October 30th, 2008 at 19:54 | #16

    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

  17. James Clements
    October 31st, 2008 at 11:53 | #17

    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.

  18. Glen
    February 11th, 2009 at 21:08 | #18

    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

  19. James Clements
    February 11th, 2009 at 21:43 | #19

    Glen,

    The MSIs are available above. The files that the MSIs contain are also listed above. They are all available for download.

  20. Demesmaeker
    March 29th, 2010 at 06:56 | #20

    Thank you very much for making this msi!

*

code