Local Drive F: Ignored
Gentle Greetings, We have a puzzling problem with one of our nodes... any help/insight would be appreciated. OS: WinNT 4 Client: 3.7.2.17 Manual backups through the GUI run fine... all drives are listed under the Local tree. However, during automatic backups, the F: drive is completely ignored... no mention of it whatsoever... not even an error message in the error log. Any ideas? Thanks in advance, Jennifer
Re: cloptset broken for Windows 4.1.2.X client
Greetings, We are running a test of Client Option Sets from an AIX server running TSM 4.1.2 and an NT 4.0 Workstation running TSM 4.1.2.12. Things *seem* to be behaving as expected with includes/excludes. One that exists only on the server side is working to exclude the entire D:drive. This is set to force=yes, and it does override an include on the client sode. Incl/excl rules that exist on both server and client are giving the expected duplicate error messages in the dsmerror.log (and the files are being excluded). My understanding from documentation is that specifying force=yes on server side inclexcl options will process those includes/excludes *before* the ones in the client side dsm.opt file. And force=no will process them after. In effect, force=yes puts the server side rules at the "bottom" of the include/exclude list and force=no puts them at the "top". We are new at this, so this may not be entirely accurate information. Just wanted to share our experiences so far. Thanks, Jennifer At 09:18 AM 4/10/2001, you wrote: What if one has all of inclexcl statements defined in the client option set and none in the dsm.opt file? -Original Message- From: Richard Sims [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 10, 2001 9:16 AM To: [EMAIL PROTECTED] Subject: Re: cloptset broken for Windows 4.1.2.X client Suad, did you specify force=yes (to override the options in the dsm.opt file)? Note that INCLEXCL and DOMAIN are additive options such that Force has no effect. That is, Force pertains only to singular options. --- The information contained in this e-mail message, and any attachment thereto, is confidential and may not be disclosed without our express permission. If you are not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution or copying of this message, or any attachment thereto, in whole or in part, is strictly prohibited. If you have received this message in error, please immediately notify us by telephone, fax or e-mail and delete the message and all of its attachments. Thank you. Every effort is made to keep our network free from viruses. You should, however, check this e-mail message, as well as any attachment thereto, for viruses. We take no responsibility and have no liability for any computer virus which may be transferred via this e-mail message.
Hung Admin Sessions
Gentle Greetings, Has anyone noticed any situations where Admin sessions on the server get hung and become "ghost" sessions that will not go away? Cancelling has no effect. Opening a separate Admin session and cancelling from there has no effect. In some cases, subsequent sessions get hung and a reboot is necessary. And in other cases, there seems to be no adverse side effects. In this case, I was doing some SQL queries on the database, and two user Admin sessions hung and two Query Admin sessions hung. (Fortunately, everything else is continuing to run smoothly.) Below is the output from "show threads" related to these 4 sessions. We are running 4.1.2 Server on an IBM M80 running AIX 4.3.3. Thank you in advance for any help and/or suggestions. Jennifer Thread 68: SessionThread tid=4437, ktid=34577, ptid=52, det=1, zomb=0, join=0, result=0, sess=31636 Awaiting cond 5c355b04 (mutex 301a65b0) at 10009b38 (outGetNext) Thread 101: SessionThread tid=653d, ktid=69811, ptid=52, det=1, zomb=0, join=0, result=0, sess=31768 Awaiting cond 5c33a484 (mutex 301a65b0) at 10009b38 (outGetNext) Thread 105: SessionThread tid=6963, ktid=72547, ptid=52, det=1, zomb=0, join=0, result=0, sess=30446 Awaiting cond 5c286354 (mutex 301a65b0) at 10009b38 (outGetNext) Thread 108: SessionThread tid=6acf, ktid=52079, ptid=52, det=1, zomb=0, join=0, result=0, sess=31704 Awaiting cond 5c1c69d4 (mutex 301a65b0) at 10009b38 (outGetNext)
Re: Client v4.1.2 -- Uninstall on NT results in blank desktop?
Hi Tim, Yes, this is what we are seeing. And, in fact, I read the whole README... and even remember now reading this part. Guess it was a long day. My apologies to the list for sending unnecessary mail. And thank you Tim for bringing this back to my attention. Do you know if it is targetted to be fixed in future patches or releases? The obvious concern is that it may cause confusion for our user population. Thanks! Jennifer At 06:27 PM 1/9/2001, you wrote: The following is in the readme: - IMPORTANT NOTE REGARDING A KNOWN UNINSTALL ISSUE: - Issue: Grey desktop on uninstall. There is an issue that has been seen on some systems with Active Desktop installed. The symptoms are that after an uninstall the desktop will turn grey and the desktop icons will not be visible. The system will continue to work otherwise. The desktop is restored as soon as you log off and log back on. The problem is that Installshield will attempt to remove the All Users desktop folder if the TSM desktop icons are the only items in the folder. The problem is that the desktop folder is a protected system folder and can't be removed. This issue will be addressed in the future. For now, if you see this problem, simply log off and log back on to reset the desktop. Is this what you are experiencing? Tim Rushforth City of Winnipeg [EMAIL PROTECTED] -Original Message- From: Jennifer I. Moore [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 09, 2001 4:26 PM To: [EMAIL PROTECTED] Subject: Client v4.1.2 -- Uninstall on NT results in blank desktop? Gentle Greetings, We've noticed a strange behavior when uninstalling TSM client v4.1.2 on an NT 4.0 Workstation system (SP5). When the Add/Remove Programs process finishes, the desktop goes to a blank grey screen with only the Start menu and Task Bar showing. Right-clicking in the grey area results in a Desktop message as follows: C:\WINNT\Profiles\All Users\Desktop is not accessible. Access is denied. Retry. Cancel. Retry results in the same message. Cancel returns to the blank grey screen. The only way we've found to get out of this is to restart the machine. (Fortunately, the Start menu still works fine, so it's not necessary to be brutal about the restart.) Has anyone else noticed this behavior? Thank you in advance for any help, information, and/or shared experiences. Jennifer
Re: Custom dsm.opt in Client v4.1.2
Hi Arthur, Thanks for sharing your experiences with this. It's good to know that there's already a PMR open on it (or did they close it?). We also tried downloading the files multiple times to clear any potential for corruption. But with no success. Being able to include these custom pieces in previous versions has been a fabulous help! I hope it's possible to iron out the wrinkles that seem to be popping up here and there (apparently not across the board though) in the case of v4.1.2. Thanks again! Jennifer At 10:27 AM 1/10/2001, you wrote: Hi Tim, We built an SMS package for the install. After we realized the the files were not being copied over, we added an extra command to force this step. As I mentioned, I called Tivoli (PMR 19101, 23e) but was told that their testing didn't show any problems with this. AND, I was told that the client files may have been corrupted while I was downloading them. I downloaded the 6 files again, but the problem remained. Thanks. -Original Message- From: Rushforth, Tim [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 10, 2001 10:00 AM To: [EMAIL PROTECTED] Subject: Re: Custom dsm.opt in Client v4.1.2 Hi Arthur: Were you using Group Policy? Did you open a problem with Tivoli? If so is there an APAR on this? I was not sure if Tivoli would treat this as a problem or a design request - I was going to try as a problem but if you already have one open ... Another feature we would like to see is the ability to install the Web Client Service and Schedule Service via Group Policy Software Installation. Then it would be a totally automated installation. Thanks, Tim Rushforth City of Winnipeg [EMAIL PROTECTED] -Original Message- From: Kleynerman, Arthur [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 10, 2001 8:35 AM To: [EMAIL PROTECTED] Subject: Re: Custom dsm.opt in Client v4.1.2 We had the same problem. After calling Tivoli, I was told that I was the only one who complained about this. Apparently no one else has. Our workaround was to manually copy the predefined dsm.opt file into the baclient directory during the installation. Arthur. -Original Message- From: Rushforth, Tim [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 09, 2001 5:52 PM To: [EMAIL PROTECTED] Subject: Re: Custom dsm.opt in Client v4.1.2 I have installed a predefined dsm.opt file, when installing TSM 4.1.2 on Windows 2000 that has not had the client previously installed. Placed dsm.opt in the ..\config directory and ran setup. If you are using W2K Group Policy to install the client (again on a "clean" server), I have found that it does not use the custom dsm.opt file. Ditto if you just run "Tivoli Storage Manager Client.msi". How were you installing the client? Tim Rushforth City of Winnipeg [EMAIL PROTECTED] --- The information contained in this e-mail message, and any attachment thereto, is confidential and may not be disclosed without our express permission. If you are not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution or copying of this message, or any attachment thereto, in whole or in part, is strictly prohibited. If you have received this message in error, please immediately notify us by telephone, fax or e-mail and delete the message and all of its attachments. Thank you. Every effort is made to keep our network free from viruses. You should, however, check this e-mail message, as well as any attachment thereto, for viruses. We take no responsibility and have no liability for any computer virus which may be transferred via this e-mail message.
Custom dsm.opt in Client v4.1.2
Gentle Greetings, Has anyone yet succeeded in installing a predefined (custom) dsm.opt file with TSM client version 4.1.2? So far all of our attempts have failed... the installer seems to ignore anything I put in the ...\config folder. I have read and tried to follow the instructions in the README that came with 4.1.2, though I have some concern that the path referenced there does not reflect the path to the config folder after extracting the files from the 4.1.2 installer exe. It looks more like the path that was used in previous versions. So I wonder if this process works in this version. Thank you in advance for any help, suggestions, and/or shared experiences. Jennifer
Client v4.1.2 -- Uninstall on NT results in blank desktop?
Gentle Greetings, We've noticed a strange behavior when uninstalling TSM client v4.1.2 on an NT 4.0 Workstation system (SP5). When the Add/Remove Programs process finishes, the desktop goes to a blank grey screen with only the Start menu and Task Bar showing. Right-clicking in the grey area results in a Desktop message as follows: C:\WINNT\Profiles\All Users\Desktop is not accessible. Access is denied. Retry. Cancel. Retry results in the same message. Cancel returns to the blank grey screen. The only way we've found to get out of this is to restart the machine. (Fortunately, the Start menu still works fine, so it's not necessary to be brutal about the restart.) Has anyone else noticed this behavior? Thank you in advance for any help, information, and/or shared experiences. Jennifer
