The following is in response to the numerous questions/complaints
concerning the new 32-Bit Windows client installation package.
The note was composed by the Mike Collins, who is the primary ADSM
NT server developer, and who designed much of the new installation
package.
Mike is having problems appending to the list server so I am posting
this append on his behalf.
Pete Tanenhaus
ADSM Client Development
------------------------------------------------------------------------------
Hello,
Hello,
There have been a number of interesting comments and suggestions
regarding ADSM client installation over the past few days mostly
stemming from the ptf 5 win32 client.
Following are the key topics I've picked out of the discussion along
with comments and answers to questions. To save space I'll be cutting
sections out of various notes and will try not to change the original
context. The sections I've cut out have a > as the first character of
a line.
First, let me say that we hear what you're saying, we appreciate your
cooperation in helping us to determine your installation and
configuration needs, and we value your feedback. Please respond with
ideas and suggestions to either this forum or directly to me at
ecollins AT vnet.ibm DOT com.
=============================================================================
> Unfortunately, the installation process for the Level 5 PTF for the 32
> bit client is such a mess that I cannot in good conscience give it to
> anyone to try to install. Something that does not clean up the old
> release, and requires two DSM.OPT files to run is in effect
> uninstallable at my shop. Can we get this fixed for the level 6 and
> go back to a single directory for both the client and the admin, and
> follow that basic rule we all learned in Kindergarte n "CLEAN UP AFTER
> YOURSELF!" Until that time - I will not propagate this release unless
> someone is directly complaining of a bug that this release fixes.
CLEANING UP AFTER YOURSELF
The old win32 installation was based on the Microsoft setup toolkit.
The new win32 installation uses InstallShield which is not only
recommended by Microsoft, it is being standardized on by IBM for
all IBM products running on Windows platforms. Many companies are
using InstallShield so that customers will have a familiar
installation procedure when installing products on Windows.
The problem with cleaning up after older win32 clients is not due to using
a new install tool, it is because the old one did not include a deinstall
program or store any install-related information in the registry.
Starting with ptf5 you can deinstall individual components and since
install-related information is stored in the registry, ptfs starting
with ptf5 will be able to clean up after themselves.
As far as cleaning up pre ptf 5 installations I'd suggest doing a
manual deinstall. I know this will be time consuming when many clients
are involved as it basically adds one or two steps (a and or b below)
to the new install:
a. Save options file (optional)
b. Using file manager, select the dir (ex: c:\adsm) and press the del key.
c. perform new install.
TWO OPTIONS FILES
Ptf 5 introduces a new directory structure. This matches the structure of
the full ADSM for Windows NT package.(which GA'd Sep 27th!) The full
package has many components and each gets a subdirectory in the tree.
The saclient and baclient are separate components and are installed in
separate directories. When more than one component is installed in a
directory it becomes hard to remove or upgrade a single component
because it is not always clear what can safely be removed or replaced.
When separate components are in their own directory you can adjust the
contents of a directory without impacting another component.
Some customers prefer separate options files because while the
baclient usually points to one server an admin client could point to
several servers. If you change a common opt file for the benefit of
an admin, then you either have to change it back for the baclient's
benefit or find out the hard way when you use the baclient again and
then have to change it. If they both stay the same then it comes down
to: copy dsm.opt ..\saclient or a drag/drop from file manager.
=============================================================================
> Please take this as a requirement: Customers need to be able to customize
> the installation process for their own users. Please provide installation
> tools that allow for this.
> The 2.1.5 version of the ADSM Windows client uses InstallShield to
> install and setup ADSM. Is the ADSM InstallShield rules file
> available? Of course we want to customize the install for general
> distribution here; insure ADSM goes into the 'correct' directory, that
> the appropriate components are installed, etc.
CUSTOMER'S ABILITY TO CUSTOMIZE THE INSTALLATION PROCESS
InstallShield has a Silent install option (setup -S) that allows an
administrator to specify both the sequence of dialogs and answers to
each dialog -- I.E. the administrator specifies a path through the
install sequence. This allows you to specify all parameters including
what gets installed and where it gets installed. Samples will be made
available in upcoming ptfs.
The readme files come in two forms starting with ptf 5 and in the full
ADSM for Windows NT product; 1) as a text file in each component
directory and 2) All readme files are in a single README.HLP file.
The advantage of the readme.hlp file is that you can use the windows
help engine to search through all component readmes. You can also
print, copy, set bookmarks, and annotate parts of the readmes.
InstallShield includes a compressed file and set of uncompressed files
as part of the distribution. While we currently have the dsm.opt and
readmes in the compressed file we can move them to the uncompressed
directory. Although we need to test this before saying we'll do it, I
believe we can do this and it would allow you to modify or replace
these files.
The server utilities package, available in the full ADSM/NT product
package, includes a client configuration wizard that allows you to
create a client configuration package. This package includes a .cfg
file a .bat file and a GUI .exe file. The idea is that all clients
connect to a shared drive. For example, I share a directory (c:\shared)
on a file server and have each client connect to that as drive z:\.
You run the wizard on the ADSM server where it will detect protocol
values for the protocol you select, allows you to specify a base
options file (for incl/excl etc) and stores the package in a location
of your choice. If you tell the wizard to create a package named
srv1tcp in z:\ it will create and copy srv1tcp.cfg, srv1tcp.bat,
dsmcfg.exe and any specified base options file to z:\.
Any or all clients can cd to z: and enter: srv1tcp. A gui will appear
displaying what will be done and prompting for a node name (which
defaults to the NETBEUI machine name). When the client clicks ok,
dsmcfg will look in the registry to see where the baclient was
installed and will write out the options file that will allow it to
connect to server1.
+-------------+ +-------------+ +-------------+
|ADSM Server1 | |ADSM Client | |ADSM Client |
| | | z:\ | | z:\ |
|20.12.34.7 | +-------------+ +-------------+
| |
| z:\ | +-------------+ +-------------+
+-------------+ |ADSM Client | |ADSM Client |
| z:\ | | z:\ |
+-------------+ +-------------+ +-------------+
|File Server |
| | +-------------+ +-------------+
| c:\shared | |ADSM Client | |ADSM Client |
| srv1tcp.bat | | z:\ | | z:\ |
+-------------+ +-------------+ +-------------+
A prototype version of dsmcfg.exe also exists for Presentation Manager on
OS/2 and a Motif version is integrated with the server utilities on
AIX. This mechanism allows you to easily assign clients to particular
ADSM servers as well as to setup certain clients to use certain
protocols or to share base options files. It is intended to provide
one way to help customers configure their ADSM clients.
=============================================================================
> I have about 500 ADSM clients of various platforms that I maintain.
> When a new version is released, it is I who must upgrade each client.
> This currently is a client-by-client process and takes weeks. What
> would be really nice is to put the new client code on the ADSM Server
> and set a switch that would cause each client to download the new client
> and install it automatically during the next incremental backup.
>
> Any thoughts from the group or from IBM on this idea.
> The answer is probably Netview/DM or TME10 Software Distribution as
> they now call it.
> A kludge might be to upgrade one workstation and backup the adsm directory,
> then restore -fromnode on the other clients. The only issue would be to
> restore to another directory than the current adsm one because the dsmc
> would be in use.
> This makes so much sense. I know some of ADSM's competition already
> works this way. They should be able to do it for us. I wonder if
> they don't because it might compete with their software distribution
> product.
This is an interesting idea and one that has been around for awhile.
There are a number of issues involved. Network management software
from IBM, Microsoft, and others is available and we expect that many
customers who have lots of clients will have this kind of software.
We also know that many customers will not have this kind of software.
It could work as suggested above where a client package could be
backed up and then scheduled for a restore on each client. Problems
show up though when the destination directory is different on
different clients, restoring files that are in use, rebooting,
determining free disk space, making registry entries, handling error
conditions, etc. Combine this with the variety of platforms ADSM
supports and we would have to basically create a network management
software package as part of ADSM.
Other alternatives start to look good when you start considering the
details of this approach. We would be interested in hearing details
though of any ideas along these lines.
=============================================================================
> We are using ADSM heavily for two years now serving hundreds of nodes
> of all kinds per site (having six sites spread over the country).
>
> Since we are using DCE/DFS also heavily we exploited this technique to
> install ADSM UNIX clients once and for all in ONE central place for ALL
> users, that want to participate (we just offer this service, local
> installation is not forbidden, but it does not make sense to support or
> maintain hundreds of them manually). Data, that may be different (eg.
> dsm.sys, dsm.opt) from client to client, may be kept locally, of course.
>
> After installation within DFS (AFS, NFS3, or - if LAN - NFS2DFS, or NFS2
> would do the same job) all that remains to do on the client side is to
> restart the schedule demon.
>
> For platforms not currently supported by this idea (PCs) at least
> automatic local installation or updates are possible by downloading
> pre-configured company-fit ADSM client packages from one server (the
> same as above) just by activating an icon.
> Better yet, IBM, how about accepting and planning for the idea that many
> installations are going to be distributing ADSM via FTP. I suspect enough
> of us do it, that it would be a real bonus to us all.
>
> - Don't depend on loaddskf, use self-extracting exe files (or whatever is
> appropriate for the particular platform
> - Provide user instructions on how to install this way
> - Allow user installation to first customize dsm.opt (preferences) file
> before putting up on local ftp site. Also allow customization of readme
> files, inclexcl, etc. I.e., don't put it all in a black box without
> giving us the key and a way to change the contents.
Using an application server is a very reasonable approach to managing
a large number of clients. Depending on the network configuration
available and desired variety of client platforms this could be very
appealing as it greatly reduces the copying, updating and configuring
process.
Creating a custom ADSM package and distributing it using FTP can also
be a reasonable approach depending on your network and software
configuration. Including an example of this in the documentation would
be useful.
There may be licensing issues regarding the use of pkzip on certain
platforms. It will have to be looked into further. We will provide a
silent install sample and will look into having the readme and options
files in the uncompressed set of files to allow more custimization
possibilities.
This was a long note about an important topic. If you have further
suggestions please respond. (I haven't heard any web based options
mentioned yet...) We will be working to improve our installation and
configuration and we value your feedback.
Regards,
Mike Collins
ADSM Server Development
|
