Hi,
I've been conducting several tests for upcoming installations taking place at a client’s site. Due to a lack of hardware and resources, I've had to resort to using my workstation to conduct this testing. To be clear, I already have Progress OpenEdge 10.2B locally installed on my workstation (which is unrelated to the following experiment, but is mentioned due to the similar nature to what I may soon be encountering).
The Experiment:
I've been assigned to a project that requires a shared network installation (stored on a remote mapped Windows drive; We'll use 'B:\' for the sake of this discussion), which the clients will utilize (for netsetup local installation on their end). The client-end of the task is of no concern, as it is pretty straight forward and there really isn't all that much to comprehend. I am more confused on the actual complete installation itself (on B). To be more specific, this is what I've discovered.
In a test environment, I loaded a virtual machine (Windows-based) which was to simulate the 'NAS’ (B Drive). So, to the installation machine, it just sees B, which doesn't make a difference as we're simulating a NAS-setup in this case. It’s just a place to store files. A remote logical partition, if you will.
When I installed 10.2B to the ‘B:\’ drive, I observed that while the installation program created all Progress files in the intended remote destination (on B), the installation program obviously placed local registry keys (of the new installation) in the system which initiated the installation (my system), vs the 'B Drive'. I knew this would occur, so that is not a surprise.
Here is my issue: When trying to work with Progress files (i.e., prowin32.exe), I would receive errors, which according to research (progress kb articles), indicated that Progress was unable to start properly because the registry was now pointing to configuration files on the 'B Drive' (at this moment in time, the VM (acting as B Drive) was turned off, so it would be unable to call the 'remote' configuration files needed to initialize the platform). At this specific moment, this was an issue because I had other commitments which required use of my typical Progress installation (stored locally; but it also occurred to me that this same issue could become a serious problem for the client).
I tried modifying some registry entries on my host to point to the correct configuration files, but that didn't work out; so I'll probably have to re-install the platform on my machine - no big deal. I'm more concerned about the outcome, if anything.
Questions
1. I was aiming for a side-by-side installation on one machine/host (two copies of 10.2B - each with different licenses). One installation was intended for local compiling and the other was intended to serve as a shared location where clients could reach netsetup. Is a side-by-side installation possible with the same version of OpenEdge? In other words, can I have two instances of 10.2B installed, without there being any problems? If not, this is not a problem, but it would be nice if someone else could confirm this, as well.
2. I do realize that having both licenses, as well as one installation/location, where the compiles could take place, and also where the client machines could call netsetup would obviously be more efficient. If it was up to me, I would define this within the scope of the project, but that is beyond my role and level of authority within the audience I am working with. The client wants to have the platform installed to a NAS device, but has been unclear as to which systems they have administrative access to. In other words, it has been strongly implied (not confirmed) that the client may want to install to the NAS from a system that already contains a Progress OpenEdge 10.2B installation. This, to me, is potentially a major issue as I experienced problems doing this in my own test environment. If this is not possible, and an installation must be carried out on an alternate system, I would very much appreciate if someone could confirm this. If this is correct, then at least I can inform the client of this specific requirement. So, in my specific case, would the remote installation have to be done by a different host? I believe this would probably be the solution.
3. What occurs when the files on 'B' are unable to reference registry entries on the system which installed the platforn (due to network connectivity problems, etc.) - is this something I need to be concerned about? Was Progress even intended to be installed in this fashion? I have been unable to find any documentation which specifically mentions NAS device configurations or a setup like this. In case anyone is unaware, NAS stands for network attached storage, which is essentially a collection of hard drives (typically configured in a RAID setup for data protection/redundancy purposes) that is connected to the network, and does not contain an Operating System of any kind, at least not any that I'm familiar with.
But the client has not been clear on whether this is a NAS or SAN we’re dealing with. I’m thinking it doesn’t make a difference in this specific context. Any help is greatly appreciated. Thank you.
Progress on windows must be installed on the system that'll be running the code. Installing to a remote storage device and then access the binaries from another, unrelated system won't work.
On Linux / Unix - you may be able to get it to work because no registry entries are involved.
I was able to access the binaries without any problems. My client workstation test machine was able to successfully install via netsetup from the remote storage device, even though the installation was performed by another host (and not the storage device/test vm itself).
Also, when you run netsetup, the workstation creates local registry entries for itself and simply points to the remote storage which holds the platform files.