ADSM-L

Re: [ADSM-L] Updating Windows client on systems with multiple schedules/CIFs shares

2013-01-18 15:36:18
Subject: Re: [ADSM-L] Updating Windows client on systems with multiple schedules/CIFs shares
From: Zoltan Forray <zforray AT VCU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 18 Jan 2013 15:26:02 -0500
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