All you need is a different dsm.opt file and service for each node.  You only 
need one set of binaries. (dscenu.txt is considered a binary as it is part of 
the program, not a config file) 
The different dsm.opt for each node can put the logs anywhere.

Good luck.

Andy Huebner


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Zoltan Forray
Sent: Friday, January 18, 2013 2:26 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Updating Windows client on systems with multiple 
schedules/CIFs shares

That is my purpose - to simplify.  For some strange reason their procedure says 
to copy the dscenu.txt file to the folder with the dsm.opt and log files.  I am 
trying to prove this is nonsense.

The reason for separate folders for each share is for organization plus 
ownership.  As I said, this one server is used to backup 32-CIFS share for 
32-different departments/units within the university. Separate nodes gives us 
control over what ID can access/restore for each share.

On Fri, Jan 18, 2013 at 3:13 PM, Huebner, Andy <andy.huebner AT alcon DOT 
com>wrote:

> I go with the K.I.S.S. principle.  I have a short batch that installs 
> or upgrades the client.  Requires only the ability to run a batch file.
> If your Windows admins wish to make it complicated then they should be 
> required to support it.
>
> Andy Huebner
>
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
> Of Zoltan Forray
> Sent: Friday, January 18, 2013 11:17 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: [ADSM-L] Updating Windows client on systems with multiple 
> schedules/CIFs shares
>
> I have some questions related to maintaining the TSM client on a 
> single machine (currently W2K3) that has 32-schedules. This machine 
> backs up lots of CIFS shares of SAN storage.
>
> The client is old (6.2.2.0) with numerous issues that are fixed in 
> later releases (can we say major memory leak in the scheduler service 
> - had to reboot the machine when all of the backups started failing).  
> When I talked with the Windows admin about updating the client, they 
> said it is a real pain to do because of the way it is setup.  When 
> they first setup a node,
> they:
>
> 1.  Create a new folder which holds the dsm.opt, dsmsched and dsmerror 
> log files 2.  Create the schedule service entries 3.  Copy the 
> *dscenu.txt *file from the TSM install directory (???????)
>
> The last step confuses me.  I know from previous experience when 
> upgrading Windows clients that some times the dscenu.txt file was 
> either not updated or the upgrade process put it in a new place and 
> the old was left behind and still found by the client, thus causing 
> errors about the message file index.
>
> The admin person says they have to login to each share/account and 
> copy the dscenu.txt file, rinse, lather, repeat,  thus part of the 
> hesitancy to update/upgrade the client.
>
> Any suggestions on how the Windows client in this config can be 
> properly updated without loosing the settings and not having to go 
> back through these machinations?
>
> --
> *Zoltan Forray*
> TSM Software & Hardware Administrator
> Virginia Commonwealth University
> UCC/Office of Technology Services
> zforray AT vcu DOT edu - 804-828-4807
> Don't be a phishing victim - VCU and other reputable organizations 
> will never use email to request that you reply with your password, 
> social security number or confidential personal information. For more 
> details visit http://infosecurity.vcu.edu/phishing.html
>



--
*Zoltan Forray*
TSM Software & Hardware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
zforray AT vcu DOT edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will never 
use email to request that you reply with your password, social security number 
or confidential personal information. For more details visit 
http://infosecurity.vcu.edu/phishing.html