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:[email protected]] On Behalf Of Zoltan Forray Sent: Friday, January 18, 2013 2:26 PM To: [email protected] 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 <[email protected]>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:[email protected]] On Behalf > Of Zoltan Forray > Sent: Friday, January 18, 2013 11:17 AM > To: [email protected] > 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 > [email protected] - 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 [email protected] - 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
