Hi Wanda,
For your very short term requirements you may be able to use the
client configuration utility that ships with the full ADSM for
Windows NT package. The package is currently available as a try/buy
from ADSM's web site:
http://www.storage.ibm.com/storage/software/adnttry.htm
The client configuration utility is a wizard in the ADSM server
utilities. The utilities get installed as part of the server component.
The way it works is as follows:
Machine with Machine with
ADSM/NT server ADSM/NT/95 client
+---------------+ +---------------+
|utils | |client |
| | | |
|c:\shared |-------------|z: |
+---------------+ +---------------+
1) The client configuration wizard will allow you to choose a
communications protocol and will then detect the associated
parameters required by the client. (works for TCP/IP, Named
Pipes, IPX/SPX, and NetBIOS) You can also override any value
so that you can point to any ADSM server whether it runs on
NT or not.
2) The wizard allows you to specify ADSM administrator contact
information and a base options file. The base options file is
an ADSM client options file without the communications settings.
You can setup a specific exclude list in the base options file.
3) The wizard writes out a package (ex. mars1) consisting of the
following files to the location of your choice:
dsmcfg.exe
mars1.cfg
mars1.bat
base3.opt
If you name the package mars1 and store it in c:\shared and your win32
clients can connect to it as z:, then all clients can cd to z: and
issue mars1. This will run mars1.bat which contains the single line:
dsmcfg mars1.cfg. A GUI will pop-up on the client machine displaying
info on what it's about to do. (for ptf5 clients and above it knows
where the client is installed and will update the options file
directly, for pre-ptf5 clients the options file location can be
specified). The GUI prompts for a node name (defaults to the machine
name) and when OK is clicked the options file will be written.
Instructions are also given as to what to do if they can't connect
when done.
So, with this method you can setup any number of configuration files
and have any number of win32 clients type a name and click ok
to update their options file.
Your first 50 clients could enter mars1, next fifty could enter mars2,
etc. and each client would have a specific incl/excl list that you've
specified in the base options file.
It's possible to obtain the set of files that the wizard
creates and then edit the .cfg file by hand. You could then start
at step 3.
This method requires each client to have access to a shared directory
and type a name but allows centralized distribution of ADSM options
files.
Regards,
Mike Collins
ADSM Development
ex. client configuration file (mars1.cfg)
*=======================================================================
* Note: This file was generated by an ADSM client configuration utility.
*
* Generated on Mon Nov 25 10:02:28 1996
*
* ADSM Administrator: mike@mars
*
*=======================================================================
*
adsm_admin_contact=mike@mars
*
commmethod=TCPIP
tcpport=1500
tcpserveraddress=200.12.34.10
base_dsm_opt_filename=base3.opt
Wanda Prather writes:
> I see the same problem --- the amount of software on our desktops
> (primarily Win95 and WinNT) is increasing at an increasing rate! But
> for us it's not just a data base issue, it's an overall storage and
> network capacity issue
>
> An increasing number of the desktop files are "temp" files, as Wayne
> said. But in our network, because we administer the networks centrally
> and install most software over the network, the bulk of the files on
> desktops are executables (or help files) that are duplicated at the same
> level on every desktop and do not change.
>
> NOT backing up this junk is very important to us, because of the
> capacity issues in our robotic libraries and the offsite vault.
>
> We very much need the following:
>
> Very short term:
> We need the option to get the exclude list OUT of dsm.opt and into a
> separate file for the Windows clients. That would at least help us in
> an attempt to create and distribute a suitable exclude list. It's not a
> very good solution because software for the desktop changes so
> frequently and we lack a good means of frequently redistributing the
> exclude list.
>
> Short term:
> We need above all else the option to specify a global exclude list, say
> one for each management class, that lets us define an exclude list in
> ONE PLACE, not on every desktop. The administrator should determine
> whether the global exclude list takes precedence over the local exclude
> list or not.
>
> Long term:
> We need a "smarter" backup system. The administrator should be able to
> identify a set of files which are "common" for all clients associated
> with a management class. Those files (such as WIN95 executables and
> HELP files) should only be backed up ONCE, but be available for restore
> by all clients in the management class.
>
> Thanks for listening!
>
> >----------
> >From: Wayne T. Smith[SMTP:wts AT MAIL.CAPS.MAINE DOT EDU]
> >Sent: Friday, November 22, 1996 4:51 PM
> >To: Multiple recipients of list ADSM-L
> >Subject: Database size problems
> >
> >Our ADSM database usage used to be dominated by our servers. Each of
> >those servers typically have 20,000 to 200,000 files; a PC or Mac
> >typically has 2,000-6,000 files.
> >
> >But more recently our desktop workstations have grown dramatically in
> >terms of required ADSM database usage. Some of this is due to
> >additional operating system and application code, but IMHO it is
> >*dominated* now by worthless throw-away entries such as Pointcast
> >Network - (.../pcn/...) and other applications caching files such as
> >WBI, NetScape, MSIE, etc.
> >
> >Yet ADSM gives us few tools to measure or manage this "problem".
> >
> >For example, right now my Win95 desktop machine has about 9,000 files,
> >while ADSM is managing *36,000* database entries. My daily backup is
> >dominated by these worthless files and my ADSM database requirements
> >are growing uncomfortably with it.
> >
> >I suggest improvements in 2 areas:
> >
> >o Make it easy for sites to customize DSM.OPT; recognize "temp"
> > directories fr common applications in the "standard DSM.OPT.
> >
> >o Give us the database query tools to understand what we are backing up
> > and how policy changes might affect the volume. I'd love to be able to
> > answer such "What if?" questions as "If I reduced #inactive versions,
> > how is the DB reduced?" "If I reduced expiration times, how is DB
> > affected?"
> >
> >Your thought would be most welcome,
> >
> >Wayne T. Smith mailto:wts AT maine.maine DOT edu
> >Systems Group -- CAPS University of Maine System
> >
|
