Multiple Installations on Citrix Server

I have a need to have 2 separate and distinct installs for 2 Business Units. They will have separate enterprise servers but there is a need to have them share Citrix servers. For the most part all clients will be web. There are some (5-10) Citrix users for each install.

Has anyone ever tried to run 2 separate and distinct clients on a Citrix server? There is an interest in trying to put all of the Citrix clients onto 2 Citrix servers (2 Servers for redundancy). It would be like multiple foundations on a citrix server --- only both would be production. I am thinking there are going to be registry issues but I am curious anyway.

I have never heard of that but if you get it working post your response out here. I would beinterested in seeing if it can work.

I don't think ou can do that ona Ctirix Server with 2 distinct thick clients.

I appreciate your contribution but you don't say why you don't think it will work.

I am trying to figure out why this is different than multiple foundations.

Absolutely you can do this. One issue is that you have must have enough space on the drive where you will store multiple copies of the client. The second issue will be for you to group your clients according to which installation they will be accessing. You could do this much the same way a development TSE is configured. However, they don't need a separate copy of the specs for each user, just one for each business unit. Create a folder and call it something that describes BU 1 and another for BU 2. Install OneWorld on the TSE like you would normally do, and then make a copy of the B7 or B9 installation folder and drop it into each of your BU folders. The JDE.INI for every user must point the B7 or B9 directory to the proper location for their business unit. For instance, B9 would have a line in the JDE.INI like this:

B9=d:\B9

Xe looks like this:

B733=D:\B7

You would want the BU1 groups JDE.INI to look like this:

B9=D:\BU1\B9
or
B7333=D:\Bu1\B7333

I'm sure you can figure out what to do for the BU2 JDE.INI.

One caveat to this is the tendency for the JDE.INI to be deleted from the users home directory. Thanks to AltQuark, I have a solution for that; You simply publish the app for one group using one batch file, and another app for the other business unit using another batch file. The batch files would copy the JDE.INI from a stored location in to the users home directory before loading the ActivConsole.exe or the OExplore.exe.

For those that have a single installation and aren't using batch files to publish the application, you have to do something else to keep the JDE.INI from being deleted. For starters, make a backup copy of the INI and call it something like JDE.INI.ORIG. Copy that over the top of your JDE.INI every time you install another full package on the machine. That won't keep it from happening if you are on 8.9; I've found the solution for that and I hope others can benefit from this tip. First, after you install the package and before you let users log in, delete any .INF files from the bin32 and spec directories of the pathcode you just installed. Also, delete the setup.inf file from the system directory as it also gets updated every time you install a new full package. Update packages are a little different. I've not seen those blow away the INI unless these INF files were still present.

Hope this helps.

Charles, thanks for the post. My gut feeling is that this is possible. This is an awesome explanation. I am impressed.

The one thing I would be concerned about is the Windows registry entries for ERP/XE. Are there any implications as far as the registry is concerned? Have you done this in a production environment?

Thanks also to AltQuark.

Thanks for the compliment. It's much appreciated. I try to answer as many questions as I can on this forum and gain a lot of valuable knowledge by reading the answers of others.

To answer your question about doing this in a production environment: I have in the sense that Dev is always someones Prod. If my development TSE goes down, I have a potential for up to 30 people losing access functionality critical for our development efforts for the 8.9 upgrade. In some cases that is measured in actual consultant dollars. They would have to use a fat client, and for some this is very inconvenient based on their proximity to the corporate office. We've had only a few issues with JDE.INI replacements, but I attribute that to not taking my own medicine. I should redo some of the setup when I get the opportunity. It works well for what we do, but you really need a big fast box if you intend to support development on a TSE.

On the rest of your question; The registry entries on the fat client are very generic. So long as you keep the original installation on the drive, i.e. d:\b7 or d:\b9, you won't run in to any issues that I can think of. Make sure you copy the system directory in with everything else. It won't work without it. Your best bet is to set this up in your sandbox or dev environment and test, test, test. If you look at the Development TSE guide in the tips and tricks section, you can apply some of that knowledge to what you want to do here. I wish that guide was available when I set up our development TSE late last year. I had to go off of the Alan Jacot guide which wasn't nearly as detailed and didn't have the batch file idea...which is a good one.

