I was also not happy to see filespaces being created for all of my network
drives. These drives are used to serve common apps like word, excel etc. and
they are backed by the servers that own them.
I am looking at backing up several thousand PC's with standard configurations
and plan to the use client option sets on the server to specify what they can
backup. (Currently only the 'My Documents' directory and sub-directories). I
don't want them to be able to backup network drives and I would prefer that they
don't even see them.
Using the Exclude.dir I have been able to "hide" most of the directories that I
don't want them to be able to backup:

* DRIVE/DIRECTORY SPECIFICATIONS                       MGMTCLAS
* ________________________________________________     ________________
  Exclude *
  Exclude ?:\...\*
  Exclude.dir [a-b]:*
  Exclude.dir [d-z]:*
  Exclude.dir ?:\[a-l]*
  Exclude.dir c:\m[a-x]*
  Exclude.dir c:\mz*
  Exclude.dir ?:\[n-z]*
  Include "c:\My Documents\...\*"                      standard


When I go into the backup GUI Using this Include/Exclude, The tree expands as
follows:

[] TEST-USER
   - [] Network Filespaces
      + [] \\comapps\mail
      + [] \\comapps\winword
      + [] \\comapps\pp40
      + [] \\comapps\winproj
      + [] \\comapps\access
      + [] \\comapps\request
   - [] Local Filespaces
      - [] C_TEST-USER (C:)
           [] My Documents

The only problem with the Exclude.dir is that you cannot exclude root files. As
a result all sub directories and associated files are exclude but not files at
the root level. Unfortunately for about half of these network drives the files
are at the root level. So as a result I am seeing a lot of filespaces for these
drives for each client node. As the subject of this thread says, "It's too
easy!" Under version 2 they may have been able to do it, but they had to make an
effort. I was not seeing all of the filespaces being created that I do with
Version 3. I agree with one of the earlier suggestions, the ability to backup
Network Filespaces is something that we should be able to control at the server
(node definition) level. Allowing thousands of users the ability to backup the
same shared network drive is not a good idea. And as someone pointed out
earlier, you definitely wouldn't want one of these users to restore their backup
version of a file from a shared network drive because you have no way of knowing
who has the most recent backup version. I will forward a copy of this
requirement to our local IBM representative as a formal request and urge others
that feel the same way to do the same.

Larry Robertson
Compuware Corporation
248 737-7300


______________________________ Reply Separator _________________________________
Subject: Re: It's too easy !
Author:  "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> at 
CWUS-Internet
Date:    4/6/98 3:39 PM


Chris,

>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.

This would certainly be new function, as we have never allowed this before.
But I can certainly see the benefit of it.  I will carry this requirement
into our internal discussions, but I also suggest submitting an official
ADSM requirement, via your IBM rep.  Then it gets into our official
requirements database, and it gets tracked, etc.

>I would also like more security administered from the Administrator
>console to prohibit
>access to various options on the client.

If you're talking about option file options, these can now be forced by the
server, so the client can't change them.

Cheers,
Brett

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