Dsmsched log not updating

14-Jul-2016 14:11 by 6 Comments

Dsmsched log not updating - while updating ipod system service exception

-- *Zoltan Forray* TSM Software & Hardware Administrator Virginia Commonwealth University UCC/Office of Technology Services zforray - 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. [quote] Andy Huebner -----Original Message----- From: ADSM: Dist Stor Manager [mailto] On Behalf [/quote]Of Zoltan Forray [quote]Sent: Friday, January 18, 2013 AM To: ADSM-L VM. EDU Subject: [ADSM-L] Updating Windows client on systems with multiple [/quote]schedules/CIFs shares [quote] I have some questions related to maintaining the TSM client on a single [/quote]machine (currently W2K3) that has 32-schedules.

dsmsched log not updating-43

For more details visit file is held open by the scheduler when it is running, so you have to stop the services before upgrading if you want to avoid copying the file in afterwards.The and log files are not overwritten by an upgrade, so I don't think you need to create a new folder specifically for them.It seems like you're making upgrading a lot harder than it really is...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. Create a new folder which holds the dsm.opt, dsmsched and dsmerror log files 2. Copy the **file from the TSM install directory (??????? I know from previous experience when upgrading Windows clients that some times the 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 file, rinse, lather, repeat, thus part of the hesitancy to update/upgrade the client. I have a short batch that installs or upgrades the client. If your Windows admins wish to make it complicated then they should be required to support it.

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? Andy Huebner -----Original Message----- From: ADSM: Dist Stor Manager [mailto] On Behalf Of Zoltan Forray Sent: Friday, January 18, 2013 AM To: ADSM-L VM. 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.

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.

All my services are using binaries in installation directory, configuration files are in own places. 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. Create a new folder which holds the dsm.opt, dsmsched and dsmerror log files 2. Copy the **file from the TSM install directory (??????? I know from previous experience when upgrading Windows clients that some times the 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.

Services are configured to use those configuration files. The admin person says they have to login to each share/account and copy the 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? 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).