Discussions
Categories
- 196.7K All Categories
- 2.2K Data
- 235 Big Data Appliance
- 1.9K Data Science
- 449.8K Databases
- 221.5K General Database Discussions
- 3.8K Java and JavaScript in the Database
- 31 Multilingual Engine
- 549 MySQL Community Space
- 477 NoSQL Database
- 7.9K Oracle Database Express Edition (XE)
- 3K ORDS, SODA & JSON in the Database
- 532 SQLcl
- 4K SQL Developer Data Modeler
- 186.8K SQL & PL/SQL
- 21.3K SQL Developer
- 295.4K Development
- 17 Developer Projects
- 138 Programming Languages
- 292.1K Development Tools
- 104 DevOps
- 3.1K QA/Testing
- 645.9K Java
- 28 Java Learning Subscription
- 37K Database Connectivity
- 153 Java Community Process
- 105 Java 25
- 22.1K Java APIs
- 138.1K Java Development Tools
- 165.3K Java EE (Java Enterprise Edition)
- 17 Java Essentials
- 158 Java 8 Questions
- 85.9K Java Programming
- 79 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.2K Java SE
- 13.8K Java Security
- 203 Java User Groups
- 24 JavaScript - Nashorn
- Programs
- 394 LiveLabs
- 37 Workshops
- 10.2K Software
- 6.7K Berkeley DB Family
- 3.5K JHeadstart
- 5.6K Other Languages
- 2.3K Chinese
- 170 Deutsche Oracle Community
- 1.1K Español
- 1.9K Japanese
- 230 Portuguese
Anyone install windows client on network drive?
At a place I did some work for a couple of years ago, the Oracle client (11.x +) was installed on a network drive rather than installed on users (Windows) workstations.
IIRC, the install was just pointed to a network share, then a .reg file was generated and rolled out to the clients, so when they opened up an app that needed the client, it pointed to the client on the network drive.
Present day, company I am doing some work for is still using an Oracle 10 client for a legacy app using Oracle 10 database, which is going away in a few months. In the meantime, they need to test an app that needs an 11 or later client, and are also rolling out Windows 10 before the end of the year and want to include a newer Oracle client as part of the roll out.
I'd like to look at having the client on a network share, initially so this new app can be tested with a newer client, and if there are no show stopping issues with this use the network install approach instead of installing it on client workstations.
I'm trying to remember exactly what was on the .reg file that was rolled out, and how it was generated, hoping someone here has done something similar and can share how they did it.
Thanks in advance.
Best Answer
-
GlenStrom wrote:At a place I did some work for a couple of years ago, the Oracle client (11.x +) was installed on a network drive rather than installed on users (Windows) workstations. IIRC, the install was just pointed to a network share, then a .reg file was generated and rolled out to the clients, so when they opened up an app that needed the client, it pointed to the client on the network drive. Present day, company I am doing some work for is still using an Oracle 10 client for a legacy app using Oracle 10 database, which is going away in a few months. In the meantime, they need to test an app that needs an 11 or later client, and are also rolling out Windows 10 before the end of the year and want to include a newer Oracle client as part of the roll out. I'd like to look at having the client on a network share, initially so this new app can be tested with a newer client, and if there are no show stopping issues with this use the network install approach instead of installing it on client workstations. I'm trying to remember exactly what was on the .reg file that was rolled out, and how it was generated, hoping someone here has done something similar and can share how they did it.Thanks in advance.
What needs to be in the reg file is the Oracle key that goes under HKLM/Software. You need to standardize on how the network drive will be mapped (say, to the "X:" drive. Install to such on a golden image, then extract the HKLM/SOFTWARE/Oracle key. We used to do this in a shop I worked at quite a few years ago. In fact, it seems like we might have been able to bypass the drive mapping by using a unc reference. You can always experiment with that. We had it simpler then, as we only had to worry about 32-bit. Supporting both 32-bit and 64-bit (when WILL software developers, MS included, simply quit supporting 32-bit? When was the last time you could even purchase 32-bit hardware?) will be quite a bit more complex. It shouldn't be in theory, with simply pulling the registry key from two locations, but it has been my experience that when dealing with this, theory seldom works out in practice.
Answers
-
GlenStrom wrote:At a place I did some work for a couple of years ago, the Oracle client (11.x +) was installed on a network drive rather than installed on users (Windows) workstations. IIRC, the install was just pointed to a network share, then a .reg file was generated and rolled out to the clients, so when they opened up an app that needed the client, it pointed to the client on the network drive. Present day, company I am doing some work for is still using an Oracle 10 client for a legacy app using Oracle 10 database, which is going away in a few months. In the meantime, they need to test an app that needs an 11 or later client, and are also rolling out Windows 10 before the end of the year and want to include a newer Oracle client as part of the roll out. I'd like to look at having the client on a network share, initially so this new app can be tested with a newer client, and if there are no show stopping issues with this use the network install approach instead of installing it on client workstations. I'm trying to remember exactly what was on the .reg file that was rolled out, and how it was generated, hoping someone here has done something similar and can share how they did it.Thanks in advance.
What needs to be in the reg file is the Oracle key that goes under HKLM/Software. You need to standardize on how the network drive will be mapped (say, to the "X:" drive. Install to such on a golden image, then extract the HKLM/SOFTWARE/Oracle key. We used to do this in a shop I worked at quite a few years ago. In fact, it seems like we might have been able to bypass the drive mapping by using a unc reference. You can always experiment with that. We had it simpler then, as we only had to worry about 32-bit. Supporting both 32-bit and 64-bit (when WILL software developers, MS included, simply quit supporting 32-bit? When was the last time you could even purchase 32-bit hardware?) will be quite a bit more complex. It shouldn't be in theory, with simply pulling the registry key from two locations, but it has been my experience that when dealing with this, theory seldom works out in practice.
-
When installing something simple like SQL*Net 7.0 or Oracle 8, you can get away with something simple like HKLM/SOFTWARE/Oracle, but now there are many things associated with the install. OLEDB, ODBC are two that I can remember but there are several more. You almost need to use software to take a snapshot before and after and compare them. This is what I did up until Oracle 10. It took 5 minutes to copy the software to C: and reset the Windows Registry. With Oracle 11 and Windows 32/64 it became too complicated. Now we use silent installs. It takes an hour, but we know that it does everything that Oracle Support expects.
-
I did this at the last company I worked for. To get it set up, I started with a desktop that did not have any Oracle software installed on it. We used the O: drive (O for Oracle) that was mapped to everyone's workstation. So everyone had access to the drive. On my basic workstation, I installed the Oracle client software and installed it on the O: drive. After the installation was complete, I used regedit to export HKLM\Software\Oracle to a .reg file. I also used regedit to do a string search for 'oracle' and get any registry keys that are outside of that hive location. This is important if you want access to the ODBC drivers. I did have a few .reg files after my exports, but I opened those files in Notepad and copy/paste everything into one file. Installation was as simple as double-clicking on the .reg file and client was set up for the user.
Cheers,
Brian -
-
Thanks - did you export the entire key under HKLM_LOCAL_MACHINE\SOFTWARE\ORACLE?
Re 32 & 64 bit clients - that's an issue they have run into here too, whereas some legacy apps still need the 32 bit client while newer ones require the 64 bit. It can be a real pain in the you-know-what..
The challenge they have now is going to be keeping the 10 (64 bit) client around until the legacy app is gone.
update - was on a support call with Oracle about another matter and did not realize there was other replies before I finally sent this one ;-)
-
BPeaslandDBA wrote:I did this at the last company I worked for. To get it set up, I started with a desktop that did not have any Oracle software installed on it. We used the O: drive (O for Oracle) that was mapped to everyone's workstation. So everyone had access to the drive. On my basic workstation, I installed the Oracle client software and installed it on the O: drive. After the installation was complete, I used regedit to export HKLM\Software\Oracle to a .reg file. I also used regedit to do a string search for 'oracle' and get any registry keys that are outside of that hive location. This is important if you want access to the ODBC drivers. I did have a few .reg files after my exports, but I opened those files in Notepad and copy/paste everything into one file. Installation was as simple as double-clicking on the .reg file and client was set up for the user. Cheers,
BrianBrian,
Hate to revive a dead thread (but it seems the body is still warm!) but I just stumbled across this while looking at something else. With fresh eyes I have a few comments/questions.
Having done this several employers back (see one of my previous comments) I've started giving some thought to trying to implement it at my current position. One thing that strikes me as haveing been left out of the previous comments is other things that need to be set in the newly configured workstation, in addition to the registry settings.
First is setting %ORACLE_HOME%/bin into the system environment setting for PATH. And that could include both 32-bit and 64-bit homes. Did you somehow automate setting it? How did you deal with the 32-bit vs. 64-bit fight, and who gets precedence in PATH?
Second is the oracle central inventory, always (??) at C:\Program Files\Oracle. Again, how do you populate it?
Third is setting TNS_ADMIN into system environment variable.
As best I recall, where I did this these things (apart from the 32 vs 64 fight) were pushed out to the client workstation as part of the network logon sequence - registry settings, environment variables, and central inventory files. That was set up by the sysadmin responsible for network access and the logon sequence.
Comments?
-
Hate to revive a dead thread
Its only five weeks old. I've seen people dust off ones five years old!
First is setting %ORACLE_HOME%/bin into the system environment setting for PATH. And that could include both 32-bit and 64-bit homes. Did you somehow automate setting it? How did you deal with the 32-bit vs. 64-bit fight, and who gets precedence in PATH?
Back when I did this, we did put in the registry key to set the PATH env var. But back when I did this last, there was no 64-bit client either. So it was a much simpler time. We controlled the software on the workstations so we knew what the PATH would be for everyone. I would think if I had to do this today it would be more complex where end users often require different sets of software. So if I did this today, I would probably look towards using a Powershell script to modify PATH.
Second is the oracle central inventory, always (??) at C:\Program Files\Oracle. Again, how do you populate it?
This wasn't an issue for me back in the day. We never patched the Oracle client back then (I'm talking about Oracle 8 and 8i days). If we did upgrade to a newer client version, we just imported new registry settings for the new Oracle home. What would I do today? Probably move the oraInventory to a shared drive and then look in HKLM->Software->Oracle for the key named inst_loc. Change this to point to the oraInventory you copied to the shared drive.
Third is setting TNS_ADMIN into system environment variable.
This is just an env var. You can set this with a key in your .reg file you import. Look in HKEY_CURRENT_USER\Environment and HKLM\SYSTEM\CurrentControlSet\Session Manager\Environment for user and system env vars.
HTH,
Brian
-
Looks like may be a moot point, it seems (at least with 12.2 & newer) that the client will not let you install to a network drive.
I finally got around to trying this, took a clean machine,, found a location that everyone has access too and pointed to it for the oracle home and installation folder then ran OUI to install the client from it.
Created an "oracle" folder & made sure everyone had rights to it, but OUI won't let me get past the 3rd step and won't take a networked drive as a location for Oracle base & software location. Even tried creating a share on another workstation & granted everyone full control over it, but still get INS-32012 "Unable to create directory" errors when trying to choose the share as install location.
update: I found out you need to map to the network drive from the machine you're installing from to avoid the INS-32012 error, so I got it installed, now to test exporting reg files and accessing the client from other workstations
-
update: I found out you need to map to the network drive
Yep...that is what I did in the past. In my first response in this thread, I mentioned that we used the O: drive. So we mapped the UNC path to a drive letter on the workstation. But this was part of our group policy that everyone in the company mapped the O: drive (where O stood for Oracle).
Cheers,
Brian -
Update 2: install went okay, and I am just checking over the registry export for HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE key. It looks straightforward enough but for the referral to C drive for inventory location.
I am curious if the "inst_loc"="C:\\Program Files\\Oracle\\Inventory" part would be even needed, but probably safest just to copy the (inventory) contents to a folder to the mapped drive and edit the key to reflect it.
I did a custom install, only picking components I think we'd need here, including ODBC. Then did a registry search for "oracle" and only found some obscure references to OLEDB keys, nothing to do with ODBC. I may redo the install without the OLEDB component, as I'm not sure its needed. There was no references to ODBC showing up (in search for "oracle") in the registry.
update: found the oracle ODBC entries under the HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ key, & copied them into the text file I created. Also notice that there's a TNS_ADMIN registry entry in the ORACLE key, so curious to see if a TNS_ADMIN environment variable will need to be set in workstations
