> With four open windows on the screen it gets a bit confusing
> as to which is which... When the admin client comes up it overwrites
> the window title with "IBM Tivoli Storage Manager" is there any way
> to change this to something more descriptive?
This is a known requirement that has been back-burnered for a while now,
but is on the radar screen for this year, to include info like the TSM
server name in the title.
Regards,
Andy
Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com
The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 2005-02-14
23:15:54:
> Paul,
>
> When you install a second windows service, how do you automate the
> install of a second set of icons into the start menu? I'm struggling
> with this at the moment
>
> and while I'm asking windows questions :) (server and client version
5.3.0)
>
> I don't like the Windows MMC interface, and far prefer to use two
> sessions, one for command line entry and the other to watch the log.
> I'm rolling out an implementation that has a "strategic" and a
> "tactical" backup server instance at each site to a whole new set of
> green admins so I'd like to make the set up as easy as possible for
> them. With four open windows on the screen it gets a bit confusing
> as to which is which... When the admin client comes up it overwrites
> the window title with "IBM Tivoli Storage Manager" is there any way
> to change this to something more descriptive?
>
> Thanks
>
> Steve
>
> Steve Harris
> TSM Admin
> Queensland Health, Brisbane Australia
>
> >>> paul AT FIELDING DOT CA 15/02/2005 13:00:42 >>>
> I have things configured pretty much as you describe, and I also use
> dsmcutil to create the services when using a cluster- Way easier to
reduce
> mistakes since I can throw it into a batch file and run it on both sides
of
> the cluster. :)
>
> The issue I'm seeing, though, can be duplicated on a non-cluster.
(however
> the results seem to happen on some systems but not others) If you take a
> Windows 2000 or 2003 server and try the following:
>
> 1. Install a regular dsmcad, agent and scheduler service using the
default
> baclient\dsm.opt file.
> 2. create a second options file named something different such as
dsm2.opt
> 3. install a second set of services, named differently, and using the
> dsm2.opt, and using a different nodename from the first set. (ie. you
would
> use this if setting up a scheduler for an agent perhaps, or for a
cluster
> resource group).
> 4. before starting the dsmcad service, start up a console window
> (dsmadmc -console)
> 5. start dsmcad, wait the minute for the scheduler to kick in
>
> What I see on the console (and in the actlog) is:
> - an inital connection using the correct (second) nodename, by the
dsmcad as
> soon as I start the service
> - 1 minute later, I see two more client connections as the scheduler
> connects. the first connection uses the wrong (first) nodename, the
second
> connection uses the correct (second) nodename.
>
> other than that, everything seems to work correctly.....
>
> Paul
>
> ----- Original Message -----
> From: "TSM_User" <tsm_user AT YAHOO DOT COM>
> To: <ADSM-L AT VM.MARIST DOT EDU>
> Sent: Monday, February 14, 2005 9:58 PM
> Subject: Re: [ADSM-L] Bug? Using multiple client service instances on
> Windows server
>
>
> > We have over 20 Windows 2000 Cluster servers. On all of these servers
we
> > have to create 2 sets of all the services. One for the local drive and
one
> > for the cluster. We have never run into the issue you are speaking
of.
> > We use the dsmcutil command to create all our servers via scripting.
The
> > only issue I have ever seen is that if you don't use the short 8.3
name
> > for the path for "/clientdir" then you can have problems.
> >
> > I'm not sure if this will help but here is an example of what we use.
> > ex:
> > "C:\Program Files\Tivoli\TSM\Baclient\DSMCUTIL" Install /name:"TSM
Central
> > Scheduler" /node:%COMPUTERNAME%
/clientdir:C:\Progra~1\Tivoli\TSM\Baclient
> > /optfile:C:\Progra~1\Tivoli\TSM\Baclient\dsm.opt /pass:%COMPUTERNAME%
> > /startnow:no /autostart:no
> >
> > One thing I have noticed is if you ever create services on a cluster
you
> > must ensure that you create them adding the /clustername and
/clusternode
> > options. Also, you have to use the /clusternode:no for the services
you
> > create that aren't for the cluster. Finally you also have to make
sure
> > that you create the cluster services first. If you don't do this
> > correctly you will get errors but they aren't all as clear as I would
> > like.
> >
> > Paul Fielding <paul AT FIELDING DOT CA> wrote:
> > Several years ago I noticed an interesting behavior when installing
> > multiple client scheduler services on a server. A ticket was opened
with
> > IBM and the final word came back that there was indeed a bug, the apar
was
> > opened, and we were told it would be resolved. This week I've
encoutered
> > the same situation, so I'm wondering if anyone has also noticed this
> > behavior? I no longer have the apar number of the original ticket, so
I
> > can't check to see the apar's status.
> >
> > When installing a scheduler service (with apropriate cad, etc) you
must
> > supply the dsm.opt file fo the service to use. For the first nodename
on
> > the server, this is typically the Tivoli\TSM\baclient\dsm.opt file.
When
> > installing the second set of services for an alternate nodename, you
must
> > supply an alternate dsm.opt file.
> >
> > If you run a dsmadmc -console while starting the CAD, you may notice
that,
> > when the scheduler service contacts the TSM Server, it touches the
server
> > twice. Under normal circumstances, this is just something I shrugged
off
> > as an 'interesting' thing.
> >
> > However, after the second service instance is installed, when starting
up
> > the CAD, I noticed that the the first of those two connections was
using
> > the wrong nodename - instead of connecting to the TSM server with the
> > nodename of the second service, it connected with the nodename of the
> > first service. The second connection attempt then proceeded to use the
> > correct nodename. Not knowing exactly what information is sent on each
of
> > those connections, I do not know the implications of this.
> >
> > Basically what was happening was that when the scheduler service first
> > starts it grabbed the default dsm.opt location, instead of using the
> > dsm.opt file defined for that service. By the time it makes it's
second
> > connection attempt, it's read the correct dsm.opt file.
> >
> > The temporary band-aid was to configure the first scheduler service to
use
> > a *non-standard* dsm.opt - the result being that when the second
service
> > tried to connect using the default location, it failed to find a
dsm.opt
> > file there, and simply connected sucessfully on the second attempt,
using
> > the correct dsm.opt file.
> >
> > More recently, I've noticed that when this situation occurs, if you
set
> > the first service to use a non-standard dsm.opt file, during the
install
> > process I initially get an error message stating that the service
'Could
> > not find c:\Program Files\Tivoli\TSM\baclient\dsm.opt' , even though
> > that's not the dsm.opt file I told it to read. The service then goes
and
> > sucessfully installs. *shrug*.
> >
> > It doesn't appear to be causing any real grief, but I'm wondering if
I'm
> > the only one seeing this behavior or not, and if anyone may know of
any
> > genuine grief this could cause?
> >
> > regards,
> >
> > Paul
> >
> >
> > ---------------------------------
> > Do you Yahoo!?
> > Yahoo! Search presents - Jib Jab's 'Second Term'
> >
>
>
>
***********************************************************************************
> This email, including any attachments sent with it, is confidential
> and for the sole use of the intended recipient(s). This
> confidentiality is not waived or lost, if you receive it and you are
> not the intended recipient(s), or if it is transmitted/received in
error.
>
> Any unauthorised use, alteration, disclosure, distribution or review
> of this email is prohibited. It may be subject to a statutory duty
> of confidentiality if it relates to health service matters.
>
> If you are not the intended recipient(s), or if you have received
> this email in error, you are asked to immediately notify the sender
> by telephone or by return email. You should also delete this email
> and destroy any hard copies produced.
>
***********************************************************************************
|
