Setting up journaling just creates another service. It should be stopped as
well.
But there is still just one set of binaries in the installation directory.
-----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 4:29 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 what I figured.
Out of curiosity, do you use any of the services like OFS or Journaling?
On Fri, Jan 18, 2013 at 3:25 PM, Sami Ahomaa <sami.ahomaa AT gmail DOT com>
wrote:
> I have done it everytime in only one way, all services down, upgrade,
> services up. All my services are using binaries in installation
> directory, configuration files are in own places. Services are
> configured to use those configuration files.
>
>
> Regards,
> Sami
>
> When command line fails, try Google.
>
>
> 2013/1/18 Huebner, Andy <andy.huebner AT alcon DOT com>:
> > 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
|
