I think I've managed to look into this enough to determine that it is the
best solution with the minimum amount of administration for everyone
involved.
However, it brings me to another question!
Our in-house developed programs will all be signed so that the security
policy trusts these assemblies. However, we also use some third party
components etc that also require trust to be executed on a share.
Should we create a code group just below the 'All Code' level for each
vendor who sign their assemblies with a different strong-name? I have tested
this, and it works on my machine.
Would it be a better configuration to create code groups for the third party
vendors as children of our in-house code group? This seems to keep everything
grouped together, it will be clearer to everyone that the children code
groups are all used by our in-house apps, rather than having various groups
at the All_Code level. I did try to test this, but encountered security
exceptions.
I didn't change the settings of the code group at all, merely the level at
which it resides on the tree. Just below All_Code, it works fine. As a child
of our in house code group, it fails.
Is there something else I need to configure, or just stick with everything
at All_Code level? (since that works!!)
Any advice on recommended configurations appreciated.
Thanks
[quoted text, click to view] "DylanM" wrote:
> Hi,
>
> We are a software development team for a retail company, all of the programs
> we develop are for use internally on our network. Recently, we have moved
> towards thin-client technology with everyone running remote desktops using
> Citrix.
>
> This proves to be troublesome when deploying - only domain administrators
> can actually install anything onto the Citrix Server itself. Since we have a
> farm of about 30 servers, we have to schedule in a deployment date & ensure
> the Citrix team carry out the install correctly and replicate it across all
> servers!
>
> We've got around this in the past by deploying onto a network share that has
> user specific data in. Eg;
>
> \\SharePath\data\UserName\Program Files\MyExecutable.exe
>
> This ensures we are in control of our programs, we have an auto-update
> program that rolls out any fixes or amendments we have made to programs -
> there is no major delay in rolling out a new version.
>
> In the .Net framework, there are security issues when running from a shared
> network drive. What is the best approach to allow us to continue to run an
> executable from a share path, using resources located locally on the Citrix
> Server?
>
> We have a Strong Name key file for our department that we sign all of our
> programs with. If the Citrix team amend the security configuration for the
> .Net framework on each of the servers, can we trust all assemblies signed
> with our Strong Name Key so that they can run from network shares (as in .7
> of .NET Framework Enterprise Security Policy Administration and Deployment
> FAQ?)
>
> Is this the best approach to allow us to continue share deployment?
>
