*smile* good question!!!!
please read the monthly faq-list!
Christian Demnitz
mailto:christian.demnitz AT sinius DOT com
Richard Seger <richard.seger AT ADIC DOT COM>
Gesendet von: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
16.02.2005 21:04
Bitte antworten an
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
An
ADSM-L AT VM.MARIST DOT EDU
Kopie
Thema
Unsubscribe
How do I unsubscribe from this list?
Thank you.
Rich Seger
-----Original Message-----
From: ADSM: Dist Stor Manager on behalf of Paul Fielding
Sent: Tue 2/15/2005 8:44 PM
To: ADSM-L AT VM.MARIST DOT EDU
Cc:
Subject: Re: Bug? Using multiple client service instances
on Windows server
Hi Andy,
This is interesting. (Warning, long message)
I tried doing this tonight on my XP SP2 system with 5.3.0
client to
demonstrate, since I don't have a server handy (will try
with 2003 server
tommorow hopefully).
I didn't see the behavior I previously described. But
the behavior I did
see was even more interesting. Below I'll describe the
steps, in order. In
the places where I break out into console log entries,
this is the point
during the install where that log item showed up in the
console.
Here's what I did:
XP SP2 system with TSM 5.3.0 installed, no services
installed.
Two nodes - MATHILDA and BOOGA (hey, it's late)
Two optfiles:
dsm.opt, default location:
nodename mathilda
PASSWORDACCESS GENERATE
schedmode prompted
TCPSERVERADDRESS xxxxxxxxx
schedlogretention 7
errorlogretention 7
MANAGEDSERVICES WEBCLIENT SCHEDULE
dsm2.opt, default location:
nodename booga
PASSWORDACCESS GENERATE
schedmode prompted
TCPSERVERADDRESS xxxxxxxxx
schedlogretention 7
errorlogretention 7
MANAGEDSERVICES WEBCLIENT SCHEDULE
A. Install Acceptor #1
1. Startup GUI
2. Setup Wizard, check both install web client and
scheduler
3. Install new acceptor
4. Named "TSM Client Acceptor" (default name)
5. default dsm.opt file (in the tsm\baclient directory)
--console log--
ANR0406I Session 6664 started for node MATHILDA (WinNT)
(Tcp/Ip
142.163.252.132(4496)).
ANR0403I Session 6664 ended for node MATHILDA (WinNT).
--end console log--
6. http port 1581
7. Node MATHILDA, Pass MATHILDA, check validation
8. Start with System account, start manually
9. Named "TSM Remote Client Agent" (default name)
10. No revocation
11. Do not start now
12. Finish.
--console log--
ANR0406I Session 6665 started for node MATHILDA (WinNT)
(Tcp/Ip
142.163.252.132(4510)).
ANR0403I Session 6665 ended for node MATHILDA (WinNT).
ANR0406I Session 6666 started for node MATHILDA (WinNT)
(Tcp/Ip
142.163.252.132(4511)).
ANR0403I Session 6666 ended for node MATHILDA (WinNT).
--end console log--
13. Popup indicates installed.
B. Install Scheduler #1
1. Install new scheduler
2. Named "TSM Client Scheduler" (default name), Local,
with CAD
3. Select Acceptor defined above
4. leave log names blank to take default, uncheck event
logging
5. Finish.
--console log--
ANR0406I Session 6667 started for node MATHILDA (WinNT)
(Tcp/Ip
142.163.252.132(4516)).
ANR0403I Session 6667 ended for node MATHILDA (WinNT).
ANR0406I Session 6668 started for node MATHILDA (WinNT)
(Tcp/Ip
142.163.252.132(4517)).
ANR0403I Session 6668 ended for node MATHILDA (WinNT).
ANR0406I Session 6669 started for node MATHILDA (WinNT)
(Tcp/Ip
142.163.252.132(4518)).
ANR0403I Session 6669 ended for node MATHILDA (WinNT).
--end console log--
6. Popup indicates Installed.
C. Install Acceptor #2
1. Startup GUI
2. Setup Wizard, check both install web client and
scheduler
3. Install new acceptor
4. Named "TSM Client Acceptor - BOOGA"
5. dsm2.opt file (in the tsm\baclient directory)
--console log--
ANR0406I Session 6670 started for node MATHILDA (WinNT)
(Tcp/Ip
142.163.252.132(4519)).
ANR0403I Session 6670 ended for node MATHILDA (WinNT).
--end console log--
(note that it was Mathilda that just connected, not
Booga, even though we
just pointed it at the dsm2.opt file which has Booga as
the nodename)
6. http port 1583
7. Node BOOGA, Pass BOOGA, check validation
8. Start with System account, start manually
9. Named "TSM Remote Client Agent - BOOGA"
10. No revocation
11. Do not start now
12. Finish.
--console log--
ANR0406I Session 6671 started for node BOOGA (WinNT)
(Tcp/Ip
142.163.252.132(4534)).
ANR0403I Session 6671 ended for node BOOGA (WinNT).
ANR2841W Server is NOT IN COMPLIANCE with license terms.
ANR0406I Session 6672 started for node BOOGA (WinNT)
(Tcp/Ip
142.163.252.132(4535)).
ANR0403I Session 6672 ended for node BOOGA (WinNT).
ANR2841W Server is NOT IN COMPLIANCE with license terms.
--end console log--
13. Popup indicates Installed.
B. Install Scheduler #2
1. install new scheduler
2. Named "TSM Client Scheduler - BOOGA"
3. Select Acceptor defined above
4. select c:\temp\dsmched.log and dsmerror.log, no event
logging
5. Finish.
--console log--
ANR0406I Session 6678 started for node BOOGA (WinNT)
(Tcp/Ip
142.163.252.132(4541)).
ANR0403I Session 6678 ended for node BOOGA (WinNT).
ANR0406I Session 6679 started for node MATHILDA (WinNT)
(Tcp/Ip
142.163.252.132(4542)).
ANR0403I Session 6679 ended for node MATHILDA (WinNT).
ANR0406I Session 6680 started for node MATHILDA (WinNT)
(Tcp/Ip
142.163.252.132(4543)).
ANR0424W Session 6680 for node MATHILDA (WinNT) refused -
invalid password
submitted.
ANR0403I Session 6680 ended for node MATHILDA (WinNT).
--end console log--
(Note that first attempt is Booga, subsequent attempts
Mathilda)
6. Popup Error message labeled DSM:
Error 2 establishing TSM API session: .
The password couldn't be authenticated with the TSM
server
7. Click on OK, then new popup indicates Installed.
----------------------
Output of dsmcutil list:
Command: List Installed TSM Client Services
Machine: MATHILDA(Local Machine)
Installed TSM Client Services:
1. TSM Client Acceptor
2. TSM Client Acceptor - BOOGA
3. TSM Client Scheduler
4. TSM Client Scheduler - BOOGA
5. TSM Remote Client Agent
6. TSM Remote Client Agent - BOOGA
6 TSM Client Services were located.
----------------------
Output of dsmcutil query /name:"TSM Client Acceptor -
BOOGA":
Connecting to service 'TSM Client Acceptor - BOOGA' ...
Service Configuration/Status:
Service Name : TSM Client Acceptor - BOOGA
Logon Account : LocalSystem
Start Type : Demand
Current Status : Stopped
TSM Client Service Registry Settings:
Client Service Type = Client Acceptor Service
Client Directory = "C:\Program
Files\Tivoli\TSM\baclient\dsmcad.exe"
Partner Service = TSM Remote Client Agent - BOOGA
Cad Schedule Service = TSM Client Scheduler - BOOGA
Options file = C:\Program
Files\Tivoli\TSM\baclient\dsm2.opt
Event Logging = YES
TSM Client Node = BOOGA
Comm Protocol = (value not currently set)
Server = (value not currently set)
Server Port = (value not currently set)
HTTP Port = 1583
Secure HTTP Port = (value not currently set)
Web Ports = (value not currently set)
Schedule Log = (value not currently set)
Error Log = (value not currently set)
----------------------
Output of dsmcutil query /name:"TSM Client Scheduler -
BOOGA":
Connecting to service 'TSM Client Scheduler - BOOGA' ...
Service Configuration/Status:
Service Name : TSM Client Scheduler - BOOGA
Logon Account : LocalSystem
Start Type : Demand
Current Status : Stopped
TSM Client Service Registry Settings:
Client Service Type = Client Scheduler Service
Client Directory = "C:\Program
Files\Tivoli\TSM\baclient\dsmcsvc.exe"
Options file = C:\Program
Files\Tivoli\TSM\baclient\dsm2.opt
Event Logging = NO
TSM Client Node = MATHILDA
Comm Protocol = (value not currently set)
Server = (value not currently set)
Server Port = (value not currently set)
Schedule Log = c:\temp\dsmsched.log
Error Log = c:\temp\dsmerror.log
Cluster Enabled = (value not currently set)
Cluster Name = (value not currently set)
------------------------
If I start the service right now, the BOOGA service
indeed connects using
Mathilda's nodename (and Mathilda's password). Very
odd. If I go back in
and *edit* the service and change the node back to BOOGA
then it works fine
after that. I won't bother with the console output at
that point, because
this is a whole different ballgame to the original
behavior I was previously
discussing.
Tommorow I'll try this with a 2003 server to see if I can
demonstrate the
original behavior I was talking about, but clearly
something is amis
regardless....
regards,
Paul
----- Original Message -----
From: "Andrew Raibeck" <storman AT US.IBM DOT COM>
To: <ADSM-L AT VM.MARIST DOT EDU>
Sent: Tuesday, February 15, 2005 12:24 PM
Subject: Re: [ADSM-L] Bug? Using multiple client service
instances on
Windows server
> Paul,
>
> I think you are referring to IC33355, which was closed
SUG. I do not know
> the details behind the closure, but it was closed that
way presumably due
> to the complexity (despite the seemingly simple problem
description) of
> addressing the issue.
>
> I have not been able to reproduce your symptoms. Can
you clarify a few
> things for me?
>
> 1) Content of your two dsm.opt files
>
> 2) Output from "dsmcutil list"
>
> 3) Output from "dsmcutil query /name:xxxx" for each
xxxx that shows up in
> the dsmcutil list output
>
> 4) Admin console output that illustrates the problem
>
> 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
> 20: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'
>> >
>
|
