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