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:[email protected]] On Behalf Of Zoltan Forray Sent: Friday, January 18, 2013 4:29 PM To: [email protected] 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 <[email protected]> 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 <[email protected]>: > > 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
