5

The question here is straight-forward: how do I install TortoiseSVN on Citrix XenApp so that only specific people can see/use the program, without a 2nd group of people even seeing that the program exists?

Under Citrix's old MetaframeXP product, there was an option to install applications on a per-user basis. Normally, using the system's "Install Program" feature from the Applications control panel resulted in the Citrix server entering a specific mode that registered the installed program for all users. If you didn't use this mode, the program would install for the user account that was performing the installation only. This allowed the administrator to set up programs that could be used only by specific users; other users would not see the program, nor would they have the appropriate registry entries. Yes, you could see the installed files, but it was pretty much non-functional for other users.

With the XenApp environment, this is supposedly no longer an option. As it has been explained to me by the admin(s) heading up systems maintenance for our Citrix installs, programs installed in XenAppDesktop and used as a published desktop (not published app) will be visible to everyone on the server. And here lies the issue: TortoiseSVN installs a shell extension, and because of that, the extension will be visible to all users, not just developers or admins that need access to it. Our non-technical end-users will simply go bananas when they start calling about "some weird thing showing up when I click to look at files".

We are running XenApp on WS2003R2/64.

Before answering with something other than "this is how to do it with what you've got", please consider the following as well:

Yes, this is a business installation, which means licenses, etc.

No, switching off of Subversion is not an answer at this time. Yes, I am fully aware of the popularity of Git/Mercuriual/${Insert-Favorite-DVCS-Here} and how they are all a bazillion times better, will make my laundry whites whiter, save kittens and puppies, etc. etc. That is beside the point; the effort of migrating to a different system just to get around this issue is several times higher than just addressing the issue. So, no, switching the back-end is not an acceptable answer.

No, adding yet another (expensive) Citrix server just for developers is also out of the question. I don't set budgets, and I don't get to determine what money is spent where. Telling me to "Just add another server" is akin to me going to some country's starving population and saying "just eat more food". The resources available are fixed, so it's not an option.

Yes, having another cheap/free remote access solution that provides a Windows desktop as a hosted service may be considered. However, the cheapest solution I've found is still in the four-digit range, which is not something that I can talk to management about approving. Short version: if the cost of setting up a secondary remote Windows desktop exceeds $25/seat for 7 developers then it's not viable (not including of course the licensing fees for Windows...) It would have to be a really compelling solution for management to consider this, but if it looks good, I'll try to make a case for it.

Tom
  • 424
  • 3
  • 12
Avery Payne
  • 14,326
  • 1
  • 48
  • 87
  • 1
    Given your requirements I think you may be out of luck. I suppose just telling the devs to use svn from the command line is out of the question as well? Is setting up App-V an option? That is free with some types of volume licensing. http://blog.stealthpuppy.com/virtualisation/adding-shell-extensions-to-app-v-packages/ – Zoredache Feb 15 '12 at 21:30
  • Command line usage may be the way to go for commits, but the shell overlay in Tortoise is what I'm after. Being able to visually see all of the files - and their status - is a boon, especially for Windows devs who are used to pointy-clicky. Still, I'll look into that as well. – Avery Payne Feb 15 '12 at 21:54
  • Which version of Xenapp are you using? Advanced, Enterprise or Platinum? – Tom Feb 20 '12 at 14:05
  • XenApp 5, I believe "Advanced" – Avery Payne Feb 21 '12 at 01:39

2 Answers2

1

Two options come to mind:

  1. Set permissions on the directories and registry keys created during the TortoiseSVN install in such a way that users that should not see TortoiseSVN's shell extension do not have read access.

  2. Replace the physical XenApp installation with two virtual XenApp servers on the existing hardware. Install TortoiseSVN on only one of them.

Helge Klein
  • 2,031
  • 1
  • 15
  • 22
  • I like the permissions idea about the registry key; unfortunately I already tried to extract all of the registry changes that Tortoise makes *by hand*. After the 40th entry, I threw my hands up - it leaves little hooks all over the place, which means securing it would be just as hard because I have to hunt all the entries down. Re: the two XenApp installs, that would work, but it's still a licensing issue. I'll give a point for heading in the right direction, but I can't award the answer. – Avery Payne Mar 28 '12 at 17:23
  • Try RegShot to identify the registry changes made by Tortoise. – Helge Klein Mar 28 '12 at 20:34
0

App-V wont work if you want to put in explorer extensions. I'm not familiar with TortoiseSVN, does it have a main exe that it runs? If so, can you add a security group to the exe so that only users in that group can see/run it (remove everybody)? This would mean that you will be able to prove to the licensing that you are restricting access to it. The extensions might still show in explorer for all users, but wont be usable unless the user is in the group.

user114106
  • 141
  • 1
  • 6