Date: October 1, 1996 Time: 13:53
From: Jerry Lawson
ITT Hartford Insurance Group
(860) 547-2960 jlawson AT itthartford DOT com
-----------------------------------------------------------------------------
This is intended as a constructive response to the posting from Mike Collins
This is intended as a constructive response to the posting from Mike Collins
about Client Installation issues. Mike posted a very informative note the
other day, and I have taken my time in responding in hopes that I would get my
response on the same high level that he used in his post. This may wind up
being long - for that I apologize in advance......And Pete Tanenhaus - if Mike
is still having difficulty with the list, can you please forward this to him?
I have documented my concerns about installation several times, but I am
beginning to wonder if the amount of work that we have to go through to
distribute ADSM to our customers is really clearly understood. I know here at
The Hartford, we have approximately 500 installed users, and that number is
growing again, after being stable for a while. I am not a PC trained person -
my background is mainframe systems programming first, with a touch of storage
management on the side. When it comes to being able to handle all of the plat
forms ADSM supports, all I can say is that I am better on some (such as OS/2)
than others (such as Windows 95), and some (Unix) I have no experience on at
all. Still it falls on me as the project leader and house ADSM bigot to
understand new features and products, and get them out to LAN administrators
and PC support staff in a timely manner.
One of the major pluses when we selected ADSM as our backup tool was the
consistent approach that was applied to the initial design. This starts with
the consistent look and feel of the clients as they are applied to each
platform. At the same time, they are appropriately implemented for that
platform. For example - the MAC client looks and runs like a MAC application,
not a Windows app, but at the same time - all of the functions are implemented
in a consistent manner, so that I don't have to learn a bunch of special MAC
stuff to use the MAC ADSM client. The same can be said for OS/2 and Windows
3.1. Even the NetWare client, if you look at it from a comparison to the
other command line clients, is consistent in this manner. While my only
exposure to Unix has been by watching someone else install the Sun client -
the GUI seemed very consistent.
The same used to be true with the installation process. All Intel (and MAC)
clients installed in a directory called ADSM. The options file was right
there, in the same directory. There were no problems in doing this that I
ever ran into, outside of a minor problem with a backup copy that I think was
resolved at V1 level 7. But then along came the Win95 client, and first it
created a directory called ADSM32. (I am speaking about Level 3 of the 32 bit
client - we really didn't use the NT client from level 1 and 2). This caused
some problems for us because first of all, it was different for no apparent
reason, and installation procedures had to be changed. Many of my customers
used the Win3.1 client on their Win95 systems, even though it didn't support
long file names, because they had been using the client on Win31, and didn't
want to stop backing up their machines until the Win95 client became
available. Also we didn't use long file names, and so applications, and perso
nal files were probably OK. So many of my Win95 installations went over
Win31, and we had to futz with the directories. I could at least rationalize
this to myself in saying that what we did was not supported, even though it
was widely known to work.......
Now we get to a level change within the supported code, and also the eagerly
awaited Win95 Admin GUI client. And what do I find? Another change in the
installation process, and a completely different set of libraries, and nothing
to support the cleanup process. And while I have read the response several
times, I still do not have a good reason as to why. Here is why I say that.
(I have not included Mikes responses, and our original questions, because this
is already too long - please refer to the original note.)
CLEANING UP AFTER YOURSELF.
I am sorry - but there is no excuse here. IBM - you wrote the code. You know
what the module names are. If the Microsoft programs that you are using do
not support deleting a known set of modules from a directory that you
suggested, then you should write a program that deletes these and cleans up
any associated folder/programs and call it a post clean up job. It is not
necessary to search the whole hard drive - if the default names of the
libraries were not used, or there is not an easy way to determine that the
customer has changed the names, then that is my problem - not yours. But if I
have followed all of your naming conventions, you should be able your own
conventions, and find DSM.EXE and delete it. You guys are the experts here, n
ot me. And I have wasted an awful lot of time debugging problems that were
traced back to having more than one copy of the same program present - it
would probably save your support staff enough time to justify the costs.
TWO OPTIONS FILES
I have never wanted more than one options files. We have more than one
server, if you count the test server, and the one I use for demos. I keep
this separate via putting scripts together to launch the appropriate applicati
ons and options combinations. The other 25 or so people that we have
installed as local administrators with policy level authority never have to go
after these servers. They do not want or need two options files - it is more
confusing - for example - if the server name changes, I have to remember to
change it in two places now. Just yesterday, I had to debug a problem with a
brand new customer install with the level 5 Win95 client (the only kind I will
do) where the LAN administrator had copied a standard DSM.OPT file to the ADS
M directory instead of the BACLIENT directory. I think that the majority of
people would like one options file - not two. How about leaving it in the
ADSM directory?
This also brings me to the issue of two directories. I still don't understand
"Why". I have the OS/2 server and client (both admin and backup) installed on
the same machine. The server is separate from the client - no problem. But
the Admin is in the same directory as the backup client. I have no problems
here. It works fine. There is no confusion about which modules do which. I
still don't see why this couldn't have been done with the Win95 client. It
would have made the whole issue of two options files go away, and the
Microsoft install wizard should still be able to deinstall the files. Maybe I
am being overly dense - if so tell me - I can take it - but this just seems to
have missed the point.
CUSTOMIZING THE INSTALL PROCESS
I have not tried to customize the installation process yet, and so am not
qualified to comment on this process. However - remember the old addage
"Everything in life is like ripples in a pond - everything you do touches me -
everything I do touches you." The last thing that someone who has set up a
customized install process wants to hear is that the process just changed.
That kind of activity just makes them NOT install the new maintenance until
they can find the time to rewrite and retest the installation.
AUTO DOWNLOADING of NEW CLIENTS
From the conservative systems programmer in me, my first impulse is to say -
No way - what if something is bad and the new release won't work...... But
let's get over my conservative midwest nature and look at this in more detail.
When you do - I think that this becomes a VERY GOOD idea. And when you start
thinking of the consistency in approach issues that I raised before - then it
looks even better. You folks now support what appears to be over 20 different
client platforms. You're probably saying - that's too many to do a "download
from the server" approach - two many variables. But if you don't do something
like that - who will? I worked on a Software distribution project for over a
year about 3 years ago - and at that time I would say that the market will
never support that kind of versatility. And even with NetView DM - I wouldn't
expect to see it today. A general product to install anything on everything
from plain old DOS and Macintosh and NetWare to all of the Unix flavors, and
now DEC platforms is quite a product. You have a luxury of knowing what you
need to install, and where it should go. Again, if we decide that we need to
change the defaults, then I think we have to take responsibility for our
actions. I for one am willing to forego that level of individuality in order
to get new client code distributed to all of my customers in a timely manner.
If I can ever cut through the corporate red tape - that could be well over
10,000 clients.
This is already too long. The unfortunate part of it is that you've already
done it. Fixing it now for the next release will cause problems with all of
the new releases and upgrades we have done - UNLESS you are willing to commit
to making the changes we requested and getting them into the level 6 fix so
that we can wait for it with some certainty. For the most part, the real
serious problems were addressed with the level 4 fixes for the API. This
release only fixed scheduler problems for me (and not all of those) so I can
postpone it - outside of the people clamoring for the GUI Admin. But then
again they've waited this long.......
I really am serious here - this release deserves the William Tell Near Miss
award. It is a product that we all use daily. We all believe highly in the
product. If you had missed the mark by a mile, we wouldn't have used the
product at all, and no one would care. But you were close. but you missed
the arrow. And prize that went along with this award (beside the arrow
through the forehead) is a broken anvil. And do you know how hard it is to
break an Anvil. I really wish you would have consulted with the people on
the list before you had made these changes. I am always more than happy to
provide my input (as you can tell from this note).
If anyone else got this far - do you agree? Disagree? Should I keep quiet?
*****************************************************************************
Jerry Lawson
ITT Hartford Insurance Group
jlawson AT itthartford DOT com
PS. Mike - if you designed the Win32 Admin client - great job - I am pleased,
and it seems to perform well too.
|