The best thing for you to do is set this up in your dev or sandbox area and get it right. Then QA the concept and move it to production when you've had enough users from both Business Units in there hammering away. About the only thing that might be an issue is permissions and maybe media objects. As long as you give each group full access to the registry or at minimum change access to all of the JDEdwards keys, you should be fine.

Charles,

This is very good to separate the specs, when using the same software foundation, but does nothing to separate different foundations.

I don't think you can separate different foundations in this scenario at all. Registry, particularly HKEY_CLASSES_ROOT will be pointing to one foundation at a time only.

In effect, with any problem, you will never know which foundation has caused it, because your secondary install will be using bits from the first install and bits from the second one at the same time. And there are some API changes with almost every SP.

I wouldn't go this path...

Regards,
Alexander Pastuhov
http://www.pastuhov.com.au/index.htm

Alex,

I agree with you in some respects but not completely. I agree it could be difficult to support if the two business units have a desire to be independent in their foundations. You have a point about the HKEY_CLASSES_ROOT, but don't you need to test this and see what does and does not work before you stop someone in their tracks and discourage them from doing it? I'm speaking strictly in terms of theory here. I don't like to discourage independent thinking and it's great when someone can come up with a new way of doing something previously thought impossible. It always depends on the circumstances, and in many cases you have to keep things the same due to those circumstances.

The way I set up my dev TSE, every developer directory has it's own copy of the system directory which is the foundation you are referring to. It will not function without it. If it's removed or corrupted in any way, the developer will not be able to log in to the system. That tells me it's using the independent system directory and things should work in that respect. I plan on testing SP3 this way and I will be able to tell you if I am indeed using SP3 on my developer directory and communicating with my lab server also on SP3. The other thing to consider is that when you publish the application, it might not be a bad idea to point each BU to it's own master copy of the service pack it's on. Any time a new service pack is introduced you would need to replace that directory in addition to the service pack on the enterprise server(s) and deployment server. If you are only running with one deployment server, this could be tricky if your two BU's are on different foundations and you would need to build a package using the alternate foundation method. There is a somewhat new document on the Knowledge Garden outlining this procedure. I've done this with success at least once already. I'd have to say it depends on which functionality the users need and what the pros/cons are against doing it one way or the other.

With the way prices have fallen for hardware, a server farm with separate servers for each business unit might not be out of the question. You'd want that anyway for load balancing. If they are wanting to do this because they only want to buy one server, these two business units must not have many users online at the same time. Not really for me to judge, though. I guess I just have to say it's important for everyone to test everything they do thoroughly before promoting a solution to production. They may find this is just fine for them, they may decide to scrap the idea all together when they realize how little benefit it is. Remember, creating a dependency on the other company or business unit is not necessarily a good thing. If you have to reboot a TSE because of one users memory leak and it causes downtime for the other line of business, that's not necessarily a good thing. The overall cost of such an implementation may be exceeded by lost revenue when things go awry.

Charles,

interesting thread conversation! I especially liked your last post comment that you should put the two different business units on two different servers. That is what I was about to add to the conversation. It's one thing to try to play with multiple think clients in a sandbox environment, a support nightmare, but doable. It's an entirely different thing to try that trick with a production environment. Tell the business people to put up the cash for seperate hardware and seperate citrix licenses and do the job right.

Gregg Larkin
North American PeopleSoft
Enterprise One System Administrator
Praxair Inc.

Gregg,

Exactly. By the way, your comments about the application servers were forwarded on to my CTO about a month back. We disabled the application server BSFN mappings before I went on vacation and things worked fine without them. When I returned, I was congratulated and given a raise. HAHAHAHAHA! That didn't happen, but we did cut more than 10 application servers from our support nightmare.

Thanks again,

Thanks for the replies.