Re: Remote automated installation of Oracle clients

In our lab, we created an MSI file that was pushed onto the client's PC. The MSI only contained the registry values, all the software was on central (replicated) servers. The installation was very quick (just touching the registry). That was the time when we still had to support Developer 6i, and at that time, the oracle installer was really a bad bad piece of software. The current MSI contains things like Developer + Developer 6i, Oracle 9i + 10g clients.
It was not a flawless process, as sometimes, the local installation was somehow ruined for unknown reasons, and the client had to manually either refresh the msi or remove it and reinstall it.

Now with the instant clients, and Forms on the Web, it is much easier. By default, all he users get the latest instant client package (local intallation) only (widely used for ODBC access from Excel et al). For the forms and designer developers, we prepare some basic installations using oracle response files. It is a small community, so it is easy to maintain. The tnsnames.ora is still located on a network disk.

If there are users that are "smart" enough to perform their own installation (XE ...), then they are smart enough to resolve the potential conflicts with different installation kits. We shall not support them unless they abide by our rules... :)

regards.

Nilo Segura
Oracle support - IT/DES
CERN On 1/10/07, Edgar Chupit <chupit_at_gmail.com> wrote:
>
> In our shop we are using automated installation of Oracle client at
> application startup time.
>
> Our application is checking for installed Oracle client. If client version
> doesn't much with the one we are trying to install, it tries to uninstall
> old client and install new one.
>
> As a client we are using Oracle Instant client 10.2.
>
> To connect to our DB we are using new connect string format
> name/pass@//hostname/sid by using this format we can later change "address"
> of the server, simply by changing IP entry at DNS server. Because we have
> very heterogeneous network and only few databases we didn't even considered
> using OID/AD.
>
> From our experience I can fully agree with Niall that a real pain in all
> this process is deinstallation of oracle client from user computers,
> especially when a user "for security reason" doesn't have enough privileges
> on his workstation. Uninstallation should be also performed with care, what
> if he has some other application, that you "don't care" about (or he has
> installed OracleXE to play with, or he has to connect to 8.0 database, but
> new oracle client doesn't support it), what should your script do? Uninstall
> it? Replace tnsnames.ora? Or what?
>
> What we have done first of all: we have selected dozen different
> workstations (that were bought/installed at different time frames) analyzed
> its configurations and developed "patterns" to recognize standard
> configuration and to know how to correctly replace it. And than made a
> decision, that if we are not sure that we can uninstall Oracle client
> "safely" from workstation (if tnsnames.ora is different from default, if
> version is unknown, if user has oracle servers binaries, it is better to
> inform user describe a problem to him and ask him to contact us to solve
> this problem. Because in reality by changing Oracle client you are not only
> affecting your application configuration, but you are changing user
> workstation configuration. And if you will brake something at users
> workstation that user will be very angry at your department and your
> application. "Advanced" users never contact us, they are able to solve a
> problem by they own.
>
> Of course we only have 350+ workstations spread over 30 sq.km.
>
> On 1/10/07, Stephen Booth < stephenbooth.uk_at_gmail.com> wrote:
> >
> > On 10/01/07, Niall Litchfield < niall.litchfield_at_gmail.com> wrote:
> >
> >
> > Thanks.
> >
> >
> >
> > Part of the prep work we're doing for this is going to be tracking
> > down as many of the apps as we can. We're not going to get them all
> > but we're, of necessity, going for an 80/20 rule. If we find a
> > solution that deals with 80% of our desktops then we'll consider it a
> > success and deal with the other 20% as exceptions. Obviously we'll
> > hope to do better than 80% sorted on the first pass but even that with
> > 2400 'exceptions' will be better than we've got right now.
> >
>
>
> --
> Best regards,
> Edgar Chupit
> callto://edgar.chupit

-- 
Nilo Segura
Oracle Support - IT/DES
CERN - Geneva
Switzerland

--
http://www.freelists.org/webpage/oracle-l