*smile* good question!!!! please read the monthly faq-list!
Christian Demnitz mailto:[EMAIL PROTECTED] Richard Seger <[EMAIL PROTECTED]> Gesendet von: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> 16.02.2005 21:04 Bitte antworten an "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> An ADSM-L@VM.MARIST.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@VM.MARIST.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" <[EMAIL PROTECTED]> To: <ADSM-L@VM.MARIST.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/[EMAIL PROTECTED] > Internet e-mail: [EMAIL PROTECTED] > > 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@VM.MARIST.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" <[EMAIL PROTECTED]> >> To: <ADSM-L@VM.MARIST.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 <[EMAIL PROTECTED]> 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' >> > >
