Thanks Brett -
It was good to hear some thoughts on the subject from ADSM.
We would like to make it next to impossible for users to even see
the Network volumes. I don't want them backing up any network volumes. I
have ADSM backing up those Netware and NT volumes already.
I would also like more security administered from the Administrator
console to prohibit
access to various options on the client.
TIA -
CR
________________________
Cris Robinson
Senior Technical Analyst
Desktop Services Technical Support
Liberty Mutual Insurance
603.431.8400.54837
cris.robinson AT libertymutual DOT com
> -----Original Message-----
> From: Brett Walker [SMTP:walkerbl AT VNET.IBM DOT COM]
> Sent: Friday, April 03, 1998 8:36 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: It's too easy !
>
> *** WARNING: Long Post ***
>
> Sigh. Well, it looks like I need to wade into the fray. As the
> developer
> who actually designed how this function works, maybe I can shed some
> light
> on this issue, at least to what the thought processes were:
>
> Thoughts
> --------
> 1) Realize that in ADSM, no matter what version, the DOMAIN option has
> always been only a *suggestion* of what should be backed up. Using
> the
> command line, you can backup anything in or out of the so-called
> domain.
> Same way with the GUI. The V2 GUI did indeed highlight the drives
> listed
> in the domain, but all it took was a "Select All" and everything was
> highlighted. The user has *always* had full control of what could be
> backed up on the machine.
>
> 2) One of the big problems with the V2 GUI was its terrible
> performance
> when displaying filesystems and trees. Customers have been very
> unhappy
> with its performance for several years. So one of the key design
> points
> was to make the trees dynamic - don't spend time, potentially minutes,
> reading information that the user hasn't requested. Therefore, the
> filesystems, directories, and files are only read in from disk when
> the
> user asks for that information.
>
> In order to correctly highlight the filesystems in the DOMAIN option,
> all
> filesystems would have to be queried up front. The DOMAIN option can
> specify local filesystems and network filesystems. However, the
> reading of
> filesystems can take a long time. All too often I have waited around
> while
> trying to display a list of network drives on NT or Unix, and waiting
> for
> the network timeouts to occurr. And we have had many customers over
> the
> years complain about this delay as well. They were not interested in
> looking at the network drives, why were we querying them, and wasting
> their
> time? Some customers have hundreds of local and network filesystems.
>
> So we decided to seperate out the Local and Network drives into
> different
> sections. This would provide the user with the ability to better
> control
> what they saw, queried, and backed up, while providing better overall
> performance and better user experience.
>
> 3) We did make two mistakes in this design (hey, we're not perfect).
> We
> did know that we would need to provide some way to be able to quickly
> backup the defined DOMAIN - we ran out of time and it fell through the
> cracks. We also missed the fact that removable media, particularly
> CD-ROMs, appeared in the Local Filespaces category. I agree that's a
> problem.
>
> Solutions We're Implementing
> ----------------------------
> There are a couple things we're doing to make this better to use
> 1) in PTF 3, we've added the "Backup Domain" menu option. We intended
> to
> have something like this in the original version, but it didn't make
> it.
> It provides the function that you really want - to backup the
> filesystem in
> the domain. You may see this appear as a button in the Main Window
> (maybe
> "One-click Backup" or something) - but that is still in debate (any
> feedback on this is welcome and appreciated).
>
> We were not happy with other proposed solutions: we didn't wan't to
> preselect them in the tree window, because it would bypass the
> performance
> benefits we had gained. We could have provided a button that the user
> could press to read all the filespaces and select them based on the
> DOMAIN,
> but that didn't seem right either - too many actions to go through to
> do
> it. We felt that being able to select one menu item and have your
> machine
> backed up according to your DOMAIN definition provided an easy and
> usable
> way for the user to perform this function.
>
> 2) We will be auto-expanding the Machine node (top level node in the
> tree)
> so that the user will immediately see the Local and Network nodes.
> This
> will make it much more apparent what the user will be backing up then
> they
> select one of those nodes. If they select the machine node, they will
> see
> that Local and Network are also selected. Most users know that
> backing up
> network drives is not good.
>
> 3) We will be creating a new node, called Removable (or something),
> that
> CD-ROMs, ZIPs, etc, will be shown under. These types of filesystem
> shouldn't appear in the Local section.
>
> Responses
> ---------
> There were a variety of posts on this - instead of responding to each
> one
> individually, I've copied relevant parts here and responded to them:
>
> *** Allen Barth wrote: ***
> > You didn't miss a thing. This is being marketed as a FEATURE!
> The
> > gui ignores the domain parm in dsm.opt, but I've been told that
> the
> > command line and scheduler do not (I'm not willing to try).
> >
> > If the gui's stay this way, then they're useless "cow droppings"
> >
> > I'm hoping someday the ADSM developers will recognize and admit
> this
> > to be the major FLAW that it is, as opposed to adding menu bar
> items
> > to do what the client is supposed to be doing in the first
> place!
>
> I don't know where it's being mentioned as a feature, but its function
> that
> we weren't able to get into the initial release. However, if it had
> made
> the initial release, it would have been implemented the same way. We
> have
> tried very hard in Version 3 to incorporate a variety of changes and
> enhancements that customers have been asking for over 5 years
> (obviously
> there are more for us to do ;-). In doing so, we have necessarily had
> to
> change how we did some things - several paradigm shifts were
> introduced.
> These changes were not done to cause confusion, but to move the
> product
> forward both in usability and functionality.
>
> *** Bob Matthews wrote: ***
> >Unfortunately, what I hear is not encouraging. Neither the latest fix
> nor the
> >proposed future development come anywhere near solving the problem.
> >There's no
> >way we can upgrade our 1,000 clients to version 3 while this
> situation
> >exists.
> >In my humble opinion, once a domain has been defined for a client,
> the client
> >should never look at anything outside that domain irrespective of
> whether the
> >backup is by GUI, non-GUI, scheduled or non-scheduled.
>
> This is not how V2 works either. The DOMAIN option has always been
> only a
> suggestion of what should be backed up. The user has always been free
> to
> backup anything on their system. This is not a V3 issue.
>
> >If I understand the
> >documentation correctly, I can "enforce" a domain in a client option
> set
> >but the
> >GUI will then ignore it. What's the use of "enforcing" something that
> can be
> >ignored? This seems like a contradiction!
>
> By using the "Backup Domain" menu in the GUI, it will backup whatever
> the
> DOMAIN has been set to, either by the options file or the server.
> This
> takes only one click from the menu. If they use the tree, then they
> can
> backup anything they want, just like V2.
>
> >Is this another example of IBM not listening to the requirements of
> its
> >customers?
> >Forgive me if I'm wrong.
>
> We try very hard to listen to customer requirements. However, we
> usually
> get many conflicting requirements from customers, some want it one way
> and
> others want it another way, and we have to balance all of them. A big
> part
> of V3, at least from my standpoint, was to try to handle many of the
> customer requirements and problems we've gotten over the years. There
> are
> still many more to deal with, but we do hear what you all are asking
> for.
>
> *** Cris Robinson wrote: ***
> >You are so very right. This issue is one my major beefs with vendors.
> >There is not enough input from the customers.
> >Version 3 was being developed before we could ask for input. We are
> >faced with the same issue although we are developing
> >ways to overcome this issue. One thing that we are doing is creating
> a
> >command line shortcut, WIN95, which does an incremental backup
> >of the client device sans GUI. It don't eliminate the ability to
> backup
> >through the GUI but if people are given the simple backup icon they
> tend
> >to take the shortest road to completing a backup. This process is
> used
> >by our portable users who are not plugged into the network during the
> >"normal" backup
> >window at night.
>
> We do get feedback from customers - we run internal usability sessions
> with
> customers, and we did give early code to some customers. I am hoping
> that
> we will be able to have more extensive beta programs in the future.
>
> So let me ask you this: If we created another graphical button on the
> main
> window, called something like "Easy Backup" or "Quick Backup" or
> something,
> would this obviate the need for creating a command line shortcut?
>
> >Also - There needs to be the facility to grant or deny functions on
> the
> >client GUI from the server. We would like to limit the client
> >interaction
> >with the server in certain cases like locking the preferences,
> denying
> >access to the preferences and access to the opt file. users just LOVE
> to
> >mess with that one!
>
> It is already possible to limit access to the options file. Almost
> every
> option can be "forced" by the V3 server, which means no matter what
> the
> user sets it to, the server value will take precedence. Even the GUI
> options editor won't let the user change settings that the server has
> "forced".
>
> *** Allen Barth wrote: ***
> > What you describe below is NOT a solution...it's a work around.
> >
> > Your discussion here, Andy's earlier, and all other discussion
> about
> > this fail to point out why the v3 client gui still does not
> establish
> > whatever is specified in DOMAIN as the default. You
> know...highlight
> > those drives! Pre-expanding the tree is a good idea, but not
> enough.
>
> I hope I have answered this above. There are performance and
> usability
> reasons for not doing this.
>
> > If the command line and scheduler interfaces do recognise and
> honor
> > the DOMAIN as stated, the gui should too... WITHOUT the need for
> > developers to add new action items, and more important WITHOUT
> the
> > need for me to run around to all my users and retrain them!
>
> It is true that the initial V3 clients did ignore the DOMAIN option.
> However with PTF 3, we added the Backup Domain function. We didn't
> just
> add another action item, we implemented the function we were planning
> on
> implementing anyway. I understand the difficulty in the some of the
> retraining that will have to happen, but the ADSM interface hasn't
> been
> changed in over 5 years. There were many things we couldn't do with
> the
> old interface, and it was time to make a change. There is no way to
> get
> around having to do some retraining. Hopefully future changes won't
> be as
> dramatic.
>
> > Um, when did Jerry become the sole voice of the ADSM user
> community?
> > He certainly did recognize a problem, report it, and something
> was
> > done. But, as I've stated before, the methods ADSM development
> is
> > proposing are UNACCEPTABLE to me because of the very real
> aspects of
> > system failure and data integrety.
>
> Jerry happened to be the most vocal about this problem at the time,
> and was
> willing to work offline with us. I'm not sure he is fully satisfied
> with
> our implementation either, but we have to make tradeoffs to maintain
> certain design goals.
>
>
>
> I hope this, if nothing else, at least explains some of our thinking
> behind
> this issue.
>
> Cheers,
> Brett Walker
> ADSM Development
>
> o------------------------------------------------------o
> Brett Walker ADSM Development, IBM
> walkerbl AT vnet.ibm DOT com tie 276-0265
> o------------------------------------------------------o
> "That's just my opinion; I could be wrong."
> --- Dennis Miller
|
