Deploying .NET Security Policies [Office 2003 SDK Documentation]
How you should go about deploying the .NET security policies to clients' computers very much depends on your clients computing environment and network structure. If you have a small office and your users are technology savvy and have administrative rights on their computers, you could let them set up the .NET security policies themselves. If you have a large enterprise with thousands of desktops where all the users runs as a "User" and they don't have administrative rights, then it is best to have your network administrator roll out the .NET security policies.
As discussed in the Setting Up .NET Security Policies topic, whether you should grant permission sets at User, Machine or Enterprise level depends on your deployment scenario and what rights your users have on their computer. It is recommended that you give permission sets at the user policy level unless there is a need for you to give the same permission sets to all users on a machine, for example in a terminal server environment. However, if an enterprise is rolling out smart tags to its users then they should probably go with machine level so that the user can't delete the policy settings for example. But if they want to enable end-users to run smart tags on an ad-hoc basis then they need to work at User level.
If you require the end users to modify .NET security policy themselves instead of a network administrator, by running a CASPOL command batch file or MSI that automatically sets up .NET security policy for the user when run, you need to first determine what kind of rights the user has on the computer. To set up .NET security policy at the user policy level, the user only needs to log on with user rights on the computer. The user does not need to have administrative rights and does not need to log on as an administrator on the computer.
However, if the batch file or MSI are configured to set .NET security policy at the machine policy level and the user only has user rights on the computer, the .NET security policy setup will fail as the user does not have adminstrative rights to modify .NET security policy at the machine policy level.
To avoid having your setup fail because it requires the user who run it to have rights that they don't have, see the guidelines in the "End Users or Administrator to Set Up .NET Security Policies" sub topic of the Setting Up .NET Security Policies topic.
Below are ways you can deploy .NET security policies and which way you choose as discussed above depends on what type of client computing environment you are deploying to.
Note It is recommended that you also see the Managed Smart Tag Security section for detailed discussions and recommendations on setting up .NET security policies, uing the Visual Studio Tools for Office loader, granting full trust permissions to interop and dependent Assemblies and so forth.
Use Batch Files to Run CASPOL to Set Up .NET Security Policy
You can use batch files to run CASPOL to set up .NET security policy on clients' computers. You can either let users run the batch files themselves or you can build an MSI with a custom action that spawned a command line, and drop that into Group Policy. You can also run batch files using Systems Management Server (SMS).
You can find documentation on the Code Access Security Policy Tool (Caspol.exe) on MSDN or in the .NET Framework SDK documentation (to display it, click Start, point to All Programs, point to Microsoft .NET Framework SDK v1.1, and click Documentation).
Deployment Package Wizard and .NET Framework Configuration Tool 1.1
Another way to deploy .NET security policy is by using the Deployment Package Wizard included in the Windows .NET Framework redistributable to create a Windows Installer Package (.msi file) to deploy policy to Windows clients using Group Policy or Microsoft Systems Management Server (SMS). For more details see the .NET Framework Configuration Tool 1.1 and Code Access Security Policy Tool topic.
Create Custom Action
You can also use a custom action to call a method in an Installer Class that will allow you to create and to set up .NET security policy on clients' computers when the users run your installer. You can find examples on how to use a custom action in the Increasing Permissions for Web-Deployed Windows Forms Applications article and Visual Studio Custom Actions Management in Deployment documentation on MSDN.
.NET Framework Enterprise Security Policy Administration and Deployment
In an enterprise environment, you can use Group Policy instead of SMS if you have that deployed in your organisation. If your organization are using SMS or Group Policy, an MSI can be deployed to normal users to run. You can also register an MSI (in Active Directory) to install with elevated privileges.
For walkthroughs on how to build and deploy a .NET security policy deployment package, below are some articles that show how:
1. HOW TO: Build and Deploy a .NET Security Policy Deployment Package
2. .NET Framework Enterprise Security Policy Administration and Deployment
3. HOW TO: Use Group Policy to Remotely Install Software in Windows 2000
4. Increasing Permissions for Web-Deployed Windows Forms Applications